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 為您開發(fā)的應(yīng)用的每一版本提供自動(dòng)全面的性能分析
在上一篇發(fā)布的博客中，我們討論了監(jiān)視app性能的重要性。這一回我們將要想大家詳細(xì)展示怎樣具體操作。我們和一些世界著名app的開發(fā)團(tuán)隊(duì)（其中包括微信和雅虎新聞聚合的團(tuán)隊(duì)）就開發(fā)流暢的app所需的最好的開發(fā)規(guī)范進(jìn)行過交談。就我們的經(jīng)驗(yàn)和同那些開發(fā)團(tuán)隊(duì)的Leader交談的結(jié)果來看，我們發(fā)現(xiàn)開發(fā)好的app最重要的規(guī)范是建立一套app優(yōu)化流程：
持續(xù)地監(jiān)測你的app的性能來檢測你的app是否表現(xiàn)不佳是非常重要的。一旦一項(xiàng)性能問題被檢測到，你應(yīng)當(dāng)集中精力去尋找問題的根源。這項(xiàng)診斷也許需要更多的檢測和優(yōu)化具體性能的數(shù)據(jù)，這會使你陷入一個(gè)我們所謂的“檢測—分析 循環(huán)”的陷阱相當(dāng)長的時(shí)間。即使在你搜尋到問題的根源后，僅僅修改好懶散的代碼是遠(yuǎn)不夠的。你必須重估你app的度量以確保你的修改奏效。這就意味著更多的檢測。
主要影響用戶體驗(yàn)的性能度量有兩種。第一種，我們主要關(guān)注響應(yīng)時(shí)間：你的app對一個(gè)用戶操作（比如：app的啟動(dòng)，看一篇新的文章，加載一個(gè)聯(lián)系人列表，或者是查看一個(gè)Facebook也頁面）的響應(yīng)需要多長時(shí)間。理想情況下，你的app對以上這些情景響應(yīng)都很迅速，這會使得你的app有更好，更吸引人的用戶體驗(yàn)。
關(guān)于響應(yīng)時(shí)間的一個(gè)關(guān)鍵（并且獨(dú)特）的例子是啟動(dòng)時(shí)間。app啟動(dòng)時(shí)間是一個(gè)用戶對一款app的第一印象，而第一印象是非常重要的。事實(shí)上，一項(xiàng)計(jì)算機(jī)軟件調(diào)查顯示79%的用戶會在刪除這個(gè)問題app之前再次嘗試一或兩次。
以下是在軟件性能和優(yōu)化方面有很多年經(jīng)驗(yàn)的NimbleDroid所給的一些建議。
我們建議你的app應(yīng)當(dāng)在2秒之內(nèi)完成啟動(dòng)，因?yàn)檫@是用戶所期待啟動(dòng)時(shí)間的中等水平。對于那些對web性能優(yōu)化很熟悉的人，47%的用戶希望一個(gè)頁面在2秒以內(nèi)加載完畢，用戶對于他們使用活躍的移動(dòng)app更缺少耐心。
第二重要的度量是流暢度。app在短時(shí)間內(nèi)響應(yīng)是很好的體驗(yàn)，但響應(yīng)同時(shí)必須流暢，盡量少的卡頓。用戶非常善于察覺卡頓，這也意味著即使微小的卡頓也會對你的app用戶體驗(yàn)有負(fù)面影響。一般來說，人類可以察覺22毫秒的卡頓，其中1/4的人可以洞察2毫秒—16毫秒的卡頓 — 即標(biāo)準(zhǔn)的60幀每秒的刷新率（FPS）。
要理解流暢度，你可以通過收集你的app的FPS和每幀耗時(shí)的數(shù)據(jù)。然而，你需要牢記：這些數(shù)據(jù)并不能告訴你app性能問題的根源，也不能幫你找出代碼里導(dǎo)致卡頓的方法。
對于Android手機(jī)，UI線程（你的app執(zhí)行的主線程）是唯一能更新UI的線程。為了保持60FPS的刷新率，UI線程必須在16毫秒內(nèi)完成每幀的繪制。如果UI線程里任何方法的調(diào)用耗時(shí)比這更長，你的app就會丟失一幀，造成短暫的卡頓。更糟糕的是在這段時(shí)間里，你的app對用戶的任何操作是不響應(yīng)的因?yàn)閁I線程被一個(gè)方法的調(diào)用給阻塞了。
按照常規(guī)來說，要想保證UI線程里每次的方法調(diào)用都在16毫秒以內(nèi)幾乎是不可能的。32毫秒是一個(gè)臨界值，相當(dāng)于丟掉2幀，也更加真是。我們把那些執(zhí)行時(shí)間超過這個(gè)臨界值（超過32毫秒執(zhí)行的）方法稱之為耗時(shí)方法，因?yàn)檫@些方法導(dǎo)致了這個(gè)app暫時(shí)“掛起”了。剔除所有耗時(shí)方法可以有效地使你的app表現(xiàn)更加流暢，整體上提供一個(gè)更好的用戶體驗(yàn)。
好吧。檢測那些和用戶體驗(yàn)有關(guān)的度量非常重要，但是我們檢測這些度量的頻率是多少呢？每次構(gòu)建的時(shí)候檢測？還是每天構(gòu)建的時(shí)候？或是發(fā)布之前？或是版本在生產(chǎn)環(huán)境中？！你應(yīng)該一有機(jī)會就檢測 — 你越是頻繁地追蹤你軟件的度量，你就越早地能察覺和對性能問題做出反應(yīng)。雅虎的團(tuán)隊(duì)告訴我們在每次他們的app發(fā)布前都有分析，微信的團(tuán)隊(duì)每天構(gòu)建的時(shí)候都分析他們的app。
優(yōu)化你的軟件的關(guān)鍵是了解常見的性能問題的和系統(tǒng)地在你的代碼中移除他們。在我們對app下載超過5M的文件時(shí)的性能問題分析中，我們發(fā)現(xiàn)開發(fā)者經(jīng)常使用那些在桌面機(jī)器上執(zhí)行很快卻在性能較弱的移動(dòng)設(shè)備上執(zhí)行非常慢的構(gòu)造方法。例如：在一臺Macbook Air上ClassLoader.getResourceAsStream()這個(gè)方法獲取一個(gè)有3K大小的jar包資源花費(fèi)7毫秒執(zhí)行完畢。然而2013年的Nexus 7 在同樣資源文件的情況下執(zhí)行該方法需要1700毫秒。原因是Android對getResourceAsStream這個(gè)方法的實(shí)現(xiàn)在第一次執(zhí)行的時(shí)候干了很多額外的工作，對apk文件中所有資源文件進(jìn)行了索引，驗(yàn)證授權(quán)的apk文件，解析它的manifest文件。類似這類的操作很耗費(fèi)CPU資源，導(dǎo)致app明顯減速，— getResourceAsStream使Walgreens大約減速1.7倍。NimbleDroid編了一個(gè)在你的app中可以避免這種情況的方法列表。你可以在這查看。
有時(shí)候性能問題是由你使用的第三方的SDK而不是你的代碼導(dǎo)致的。這些問題往往很難被追蹤到?？紤]到 org.joda.time是一個(gè)很流行的處理時(shí)間的java庫。你很可能在你以往的Java工程中用到了它。結(jié)果表明僅僅在app啟動(dòng)的時(shí)候創(chuàng)建一個(gè)org.joda.time.DateTime()對象會導(dǎo)致啟動(dòng)言重變慢 — Yahoo Fantasy Sports這款app會啟動(dòng)慢2秒。這是因?yàn)閛rg.joda.time.DateTime()使用了getResourceAsStream()這個(gè)方法來從apk文件中加載時(shí)區(qū)數(shù)據(jù)。
修改懶散的代碼可以是一個(gè)噩夢般的經(jīng)歷。造成app減緩、停止運(yùn)行的方法有很多，排除這些問題可能會花費(fèi)幾周的開發(fā)時(shí)間。與此同時(shí)，也有一些通用的修改建議。你可以一方面用更多高效的數(shù)據(jù)展現(xiàn)形式、算法和實(shí)現(xiàn)來使代碼運(yùn)行地更快，或者（在那些引用第三方SDK不能直接修改代碼的情況下）你可以調(diào)用子線程的代碼以確保UI不會等待。遵循這些建議會使你在讓app更加高效，創(chuàng)造用戶喜愛的產(chǎn)品的道路上走得更遠(yuǎn)。
通常需要寶貴的時(shí)間和一些靈感來使這個(gè)性能優(yōu)化過程幫助你打造更加流暢的app。這就是我們提供給Android開發(fā)者快速，強(qiáng)大的優(yōu)化分析工具的原因，以保證這些開發(fā)者可以更集中精力于你們所擅長的方面：給用戶帶來美妙的產(chǎn)品。
掃碼關(guān)注鍍金池微信號
手機(jī)訂課，優(yōu)惠多多
