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