Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
要:本文主要面對產(chǎn)品小白講一些常見的移動端應(yīng)用通常采用的技術(shù)框架,同時對當(dāng)前的移動開發(fā)前沿進(jìn)行解讀。部分內(nèi)容來源于網(wǎng)絡(luò),侵刪。
溫馨提示:全文共4398字,閱讀大約需要8分鐘。
三種主流App技術(shù)框架之間的關(guān)系
目前App的技術(shù)框架基本分為三種(上圖):
1、Native App
Native App(也叫原生App)是一種基于智能手機(jī)本地操作系統(tǒng)如iOS、Android、WP并使用原生程式編寫運(yùn)行的第三方應(yīng)用程序,也叫本地app。一般使用的開發(fā)語言為JAVA、C++、Objective-C。Native App使用對應(yīng)系統(tǒng)所適用的程序語言編寫運(yùn)行的第三方應(yīng)用程序,由于它是直接與操作系統(tǒng)對接,代碼和界面都是針對所運(yùn)行的平臺開發(fā)和設(shè)計(jì)的,能很好地發(fā)揮出設(shè)備的性能,所以交互體驗(yàn)會更流暢。
話題:在哪里采用原生App?
☆ 原生應(yīng)用場景:
在頭部以上的應(yīng)用(剛需成熟型產(chǎn)品),例如吃飯、閱讀、瀏覽、通信,通過App的方式來解決是比較有效率的。例如吃飯這樣高頻次的領(lǐng)域,用戶是可以養(yǎng)活這樣一個原生App的。比如常見的美團(tuán)外賣、餓了么、百度外賣等等的主要欄目模塊均采用基于本地系統(tǒng)的原生App。
在洗腳、拍結(jié)婚照、修車這樣的低頻次使用的領(lǐng)域,使用App就缺乏效率了。
重度應(yīng)用更加適合App來解決,例如手機(jī)游戲。而輕度應(yīng)用更加適合Web,例如看新聞。
Web應(yīng)用的推廣成本要遠(yuǎn)遠(yuǎn)小于App。有朋友做過統(tǒng)計(jì),點(diǎn)擊移動廣告到HTML5游戲的轉(zhuǎn)化率是App游戲的40倍。
☆ 原生制約瓶頸:
單個用戶的獲取成本越來越高。相信大家都有同感,無論是iOS還是Android,不管是推薦位,還是iAD、ADmob或者別的,價格都在扶搖直上。
來自官方渠道的site to APP轉(zhuǎn)化率降低。這就像是伐木,剛開始轉(zhuǎn)化率會很高,慢慢的官方渠道用戶會榨干到一個瓶頸期。
刷榜泛濫,無序競爭。競爭對手砸錢刷榜,你到底要不要跟?
2、Web App
Web App是指基于Web的系統(tǒng)和應(yīng)用,其作用是向廣大的最終用戶發(fā)布一組復(fù)雜的內(nèi)容和功能。從一個簡單的幫助消費(fèi)者計(jì)算汽車租借費(fèi)用的網(wǎng)頁,到為商業(yè)人員和度假者提供全套旅游服務(wù)的大型復(fù)雜的WEB站點(diǎn),都是WebApp。它包括一些完整的WEB站點(diǎn),WEB站點(diǎn)的專門功能以及在Internet、Intranet或ExtraNet上的信息處理應(yīng)用。
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àn)的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”。本文后半部分會對Hybrid App進(jìn)行著重講解。
產(chǎn)品特點(diǎn)、框架特點(diǎn)和項(xiàng)目時間的考慮
對于設(shè)計(jì)師而言,我們往往是被告知這個項(xiàng)目采用的是哪種技術(shù)框架,然后就開始設(shè)計(jì)了,其實(shí),我們也可以根據(jù)產(chǎn)品特點(diǎn)、框架特點(diǎn)和項(xiàng)目時間(圖2)來與產(chǎn)品和開發(fā)同學(xué)協(xié)商,合理地為App中不同的部分選擇對應(yīng)技術(shù)框架,然后才在對應(yīng)的技術(shù)框架下思考設(shè)計(jì)方案。
由于Hybrid App是融合了Native App和Web App的技術(shù)特點(diǎn),通過分析Hybrid App的技術(shù)框架成分,能讓我們更好地掌握App框架的基本開發(fā)知識,有助于我們更好地去做設(shè)計(jì)。
Hybrid App的大部分內(nèi)容都是在Native框架中加載Web網(wǎng)頁內(nèi)容,能在保證用戶體驗(yàn)的前提下,讓App的內(nèi)容更具有擴(kuò)展性,即使接入再多的內(nèi)容和業(yè)務(wù)功能,也不會使得整個App的安裝包過大,典型Hybrid App的代表就是我們的手機(jī)淘寶客戶端。Hybrid App在設(shè)計(jì)時,要注意以下五個要點(diǎn)(下圖)。
Hybrid App的五個設(shè)計(jì)要點(diǎn)
1、圖像渲染
Native技術(shù)部分由于能直接調(diào)用系統(tǒng)的渲染引擎,所以能實(shí)現(xiàn)流暢的復(fù)雜圖像渲染,而不影響設(shè)備的性能。
Web內(nèi)容部分由于是基于內(nèi)置瀏覽器,在圖像渲染的時候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調(diào)用基于瀏覽器的第三方渲染引擎,中間需要在多個層級進(jìn)行渲染請求,所以渲染的時效性和性能會下降不少,導(dǎo)致較復(fù)雜的圖像渲染或動態(tài)渲染時,會出現(xiàn)機(jī)器卡頓。
如下圖所示,由于標(biāo)題欄采用了Native技術(shù)框架,可采用復(fù)雜的毛玻璃效果,讓標(biāo)題欄更通透,而內(nèi)容區(qū)采用了基于Html5的Web技術(shù),因此不適合動態(tài)變換背景圖的渲染方案(當(dāng)圖片輪播時,背景圖會隨著圖片內(nèi)容而動態(tài)變換出模糊的背景)。
動態(tài)的圖像渲染
2、動效體驗(yàn)
由于Hybrid App的內(nèi)容區(qū)大部分采用基于Html5的Web技術(shù),對動效的解釋和操作需要消耗大量的CPU性能,在設(shè)計(jì)時,要注意以下三個方面:
不同的動效類型對CPU性能的消耗不同(下圖):對CPU性能要求低的動效類型能運(yùn)行得更流暢,但如果當(dāng)你的設(shè)計(jì)方案是非系統(tǒng)自帶的動效類型時(下圖),就需要提前跟開發(fā)溝通可行性和對CPU性能的消耗問題。
不同的動效類型對CPU的性能要求
不同的動效類型對CPU的性能要求
液化翻轉(zhuǎn)的動效
機(jī)型的性能差異:不同的手機(jī)機(jī)型的CPU性能相差較大,需要了解不同機(jī)型在你的App中的占比(下圖),因?yàn)榧丛趇Phone6上能完美運(yùn)行的動效或交互動作,在iPhone6以下的手機(jī)上可能就會卡住不動了,所以不太適合用于CPU性能消耗較大的頻繁渲染。
不同機(jī)型的市場占比(15-16年數(shù)據(jù))
網(wǎng)絡(luò)的影響:如果你的動效在運(yùn)動時,還需要加載內(nèi)容,就要考慮網(wǎng)絡(luò)較慢時,內(nèi)容加載對動效流暢度的影響,這時可考慮先加載完內(nèi)容,再開始動效或簡化、壓縮加載的內(nèi)容量。如下圖所示,在Web內(nèi)容區(qū),當(dāng)點(diǎn)擊圖片后,該圖片放大(系統(tǒng)默認(rèn)的縮放動效,對CPU性能消耗小),但其它圖片自動重新排列的動效會比較消耗CPU性能,在低端機(jī)器上會出現(xiàn)卡頓或閃退的情況,并且還會受到網(wǎng)速的影響,導(dǎo)致體驗(yàn)不友好,如果必須做復(fù)雜動效,可以讓該動效只出現(xiàn)在高端機(jī)型中。
圖片縮放的重新排列動效
3、平臺兼容
由于Hybrid App的Web內(nèi)容,是不同的平臺共用同一套設(shè)計(jì)方案,所以為了更好地讓設(shè)計(jì)方案兼容不同的平臺特性和手機(jī)分辨率,所以建議文案和圖形采用以下三種方式:
系統(tǒng)默認(rèn)字體:如果不是為了設(shè)計(jì)出特殊的字體樣式,iOS、Android和Windows Phone系統(tǒng)的默認(rèn)字體(圖9)是基本滿足我們的需求,同時在不同平臺上的顯示效果也會比較好。
系統(tǒng)默認(rèn)字體
可縮放矢量圖形:能夠自由縮放大小來適應(yīng)不同屏幕尺寸和分辨率,不會模糊變形:
SVG(可縮放矢量圖形)
Iconfont來代替圖標(biāo):能夠自由變換大小和顏色:
Iconfont圖標(biāo)
采用這三種方式不僅可以很好適配不同機(jī)型和屏幕尺寸,而且還不會增加安裝包的大小。如果按鈕上的“精選尖貨放心購”采用的不是Iconfont和系統(tǒng)默認(rèn)字體,則在不同尺寸的屏幕上的顯示效果會很難控制,有被拉伸變形或模糊的風(fēng)險。
圖標(biāo)和字體在不同尺寸屏幕上的顯示效果
4、交互行為
由于Hybrid App主要是通過網(wǎng)頁的CSS樣式結(jié)構(gòu)和JavaScript程序語言來還原界面的設(shè)計(jì)和交互行為,所以跟純Native App技術(shù)框架相比,需要通過更繁瑣的代碼和層級請求才能實(shí)現(xiàn)跟原生系統(tǒng)一樣的交互方式,雖然也可模擬Native App的交互方式,但這樣的模擬首先提高了開發(fā)成本,有悖于不影響性能和高效的原則,所以需要根據(jù)設(shè)計(jì)目標(biāo)來合理選擇是否需要跟系統(tǒng)交互保持一致。
如下圖所示,如果“每日贏寶箱”的頁面是純Native框架搭建的,則當(dāng)用戶點(diǎn)擊“參與互動拿紅包”的卡片后,下一個頁面會采用iOS系統(tǒng)默認(rèn)的自右向左切入的交互方式。
系統(tǒng)默認(rèn)的交互方式
然而,由于這里采用的是Hybirid App技術(shù)框架,所以會像網(wǎng)頁一樣,直接變換內(nèi)容區(qū)的信息(下圖),因?yàn)檫@樣的實(shí)現(xiàn)方式更高效和不影響性能,更重要的是如果該頁面采用直接變換內(nèi)容的方式不會影響到用戶的使用體驗(yàn),這里就可以考慮不需要跟系統(tǒng)交互保持一致。
直接變換內(nèi)容區(qū)的交互方式
5、加載方式
對于Hybrid App框架的頁面,由于同時存在Native和Web部分,所以在加載內(nèi)容時,可以分開考慮加載方式:
Native部分:可以根據(jù)需要把常規(guī)內(nèi)容存儲在用戶的手機(jī)上,加快加載的時間和減少重復(fù)加載相同內(nèi)容的麻煩。
Web部分:Web內(nèi)容區(qū)域是需要從網(wǎng)絡(luò)上加載內(nèi)容的,尤其在網(wǎng)絡(luò)條件不好時,需要設(shè)計(jì)友好的等待狀態(tài),緩和用戶的焦慮情緒。
如下圖所示,可以根據(jù)不同的框架,來設(shè)計(jì)不同的加載方式,讓等待過程更短或更愉悅。
根據(jù)技術(shù)框架來設(shè)計(jì)加載方式
1、明確設(shè)計(jì)方案的主流程
在技術(shù)面前,設(shè)計(jì)是否只能妥協(xié)呢?答案是否定的,在對應(yīng)的App技術(shù)框架下,我們在考慮設(shè)計(jì)方案時,要明確設(shè)計(jì)方案的主流程和支流程,凡是會影響到方案核心的主流程的方案,即使開發(fā)的實(shí)現(xiàn)難度和成本較高,我們也要持續(xù)推動技術(shù)的突破,來為用戶提供更好的使用體驗(yàn),而對于方案的支流程,我們就可以跟開發(fā)協(xié)商不同的解決方案,明確哪些地方可以調(diào)整技術(shù)實(shí)現(xiàn)方式或換一種設(shè)計(jì)方案,哪些方案存在風(fēng)險,需要有備選方案。
設(shè)計(jì)方案的主流程和支流程
如下圖所示,在設(shè)計(jì)手機(jī)淘寶店鋪的標(biāo)簽?zāi)K時,由于大部分商家會根據(jù)寶貝圖的特點(diǎn),來設(shè)置圖上標(biāo)簽的內(nèi)容和位置,可是,由于店鋪的技術(shù)框架不支持標(biāo)簽移動的功能,而我們的設(shè)計(jì)目標(biāo)和方案的主流程就是要為商家提供更靈活設(shè)置寶貝標(biāo)簽的功能,所以即使技術(shù)實(shí)現(xiàn)難度和成本較高,我們也推動技術(shù)進(jìn)行突破,實(shí)現(xiàn)標(biāo)簽的可移動功能。
店鋪的標(biāo)簽?zāi)K(上圖的浮動標(biāo)簽)
2、提前與開發(fā)溝通設(shè)計(jì)想法的可行性
我們分析完產(chǎn)品需求后,可以先簡單地在紙上畫出粗獷的交互原型,然后,跟開發(fā)溝通想法的可行性及實(shí)現(xiàn)難度,做到心中有數(shù)。如果方案中涉及動效設(shè)計(jì),可通過紙片來錄制粗略的動效,或拿出自己平時收集的動效素材與開發(fā)溝通可行性,來快速驗(yàn)證設(shè)計(jì)想法。
常見典型動效素材
“世上沒有完美的設(shè)計(jì),因?yàn)槟阕罱K能做的就是在各種關(guān)系之間取得平衡”
在項(xiàng)目中,設(shè)計(jì)師往往需要權(quán)衡商業(yè)目標(biāo)、用戶體驗(yàn)和技術(shù)實(shí)現(xiàn)三者之間的關(guān)系來做設(shè)計(jì)方案,以上只是介紹App技術(shù)框架的基本知識,讓產(chǎn)品經(jīng)理在做方案時更有把握。
在純原生之外,前有ReactNative,Weex的混合開發(fā)方案,可以快速開發(fā)APP,后有微信小程序等的移動端替代方案,技術(shù)上的分流代表著原生開發(fā)者的市場被剝削。但總體上來看,匹配公司發(fā)展前景的App端的開發(fā)技術(shù)才是好技術(shù)。
UI設(shè)計(jì)的朋友肯定都有所感受,當(dāng)你滿懷激動的拿著方案去給開發(fā)程序猿講解的天花亂墜時,開發(fā)程序猿就會突然蹦出來一句話“這個方案實(shí)現(xiàn)不了”,然后此時的你話未落身先死,瞬間就整個人就不好了!那么,又有什么用呢?接下來的日子可想而知就是在產(chǎn)品經(jīng)理和開發(fā)程序猿的不斷催促下進(jìn)行著無數(shù)的加班和改方案。
那有些朋友就會非常的不理解,問題到底出現(xiàn)在哪兒呢?這其實(shí)就是設(shè)計(jì)師對于APP技術(shù)框架知識的匱乏,雖然不用寫代碼,但掌握基本的app技術(shù)框架原理,能更加有效的幫助我們預(yù)判哪些方案行之有效。所以今天,各位看官跟著大狗共同了解一下APP的技術(shù)框架都有哪些吧。
三種技術(shù)框架之間的關(guān)系
● Native App:一種基于智能移動設(shè)備本地操作系統(tǒng)(如iOS、Android、WP操作系統(tǒng)),并使用對應(yīng)系統(tǒng)所適用的程序語言編寫運(yùn)行的第三方應(yīng)用程序,由于它是直接與操作系統(tǒng)對接,代碼和界面都是針對所運(yùn)行的平臺開發(fā)和設(shè)計(jì)的,能很好地發(fā)揮出設(shè)備的性能,所以交互體驗(yàn)會更流暢。
● Web App:一種采用Html語言編寫的,存在于智能移動設(shè)備瀏覽器中的應(yīng)用程序,不需要下載安裝,可以說是觸屏版的網(wǎng)頁應(yīng)用,由于它不依賴于操作系統(tǒng),因此開發(fā)了一款Web App后,基本能應(yīng)用于各種系統(tǒng)平臺。
● Hybrid App:一種用Native技術(shù)來搭建App的外殼,殼里的內(nèi)容由Web技術(shù)來提供的移動應(yīng)用,兼具“Native App良好交互體驗(yàn)的優(yōu)勢”和“Web App跨平臺開發(fā)的優(yōu)勢”。
對于設(shè)計(jì)師而言,我們往往是被告知這個項(xiàng)目采用的是哪種技術(shù)框架,然后就開始設(shè)計(jì)了,其實(shí),我們也可以根據(jù)產(chǎn)品特點(diǎn)、框架特點(diǎn)和項(xiàng)目時間來與產(chǎn)品和開發(fā)部門協(xié)商,合理地為App中不同的部分選擇對應(yīng)技術(shù)框架,然后再在對應(yīng)的技術(shù)框架下思考設(shè)計(jì)方案。
由于Hybrid APP是融合了Native APP的技術(shù)特點(diǎn),通過分析Hybrid APP的技術(shù)框架成分,能讓我們更好的掌握APP框架的基本開發(fā)知識,有助于我們更好的去做設(shè)計(jì)。
Hybrid APP的大部分內(nèi)容都是在Native框架中加載Web網(wǎng)頁內(nèi)容,能在保證用戶體驗(yàn)的前提下,讓APP的內(nèi)容更具有廣闊性,即使接入再多的內(nèi)容和業(yè)務(wù)功能,也不造成整個APP的安裝包過大。典型Hybrid APP的代表就是我們的手機(jī)淘寶客戶端,Hybrid APP在設(shè)計(jì)時,要注意以下五個要點(diǎn):
● 圖像渲染
Native技術(shù)部分由于能直接調(diào)用系統(tǒng)的渲染引擎,所以能實(shí)現(xiàn)流暢的復(fù)雜圖像渲染,而不影響設(shè)備的性能。
Web內(nèi)容部分由于是基于內(nèi)置瀏覽器,在圖像渲染的時候要通過瀏覽器訪問系統(tǒng)的渲染引擎或調(diào)用基于瀏覽器的第三方渲染引擎,中間需要在多個層級進(jìn)行渲染請求,所以渲染的時效性和性能會下降不少,導(dǎo)致較復(fù)雜的圖像渲染或動態(tài)渲染時,會出現(xiàn)機(jī)器卡頓。
如圖所示,由于標(biāo)題欄采用了Native技術(shù)框架,可采用復(fù)雜的毛玻璃效果,讓標(biāo)題欄更通透,而內(nèi)容區(qū)采用了基于Html5的Web技術(shù),因此不適合動態(tài)變換背景圖的渲染方案(當(dāng)圖片輪播時,背景圖會隨著圖片內(nèi)容而動態(tài)變換出模糊的背景)。
● 動效體驗(yàn)
由于Hybrid App的內(nèi)容區(qū)大部分采用基于Html5的Web技術(shù),對動效的解釋和操作需要消耗大量的CPU性能,在設(shè)計(jì)時,要注意以下三個方面:
1.不同的動效類型對CPU性能的消耗不同:對CPU性能要求低的動效類型能運(yùn)行得更流暢,但如果當(dāng)你的設(shè)計(jì)方案是非系統(tǒng)自帶的動效類型時,就需要提前跟開發(fā)溝通可行性和對CPU性能的消耗問題。
2.機(jī)型的性能差異:不同的手機(jī)機(jī)型的CPU性能相差較大,需要了解不同機(jī)型在你的App中的占比,因?yàn)榧丛趇Phone6上能完美運(yùn)行的動效或交互動作,在iPhone6以下的手機(jī)上可能就會卡住不動了,所以不太適合用于CPU性能消耗較大的頻繁渲染。
3.網(wǎng)絡(luò)的影響:如果你的動效在運(yùn)動時,還需要加載內(nèi)容,就要考慮網(wǎng)絡(luò)較慢時,內(nèi)容加載對動效流暢度的影響,這時可考慮先加載完內(nèi)容,再開始動效或簡化、壓縮加載的內(nèi)容量。
不同的動效類型對CPU的性能要求
如下圖所示,在Web內(nèi)容區(qū),當(dāng)點(diǎn)擊圖片后,該圖片放大(系統(tǒng)默認(rèn)的縮放動效,對CPU性能消耗小),但其它圖片自動重新排列的動效會比較消耗CPU性能,在低端機(jī)器上會出現(xiàn)卡頓或閃退的情況,并且還會受到網(wǎng)速的影響,導(dǎo)致體驗(yàn)不友好,如果必須做復(fù)雜動效,可以讓該動效只出現(xiàn)在高端機(jī)型中。
● 平臺兼容
由于Hybrid APP的WEB內(nèi)容,是不同的平臺公用同一套設(shè)計(jì)方案,所以為了更好的讓設(shè)計(jì)方案兼容不同平臺的手機(jī)特性和手機(jī)分辨率,所以建議文案和圖形采用以下三種方式:
1.系統(tǒng)默認(rèn)字體:如果不是為了設(shè)計(jì)出特殊的字體樣式,iOS、Android和Windows Phone系統(tǒng)的默認(rèn)字體可以基本滿足我們的需求,同時在不同平臺上的顯示效果也會比較好。
2. SVG(可縮放矢量圖形):能夠自由縮放大小來適應(yīng)不同屏幕尺寸和分辨率,不會模糊變形。
3. Iconfont來代替圖標(biāo):能夠自由變換大小和顏色。
● 交互行為
由于Hybrid App主要是通過網(wǎng)頁的CSS樣式結(jié)構(gòu)和JavaScript程序語言來還原界面的設(shè)計(jì)和交互行為,所以跟純Native App技術(shù)框架相比,需要通過更繁瑣的代碼和層級請求才能實(shí)現(xiàn)跟原生系統(tǒng)一樣的交互方式,雖然也可模擬Native App的交互方式,但這樣的模擬首先提高了開發(fā)成本,有悖于不影響性能和高效的原則,所以需要根據(jù)設(shè)計(jì)目標(biāo)來合理選擇是否需要跟系統(tǒng)交互保持一致。
● 加載方式
對于Hybrid App框架的頁面,由于同時存在Native和Web部分,所以在加載內(nèi)容時,可以分開考慮加載方式:
Native部分:可以根據(jù)需要把常規(guī)內(nèi)容存儲在用戶的手機(jī)上,加快加載的時間和減少重復(fù)加載相同內(nèi)容的麻煩。
Web部分:Web內(nèi)容區(qū)域是需要從網(wǎng)絡(luò)上加載內(nèi)容的,尤其在網(wǎng)絡(luò)條件不好時,需要設(shè)計(jì)友好的等待狀態(tài),緩和用戶的焦慮情緒。
● 明確設(shè)計(jì)方案的主流程
在技術(shù)面前,設(shè)計(jì)是否只能妥協(xié)呢?答案是否定的,在對應(yīng)的APP技術(shù)框架下,要明確設(shè)計(jì)方案的主流程和分支流程,凡是會影響到核心的主流程方案,即使開發(fā)難度和成本較高,我們也要持續(xù)推動技術(shù)的突破,為用戶提供更好的使用體驗(yàn),而對于方案的分支流程,則可以跟開發(fā)協(xié)商不同的解決方案,明確哪些地方可以調(diào)整技術(shù)實(shí)現(xiàn)方式或者換一種設(shè)計(jì)方案,哪些方案存在風(fēng)險,需要有備選方案。
● 提前與開發(fā)溝通設(shè)計(jì)想法的可行性
我們分析完產(chǎn)品需求后,可以先簡單地在紙上畫出粗獷的交互原型,然后,跟開發(fā)溝通想法的可行性及實(shí)現(xiàn)難度,做到心中有數(shù)。如果方案中涉及動效設(shè)計(jì),可通過紙片來錄制粗略的動效,或拿出自己平時收集的動效素材與開發(fā)溝通可行性,來快速驗(yàn)證設(shè)計(jì)想法。
“世界上沒有完美的設(shè)計(jì),因?yàn)槟阕罱K能做的就是在各種關(guān)系之間取得平衡”--Paul Rand(美國著名設(shè)計(jì)師)
注本頭條號,專注做前端
今天要來分享的是一款原生JS插件 (因?yàn)橛蟹劢z提到要多分享一些原生JS) ,所以今天分享的這塊不依賴jquery,原生JS ,采用html5+canvas實(shí)現(xiàn)
它模擬了霧氣在玻璃上凝結(jié),玻璃模糊,并且水滴慢慢滑落的效果,及其逼真
//
*請認(rèn)真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。