開發app怎么提高運行速度？

App運行速度分析以及初步優化方案

一、 App運行速度分析

(1)硬件約束

CPU主頻，多核；

CPU主頻決定手機的運算速度，多核則更多體現在并發任務方面。

內存：運存與內存（RAM+ROM）

圖1-1 移動端內存示例圖

運存是指手機運行程序時的內存，也叫RAM簡稱運存；RAM越大，手機可運行的APP應用程序越多，運行越流暢，目前RAM基本是2GB夠用，3GB流暢，4GB極佳。

內存是指手機的存儲控件，也叫ROM；ROM越大，手機儲存的文件空間越多，目前ROM基本是16GB，32GB，64GB；ROM不影響手機的運行速度。

當運存（RAM）匱乏時，運行大型APP會出現卡頓、黑屏甚至出現暫時性卡死狀態。

在運存不夠時可以采取手動關閉后臺不必要的程序進行釋放，或者通過手機管理軟件進行內存釋放，例如手機管家、手機安全衛士等。

(2)網絡環境影響以及服務器接口環境

網絡狀況直接影響業務型APP的體驗，例如用戶登陸業務；登陸時手機端需要向服務器發送用戶的登錄名及密碼等信息，服務器進行信息核對后返回登陸狀態指令，手機端接收到返回信息進行業務跳轉。登陸業務只需要進行一次接口調用，在網絡和服務器環境都理想的情況下，http三次握手時間可以控制在1秒以內。綜合考慮手機端網絡以及服務器環境，登陸控制在2.5秒內是可以被用戶接受的。

手機端針對網絡環境可采取相應的緩存策略以降低服務器的頻繁訪問，從直觀上提高頁面響應速度。根據業務級別提供相對可靠的有損服務，可采用懶加載、延遲異步加載等方式降低服務器壓力。

對于服務器可采用緩存服務器、分布式服務器、反向代理等方式進行數據提供業務，對于圖片、視頻等媒體資源采用CDN進行加速。服務器端的優化性能提高率遠大于手機端優化的提高率。

(3)View的繪制過程

Measure(計算) -> Layout(定位) -> Draw(繪制)

整個View樹的繪圖流程是在ViewRoot.java類的performTraversals()函數展開的，函數做的執行過程可簡單概況為根據之前設置的狀態，判斷是否需要重新計算視圖大小(measure)、是否重新需要安置視圖的位置(layout)、以及是否需要重繪(draw)，其框架過程如下：

圖 1-2 View繪制流程示例圖

View的繪制時間可以利用hierarchyviewer工具進行查看。

圖1-3 hierarchyviewer示例圖

上圖Measure為0.089ms，Layout為0.115ms，Draw為1.088ms，該view的繪制總耗時為1.292ms。

(4)16ms原則

目前大多數手機的屏幕刷新頻率是60hz，如果在1000/60=16.67ms內沒有辦法把這一幀的任務執行完畢，就會發生丟幀的現象。丟幀越多，用戶感受到的卡頓情況就越嚴重。16ms時間很短，身為一名應用開發者，為了讓用戶有更好的體驗，應該要充分利用這16ms，確保刷新一幀的時候在16ms內。

圖1-4 UI刷新示例圖

如果你的某個操作花費時間是24ms，系統在得到VSYNC信號的時候就無法進行正常渲染，這樣就發生了丟幀現象。那么用戶在32ms內看到的會是同一幀畫面。

圖1-5丟幀示例圖

優化16ms問題可以通過盡可能減少過度繪制，減少布局嵌套，盡可能不要在UI線程做過多耗時操作。

(5)OverDraw過度繪制

當設計上追求更華麗的視覺效果的時候，我們就容易陷入采用復雜的多層次重疊視圖來實現這種視覺效果的怪圈。這這很容易導致大量的性能問題，為了獲得最佳的性能，我們必須盡量減少Overdraw的情況發生。

圖 1-6 過度繪制四種級別示例圖

