曾經看到一篇不錯的框架解析，對感覺正在從事移動端產品設計的產品同學或許都會對app的框架應該是起到非常好的百科作

“世上沒有完美的設計，因為你最終能做的就是在各種關係之間取得平衡”

——Paul Rand（美國著名設計師）

文章分為五部分

APP技術框架的型別APP技術框架的選擇Hybrid App技術框架的設計特點設計與技術的權衡小結

一、APP技術框架的型別

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

1）Native App：

一種基於智慧移動裝置本地作業系統（如iOS、Android、WP作業系統），並使用對應系統所適用的程式語言編寫執行的第三方應用程式，由於它是直接與作業系統對接，程式碼和介面都是針對所執行的平臺開發和設計的，能很好地發揮出裝置的效能，所以互動體驗會更流暢。

2）Web App：

一種採用Html語言編寫的，存在於智慧移動裝置瀏覽器中的應用程式，不需要下載安裝，可以說是觸屏版的網頁應用，由於它不依賴於作業系統，因此開發了一款Web App後，基本能應用於各種系統平臺。

3）Hybrid App：

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

二、APP技術框架的選擇

Native（原生）

產品特點：偏操作互動多的工具類應用；

開發成本：要為iOS、Android和WP系統各自開發一套App

維護成本：不僅要維護多個系統版本，還要維護多個歷史版本（如有的使用者在5.0版本，有的使用者在4.0版本等）

版本釋出：需要釋出（使用者安裝）最新版App

資源儲存：本地

網路要求：支援離線

開發時間：耗時最長

人員配比：需要iOS、Android和WP各自系統的開發人員

Web

產品特點：偏瀏覽內容為主的新聞、視訊類應用

開發成本：只需開發一套App，即可運用到不同系統平臺

維護成本：只維護最新的版本

版本釋出：不需要釋出（使用者安裝）最新的App

資源儲存：伺服器

網路要求：依賴網路

開發時間：耗時最少

人員配比：會寫網頁語言的開發

Hybrid（混合型）

產品特點：偏既要瀏覽內容，又有較多操作互動的聊天類、購物類應用

開發成本：native部分需要為iOS、android和WP各自配備開發人員，web部分只需統一配置

維護成本：native需要為多最新版本和多個歷史版本，web只需維護最新版本

版本釋出：native部分需要釋出（使用者安裝）最新的App，web部分不需要釋出（使用者安裝）最新的App

資源儲存：本地和伺服器

網路要求：大部分依賴網路

開發時間：耗時中等

人員配比：大部分工作由寫網頁語言的開發承擔，再加上不同系統的開發

三、Hybrid App技術框架的設計特點

由於Hybrid App是融合了Native App和Web App的技術特點，通過分析Hybrid App的技術框架成分，能讓我們更好地掌握App框架的基本開發知識，有助於我們更好地去做設計。

Hybrid App的大部分內容都是在Native框架中載入Web網頁內容，能在保證使用者體驗的前提下，讓App的內容更具有擴充套件性，即使接入再多的內容和業務功 能，也不會使得整個App的安裝包過大，典型Hybrid App的代表就是我們的手機淘寶客戶端。Hybrid App在設計時，要注意以下五個要點：

1.影象渲染

Native技術部分由於能直接呼叫系統的渲染引擎，所以能實現流暢的複雜影象渲染，而不影響裝置的效能。

Web內容部分由於是基於內建瀏覽器，在影象渲染的時候要通過瀏覽器訪問系統的渲染引擎或呼叫基於瀏覽器的第三方渲染引擎，中間需要在多個層級進行渲染請求，所以渲染的時效性和效能會下降不少，導致較複雜的影象渲染或動態渲染時，會出現機器卡頓。

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

2.動效體驗

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

a. 不同的動效型別對CPU效能的消耗不同:對CPU效能要求低的動效型別能執行得更流暢，但如果當你的設計方案是非系統自帶的動效型別時，就需要提前跟開發溝通可行性和對CPU效能的消耗問題。

b. 機型的效能差異：不同的手機機型的CPU效能相差較大，需要了解不同機型在你的App中的佔比，因為即在iPhone6上能完美執行的動效或互動動作，在iPhone6以下的手機上可能就會卡住不動了，所以不太適合用於CPU效能消耗較大的頻繁渲染。

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

3.平臺相容

由於Hybrid App的Web內容，是不同的平臺共用同一套設計方案，所以為了更好地讓設計方案相容不同的平臺特性和手機解析度，所以建議文案和圖形採用以下三種方式：

a. 系統預設字型：如果不是為了設計出特殊的字型樣式，iOS、Android和Windows Phone系統的預設字型是基本滿足我們的需求，同時在不同平臺上的顯示效果也會比較好。

b. SVG（可縮放向量圖形）：能夠自由縮放大小來適應不同螢幕尺寸和解析度，不會模糊變形。

c. Iconfont來代替圖示：能夠自由變換大小和顏色。

4.互動行為

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

如圖所示，如果“每日贏寶箱”的頁面是純Native框架搭建的，則當用戶點選“參與互動拿紅包”的卡片後，下一個頁面會採用iOS系統預設的自右向左切入的互動方式。

然而，由於這裡採用的是Hybirid App技術框架，所以會像網頁一樣，直接變換內容區的資訊，因為這樣的實現方式更高效和不影響效能，更重要的是如果該頁面採用直接變換內容的方式不會影響到使用者的使用體驗，這裡就可以考慮不需要跟系統互動保持一致。

5.載入方式

對於Hybrid App框架的頁面，由於同時存在Native和Web部分，所以在載入內容時，可以分開考慮載入方式：

A. Native部分：可以根據需要把常規內容儲存在使用者的手機上，加快載入的時間和減少重複載入相同內容的麻煩。

B. Web部分：Web內容區域是需要從網路上載入內容的，尤其在網路條件不好時，需要設計友好的等待狀態，緩和使用者的焦慮情緒。

如圖所示，可以根據不同的框架，來設計不同的載入方式，讓等待過程更短或更愉悅。

四、設計與技術的權衡

1.明確設計方案的主流程

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

例如在設計手機淘寶店鋪的標籤模組時，由於大部分商家會根據寶貝圖的特點，來設定圖上標籤的內容和位置，可是，由於店鋪的技術框架不支援 標籤移動的功能，而我們的設計目標和方案的主流程就是要為商家提供更靈活設定寶貝標籤的功能，所以即使技術實現難度和成本較高，我們也推動技術進行突破， 實現標籤的可移動功能。

2.提前與開發溝通設計想法的可行性

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

五、小結

在專案中，設計師往往需要權衡商業目標、使用者體驗和技術實現三者之間的關係來做設計方案，以上只是介紹App技術框架的基本知識，讓設計師在做方案 時更有把握，但由於技術日新月異，每天都在進步中，所以在實踐中需要根據專案的不同階段與開發工程師保持緊密的溝通，來讓設計方案更靠譜。