React的(de)移動端和(hé)PC端生态圈的(de)使用(yòng)彙總

1. APP技術框架的(de)類型

2. APP技術框架的(de)選擇

3. Hybrid App技術框架的(de)設計特點

4. 設計與技術的(de)權衡

5. 小結

一、APP技術框架的(de)類型

 
三種App技術框架之間的(de)關系 

1）Native App：

一種基于智能移動設備本地操作系統（如iOS、Android、WP操作系統），并使用(yòng)對(duì)應系統所适用(yòng)的(de)程序語言編寫運行的(de)第三方應用(yòng)程序，由于它是直接與操作系統對(duì)接，代碼和(hé)界面都是針對(duì)所運行的(de)平台開發和(hé)設計的(de)，能很好地發揮出設備的(de)性能，所以交互體驗會更流暢。

2）Web App：

一種采用(yòng)Html語言編寫的(de)，存在于智能移動設備浏覽器中的(de)應用(yòng)程序，不需要下(xià)載安裝，可(kě)以說是觸屏版的(de)網頁應用(yòng)，由于它不依賴于操作系統，因此開發了(le)一款Web App後，基本能應用(yòng)于各種系統平台。

3）Hybrid App：

一種用(yòng)Native技術來(lái)搭建App的(de)外殼，殼裏的(de)内容由Web技術來(lái)提供的(de)移動應用(yòng)，兼具“Native App良好交互體驗的(de)優勢”和(hé)“Web App跨平台開發的(de)優勢”。

二、APP技術框架的(de)選擇

Native（原生）

産品特點：偏操作互動多(duō)的(de)工具類應用(yòng)；

開發成本：要爲iOS、Android和(hé)WP系統各自開發一套App

維護成本：不僅要維護多(duō)個(gè)系統版本，還(hái)要維護多(duō)個(gè)曆史版本（如有的(de)用(yòng)戶在5.0版本，有的(de)用(yòng)戶在4.0版本等）

版本發布：需要發布（用(yòng)戶安裝）最新版App

資源存儲：本地

網絡要求：支持離線

開發時(shí)間：耗時(shí)最長(cháng)

人(rén)員(yuán)配比：需要iOS、Android和(hé)WP各自系統的(de)開發人(rén)員(yuán)

Web

産品特點：偏浏覽内容爲主的(de)新聞、視頻(pín)類應用(yòng)

開發成本：隻需開發一套App，即可(kě)運用(yòng)到不同系統平台

維護成本：隻維護最新的(de)版本

版本發布：不需要發布（用(yòng)戶安裝）最新的(de)App

資源存儲：服務器

網絡要求：依賴網絡

開發時(shí)間：耗時(shí)最少

人(rén)員(yuán)配比：會寫網頁語言的(de)開發

Hybrid（混合型）

産品特點：偏既要浏覽内容，又有較多(duō)操作互動的(de)聊天類、購(gòu)物(wù)類應用(yòng)

開發成本：native部分(fēn)需要爲iOS、android和(hé)WP各自配備開發人(rén)員(yuán)，web部分(fēn)隻需統一配置

維護成本：native需要爲多(duō)最新版本和(hé)多(duō)個(gè)曆史版本，web隻需維護最新版本

版本發布：native部分(fēn)需要發布（用(yòng)戶安裝）最新的(de)App，web部分(fēn)不需要發布（用(yòng)戶安裝）最新的(de)App

資源存儲：本地和(hé)服務器

網絡要求：大(dà)部分(fēn)依賴網絡

開發時(shí)間：耗時(shí)中等

人(rén)員(yuán)配比：大(dà)部分(fēn)工作由寫網頁語言的(de)開發承擔，再加上不同系統的(de)開發

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

由于Hybrid App是融合了(le)Native App和(hé)Web App的(de)技術特點，通(tōng)過分(fēn)析Hybrid App的(de)技術框架成分(fēn)，能讓我們更好地掌握App框架的(de)基本開發知識，有助于我們更好地去做(zuò)設計。

Hybrid App的(de)大(dà)部分(fēn)内容都是在Native框架中加載Web網頁内容，能在保證用(yòng)戶體驗的(de)前提下(xià)，讓App的(de)内容更具有擴展性，即使接入再多(duō)的(de)内容和(hé)業務功 能，也(yě)不會使得(de)整個(gè)App的(de)安裝包過大(dà)，典型Hybrid App的(de)代表就是我們的(de)手機淘寶客戶端。Hybrid App在設計時(shí)，要注意以下(xià)五個(gè)要點：