藍色、淡綠、淡紅、深紅代表了4種不同程度的Overdraw情況，我們的目標就是盡量減少紅色Overdraw，看到更多的藍色區域。

(6)GC垃圾回收

GC一般耗時在幾毫秒到幾百毫秒之間，然而對于手機16ms渲染機制來說，GC會帶來不小的開銷，所以在開發過程中盡量避免顯示調用GC。頻繁GC會導致頁面卡頓，當執行GC操作時，任何線程都進入暫停狀態，等待GC操作結束后才能夠繼續運行。導致頻繁GC有兩個原因：

1、 內存抖動，即大量的對象被創建后又在短時間內立刻被釋放

2、 瞬間產生大量的對象會嚴重占用Young Generation的內存區域，當達到閥值時會觸發GC過程。

以上這些GC操作可能會造成丟幀情況，如下圖：

圖 1-7 GC時丟幀示例圖

24ms的GC形成了丟幀，用戶感知到頁面卡頓。

(7)同步任務過多

頁面啟動時同步任務過多會在短期內過多占用手機資源，直接導致其他性能下降，影響頁面響應時間。例如在Activity的onCreate方法中進行了大量的同步任務。

二、 初步優化方案

綜上所述，App運行速度分析概括為以下七點：硬件約束、網絡環境影響以及服務器接口環境、View的繪制過程、16ms原則、OverDraw過度繪制、GC垃圾回收、同步任務過多。在這里我們只對移動端開發并對后面五點提出相應的初步優化方案：異步延遲加載。

不妨先針對View的繪制過程、16ms原則來分析下某首頁，采用hierarchyviewer工具分析首頁如下：

圖 2-1 首頁MLD分析示例圖

從上圖可以看出首頁包含了1435個view，Measure耗時43.476ms，Layout耗時1.141ms，Draw耗時2.840，總耗時47.457ms（大于16ms）。基于16ms原則，該頁面會出現丟幀情況從而導致卡頓現象。針對這種長篇幅的頁面可以根據實際情況進行異步延遲加載，對于第三屏、第四屏、第五屏采用梯級延遲加載從而避開同步加載。

異步延遲加載的關鍵是延遲時間為多少是合適的，對于配置較低的手機延遲相對要高一些，對于配置較高的手機延遲相對要低一些。如果延遲配置的不合理的話，高配置手機會產生等待延遲加載的內容的情況，而低配置手機會出現優化效果不明顯的情況。所以這個時間需要結合業務以及不同配置的手機進行測試來確定的。

針對GC垃圾回收，我們以某APP MainActivity為例子分析下。MainActivity作為項目中所有Activity的托管，采用getLocalActivityManager().startActivity().getDecorView()方法獲取啟動Activity的視圖進行顯示。jumpActivity為切換Activity的方法，每次進行頁面跳轉時必須經過該方法，該方法包含GC過程。通過測試分析統計出每次跳轉頁面GC的耗時在8ms到300毫秒之間，這里的GC時間會隨著下個啟動頁面的工作量越多而耗時越長。我們采用異步處理一下，GC過程耗時在0~4ms之間，效果提升顯著。

使用低配置的手機打開某APP進入首頁時會黑屏8~·14秒，然后出現界面，通過代碼分析發現首頁同步初始化五個重量級的Fragment，導致系統運存缺乏，影響了后續的界面繪制渲染等邏輯。我們采用異步延遲加載進行處理一下，先對第一個主Fragment進行異步加載，主Fragment加載完畢后再異步加載第二個Fragment，接著第三個，最后第四個，這樣就可以在短時間內合理分配運存，避免了黑屏的情況。

以上就是App運行速度分析以及初步優化方案，我們只有對App運行速度的硬件環境、開發的軟件因素以及App運行交互的原理進行了解后才能制定相應的優化方法，方可對癥下藥。對于每一個可能影響用戶體驗的問題進行逐步優化，以先解決大問題、迫切問題為前提，以解決繁瑣、細小的問題為原則進行深入優化，App體驗才會越來越好。