整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
要：本文主要面對產品小白講一些常見的移動端應用通常采用的技術框架，同時對當前的移動開發(fā)前沿進行解讀。部分內容來源于網絡，侵刪。
溫馨提示：全文共4398字，閱讀大約需要8分鐘。
三種主流App技術框架之間的關系
目前App的技術框架基本分為三種（上圖）：
1、Native App
Native App（也叫原生App）是一種基于智能手機本地操作系統(tǒng)如iOS、Android、WP并使用原生程式編寫運行的第三方應用程序，也叫本地app。一般使用的開發(fā)語言為JAVA、C++、Objective-C。Native App使用對應系統(tǒng)所適用的程序語言編寫運行的第三方應用程序，由于它是直接與操作系統(tǒng)對接，代碼和界面都是針對所運行的平臺開發(fā)和設計的，能很好地發(fā)揮出設備的性能，所以交互體驗會更流暢。
話題：在哪里采用原生App？
☆ 原生應用場景：
在頭部以上的應用（剛需成熟型產品），例如吃飯、閱讀、瀏覽、通信，通過App的方式來解決是比較有效率的。例如吃飯這樣高頻次的領域，用戶是可以養(yǎng)活這樣一個原生App的。比如常見的美團外賣、餓了么、百度外賣等等的主要欄目模塊均采用基于本地系統(tǒng)的原生App。
在洗腳、拍結婚照、修車這樣的低頻次使用的領域，使用App就缺乏效率了。
重度應用更加適合App來解決，例如手機游戲。而輕度應用更加適合Web，例如看新聞。
Web應用的推廣成本要遠遠小于App。有朋友做過統(tǒng)計，點擊移動廣告到HTML5游戲的轉化率是App游戲的40倍。
☆ 原生制約瓶頸：
單個用戶的獲取成本越來越高。相信大家都有同感，無論是iOS還是Android，不管是推薦位，還是iAD、ADmob或者別的，價格都在扶搖直上。
來自官方渠道的site to APP轉化率降低。這就像是伐木，剛開始轉化率會很高，慢慢的官方渠道用戶會榨干到一個瓶頸期。
刷榜泛濫，無序競爭。競爭對手砸錢刷榜，你到底要不要跟？
2、Web App
Web App是指基于Web的系統(tǒng)和應用，其作用是向廣大的最終用戶發(fā)布一組復雜的內容和功能。從一個簡單的幫助消費者計算汽車租借費用的網頁，到為商業(yè)人員和度假者提供全套旅游服務的大型復雜的WEB站點，都是WebApp。它包括一些完整的WEB站點，WEB站點的專門功能以及在Internet、Intranet或ExtraNet上的信息處理應用。
Web App采用Html語言編寫的，存在于智能移動設備瀏覽器中的應用程序，不需要下載安裝，可以說是觸屏版的網頁應用，由于它不依賴于操作系統(tǒng)，因此開發(fā)了一款Web App后，基本能應用于各種系統(tǒng)平臺。
3、Hybrid App
一種用Native技術來搭建App的外殼，殼里的內容由Web技術來提供的移動應用，兼具“Native App良好交互體驗的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”。本文后半部分會對Hybrid App進行著重講解。
產品特點、框架特點和項目時間的考慮
對于設計師而言，我們往往是被告知這個項目采用的是哪種技術框架，然后就開始設計了，其實，我們也可以根據(jù)產品特點、框架特點和項目時間（圖2）來與產品和開發(fā)同學協(xié)商，合理地為App中不同的部分選擇對應技術框架，然后才在對應的技術框架下思考設計方案。
由于Hybrid App是融合了Native App和Web App的技術特點，通過分析Hybrid App的技術框架成分，能讓我們更好地掌握App框架的基本開發(fā)知識，有助于我們更好地去做設計。
Hybrid App的大部分內容都是在Native框架中加載Web網頁內容，能在保證用戶體驗的前提下，讓App的內容更具有擴展性，即使接入再多的內容和業(yè)務功能，也不會使得整個App的安裝包過大，典型Hybrid App的代表就是我們的手機淘寶客戶端。Hybrid App在設計時，要注意以下五個要點（下圖）。
Hybrid App的五個設計要點
1、圖像渲染
Native技術部分由于能直接調用系統(tǒng)的渲染引擎，所以能實現(xiàn)流暢的復雜圖像渲染，而不影響設備的性能。
Web內容部分由于是基于內置瀏覽器，在圖像渲染的時候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調用基于瀏覽器的第三方渲染引擎，中間需要在多個層級進行渲染請求，所以渲染的時效性和性能會下降不少，導致較復雜的圖像渲染或動態(tài)渲染時，會出現(xiàn)機器卡頓。
如下圖所示，由于標題欄采用了Native技術框架，可采用復雜的毛玻璃效果，讓標題欄更通透，而內容區(qū)采用了基于Html5的Web技術，因此不適合動態(tài)變換背景圖的渲染方案（當圖片輪播時，背景圖會隨著圖片內容而動態(tài)變換出模糊的背景）。
動態(tài)的圖像渲染
2、動效體驗
由于Hybrid App的內容區(qū)大部分采用基于Html5的Web技術，對動效的解釋和操作需要消耗大量的CPU性能，在設計時，要注意以下三個方面：
不同的動效類型對CPU性能的消耗不同（下圖）:對CPU性能要求低的動效類型能運行得更流暢，但如果當你的設計方案是非系統(tǒng)自帶的動效類型時（下圖），就需要提前跟開發(fā)溝通可行性和對CPU性能的消耗問題。
不同的動效類型對CPU的性能要求
不同的動效類型對CPU的性能要求
液化翻轉的動效
機型的性能差異：不同的手機機型的CPU性能相差較大，需要了解不同機型在你的App中的占比（下圖），因為即在iPhone6上能完美運行的動效或交互動作，在iPhone6以下的手機上可能就會卡住不動了，所以不太適合用于CPU性能消耗較大的頻繁渲染。
不同機型的市場占比（15-16年數(shù)據(jù)）
網絡的影響：如果你的動效在運動時，還需要加載內容，就要考慮網絡較慢時，內容加載對動效流暢度的影響，這時可考慮先加載完內容，再開始動效或簡化、壓縮加載的內容量。如下圖所示，在Web內容區(qū)，當點擊圖片后，該圖片放大（系統(tǒng)默認的縮放動效，對CPU性能消耗小），但其它圖片自動重新排列的動效會比較消耗CPU性能，在低端機器上會出現(xiàn)卡頓或閃退的情況，并且還會受到網速的影響，導致體驗不友好，如果必須做復雜動效，可以讓該動效只出現(xiàn)在高端機型中。
圖片縮放的重新排列動效
3、平臺兼容
由于Hybrid App的Web內容，是不同的平臺共用同一套設計方案，所以為了更好地讓設計方案兼容不同的平臺特性和手機分辨率，所以建議文案和圖形采用以下三種方式：
系統(tǒng)默認字體：如果不是為了設計出特殊的字體樣式，iOS、Android和Windows Phone系統(tǒng)的默認字體（圖9）是基本滿足我們的需求，同時在不同平臺上的顯示效果也會比較好。
系統(tǒng)默認字體
可縮放矢量圖形：能夠自由縮放大小來適應不同屏幕尺寸和分辨率，不會模糊變形：
SVG（可縮放矢量圖形）
Iconfont來代替圖標：能夠自由變換大小和顏色：
Iconfont圖標
采用這三種方式不僅可以很好適配不同機型和屏幕尺寸，而且還不會增加安裝包的大小。如果按鈕上的“精選尖貨放心購”采用的不是Iconfont和系統(tǒng)默認字體，則在不同尺寸的屏幕上的顯示效果會很難控制，有被拉伸變形或模糊的風險。
圖標和字體在不同尺寸屏幕上的顯示效果
4、交互行為
由于Hybrid App主要是通過網頁的CSS樣式結構和JavaScript程序語言來還原界面的設計和交互行為，所以跟純Native App技術框架相比，需要通過更繁瑣的代碼和層級請求才能實現(xiàn)跟原生系統(tǒng)一樣的交互方式，雖然也可模擬Native App的交互方式，但這樣的模擬首先提高了開發(fā)成本，有悖于不影響性能和高效的原則，所以需要根據(jù)設計目標來合理選擇是否需要跟系統(tǒng)交互保持一致。
如下圖所示，如果“每日贏寶箱”的頁面是純Native框架搭建的，則當用戶點擊“參與互動拿紅包”的卡片后，下一個頁面會采用iOS系統(tǒng)默認的自右向左切入的交互方式。
系統(tǒng)默認的交互方式
然而，由于這里采用的是Hybirid App技術框架，所以會像網頁一樣，直接變換內容區(qū)的信息（下圖），因為這樣的實現(xiàn)方式更高效和不影響性能，更重要的是如果該頁面采用直接變換內容的方式不會影響到用戶的使用體驗，這里就可以考慮不需要跟系統(tǒng)交互保持一致。
直接變換內容區(qū)的交互方式
5、加載方式
對于Hybrid App框架的頁面，由于同時存在Native和Web部分，所以在加載內容時，可以分開考慮加載方式：
Native部分：可以根據(jù)需要把常規(guī)內容存儲在用戶的手機上，加快加載的時間和減少重復加載相同內容的麻煩。
Web部分：Web內容區(qū)域是需要從網絡上加載內容的，尤其在網絡條件不好時，需要設計友好的等待狀態(tài)，緩和用戶的焦慮情緒。
如下圖所示，可以根據(jù)不同的框架，來設計不同的加載方式，讓等待過程更短或更愉悅。
根據(jù)技術框架來設計加載方式
1、明確設計方案的主流程
在技術面前，設計是否只能妥協(xié)呢？答案是否定的，在對應的App技術框架下，我們在考慮設計方案時，要明確設計方案的主流程和支流程，凡是會影響到方案核心的主流程的方案，即使開發(fā)的實現(xiàn)難度和成本較高，我們也要持續(xù)推動技術的突破，來為用戶提供更好的使用體驗，而對于方案的支流程，我們就可以跟開發(fā)協(xié)商不同的解決方案，明確哪些地方可以調整技術實現(xiàn)方式或換一種設計方案，哪些方案存在風險，需要有備選方案。
設計方案的主流程和支流程
如下圖所示，在設計手機淘寶店鋪的標簽模塊時，由于大部分商家會根據(jù)寶貝圖的特點，來設置圖上標簽的內容和位置，可是，由于店鋪的技術框架不支持標簽移動的功能，而我們的設計目標和方案的主流程就是要為商家提供更靈活設置寶貝標簽的功能，所以即使技術實現(xiàn)難度和成本較高，我們也推動技術進行突破，實現(xiàn)標簽的可移動功能。
店鋪的標簽模塊（上圖的浮動標簽）
2、提前與開發(fā)溝通設計想法的可行性
我們分析完產品需求后，可以先簡單地在紙上畫出粗獷的交互原型，然后，跟開發(fā)溝通想法的可行性及實現(xiàn)難度，做到心中有數(shù)。如果方案中涉及動效設計，可通過紙片來錄制粗略的動效，或拿出自己平時收集的動效素材與開發(fā)溝通可行性，來快速驗證設計想法。
常見典型動效素材
“世上沒有完美的設計，因為你最終能做的就是在各種關系之間取得平衡”
在項目中，設計師往往需要權衡商業(yè)目標、用戶體驗和技術實現(xiàn)三者之間的關系來做設計方案，以上只是介紹App技術框架的基本知識，讓產品經理在做方案時更有把握。
在純原生之外，前有ReactNative,Weex的混合開發(fā)方案，可以快速開發(fā)APP，后有微信小程序等的移動端替代方案，技術上的分流代表著原生開發(fā)者的市場被剝削。但總體上來看，匹配公司發(fā)展前景的App端的開發(fā)技術才是好技術。
UI設計的朋友肯定都有所感受，當你滿懷激動的拿著方案去給開發(fā)程序猿講解的天花亂墜時，開發(fā)程序猿就會突然蹦出來一句話“這個方案實現(xiàn)不了”，然后此時的你話未落身先死，瞬間就整個人就不好了！那么，又有什么用呢？接下來的日子可想而知就是在產品經理和開發(fā)程序猿的不斷催促下進行著無數(shù)的加班和改方案。
那有些朋友就會非常的不理解，問題到底出現(xiàn)在哪兒呢？這其實就是設計師對于APP技術框架知識的匱乏，雖然不用寫代碼，但掌握基本的app技術框架原理，能更加有效的幫助我們預判哪些方案行之有效。所以今天，各位看官跟著大狗共同了解一下APP的技術框架都有哪些吧。
三種技術框架之間的關系
● Native App：一種基于智能移動設備本地操作系統(tǒng)（如iOS、Android、WP操作系統(tǒng)），并使用對應系統(tǒng)所適用的程序語言編寫運行的第三方應用程序，由于它是直接與操作系統(tǒng)對接，代碼和界面都是針對所運行的平臺開發(fā)和設計的，能很好地發(fā)揮出設備的性能，所以交互體驗會更流暢。
● Web App：一種采用Html語言編寫的，存在于智能移動設備瀏覽器中的應用程序，不需要下載安裝，可以說是觸屏版的網頁應用，由于它不依賴于操作系統(tǒng)，因此開發(fā)了一款Web App后，基本能應用于各種系統(tǒng)平臺。
● Hybrid App：一種用Native技術來搭建App的外殼，殼里的內容由Web技術來提供的移動應用，兼具“Native App良好交互體驗的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”。
對于設計師而言，我們往往是被告知這個項目采用的是哪種技術框架，然后就開始設計了，其實，我們也可以根據(jù)產品特點、框架特點和項目時間來與產品和開發(fā)部門協(xié)商，合理地為App中不同的部分選擇對應技術框架，然后再在對應的技術框架下思考設計方案。
由于Hybrid APP是融合了Native APP的技術特點，通過分析Hybrid APP的技術框架成分，能讓我們更好的掌握APP框架的基本開發(fā)知識，有助于我們更好的去做設計。
Hybrid APP的大部分內容都是在Native框架中加載Web網頁內容，能在保證用戶體驗的前提下，讓APP的內容更具有廣闊性，即使接入再多的內容和業(yè)務功能，也不造成整個APP的安裝包過大。典型Hybrid APP的代表就是我們的手機淘寶客戶端，Hybrid APP在設計時，要注意以下五個要點：
● 圖像渲染
Native技術部分由于能直接調用系統(tǒng)的渲染引擎，所以能實現(xiàn)流暢的復雜圖像渲染，而不影響設備的性能。
Web內容部分由于是基于內置瀏覽器，在圖像渲染的時候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調用基于瀏覽器的第三方渲染引擎，中間需要在多個層級進行渲染請求，所以渲染的時效性和性能會下降不少，導致較復雜的圖像渲染或動態(tài)渲染時，會出現(xiàn)機器卡頓。
如圖所示，由于標題欄采用了Native技術框架，可采用復雜的毛玻璃效果，讓標題欄更通透，而內容區(qū)采用了基于Html5的Web技術，因此不適合動態(tài)變換背景圖的渲染方案（當圖片輪播時，背景圖會隨著圖片內容而動態(tài)變換出模糊的背景）。
● 動效體驗
由于Hybrid App的內容區(qū)大部分采用基于Html5的Web技術，對動效的解釋和操作需要消耗大量的CPU性能，在設計時，要注意以下三個方面：
1.不同的動效類型對CPU性能的消耗不同：對CPU性能要求低的動效類型能運行得更流暢，但如果當你的設計方案是非系統(tǒng)自帶的動效類型時，就需要提前跟開發(fā)溝通可行性和對CPU性能的消耗問題。
2.機型的性能差異：不同的手機機型的CPU性能相差較大，需要了解不同機型在你的App中的占比，因為即在iPhone6上能完美運行的動效或交互動作，在iPhone6以下的手機上可能就會卡住不動了，所以不太適合用于CPU性能消耗較大的頻繁渲染。
3.網絡的影響：如果你的動效在運動時，還需要加載內容，就要考慮網絡較慢時，內容加載對動效流暢度的影響，這時可考慮先加載完內容，再開始動效或簡化、壓縮加載的內容量。
不同的動效類型對CPU的性能要求
如下圖所示，在Web內容區(qū)，當點擊圖片后，該圖片放大（系統(tǒng)默認的縮放動效，對CPU性能消耗小），但其它圖片自動重新排列的動效會比較消耗CPU性能，在低端機器上會出現(xiàn)卡頓或閃退的情況，并且還會受到網速的影響，導致體驗不友好，如果必須做復雜動效，可以讓該動效只出現(xiàn)在高端機型中。
● 平臺兼容
由于Hybrid APP的WEB內容，是不同的平臺公用同一套設計方案，所以為了更好的讓設計方案兼容不同平臺的手機特性和手機分辨率，所以建議文案和圖形采用以下三種方式：
1.系統(tǒng)默認字體：如果不是為了設計出特殊的字體樣式，iOS、Android和Windows Phone系統(tǒng)的默認字體可以基本滿足我們的需求，同時在不同平臺上的顯示效果也會比較好。
2. SVG（可縮放矢量圖形）：能夠自由縮放大小來適應不同屏幕尺寸和分辨率，不會模糊變形。
3. Iconfont來代替圖標：能夠自由變換大小和顏色。
● 交互行為
由于Hybrid App主要是通過網頁的CSS樣式結構和JavaScript程序語言來還原界面的設計和交互行為，所以跟純Native App技術框架相比，需要通過更繁瑣的代碼和層級請求才能實現(xiàn)跟原生系統(tǒng)一樣的交互方式，雖然也可模擬Native App的交互方式，但這樣的模擬首先提高了開發(fā)成本，有悖于不影響性能和高效的原則，所以需要根據(jù)設計目標來合理選擇是否需要跟系統(tǒng)交互保持一致。
● 加載方式
對于Hybrid App框架的頁面，由于同時存在Native和Web部分，所以在加載內容時，可以分開考慮加載方式：
Native部分：可以根據(jù)需要把常規(guī)內容存儲在用戶的手機上，加快加載的時間和減少重復加載相同內容的麻煩。
Web部分：Web內容區(qū)域是需要從網絡上加載內容的，尤其在網絡條件不好時，需要設計友好的等待狀態(tài)，緩和用戶的焦慮情緒。
● 明確設計方案的主流程
在技術面前，設計是否只能妥協(xié)呢？答案是否定的，在對應的APP技術框架下，要明確設計方案的主流程和分支流程，凡是會影響到核心的主流程方案，即使開發(fā)難度和成本較高，我們也要持續(xù)推動技術的突破，為用戶提供更好的使用體驗，而對于方案的分支流程，則可以跟開發(fā)協(xié)商不同的解決方案，明確哪些地方可以調整技術實現(xiàn)方式或者換一種設計方案，哪些方案存在風險，需要有備選方案。
● 提前與開發(fā)溝通設計想法的可行性
我們分析完產品需求后，可以先簡單地在紙上畫出粗獷的交互原型，然后，跟開發(fā)溝通想法的可行性及實現(xiàn)難度，做到心中有數(shù)。如果方案中涉及動效設計，可通過紙片來錄制粗略的動效，或拿出自己平時收集的動效素材與開發(fā)溝通可行性，來快速驗證設計想法。
“世界上沒有完美的設計，因為你最終能做的就是在各種關系之間取得平衡”--Paul Rand（美國著名設計師）
注本頭條號，專注做前端
今天要來分享的是一款原生JS插件 （因為有粉絲提到要多分享一些原生JS） ，所以今天分享的這塊不依賴jquery，原生JS ，采用html5+canvas實現(xiàn)
它模擬了霧氣在玻璃上凝結，玻璃模糊，并且水滴慢慢滑落的效果，及其逼真
//
*請認真填寫需求信息，我們會在24小時內與您取得聯(lián)系。