1.圖像渲染

Native技術部分(fēn)由于能直接調用(yòng)系統的(de)渲染引擎，所以能實現流暢的(de)複雜(zá)圖像渲染，而不影(yǐng)響設備的(de)性能。

Web内容部分(fēn)由于是基于内置浏覽器，在圖像渲染的(de)時(shí)候要通(tōng)過浏覽器訪問系統的(de)渲染引擎或調用(yòng)基于浏覽器的(de)第三方渲染引擎，中間需要在多(duō)個(gè)層級進行渲染請求，所以渲染的(de)時(shí)效性和(hé)性能會下(xià)降不少，導緻較複雜(zá)的(de)圖像渲染或動态渲染時(shí)，會出現機器卡頓。

如圖所示，由于标題欄采用(yòng)了(le)Native技術框架，可(kě)采用(yòng)複雜(zá)的(de)毛玻璃效果，讓标題欄更通(tōng)透，而内容區(qū)采用(yòng)了(le)基于Html5的(de)Web技術，因此不适合動态變換背景圖的(de)渲染方案（當圖片輪播時(shí)，背景圖會随著(zhe)圖片内容而動态變換出模糊的(de)背景）。

2.動效體驗

由于Hybrid App的(de)内容區(qū)大(dà)部分(fēn)采用(yòng)基于Html5的(de)Web技術，對(duì)動效的(de)解釋和(hé)操作需要消耗大(dà)量的(de)CPU性能，在設計時(shí)，要注意以下(xià)三個(gè)方面：

a. 不同的(de)動效類型對(duì)CPU性能的(de)消耗不同:對(duì)CPU性能要求低的(de)動效類型能運行得(de)更流暢，但如果當你的(de)設計方案是非系統自帶的(de)動效類型時(shí)，就需要提前跟開發溝通(tōng)可(kě)行性和(hé)對(duì)CPU性能的(de)消耗問題。

b. 機型的(de)性能差異：不同的(de)手機機型的(de)CPU性能相差較大(dà)，需要了(le)解不同機型在你的(de)App中的(de)占比，因爲即在iPhone6上能完美(měi)運行的(de)動效或交互動作，在iPhone6以下(xià)的(de)手機上可(kě)能就會卡住不動了(le)，所以不太适合用(yòng)于CPU性能消耗較大(dà)的(de)頻(pín)繁渲染。

c. 網絡的(de)影(yǐng)響：如果你的(de)動效在運動時(shí)，還(hái)需要加載内容，就要考慮網絡較慢(màn)時(shí)，内容加載對(duì)動效流暢度的(de)影(yǐng)響，這(zhè)時(shí)可(kě)考慮先加載完内容，再開始動效或簡化(huà)、壓縮加載的(de)内容量。

3.平台兼容

由于Hybrid App的(de)Web内容，是不同的(de)平台共用(yòng)同一套設計方案，所以爲了(le)更好地讓設計方案兼容不同的(de)平台特性和(hé)手機分(fēn)辨率，所以建議(yì)文案和(hé)圖形采用(yòng)以下(xià)三種方式：

a. 系統默認字體：如果不是爲了(le)設計出特殊的(de)字體樣式，iOS、Android和(hé)Windows Phone系統的(de)默認字體是基本滿足我們的(de)需求，同時(shí)在不同平台上的(de)顯示效果也(yě)會比較好。

b. SVG（可(kě)縮放矢量圖形）：能夠自由縮放大(dà)小來(lái)适應不同屏幕尺寸和(hé)分(fēn)辨率，不會模糊變形。

c. Iconfont來(lái)代替圖标：能夠自由變換大(dà)小和(hé)顔色。

4.交互行爲

由于Hybrid App主要是通(tōng)過網頁的(de)CSS樣式結構和(hé)JavaScript程序語言來(lái)還(hái)原界面的(de)設計和(hé)交互行爲，所以跟純Native App技術框架相比，需要通(tōng)過更繁瑣的(de)代碼和(hé)層級請求才能實現跟原生系統一樣的(de)交互方式，雖然也(yě)可(kě)模拟Native App的(de)交互方式，但這(zhè)樣的(de)模拟首先提高(gāo)了(le)開發成本，有悖于不影(yǐng)響性能和(hé)高(gāo)效的(de)原則，所以需要根據設計目标來(lái)合理(lǐ)選擇是否需要跟系統交互保持一緻。

