如何讓你的App更流暢

本文由 伯樂在線 - sphynx 翻譯，zhengjunchenzjc 校稿。未經許可，禁止轉載！
英文出處：Junfeng Yang | Sarvar Dhillon。歡迎加入翻譯組。

在過往的博文中，咱們聊了監控App的性能的重要性。此次咱們就來給你示範具體怎麼操做。咱們向全球最流行的一些 App 的開發團隊（包括微信，雅虎新聞摘要）取經了開發流暢 App 的最佳實踐經驗。經過咱們本身的經驗以及與這些頂尖開發者的交流，咱們發現開發優秀 App 最重要的實踐經驗是創建一個性能優化的流程：

優化過程

當你的 App 性能不佳時，持續測量 App 的性能表現就變得尤其重要。一旦檢測出性能問題，你應專一於對問題尋根溯源。診斷可能還會用到更多的測量和詳細的性能數據，使你一段時間內陷入咱們稱之爲「測量-分析循環」的怪圈。即便在找到問題的根本緣由後，光修復爛代碼還不夠。你還得從新驗證各項指標來肯定修復是有效的。這就意味着更多的測量。

測量

有兩個最爲影響用戶體驗 (UX) 的性能指標。第一，咱們要注意的是響應時間：你的 App 要花多久時間來響應用戶的操做 (好比啓動 App， 瀏覽新文章， 加載聯繫人名單， 或者打開 Facebook 頁面)。假如你的 App 在全部上述情景中都能迅速響應，這將幫助你創建一個更好更完美的用戶體驗。

一個關鍵（而獨特）的響應時間的例子是啓動時間。App 的啓動是裝了這個 App 的用戶的第一次用戶體驗， 而第一印象又是最重要的。事實是，有關於軟件的研究發現79%的用戶在裝了有啓動問題的 App 後只重試了一兩次就卸載了。

如下是 NimbleDroid 團隊 給出的一些建議，他們在軟件性能及優化領域有着多年經驗。

咱們建議不要讓你的 App 花在啓動上的時間超過兩秒，由於這是用戶期待中 App 啓動的平均時間。熟悉網頁性能的都知道，47%的用戶但願頁面能在兩秒之內加載完畢，而用戶們在外趕時間時花在移動端 App 上的耐心就更少了。

建議一：兩秒內使 App 啓動

第二個重要指標是流暢度。即便一個 App 整體上來看響應時間很短，響應自己必須也要流暢，使「卡頓」儘量少。用戶對時間上的卡頓很是敏感，意味着即便是小小的頓挫也會影響用戶體驗。平均來講，人眼能分辨小到 22 毫秒的卡頓，而四分之一的人羣能察覺 2 毫秒到 16 毫秒的卡頓 – 60幀每秒 (FPS) 的刷新率就是根據這個原理。

你能夠從你的 App 的 FPS 和幀時間數據得出 App 的流暢度。然而請注意這數據不會告訴你你的 App 的性能問題根源所在，這就意味着它無法幫你找到 App 卡頓的 method。

在安卓系統中，用戶界面 (UI) 線程 (你的 App 執行的主線程) 是惟一能對用戶界面進行更新的線程。要保持一個 60 FPS 的刷新率，UI線程必須在每 16 毫秒內完成一幀的繪製。若是在 UI 線程上的任何 method 的調用時間超出了這一時間， 你的 App 就會掉幀， 產生時間上的卡頓。更糟的是此時你的 App 對任何的用戶操做都無響應，由於 UI 線程還在被這個 method 調用所佔據。

實際上，要確保 UI 線程的每個 method 的調用時間都少於16毫秒是幾乎不可能的。32 毫秒的門檻值，至關於兩個幀的長度，才更合理。咱們把超出這個門檻值 (執行時間超出32毫秒) 的 methods 叫作掛起 methods，由於它們使得 App 看上去「掛起」了。爲了使你的 App 絲般順滑，收穫更佳的用戶體驗， 消除全部的掛起 methods 將大有裨益。

建議二：消除掛起 methods

好吧。既然測量同用戶體驗相關的指標是如此重要，那麼咱們該多久測量一次指標呢？每一個版本？每一個日版本？在每次發佈以前？在生產中？!你應當一有機會就進行測量 —— 測量的頻率越高，你就能越早發現和補救性能問題。同咱們交流的 Yahoo 團隊在每次發佈前對 App 的性能進行採樣，而微信團隊對每一個日版本進行性能採樣。

建議三：儘量多測量

分析

優化你的軟件的關鍵是找到常規的性能問題並系統地從你的代碼中剔除。在對有着超過五百萬次下載記錄的 App 的性能問題分析中，咱們觀察到開發者常用在桌面端高效卻在移動端低效的代碼結構。舉個例子，在一臺 MacBook Air 上一個 JAR 文件調用methodClassLoader.getResourceAsStream() 處理3K 資源的花銷約爲 7 毫秒， 而在一臺 2013 年的 Nexus 7 上一個 APK 文件調用這個 method 一樣處理3K 資源的花銷約爲 1700 毫秒。後來發現，安卓對於getResourceAsStream 的執行是在第一次調用時作了大量的額外工做，如爲 APK 文件裏的全部資源編排索引，驗證 APK 文件的證書， 並解析其 manifest。這種操做是至關耗費 CPU 資源的，從而致使 App 的嚴重時滯 ——getResourceAsStream 給 Walgreens App 形成了 1.7 秒的時滯。在NimbleDroid，咱們列出了一份應該避免在你的安卓 App 中使用的 methods 清單。請戳這裏。

建議四：瞭解一些通病

有時性能問題是由你使用的第三方 SDKs 引發的，而並不是你的代碼。這些問題就很難被發現。譬如說org.joda.time ，Java中一個流行的時間庫。你可能在以往的Java項目上使用過它。結果僅僅是建立一個 org.joda.time.DateTime() 對象就形成了巨大的時滯 —— Yahoo Fantasy Sports App 性能被它拖慢了兩秒之多。這是由於org.joda.time.DateTime() 使用getResourceAsStream() 來從 APK 文件加載時區數據。

建議五：避免第三方 SDKs 帶來的麻煩

優化

修復爛代碼可能成爲噩夢般的過程。要從上百個進程中找出拖慢 App 的進程，這種尋根溯源的任務可能會佔據數週的開發週期。儘管如此，仍是有一些通用的指導方針的。使用更有效的數據表現方式，算法，和執行方式或（萬一你使用的是SDK從而沒法直接修復代碼的話）在後臺線程調用代碼而避免掛起在 UI 線程發生，這裏面任意一種方式，都能使你的代碼運行得更快。遵循這些指導方針使 App 更有效率，大大有益於創造出人見人愛的產品。

去哪尋求幫助

儘管性能優化過程幫助你的 App 運行順暢，它也須要花費時間和一點點魔力來實施。這正是爲何咱們要開發安卓快速開發，強力優化以及性能採樣工具的緣由，這樣大家就能不分心地專一於大家的強項：爲用戶帶來了不得的產品。

問啊-定製化IT教育平臺，牛人一對一服務，有問必答，開發編程社交頭條 官方網站：www.wenaaa.com 下載問啊APP，參與官方懸賞，賺百元現金。

QQ羣290551701 彙集不少互聯網精英，技術總監，架構師，項目經理！開源技術研究，歡迎業內人士，大牛及新手有志於從事IT行業人員進入！