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

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

3. Hybrid App技術(shù)框架的設(shè)計(jì)特點(diǎn)

4. 設(shè)計(jì)與技術(shù)的權(quán)衡

5. 小結(jié)

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

 
三種App技術(shù)框架之間的關(guān)系 

1）Native App：

一種基于智能移動(dòng)設(shè)備本地操作系統(tǒng)（如iOS、Android、WP操作系統(tǒng)），并使用對(duì)應(yīng)系統(tǒng)所適用的程序語(yǔ)言編寫(xiě)運(yùn)行的第三方應(yīng)用程序，由于它是直接與操作系統(tǒng)對(duì)接，代碼和界面都是針對(duì)所運(yùn)行的平臺(tái)開(kāi)發(fā)和設(shè)計(jì)的，能很好地發(fā)揮出設(shè)備的性能，所以交互體驗(yàn)會(huì)更流暢。

2）Web App：

一種采用Html語(yǔ)言編寫(xiě)的，存在于智能移動(dòng)設(shè)備瀏覽器中的應(yīng)用程序，不需要下載安裝，可以說(shuō)是觸屏版的網(wǎng)頁(yè)應(yīng)用，由于它不依賴于操作系統(tǒng)，因此開(kāi)發(fā)了一款Web App后，基本能應(yīng)用于各種系統(tǒng)平臺(tái)。

3）Hybrid App：

一種用Native技術(shù)來(lái)搭建App的外殼，殼里的內(nèi)容由Web技術(shù)來(lái)提供的移動(dòng)應(yīng)用，兼具“Native App良好交互體驗(yàn)的優(yōu)勢(shì)”和“Web App跨平臺(tái)開(kāi)發(fā)的優(yōu)勢(shì)”。

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

Native（原生）

產(chǎn)品特點(diǎn)：偏操作互動(dòng)多的工具類應(yīng)用；

開(kāi)發(fā)成本：要為iOS、Android和WP系統(tǒng)各自開(kāi)發(fā)一套App

維護(hù)成本：不僅要維護(hù)多個(gè)系統(tǒng)版本，還要維護(hù)多個(gè)歷史版本（如有的用戶在5.0版本，有的用戶在4.0版本等）

版本發(fā)布：需要發(fā)布（用戶安裝）最新版App

資源存儲(chǔ)：本地

網(wǎng)絡(luò)要求：支持離線

開(kāi)發(fā)時(shí)間：耗時(shí)最長(zhǎng)

人員配比：需要iOS、Android和WP各自系統(tǒng)的開(kāi)發(fā)人員

Web

產(chǎn)品特點(diǎn)：偏瀏覽內(nèi)容為主的新聞、視頻類應(yīng)用

開(kāi)發(fā)成本：只需開(kāi)發(fā)一套App，即可運(yùn)用到不同系統(tǒng)平臺(tái)

維護(hù)成本：只維護(hù)最新的版本

版本發(fā)布：不需要發(fā)布（用戶安裝）最新的App

資源存儲(chǔ)：服務(wù)器

網(wǎng)絡(luò)要求：依賴網(wǎng)絡(luò)

開(kāi)發(fā)時(shí)間：耗時(shí)最少

人員配比：會(huì)寫(xiě)網(wǎng)頁(yè)語(yǔ)言的開(kāi)發(fā)

Hybrid（混合型）

產(chǎn)品特點(diǎn)：偏既要瀏覽內(nèi)容，又有較多操作互動(dòng)的聊天類、購(gòu)物類應(yīng)用

開(kāi)發(fā)成本：native部分需要為iOS、android和WP各自配備開(kāi)發(fā)人員，web部分只需統(tǒng)一配置

維護(hù)成本：native需要為多最新版本和多個(gè)歷史版本，web只需維護(hù)最新版本

版本發(fā)布：native部分需要發(fā)布（用戶安裝）最新的App，web部分不需要發(fā)布（用戶安裝）最新的App

資源存儲(chǔ)：本地和服務(wù)器

網(wǎng)絡(luò)要求：大部分依賴網(wǎng)絡(luò)

開(kāi)發(fā)時(shí)間：耗時(shí)中等

人員配比：大部分工作由寫(xiě)網(wǎng)頁(yè)語(yǔ)言的開(kāi)發(fā)承擔(dān)，再加上不同系統(tǒng)的開(kāi)發(fā)

三、Hybrid App技術(shù)框架的設(shè)計(jì)特點(diǎn)

由于Hybrid App是融合了Native App和Web App的技術(shù)特點(diǎn)，通過(guò)分析Hybrid App的技術(shù)框架成分，能讓我們更好地掌握App框架的基本開(kāi)發(fā)知識(shí)，有助于我們更好地去做設(shè)計(jì)。

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

