App技術框架

1、App技術框架的類型

 

圖1 三種App技術框架之間的關係

目前App的技術框架基本分爲三種（圖1）：

（1）Native App：互動型，iOS、Android、WP各一套，並且要維護歷史版本，要安裝，開發耗時長

一種基於智能移動設備本地操做系統（如iOS、Android、WP操做系統），並使用對應系統所適用的程序語言編寫運行的第三方應用程序，因爲它是直接與操做系統對接，代碼和界面都是針對所運行的平臺開發和設計的，能很好地發揮出設備的性能，因此交互體驗會更流暢。

（2）Web App：瀏覽型，只一套，只維護最新版本，不用安裝，開發耗時短

一種採用Html語言編寫的，存在於智能移動設備瀏覽器中的應用程序，不須要下載安裝，能夠說是觸屏版的網頁應用，因爲它不依賴於操做系統，所以開發了一款Web App後，基本能應用於各類系統平臺。

（3）Hybrid App：瀏覽互動兼顧型，native部分各一套，維護歷史版本；web部分1套，維護最新版，開發耗時適中

一種用Native技術來搭建App的外殼，殼裏的內容由Web技術來提供的移動應用，兼具「Native App良好交互體驗的優點」和「Web App跨平臺開發的優點」。

2、App技術框架的選擇

對於設計師而言，咱們每每是被告知這個項目採用的是哪一種技術框架，而後就開始設計了，其實，咱們也能夠根據產品特色、框架特色和項目時間（圖2）來與產品和開發同窗協商，合理地爲App中不一樣的部分選擇對應技術框架，而後纔在對應的技術框架下思考設計方案。

 

圖2 產品特色、框架特色和項目時間的考慮

3、Hybrid App技術框架的設計特色

因爲Hybrid App是融合了Native App和Web App的技術特色，經過分析Hybrid App的技術框架成分，能讓咱們更好地掌握App框架的基本開發知識，有助於咱們更好地去作設計。

Hybrid App的大部份內容都是在Native框架中加載Web網頁內容，能在保證用戶體驗的前提下，讓App的內容更具備擴展性，即便接入再多的內容和業務功能，也不會使得整個App的安裝包過大，典型Hybrid App的表明就是咱們的手機淘寶客戶端。Hybrid App在設計時，要注意如下五個要點（圖3）。

 

圖3 Hybrid App的五個設計要點

（1）圖像渲染

Native技術部分因爲能直接調用系統的渲染引擎，因此能實現流暢的複雜圖像渲染，而不影響設備的性能。

Web內容部分因爲是基於內置瀏覽器，在圖像渲染的時候要經過瀏覽器訪問系統的渲染引擎或調用基於瀏覽器的第三方渲染引擎，中間須要在多個層級進行渲染請求，因此渲染的時效性和性能會降低很多，致使較複雜的圖像渲染或動態渲染時，會出現機器卡頓。

如圖4所示，因爲標題欄採用了Native技術框架，可採用複雜的毛玻璃效果，讓標題欄更通透，而內容區採用了基於Html5的Web技術，所以不適合動態變換背景圖的渲染方案（當圖片輪播時，背景圖會隨着圖片內容而動態變換出模糊的背景）。

 

圖4 動態的圖像渲染

（2）動效體驗

因爲Hybrid App的內容區大部分採用基於Html5的Web技術，對動效的解釋和操做須要消耗大量的CPU性能，在設計時，要注意如下三個方面：

a. 不一樣的動效類型對CPU性能的消耗不一樣（圖5）:對CPU性能要求低的動效類型能運行得更流暢，但若是當你的設計方案是非系統自帶的動效類型時（圖6），就須要提早跟開發溝通可行性和對CPU性能的消耗問題。

b. 機型的性能差別：不一樣的手機機型的CPU性能相差較大，須要瞭解不一樣機型在你的App中的佔比（圖7），由於即在iPhone6上能完美運行的動效或交互動做，在iPhone6如下的手機上可能就會卡住不動了，因此不太適合用於CPU性能消耗較大的頻繁渲染。

c. 網絡的影響：若是你的動效在運動時，還須要加載內容，就要考慮網絡較慢時，內容加載對動效流暢度的影響，這時可考慮先加載完內容，再開始動效或簡化、壓縮加載的內容量。

 

圖5 不一樣的動效類型對CPU的性能要求

 

圖6 液化翻轉的動效

 

圖7 不一樣機型的市場佔比

如圖8所示，在Web內容區，當點擊圖片後，該圖片放大（系統默認的縮放動效，對CPU性能消耗小），但其它圖片自動從新排列的動效會比較消耗CPU性能，在低端機器上會出現卡頓或閃退的狀況，而且還會受到網速的影響，致使體驗不友好，若是必須作複雜動效，可讓該動效只出如今高端機型中。

 

圖8 圖片縮放的從新排列動效

（3）平臺兼容

因爲Hybrid App的Web內容，是不一樣的平臺共用同一套設計方案，因此爲了更好地讓設計方案兼容不一樣的平臺特性和手機分辨率，因此建議文案和圖形採用如下三種方式：

