鍍金池/ 教程/ Java/ 如何使你的app更加流暢
如何使你的app更加流暢
如何使你的app更加流暢

如何使你的app更加流暢

http://wiki.jikexueyuan.com/project/lvning/images/topapp1.jpg" alt="" />

原文鏈接:http://blog.nimbledroid.com/2015/09/17/how-to-make-your-application-fluid.html

Nimbledroid.com 為您開(kāi)發(fā)的應(yīng)用的每一版本提供自動(dòng)全面的性能分析

正文

在上一篇發(fā)布的博客中,我們討論了監(jiān)視app性能的重要性。這一回我們將要想大家詳細(xì)展示怎樣具體操作。我們和一些世界著名app的開(kāi)發(fā)團(tuán)隊(duì)(其中包括微信和雅虎新聞聚合的團(tuán)隊(duì))就開(kāi)發(fā)流暢的app所需的最好的開(kāi)發(fā)規(guī)范進(jìn)行過(guò)交談。就我們的經(jīng)驗(yàn)和同那些開(kāi)發(fā)團(tuán)隊(duì)的Leader交談的結(jié)果來(lái)看,我們發(fā)現(xiàn)開(kāi)發(fā)好的app最重要的規(guī)范是建立一套app優(yōu)化流程:

1

優(yōu)化過(guò)程

持續(xù)地監(jiān)測(cè)你的app的性能來(lái)檢測(cè)你的app是否表現(xiàn)不佳是非常重要的。一旦一項(xiàng)性能問(wèn)題被檢測(cè)到,你應(yīng)當(dāng)集中精力去尋找問(wèn)題的根源。這項(xiàng)診斷也許需要更多的檢測(cè)和優(yōu)化具體性能的數(shù)據(jù),這會(huì)使你陷入一個(gè)我們所謂的“檢測(cè)—分析 循環(huán)”的陷阱相當(dāng)長(zhǎng)的時(shí)間。即使在你搜尋到問(wèn)題的根源后,僅僅修改好懶散的代碼是遠(yuǎn)不夠的。你必須重估你app的度量以確保你的修改奏效。這就意味著更多的檢測(cè)。

檢測(cè)

主要影響用戶(hù)體驗(yàn)的性能度量有兩種。第一種,我們主要關(guān)注響應(yīng)時(shí)間:你的app對(duì)一個(gè)用戶(hù)操作(比如:app的啟動(dòng),看一篇新的文章,加載一個(gè)聯(lián)系人列表,或者是查看一個(gè)Facebook也頁(yè)面)的響應(yīng)需要多長(zhǎng)時(shí)間。理想情況下,你的app對(duì)以上這些情景響應(yīng)都很迅速,這會(huì)使得你的app有更好,更吸引人的用戶(hù)體驗(yàn)。

關(guān)于響應(yīng)時(shí)間的一個(gè)關(guān)鍵(并且獨(dú)特)的例子是啟動(dòng)時(shí)間。app啟動(dòng)時(shí)間是一個(gè)用戶(hù)對(duì)一款app的第一印象,而第一印象是非常重要的。事實(shí)上,一項(xiàng)計(jì)算機(jī)軟件調(diào)查顯示79%的用戶(hù)會(huì)在刪除這個(gè)問(wèn)題app之前再次嘗試一或兩次。

以下是在軟件性能和優(yōu)化方面有很多年經(jīng)驗(yàn)的NimbleDroid所給的一些建議。

我們建議你的app應(yīng)當(dāng)在2秒之內(nèi)完成啟動(dòng),因?yàn)檫@是用戶(hù)所期待啟動(dòng)時(shí)間的中等水平。對(duì)于那些對(duì)web性能優(yōu)化很熟悉的人,47%的用戶(hù)希望一個(gè)頁(yè)面在2秒以?xún)?nèi)加載完畢,用戶(hù)對(duì)于他們使用活躍的移動(dòng)app更缺少耐心。

建議 1:顯示app啟動(dòng)時(shí)間在2秒以?xún)?nèi)

第二重要的度量是流暢度。app在短時(shí)間內(nèi)響應(yīng)是很好的體驗(yàn),但響應(yīng)同時(shí)必須流暢,盡量少的卡頓。用戶(hù)非常善于察覺(jué)卡頓,這也意味著即使微小的卡頓也會(huì)對(duì)你的app用戶(hù)體驗(yàn)有負(fù)面影響。一般來(lái)說(shuō),人類(lèi)可以察覺(jué)22毫秒的卡頓,其中1/4的人可以洞察2毫秒—16毫秒的卡頓 — 即標(biāo)準(zhǔn)的60幀每秒的刷新率(FPS)。

要理解流暢度,你可以通過(guò)收集你的app的FPS和每幀耗時(shí)的數(shù)據(jù)。然而,你需要牢記:這些數(shù)據(jù)并不能告訴你app性能問(wèn)題的根源,也不能幫你找出代碼里導(dǎo)致卡頓的方法。

對(duì)于Android手機(jī),UI線(xiàn)程(你的app執(zhí)行的主線(xiàn)程)是唯一能更新UI的線(xiàn)程。為了保持60FPS的刷新率,UI線(xiàn)程必須在16毫秒內(nèi)完成每幀的繪制。如果UI線(xiàn)程里任何方法的調(diào)用耗時(shí)比這更長(zhǎng),你的app就會(huì)丟失一幀,造成短暫的卡頓。更糟糕的是在這段時(shí)間里,你的app對(duì)用戶(hù)的任何操作是不響應(yīng)的因?yàn)閁I線(xiàn)程被一個(gè)方法的調(diào)用給阻塞了。