1.圖像渲染

Native技術(shù)部分由于能直接調(diào)用系統(tǒng)的渲染引擎，所以能實(shí)現(xiàn)流暢的復(fù)雜圖像渲染，而不影響設(shè)備的性能。

Web內(nèi)容部分由于是基于內(nèi)置瀏覽器，在圖像渲染的時(shí)候要通過(guò)瀏覽器訪問(wèn)系統(tǒng)的渲染引擎或調(diào)用基于瀏覽器的第三方渲染引擎，中間需要在多個(gè)層級(jí)進(jìn)行渲染請(qǐng)求，所以渲染的時(shí)效性和性能會(huì)下降不少，導(dǎo)致較復(fù)雜的圖像渲染或動(dòng)態(tài)渲染時(shí)，會(huì)出現(xiàn)機(jī)器卡頓。

如圖所示，由于標(biāo)題欄采用了Native技術(shù)框架，可采用復(fù)雜的毛玻璃效果，讓標(biāo)題欄更通透，而內(nèi)容區(qū)采用了基于Html5的Web技術(shù)，因此不適合動(dòng)態(tài)變換背景圖的渲染方案（當(dāng)圖片輪播時(shí)，背景圖會(huì)隨著圖片內(nèi)容而動(dòng)態(tài)變換出模糊的背景）。

2.動(dòng)效體驗(yàn)

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

a. 不同的動(dòng)效類型對(duì)CPU性能的消耗不同:對(duì)CPU性能要求低的動(dòng)效類型能運(yùn)行得更流暢，但如果當(dāng)你的設(shè)計(jì)方案是非系統(tǒng)自帶的動(dòng)效類型時(shí)，就需要提前跟開(kāi)發(fā)溝通可行性和對(duì)CPU性能的消耗問(wèn)題。

b. 機(jī)型的性能差異：不同的手機(jī)機(jī)型的CPU性能相差較大，需要了解不同機(jī)型在你的App中的占比，因?yàn)榧丛趇Phone6上能完美運(yùn)行的動(dòng)效或交互動(dòng)作，在iPhone6以下的手機(jī)上可能就會(huì)卡住不動(dòng)了，所以不太適合用于CPU性能消耗較大的頻繁渲染。

c. 網(wǎng)絡(luò)的影響：如果你的動(dòng)效在運(yùn)動(dòng)時(shí)，還需要加載內(nèi)容，就要考慮網(wǎng)絡(luò)較慢時(shí)，內(nèi)容加載對(duì)動(dòng)效流暢度的影響，這時(shí)可考慮先加載完內(nèi)容，再開(kāi)始動(dòng)效或簡(jiǎn)化、壓縮加載的內(nèi)容量。

3.平臺(tái)兼容

由于Hybrid App的Web內(nèi)容，是不同的平臺(tái)共用同一套設(shè)計(jì)方案，所以為了更好地讓設(shè)計(jì)方案兼容不同的平臺(tái)特性和手機(jī)分辨率，所以建議文案和圖形采用以下三種方式：

a. 系統(tǒng)默認(rèn)字體：如果不是為了設(shè)計(jì)出特殊的字體樣式，iOS、Android和Windows Phone系統(tǒng)的默認(rèn)字體是基本滿足我們的需求，同時(shí)在不同平臺(tái)上的顯示效果也會(huì)比較好。

b. SVG（可縮放矢量圖形）：能夠自由縮放大小來(lái)適應(yīng)不同屏幕尺寸和分辨率，不會(huì)模糊變形。

c. Iconfont來(lái)代替圖標(biāo)：能夠自由變換大小和顏色。

4.交互行為

由于Hybrid App主要是通過(guò)網(wǎng)頁(yè)的CSS樣式結(jié)構(gòu)和JavaScript程序語(yǔ)言來(lái)還原界面的設(shè)計(jì)和交互行為，所以跟純Native App技術(shù)框架相比，需要通過(guò)更繁瑣的代碼和層級(jí)請(qǐng)求才能實(shí)現(xiàn)跟原生系統(tǒng)一樣的交互方式，雖然也可模擬Native App的交互方式，但這樣的模擬首先提高了開(kāi)發(fā)成本，有悖于不影響性能和高效的原則，所以需要根據(jù)設(shè)計(jì)目標(biāo)來(lái)合理選擇是否需要跟系統(tǒng)交互保持一致。

如圖所示，如果“每日贏寶箱”的頁(yè)面是純Native框架搭建的，則當(dāng)用戶點(diǎn)擊“參與互動(dòng)拿紅包”的卡片后，下一個(gè)頁(yè)面會(huì)采用iOS系統(tǒng)默認(rèn)的自右向左切入的交互方式。

