在之前的《Hello App》一文中，總結(jié)了APP在不同的技術(shù)框架下可以分為三種：Native App（原生應(yīng)用）迅诬，Web App（網(wǎng)站應(yīng)用）箭养，Hybrid App（混合應(yīng)用）奥喻。今天碰巧看到了這篇文章：《App技術(shù)框架對(duì)設(shè)計(jì)的影響》偶宫。其總結(jié)了三種技術(shù)框架的主要特點(diǎn)非迹，以及不同框架下APP交互的影響环鲤。我想可以很好的讓我們從技術(shù)框架的角度重新認(rèn)識(shí)不同的APP設(shè)計(jì)。
以下是轉(zhuǎn)載的原文：
----------------------------------------------
不知道大家有沒有遇到過這種情景憎兽，當(dāng)你做好一個(gè)設(shè)計(jì)方案冷离，滿心歡喜地給開發(fā)講解方案的思路和創(chuàng)意時(shí)吵冒，開發(fā)突然說一句“這個(gè)方案實(shí)現(xiàn)不了”，這時(shí)你整個(gè)人都不好了西剥，心里開始嘀咕“這么簡單的設(shè)計(jì)都實(shí)現(xiàn)不了痹栖，你是搞技術(shù)的嗎？”然并卵瞭空，在產(chǎn)品和開發(fā)的催促下揪阿，作為設(shè)計(jì)師的你只能加班加點(diǎn)地改方案。到底問題出現(xiàn)在哪呢咆畏？這其實(shí)是由于我們?cè)O(shè)計(jì)師對(duì)App技術(shù)框架的知識(shí)匱乏所導(dǎo)致的南捂，雖然我們不必做到會(huì)寫代碼，但掌握必要的App技術(shù)框架原理旧找，能更有效地幫助我們預(yù)判哪些方案可行和實(shí)現(xiàn)效果較好溺健，來讓設(shè)計(jì)方案更接地氣，以下先讓我們一起來了解一下App技術(shù)框架都有哪些钮蛛。
一鞭缭、App技術(shù)框架的類型
圖1 三種App技術(shù)框架之間的關(guān)系
三種App技術(shù)框架之間的關(guān)系
目前App的技術(shù)框架基本分為三種（圖1）：
1、Native App
一種基于智能移動(dòng)設(shè)備本地操作系統(tǒng)（如iOS魏颓、Android岭辣、WP操作系統(tǒng)），并使用對(duì)應(yīng)系統(tǒng)所適用的程序語言編寫運(yùn)行的第三方應(yīng)用程序甸饱，由于它是直接與操作系統(tǒng)對(duì)接易结，代碼和界面都是針對(duì)所運(yùn)行的平臺(tái)開發(fā)和設(shè)計(jì)的，能很好地發(fā)揮出設(shè)備的性能柜候，所以交互體驗(yàn)會(huì)更流暢搞动。
2、Web App
一種采用Html語言編寫的渣刷，存在于智能移動(dòng)設(shè)備瀏覽器中的應(yīng)用程序鹦肿，不需要下載安裝，可以說是觸屏版的網(wǎng)頁應(yīng)用辅柴，由于它不依賴于操作系統(tǒng)箩溃，因此開發(fā)了一款Web App后，基本能應(yīng)用于各種系統(tǒng)平臺(tái)碌嘀。
3涣旨、Hybrid App
一種用Native技術(shù)來搭建App的外殼，殼里的內(nèi)容由Web技術(shù)來提供的移動(dòng)應(yīng)用股冗，兼具“Native App良好交互體驗(yàn)的優(yōu)勢(shì)”和“Web App跨平臺(tái)開發(fā)的優(yōu)勢(shì)”霹陡。
二、App技術(shù)框架的選擇
對(duì)于設(shè)計(jì)師而言，我們往往是被告知這個(gè)項(xiàng)目采用的是哪種技術(shù)框架烹棉，然后就開始設(shè)計(jì)了攒霹，其實(shí)，我們也可以根據(jù)產(chǎn)品特點(diǎn)浆洗、框架特點(diǎn)和項(xiàng)目時(shí)間（圖2）來與產(chǎn)品和開發(fā)同學(xué)協(xié)商催束，合理地為App中不同的部分選擇對(duì)應(yīng)技術(shù)框架，然后才在對(duì)應(yīng)的技術(shù)框架下思考設(shè)計(jì)方案伏社。
圖2 產(chǎn)品特點(diǎn)抠刺、框架特點(diǎn)和項(xiàng)目時(shí)間的考慮
三、Hybrid App技術(shù)框架的設(shè)計(jì)特點(diǎn)
由于Hybrid App是融合了Native App和Web App的技術(shù)特點(diǎn)摘昌，通過分析Hybrid App的技術(shù)框架成分矫付，能讓我們更好地掌握App框架的基本開發(fā)知識(shí)，有助于我們更好地去做設(shè)計(jì)第焰。
Hybrid App的大部分內(nèi)容都是在Native框架中加載Web網(wǎng)頁內(nèi)容买优，能在保證用戶體驗(yàn)的前提下，讓App的內(nèi)容更具有擴(kuò)展性挺举，即使接入再多的內(nèi)容和業(yè)務(wù)功能杀赢，也不會(huì)使得整個(gè)App的安裝包過大，典型Hybrid App的代表就是我們的手機(jī)淘寶客戶端湘纵。Hybrid App在設(shè)計(jì)時(shí)脂崔，要注意以下五個(gè)要點(diǎn)（圖3）。
圖3 Hybrid App的五個(gè)設(shè)計(jì)要點(diǎn)
1梧喷、圖像渲染
Native技術(shù)部分由于能直接調(diào)用系統(tǒng)的渲染引擎砌左，所以能實(shí)現(xiàn)流暢的復(fù)雜圖像渲染，而不影響設(shè)備的性能铺敌。
Web內(nèi)容部分由于是基于內(nèi)置瀏覽器汇歹，在圖像渲染的時(shí)候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調(diào)用基于瀏覽器的第三方渲染引擎，中間需要在多個(gè)層級(jí)進(jìn)行渲染請(qǐng)求偿凭，所以渲染的時(shí)效性和性能會(huì)下降不少产弹，導(dǎo)致較復(fù)雜的圖像渲染或動(dòng)態(tài)渲染時(shí)，會(huì)出現(xiàn)機(jī)器卡頓弯囊。
如圖4所示痰哨，由于標(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)變換出模糊的背景）撬讽。
圖4 動(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è)方面：
2.1
不同的動(dòng)效類型對(duì)CPU性能的消耗不同（圖5）:對(duì)CPU性能要求低的動(dòng)效類型能運(yùn)行得更流暢盗忱，但如果當(dāng)你的設(shè)計(jì)方案是非系統(tǒng)自帶的動(dòng)效類型時(shí)（圖6）酱床，就需要提前跟開發(fā)溝通可行性和對(duì)CPU性能的消耗問題。
2.2
機(jī)型的性能差異：不同的手機(jī)機(jī)型的CPU性能相差較大趟佃，需要了解不同機(jī)型在你的App中的占比（圖7）扇谣，因?yàn)榧丛趇Phone6上能完美運(yùn)行的動(dòng)效或交互動(dòng)作，在iPhone6以下的手機(jī)上可能就會(huì)卡住不動(dòng)了闲昭，所以不太適合用于CPU性能消耗較大的頻繁渲染罐寨。
2.3
網(wǎng)絡(luò)的影響：如果你的動(dòng)效在運(yùn)動(dòng)時(shí)，還需要加載內(nèi)容序矩，就要考慮網(wǎng)絡(luò)較慢時(shí)鸯绿，內(nèi)容加載對(duì)動(dòng)效流暢度的影響，這時(shí)可考慮先加載完內(nèi)容簸淀，再開始動(dòng)效或簡化瓶蝴、壓縮加載的內(nèi)容量。
圖5 不同的動(dòng)效類型對(duì)CPU的性能要求
圖6 液化翻轉(zhuǎn)的動(dòng)效
圖7 不同機(jī)型的市場占比
如圖8所示租幕，在Web內(nèi)容區(qū)舷手，當(dāng)點(diǎn)擊圖片后，該圖片放大（系統(tǒng)默認(rèn)的縮放動(dòng)效劲绪，對(duì)CPU性能消耗心锌摺），但其它圖片自動(dòng)重新排列的動(dòng)效會(huì)比較消耗CPU性能贾富，在低端機(jī)器上會(huì)出現(xiàn)卡頓或閃退的情況歉眷，并且還會(huì)受到網(wǎng)速的影響，導(dǎo)致體驗(yàn)不友好颤枪，如果必須做復(fù)雜動(dòng)效姥芥，可以讓該動(dòng)效只出現(xiàn)在高端機(jī)型中。
圖8 圖片縮放的重新排列動(dòng)效
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)字體（圖9）是基本滿足我們的需求读整，同時(shí)在不同平臺(tái)上的顯示效果也會(huì)比較好簿训。
圖9 系統(tǒng)默認(rèn)字體
b.SVG（可縮放矢量圖形）：能夠自由縮放大小來適應(yīng)不同屏幕尺寸和分辨率，不會(huì)模糊變形（圖10）。
圖10 SVG（可縮放矢量圖形）
c.Iconfont來代替圖標(biāo)：能夠自由變換大小和顏色（圖11）强品。
圖11 Iconfont圖標(biāo)
采用這三種方式不僅可以很好適配不同機(jī)型和屏幕尺寸膘侮，而且還不會(huì)增加安裝包的大小。
如圖12所示的榛，如果按鈕上的“鬧鐘和提醒我”采用的不是Iconfont和系統(tǒng)默認(rèn)字體琼了，則在不同尺寸的屏幕上的顯示效果會(huì)很難控制，有被拉伸變形或模糊的風(fēng)險(xiǎn)夫晌。
圖12 圖標(biāo)和字體在不同尺寸屏幕上的顯示效果
4雕薪、交互行為
由于Hybrid App主要是通過網(wǎng)頁的CSS樣式結(jié)構(gòu)和JavaScript程序語言來還原界面的設(shè)計(jì)和交互行為，所以跟純Native App技術(shù)框架相比晓淀，需要通過更繁瑣的代碼和層級(jí)請(qǐng)求才能實(shí)現(xiàn)跟原生系統(tǒng)一樣的交互方式所袁，雖然也可模擬Native App的交互方式，但這樣的模擬首先提高了開發(fā)成本凶掰，有悖于不影響性能和高效的原則燥爷，所以需要根據(jù)設(shè)計(jì)目標(biāo)來合理選擇是否需要跟系統(tǒng)交互保持一致。
如圖13-a所示懦窘，如果“每日贏寶箱”的頁面是純Native框架搭建的局劲，則當(dāng)用戶點(diǎn)擊“參與互動(dòng)拿紅包”的卡片后，下一個(gè)頁面會(huì)采用iOS系統(tǒng)默認(rèn)的自右向左切入的交互方式奶赠。
圖13-a 系統(tǒng)默認(rèn)的交互方式
然而鱼填，由于這里采用的是Hybirid App技術(shù)框架，所以會(huì)像網(wǎng)頁一樣毅戈，直接變換內(nèi)容區(qū)的信息（圖13-b）苹丸，因?yàn)檫@樣的實(shí)現(xiàn)方式更高效和不影響性能，更重要的是如果該頁面采用直接變換內(nèi)容的方式不會(huì)影響到用戶的使用體驗(yàn)苇经，這里就可以考慮不需要跟系統(tǒng)交互保持一致赘理。
圖13-b 直接變換內(nèi)容區(qū)的交互方式
5、加載方式
對(duì)于Hybrid App框架的頁面扇单，由于同時(shí)存在Native和Web部分商模，所以在加載內(nèi)容時(shí)，可以分開考慮加載方式：
5.1.NATIVE部分：
可以根據(jù)需要把常規(guī)內(nèi)容存儲(chǔ)在用戶的手機(jī)上蜘澜，加快加載的時(shí)間和減少重復(fù)加載相同內(nèi)容的麻煩施流。
5.2.WEB部分：
Web內(nèi)容區(qū)域是需要從網(wǎng)絡(luò)上加載內(nèi)容的，尤其在網(wǎng)絡(luò)條件不好時(shí)鄙信，需要設(shè)計(jì)友好的等待狀態(tài)瞪醋，緩和用戶的焦慮情緒。
如圖14所示装诡，可以根據(jù)不同的框架银受，來設(shè)計(jì)不同的加載方式践盼，讓等待過程更短或更愉悅。
圖14 根據(jù)技術(shù)框架來設(shè)計(jì)加載方式
四宾巍、設(shè)計(jì)與技術(shù)的權(quán)衡
1咕幻、明確設(shè)計(jì)方案的主流程
在技術(shù)面前，設(shè)計(jì)是否只能妥協(xié)呢顶霞？答案是否定的肄程，在對(duì)應(yīng)的App技術(shù)框架下，我們?cè)诳紤]設(shè)計(jì)方案時(shí)确丢，要明確設(shè)計(jì)方案的主流程和支流程（圖15）绷耍，凡是會(huì)影響到方案核心的主流程的方案吐限，即使開發(fā)的實(shí)現(xiàn)難度和成本較高鲜侥，我們也要持續(xù)推動(dòng)技術(shù)的突破，來為用戶提供更好的使用體驗(yàn)诸典，而對(duì)于方案的支流程描函，我們就可以跟開發(fā)協(xié)商不同的解決方案，明確哪些地方可以調(diào)整技術(shù)實(shí)現(xiàn)方式或換一種設(shè)計(jì)方案狐粱，哪些方案存在風(fēng)險(xiǎn)舀寓，需要有備選方案。
圖15 設(shè)計(jì)方案的主流程和支流程
如圖16所示肌蜻，在設(shè)計(jì)手機(jī)淘寶店鋪的標(biāo)簽?zāi)K時(shí)互墓，由于大部分商家會(huì)根據(jù)寶貝圖的特點(diǎn)，來設(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)功能帮哈。
圖16 店鋪的標(biāo)簽?zāi)K
2膛檀、提前與開發(fā)溝通設(shè)計(jì)想法的可行性
我們分析完產(chǎn)品需求后，可以先簡單地在紙上畫出粗獷的交互原型娘侍，然后咖刃，跟開發(fā)溝通想法的可行性及實(shí)現(xiàn)難度，做到心中有數(shù)憾筏。如果方案中涉及動(dòng)效設(shè)計(jì)僵缺，可通過紙片來錄制粗略的動(dòng)效，或拿出自己平時(shí)收集的動(dòng)效素材（圖17）與開發(fā)溝通可行性踩叭，來快速驗(yàn)證設(shè)計(jì)想法磕潮。
圖17 動(dòng)效素材
五翠胰、設(shè)計(jì)小結(jié)
“世上沒有完美的設(shè)計(jì)，因?yàn)槟阕罱K能做的就是在各種關(guān)系之間取得平衡”
——Paul Rand（美國著名設(shè)計(jì)師）
在項(xiàng)目中自脯，設(shè)計(jì)師往往需要權(quán)衡商業(yè)目標(biāo)之景、用戶體驗(yàn)和技術(shù)實(shí)現(xiàn)三者之間的關(guān)系來做設(shè)計(jì)方案，以上只是介紹App技術(shù)框架的基本知識(shí)膏潮，讓設(shè)計(jì)師在做方案時(shí)更有把握锻狗，但由于技術(shù)日新月異，每天都在進(jìn)步中焕参，所以在實(shí)踐中需要根據(jù)項(xiàng)目的不同階段與開發(fā)工程師保持緊密的溝通轻纪，來讓設(shè)計(jì)方案更靠譜。
文章來源：MIX無線設(shè)計(jì)
----------------------------------------------
原文題目：《App技術(shù)框架對(duì)設(shè)計(jì)的影響》
轉(zhuǎn)載地址：http://13tech.com.cn/?p=18740
