2015-11-25 用心設(shè)計
如果您想訂閱本博客內(nèi)容，每天自動發(fā)到您的郵箱中， 請點這里
來源：莫貝網(wǎng)
到底問題出現(xiàn)在哪呢？這其實是由于我們設(shè)計師對App技術(shù)框架的知識匱乏所導(dǎo)致的，雖然我們不必做到會寫代碼，但掌握必要的App技術(shù)框架原理，能更有效地幫助我們預(yù)判哪些方案可行和實現(xiàn)效果較好，來讓設(shè)計方案更接地氣，讓我們一起來了解一下App技術(shù)框架都有哪些。
圖1 三種App技術(shù)框架之間的關(guān)系
目前App的技術(shù)框架基本分為三種（圖1）：
1）Native App：
一種基于智能移動設(shè)備本地操作系統(tǒng)（如iOS、Android、WP操作系統(tǒng)），并使用對應(yīng)系統(tǒng)所適用的程序語言編寫運行的第三方應(yīng)用程序，由于它是直接與操作系統(tǒng)對接，代碼和界面都是針對所運行的平臺開發(fā)和設(shè)計的，能很好地發(fā)揮出設(shè)備的性能，所以交互體驗會更流暢。
2）Web App：
一種采用Html語言編寫的，存在于智能移動設(shè)備瀏覽器中的應(yīng)用程序，不需要下載安裝，可以說是觸屏版的網(wǎng)頁應(yīng)用，由于它不依賴于操作系統(tǒng)，因此開發(fā)了一款Web App后，基本能應(yīng)用于各種系統(tǒng)平臺。
3）Hybrid App：
一種用Native技術(shù)來搭建App的外殼，殼里的內(nèi)容由Web技術(shù)來提供的移動應(yīng)用，兼具“Native App良好交互體驗的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”。
對于設(shè)計師而言，我們往往是被告知這個項目采用的是哪種技術(shù)框架，然后就開始設(shè)計了，其實，我們也可以根據(jù)產(chǎn)品特點、框架特點和項目時間（圖2）來與產(chǎn)品和開發(fā)同學(xué)協(xié)商，合理地為App中不同的部分選擇對應(yīng)技術(shù)框架，然后才在對應(yīng)的技術(shù)框架下思考設(shè)計方案。
圖2 產(chǎn)品特點、框架特點和項目時間的考慮
由于Hybrid App是融合了Native App和Web App的技術(shù)特點，通過分析Hybrid App的技術(shù)框架成分，能讓我們更好地掌握App框架的基本開發(fā)知識，有助于我們更好地去做設(shè)計。
Hybrid App的大部分內(nèi)容都是在Native框架中加載Web網(wǎng)頁內(nèi)容，能在保證用戶體驗的前提下，讓App的內(nèi)容更具有擴展性，即使接入再多的內(nèi)容和業(yè)務(wù)功能，也不會使得整個App的安裝包過大，典型Hybrid App的代表就是我們的手機淘寶客戶端。Hybrid App在設(shè)計時，要注意以下五個要點（圖3）。
圖3 Hybrid App的五個設(shè)計要點
1）圖像渲染
Native技術(shù)部分由于能直接調(diào)用系統(tǒng)的渲染引擎，所以能實現(xiàn)流暢的復(fù)雜圖像渲染，而不影響設(shè)備的性能。
Web內(nèi)容部分由于是基于內(nèi)置瀏覽器，在圖像渲染的時候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調(diào)用基于瀏覽器的第三方渲染引擎，中間需要在多個層級進行渲染請求，所以渲染的時效性和性能會下降不少，導(dǎo)致較復(fù)雜的圖像渲染或動態(tài)渲染時，會出現(xiàn)機器卡頓。
如圖4所示，由于標題欄采用了Native技術(shù)框架，可采用復(fù)雜的毛玻璃效果，讓標題欄更通透，而內(nèi)容區(qū)采用了基于Html5的Web技術(shù)，因此不適合動態(tài)變換背景圖的渲染方案（當圖片輪播時，背景圖會隨著圖片內(nèi)容而動態(tài)變換出模糊的背景）。
圖4 動態(tài)的圖像渲染
2）動效體驗
由于Hybrid App的內(nèi)容區(qū)大部分采用基于Html5的Web技術(shù)，對動效的解釋和操作需要消耗大量的CPU性能，在設(shè)計時，要注意以下三個方面：
a. 不同的動效類型對CPU性能的消耗不同（圖5）:對CPU性能要求低的動效類型能運行得更流暢，但如果當你的設(shè)計方案是非系統(tǒng)自帶的動效類型時（圖6），就需要提前跟開發(fā)溝通可行性和對CPU性能的消耗問題。
b. 機型的性能差異：不同的手機機型的CPU性能相差較大，需要了解不同機型在你的App中的占比（圖7），因為即在iPhone6上能完美運行的動效或交互動作，在iPhone6以下的手機上可能就會卡住不動了，所以不太適合用于CPU性能消耗較大的頻繁渲染。
c. 網(wǎng)絡(luò)的影響：如果你的動效在運動時，還需要加載內(nèi)容，就要考慮網(wǎng)絡(luò)較慢時，內(nèi)容加載對動效流暢度的影響，這時可考慮先加載完內(nèi)容，再開始動效或簡化、壓縮加載的內(nèi)容量。
圖5 不同的動效類型對CPU的性能要求
圖6 液化翻轉(zhuǎn)的動效
圖7 不同機型的市場占比
如圖8所示，在Web內(nèi)容區(qū)，當點擊圖片后，該圖片放大（系統(tǒng)默認的縮放動效，對CPU性能消耗小），但其它圖片自動重新排列的動效會比較消耗 CPU性能，在低端機器上會出現(xiàn)卡頓或閃退的情況，并且還會受到網(wǎng)速的影響，導(dǎo)致體驗不友好，如果必須做復(fù)雜動效，可以讓該動效只出現(xiàn)在高端機型中。
圖8 圖片縮放的重新排列動效
3）平臺兼容
由于Hybrid App的Web內(nèi)容，是不同的平臺共用同一套設(shè)計方案，所以為了更好地讓設(shè)計方案兼容不同的平臺特性和手機分辨率，所以建議文案和圖形采用以下三種方式：
a. 系統(tǒng)默認字體：如果不是為了設(shè)計出特殊的字體樣式，iOS、Android和Windows Phone系統(tǒng)的默認字體（圖9）是基本滿足我們的需求，同時在不同平臺上的顯示效果也會比較好。
圖9 系統(tǒng)默認字體
b. SVG（可縮放矢量圖形）：能夠自由縮放大小來適應(yīng)不同屏幕尺寸和分辨率，不會模糊變形（圖10）。
圖10 SVG（可縮放矢量圖形）
c. Iconfont來代替圖標：能夠自由變換大小和顏色（圖11）。
圖11 Iconfont圖標
采用這三種方式不僅可以很好適配不同機型和屏幕尺寸，而且還不會增加安裝包的大小。
如圖12所示，如果按鈕上的“鬧鐘和提醒我”采用的不是Iconfont和系統(tǒng)默認字體，則在不同尺寸的屏幕上的顯示效果會很難控制，有被拉伸變形或模糊的風險。
圖12 圖標和字體在不同尺寸屏幕上的顯示效果
4）交互行為
由于Hybrid App主要是通過網(wǎng)頁的CSS樣式結(jié)構(gòu)和JavaScript程序語言來還原界面的設(shè)計和 交互行為，所以跟純Native App技術(shù)框架相比，需要通過更繁瑣的代碼和層級請求才能實現(xiàn)跟原生系統(tǒng)一樣的交互方式，雖然也可模擬Native App的交互方式，但這樣的模擬首先提高了開發(fā)成本，有悖于不影響性能和的原則，所以需要根據(jù)設(shè)計目標來合理選擇是否需要跟系統(tǒng)交互保持一致。
如圖13-a所示，如果“每日贏寶箱”的頁面是純Native框架搭建的，則當用戶點擊“參與互動拿紅包”的卡片后，下一個頁面會采用iOS系統(tǒng)默認的自右向左切入的交互方式。
圖13-a 系統(tǒng)默認的交互方式
然而，由于這里采用的是Hybirid App技術(shù)框架，所以會像網(wǎng)頁一樣，直接變換內(nèi)容區(qū)的信息（圖13-b），因為這樣的實現(xiàn)方式更和不影響性能，更重要的是如果該頁面采用直接變換內(nèi)容的方式不會影響到用戶的使用體驗，這里就可以考慮不需要跟系統(tǒng)交互保持一致。
圖13-b 直接變換內(nèi)容區(qū)的交互方式
5）加載方式
對于Hybrid App框架的頁面，由于同時存在Native和Web部分，所以在加載內(nèi)容時，可以分開考慮加載方式：
A. Native部分：可以根據(jù)需要把常規(guī)內(nèi)容存儲在用戶的手機上，加快加載的時間和減少重復(fù)加載相同內(nèi)容的麻煩。
B. Web部分：Web內(nèi)容區(qū)域是需要從網(wǎng)絡(luò)上加載內(nèi)容的，尤其在網(wǎng)絡(luò)條件不好時，需要設(shè)計友好的等待狀態(tài)，緩和用戶的焦慮情緒。
如圖14所示，可以根據(jù)不同的框架，來設(shè)計不同的加載方式，讓等待過程更短或更愉悅。
圖14 根據(jù)技術(shù)框架來設(shè)計加載方式
1）明確設(shè)計方案的主流程
在技術(shù)面前，設(shè)計是否只能妥協(xié)呢？答案是否定的，在對應(yīng)的App技術(shù)框架下，我們在考慮設(shè)計方案時，要明確設(shè)計方案的主流程和支流程（圖15），凡 是會影響到方案核心的主流程的方案，即使開發(fā)的實現(xiàn)難度和成本較高，我們也要持續(xù)推動技術(shù)的突破，來為用戶提供更好的使用體驗，而對于方案的支流程，我們 就可以跟開發(fā)協(xié)商不同的解決方案，明確哪些地方可以調(diào)整技術(shù)實現(xiàn)方式或換一種設(shè)計方案，哪些方案存在風險，需要有備選方案。
圖15 設(shè)計方案的主流程和支流程
如圖16所示，在設(shè)計手機淘寶店鋪的標簽?zāi)K時，由于大部分商家會根據(jù)寶貝圖的特點，來設(shè)置圖上標簽的內(nèi)容和位置，可是，由于店鋪的技術(shù)框架不支持 標簽移動的功能，而我們的設(shè)計目標和方案的主流程就是要為商家提供更靈活設(shè)置寶貝標簽的功能，所以即使技術(shù)實現(xiàn)難度和成本較高，我們也推動技術(shù)進行突破， 實現(xiàn)標簽的可移動功能。
圖16 店鋪的標簽?zāi)K
2）提前與開發(fā)溝通設(shè)計想法的可行性
我們分析完產(chǎn)品需求后，可以先簡單地在紙上畫出粗獷的交互原型，然后，跟開發(fā)溝通想法的可行性及實現(xiàn)難度，做到心中有數(shù)。如果方案中涉及動效設(shè)計，可通過紙片來錄制粗略的動效，或拿出自己平時收集的動效素材（圖17）與開發(fā)溝通可行性，來快速驗證設(shè)計想法。
圖17 動效素材
“世上沒有完美的設(shè)計，因為你最終能做的就是在各種關(guān)系之間取得平衡” ——Paul Rand（美國著名設(shè)計師）
在項目中，設(shè)計師往往需要權(quán)衡商業(yè)目標、用戶體驗和技術(shù)實現(xiàn)三者之間的關(guān)系來做設(shè)計方案，以上只是介紹App技術(shù)框架的基本知識，讓設(shè)計師在做方案時更有把握，但由于技術(shù)日新月異，每天都在進步中，所以在實踐中需要根據(jù)項目的不同階段與開發(fā)工程師保持緊密的溝通，來讓設(shè)計方案更靠譜。
作者：信籽
文章來源：優(yōu)設(shè)
藍藍設(shè)計( m.73404.com.cn )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供有效的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)
藍藍設(shè)計的小編 http://m.73404.com.cn