按照常規(guī)來(lái)說(shuō),要想保證UI線(xiàn)程里每次的方法調(diào)用都在16毫秒以?xún)?nèi)幾乎是不可能的。32毫秒是一個(gè)臨界值,相當(dāng)于丟掉2幀,也更加真是。我們把那些執(zhí)行時(shí)間超過(guò)這個(gè)臨界值(超過(guò)32毫秒執(zhí)行的)方法稱(chēng)之為耗時(shí)方法,因?yàn)檫@些方法導(dǎo)致了這個(gè)app暫時(shí)“掛起”了。剔除所有耗時(shí)方法可以有效地使你的app表現(xiàn)更加流暢,整體上提供一個(gè)更好的用戶(hù)體驗(yàn)。

建議 2:剔除耗時(shí)方法

好吧。檢測(cè)那些和用戶(hù)體驗(yàn)有關(guān)的度量非常重要,但是我們檢測(cè)這些度量的頻率是多少呢?每次構(gòu)建的時(shí)候檢測(cè)?還是每天構(gòu)建的時(shí)候?或是發(fā)布之前?或是版本在生產(chǎn)環(huán)境中?!你應(yīng)該一有機(jī)會(huì)就檢測(cè) — 你越是頻繁地追蹤你軟件的度量,你就越早地能察覺(jué)和對(duì)性能問(wèn)題做出反應(yīng)。雅虎的團(tuán)隊(duì)告訴我們?cè)诿看嗡麄兊腶pp發(fā)布前都有分析,微信的團(tuán)隊(duì)每天構(gòu)建的時(shí)候都分析他們的app。

建議 3:盡可能頻繁地檢測(cè)

分析

優(yōu)化你的軟件的關(guān)鍵是了解常見(jiàn)的性能問(wèn)題的和系統(tǒng)地在你的代碼中移除他們。在我們對(duì)app下載超過(guò)5M的文件時(shí)的性能問(wèn)題分析中,我們發(fā)現(xiàn)開(kāi)發(fā)者經(jīng)常使用那些在桌面機(jī)器上執(zhí)行很快卻在性能較弱的移動(dòng)設(shè)備上執(zhí)行非常慢的構(gòu)造方法。例如:在一臺(tái)Macbook Air上ClassLoader.getResourceAsStream()這個(gè)方法獲取一個(gè)有3K大小的jar包資源花費(fèi)7毫秒執(zhí)行完畢。然而2013年的Nexus 7 在同樣資源文件的情況下執(zhí)行該方法需要1700毫秒。原因是Android對(duì)getResourceAsStream這個(gè)方法的實(shí)現(xiàn)在第一次執(zhí)行的時(shí)候干了很多額外的工作,對(duì)apk文件中所有資源文件進(jìn)行了索引,驗(yàn)證授權(quán)的apk文件,解析它的manifest文件。類(lèi)似這類(lèi)的操作很耗費(fèi)CPU資源,導(dǎo)致app明顯減速,— getResourceAsStream使Walgreens大約減速1.7倍。NimbleDroid編了一個(gè)在你的app中可以避免這種情況的方法列表。你可以在這查看。

建議 4:了解一系列的常見(jiàn)問(wèn)題

有時(shí)候性能問(wèn)題是由你使用的第三方的SDK而不是你的代碼導(dǎo)致的。這些問(wèn)題往往很難被追蹤到??紤]到 org.joda.time是一個(gè)很流行的處理時(shí)間的java庫(kù)。你很可能在你以往的Java工程中用到了它。結(jié)果表明僅僅在app啟動(dòng)的時(shí)候創(chuàng)建一個(gè)org.joda.time.DateTime()對(duì)象會(huì)導(dǎo)致啟動(dòng)言重變慢 — Yahoo Fantasy Sports這款app會(huì)啟動(dòng)慢2秒。這是因?yàn)閛rg.joda.time.DateTime()使用了getResourceAsStream()這個(gè)方法來(lái)從apk文件中加載時(shí)區(qū)數(shù)據(jù)。

建議 5:避免第三方SDK所導(dǎo)致的意外

優(yōu)化

修改懶散的代碼可以是一個(gè)噩夢(mèng)般的經(jīng)歷。造成app減緩、停止運(yùn)行的方法有很多,排除這些問(wèn)題可能會(huì)花費(fèi)幾周的開(kāi)發(fā)時(shí)間。與此同時(shí),也有一些通用的修改建議。你可以一方面用更多高效的數(shù)據(jù)展現(xiàn)形式、算法和實(shí)現(xiàn)來(lái)使代碼運(yùn)行地更快,或者(在那些引用第三方SDK不能直接修改代碼的情況下)你可以調(diào)用子線(xiàn)程的代碼以確保UI不會(huì)等待。遵循這些建議會(huì)使你在讓app更加高效,創(chuàng)造用戶(hù)喜愛(ài)的產(chǎn)品的道路上走得更遠(yuǎn)。

你能得到幫助的地方

通常需要寶貴的時(shí)間和一些靈感來(lái)使這個(gè)性能優(yōu)化過(guò)程幫助你打造更加流暢的app。這就是我們提供給Android開(kāi)發(fā)者快速,強(qiáng)大的優(yōu)化分析工具的原因,以保證這些開(kāi)發(fā)者可以更集中精力于你們所擅長(zhǎng)的方面:給用戶(hù)帶來(lái)美妙的產(chǎn)品。