如圖所示，如果“每日赢寶箱”的(de)頁面是純Native框架搭建的(de)，則當用(yòng)戶點擊“參與互動拿紅包”的(de)卡片後，下(xià)一個(gè)頁面會采用(yòng)iOS系統默認的(de)自右向左切入的(de)交互方式。

然而，由于這(zhè)裏采用(yòng)的(de)是Hybirid App技術框架，所以會像網頁一樣，直接變換内容區(qū)的(de)信息，因爲這(zhè)樣的(de)實現方式更高(gāo)效和(hé)不影(yǐng)響性能，更重要的(de)是如果該頁面采用(yòng)直接變換内容的(de)方式不會影(yǐng)響到用(yòng)戶的(de)使用(yòng)體驗，這(zhè)裏就可(kě)以考慮不需要跟系統交互保持一緻。

5.加載方式

對(duì)于Hybrid App框架的(de)頁面，由于同時(shí)存在Native和(hé)Web部分(fēn)，所以在加載内容時(shí)，可(kě)以分(fēn)開考慮加載方式：

A. Native部分(fēn)：可(kě)以根據需要把常規内容存儲在用(yòng)戶的(de)手機上，加快(kuài)加載的(de)時(shí)間和(hé)減少重複加載相同内容的(de)麻煩。

B. Web部分(fēn)：Web内容區(qū)域是需要從網絡上加載内容的(de)，尤其在網絡條件不好時(shí)，需要設計友好的(de)等待狀态，緩和(hé)用(yòng)戶的(de)焦慮情緒。

如圖所示，可(kě)以根據不同的(de)框架，來(lái)設計不同的(de)加載方式，讓等待過程更短或更愉悅。

四、設計與技術的(de)權衡

1.明(míng)确設計方案的(de)主流程

在技術面前，設計是否隻能妥協呢(ne)？答(dá)案是否定的(de)，在對(duì)應的(de)App技術框架下(xià)，我們在考慮設計方案時(shí)，要明(míng)确設計方案的(de)主流程和(hé)支流程，凡 是會影(yǐng)響到方案核心的(de)主流程的(de)方案，即使開發的(de)實現難度和(hé)成本較高(gāo)，我們也(yě)要持續推動技術的(de)突破，來(lái)爲用(yòng)戶提供更好的(de)使用(yòng)體驗，而對(duì)于方案的(de)支流程，我們 就可(kě)以跟開發協商不同的(de)解決方案，明(míng)确哪些地方可(kě)以調整技術實現方式或換一種設計方案，哪些方案存在風險，需要有備選方案。

例如在設計手機淘寶店(diàn)鋪的(de)标簽模塊時(shí)，由于大(dà)部分(fēn)商家會根據寶貝圖的(de)特點，來(lái)設置圖上标簽的(de)内容和(hé)位置，可(kě)是，由于店(diàn)鋪的(de)技術框架不支持 标簽移動的(de)功能，而我們的(de)設計目标和(hé)方案的(de)主流程就是要爲商家提供更靈活設置寶貝标簽的(de)功能，所以即使技術實現難度和(hé)成本較高(gāo)，我們也(yě)推動技術進行突破， 實現标簽的(de)可(kě)移動功能。

2.提前與開發溝通(tōng)設計想法的(de)可(kě)行性

我們分(fēn)析完産品需求後，可(kě)以先簡單地在紙上畫(huà)出粗犷的(de)交互原型，然後，跟開發溝通(tōng)想法的(de)可(kě)行性及實現難度，做(zuò)到心中有數。如果方案中涉及動效設計，可(kě)通(tōng)過紙片來(lái)錄制粗略的(de)動效，或拿出自己平時(shí)收集的(de)動效素材（圖17）與開發溝通(tōng)可(kě)行性，來(lái)快(kuài)速驗證設計想法。

五、小結

在項目中，設計師往往需要權衡商業目标、用(yòng)戶體驗和(hé)技術實現三者之間的(de)關系來(lái)做(zuò)設計方案，以上隻是介紹App技術框架的(de)基本知識，讓設計師在做(zuò)方案 時(shí)更有把握，但由于技術日新月(yuè)異，每天都在進步中，所以在實踐中需要根據項目的(de)不同階段與開發工程師保持緊密的(de)溝通(tōng)，來(lái)讓設計方案更靠譜。