然而，由于這里采用的是Hybirid App技術(shù)框架，所以會(huì)像網(wǎng)頁(yè)一樣，直接變換內(nèi)容區(qū)的信息，因?yàn)檫@樣的實(shí)現(xiàn)方式更高效和不影響性能，更重要的是如果該頁(yè)面采用直接變換內(nèi)容的方式不會(huì)影響到用戶的使用體驗(yàn)，這里就可以考慮不需要跟系統(tǒng)交互保持一致。

5.加載方式

對(duì)于Hybrid App框架的頁(yè)面，由于同時(shí)存在Native和Web部分，所以在加載內(nèi)容時(shí)，可以分開(kāi)考慮加載方式：

A. Native部分：可以根據(jù)需要把常規(guī)內(nèi)容存儲(chǔ)在用戶的手機(jī)上，加快加載的時(shí)間和減少重復(fù)加載相同內(nèi)容的麻煩。

B. Web部分：Web內(nèi)容區(qū)域是需要從網(wǎng)絡(luò)上加載內(nèi)容的，尤其在網(wǎng)絡(luò)條件不好時(shí)，需要設(shè)計(jì)友好的等待狀態(tài)，緩和用戶的焦慮情緒。

如圖所示，可以根據(jù)不同的框架，來(lái)設(shè)計(jì)不同的加載方式，讓等待過(guò)程更短或更愉悅。

四、設(shè)計(jì)與技術(shù)的權(quán)衡

1.明確設(shè)計(jì)方案的主流程

在技術(shù)面前，設(shè)計(jì)是否只能妥協(xié)呢？答案是否定的，在對(duì)應(yīng)的App技術(shù)框架下，我們?cè)诳紤]設(shè)計(jì)方案時(shí)，要明確設(shè)計(jì)方案的主流程和支流程，凡 是會(huì)影響到方案核心的主流程的方案，即使開(kāi)發(fā)的實(shí)現(xiàn)難度和成本較高，我們也要持續(xù)推動(dòng)技術(shù)的突破，來(lái)為用戶提供更好的使用體驗(yàn)，而對(duì)于方案的支流程，我們 就可以跟開(kāi)發(fā)協(xié)商不同的解決方案，明確哪些地方可以調(diào)整技術(shù)實(shí)現(xiàn)方式或換一種設(shè)計(jì)方案，哪些方案存在風(fēng)險(xiǎn)，需要有備選方案。

例如在設(shè)計(jì)手機(jī)淘寶店鋪的標(biāo)簽?zāi)K時(shí)，由于大部分商家會(huì)根據(jù)寶貝圖的特點(diǎn)，來(lái)設(shè)置圖上標(biāo)簽的內(nèi)容和位置，可是，由于店鋪的技術(shù)框架不支持 標(biāo)簽移動(dòng)的功能，而我們的設(shè)計(jì)目標(biāo)和方案的主流程就是要為商家提供更靈活設(shè)置寶貝標(biāo)簽的功能，所以即使技術(shù)實(shí)現(xiàn)難度和成本較高，我們也推動(dòng)技術(shù)進(jìn)行突破， 實(shí)現(xiàn)標(biāo)簽的可移動(dòng)功能。

2.提前與開(kāi)發(fā)溝通設(shè)計(jì)想法的可行性

我們分析完產(chǎn)品需求后，可以先簡(jiǎn)單地在紙上畫(huà)出粗獷的交互原型，然后，跟開(kāi)發(fā)溝通想法的可行性及實(shí)現(xiàn)難度，做到心中有數(shù)。如果方案中涉及動(dòng)效設(shè)計(jì)，可通過(guò)紙片來(lái)錄制粗略的動(dòng)效，或拿出自己平時(shí)收集的動(dòng)效素材（圖17）與開(kāi)發(fā)溝通可行性，來(lái)快速驗(yàn)證設(shè)計(jì)想法。

五、小結(jié)

在項(xiàng)目中，設(shè)計(jì)師往往需要權(quán)衡商業(yè)目標(biāo)、用戶體驗(yàn)和技術(shù)實(shí)現(xiàn)三者之間的關(guān)系來(lái)做設(shè)計(jì)方案，以上只是介紹App技術(shù)框架的基本知識(shí)，讓設(shè)計(jì)師在做方案 時(shí)更有把握，但由于技術(shù)日新月異，每天都在進(jìn)步中，所以在實(shí)踐中需要根據(jù)項(xiàng)目的不同階段與開(kāi)發(fā)工程師保持緊密的溝通，來(lái)讓設(shè)計(jì)方案更靠譜。