a. 系統默認字體：若是不是爲了設計出特殊的字體樣式，iOS、Android和Windows Phone系統的默認字體（圖9）是基本知足咱們的需求，同時在不一樣平臺上的顯示效果也會比較好。

 

圖9 系統默認字體

b. SVG（可縮放矢量圖形）：可以自由縮放大小來適應不一樣屏幕尺寸和分辨率，不會模糊變形（圖10）。

 

圖10 SVG（可縮放矢量圖形）

c. Iconfont來代替圖標：可以自由變換大小和顏色（圖11）。

 

圖11 Iconfont圖標

採用這三種方式不只能夠很好適配不一樣機型和屏幕尺寸，並且還不會增長安裝包的大小。

如圖12所示，若是按鈕上的「鬧鐘和提醒我」採用的不是Iconfont和系統默認字體，則在不一樣尺寸的屏幕上的顯示效果會很難控制，有被拉伸變形或模糊的風險。

 

圖12 圖標和字體在不一樣尺寸屏幕上的顯示效果

（4）交互行爲

因爲Hybrid App主要是經過網頁的CSS樣式結構和JavaScript程序語言來還原界面的設計和交互行爲，因此跟純Native App技術框架相比，須要經過更繁瑣的代碼和層級請求才能實現跟原生系統同樣的交互方式，雖然也可模擬Native App的交互方式，但這樣的模擬首先提升了開發成本，有悖於不影響性能和高效的原則，因此須要根據設計目標來合理選擇是否須要跟系統交互保持一致。

如圖13-a所示，若是「每日贏寶箱」的頁面是純Native框架搭建的，則當用戶點擊「參與互動拿紅包」的卡片後，下一個頁面會採用iOS系統默認的自右向左切入的交互方式。

 

圖13-a 系統默認的交互方式

然而，因爲這裏採用的是Hybirid App技術框架，因此會像網頁同樣，直接變換內容區的信息（圖13-b），由於這樣的實現方式更高效和不影響性能，更重要的是若是該頁面採用直接變換內容的方式不會影響到用戶的使用體驗，這裏就能夠考慮不須要跟系統交互保持一致。

 

圖13-b 直接變換內容區的交互方式

（5）加載方式

對於Hybrid App框架的頁面，因爲同時存在Native和Web部分，因此在加載內容時，能夠分開考慮加載方式：

• A. Native部分：能夠根據須要把常規內容存儲在用戶的手機上，加快加載的時間和減小重複加載相同內容的麻煩。
• B. Web部分：Web內容區域是須要從網絡上加載內容的，尤爲在網絡條件很差時，須要設計友好的等待狀態，緩和用戶的焦慮情緒。

如圖14所示，能夠根據不一樣的框架，來設計不一樣的加載方式，讓等待過程更短或更愉悅。

 

圖14 根據技術框架來設計加載方式

4、設計與技術的權衡

（1）明確設計方案的主流程

在技術面前，設計是否只能妥協呢？答案是否認的，在對應的App技術框架下，咱們在考慮設計方案時，要明確設計方案的主流程和支流程（圖15），凡是會影響到方案核心的主流程的方案，即便開發的實現難度和成本較高，咱們也要持續推進技術的突破，來爲用戶提供更好的使用體驗，而對於方案的支流程，咱們就能夠跟開發協商不一樣的解決方案，明確哪些地方能夠調整技術實現方式或換一種設計方案，哪些方案存在風險，須要有備選方案。

 

圖15 設計方案的主流程和支流程

如圖16所示，在設計手機淘寶店鋪的標籤模塊時，因爲大部分商家會根據寶貝圖的特色，來設置圖上標籤的內容和位置，但是，因爲店鋪的技術框架不支持標籤移動的功能，而咱們的設計目標和方案的主流程就是要爲商家提供更靈活設置寶貝標籤的功能，因此即便技術實現難度和成本較高，咱們也推進技術進行突破，實現標籤的可移動功能。

 

圖16 店鋪的標籤模塊

（2）提早與開發溝通設計想法的可行性

咱們分析完產品需求後，能夠先簡單地在紙上畫出粗獷的交互原型，而後，跟開發溝通想法的可行性及實現難度，作到心中有數。若是方案中涉及動效設計，可經過紙片來錄製粗略的動效，或拿出本身平時收集的動效素材（圖17）與開發溝通可行性，來快速驗證設計想法。

 

圖17 動效素材

5、設計小結

「世上沒有完美的設計，由於你最終能作的就是在各類關係之間取得平衡」   ——Paul Rand（美國著名設計師）

在項目中，設計師每每須要權衡商業目標、用戶體驗和技術實現三者之間的關係來作設計方案，以上只是介紹App技術框架的基本知識，讓設計師在作方案時更有把握，但因爲技術突飛猛進，天天都在進步中，因此在實踐中須要根據項目的不一樣階段與開發工程師保持緊密的溝通，來讓設計方案更靠譜。