Android性能優化的幾點建議

安卓開發大軍浩浩蕩蕩，通過近十年的發展，Android技術優化日異月新，現在Android 9.0 已經發布，Android系統性能也已經很是流暢，能夠在體驗上徹底媲美iOS。 可是，到了各大廠商手裏，改源碼、自定義系統，使得Android原生系統變得魚龍混雜，而後到了不一樣層次的開發工程師手裏，由於技術水平的良莠不齊，即便不少手機在跑分軟件性能很是高，打開應用依然存在卡頓現象。另外，隨着產品內容迭代，功能愈來愈複雜，UI頁面也愈來愈豐富，也成爲流暢運行的一種阻礙。綜上所述，對APP進行性能優化已成爲開發者該有的一種綜合素質，也是開發者可以完成高質量應用程序做品的保證。

在Android應用優化方面，咱們主要從如下4個方面進行優化：

1. 穩定（內存溢出、崩潰）
2. 流暢（卡頓）
3. 耗損（耗電、流量、網絡）
4. 安裝包（APK瘦身）

內存優化

因爲Android應用的沙箱機制，每一個應用所分配的內存大小是有限度的，內存過低就會觸發LMK(Low Memory Killer)機制，進而會出現閃退現象。若是要對內存進行優化，就須要先搞懂java的內存是如何分配和回收的，關於這方面，能夠重點參考下面的內容： Java 垃圾回收器的GC機制，看這一篇就夠了 Android 內存泄漏常見案例及分析 Android應用內存泄漏的定位、分析與解決策略

分析工具

Memory Monitor 工具

Memory Monitor是Android Studio自帶的一個內存監視工具，它能夠很好地幫助咱們進行內存實時分析。經過點擊Android Studio右下角的Memory Monitor標籤，打開工具能夠看見較淺藍色表明free的內存，而深色的部分表明使用的內存從內存變換的走勢圖變換，能夠判斷關於內存的使用狀態，例如當內存持續增高時，可能發生內存泄漏；當內存忽然減小時，可能發生GC等。

Memory Analyzer工具

MAT 是一個快速，功能豐富的 Java Heap 分析工具，經過分析 Java 進程的內存快照 HPROF 分析，從衆多的對象中分析，快速計算出在內存中對象佔用的大小，查看哪些對象不能被垃圾收集器回收，並能夠經過視圖直觀地查看可能形成這種結果的對象。

LeakCanary工具

LeakCanary是一個內存監測工具，該工具是Square公司出品的，所謂Square出品必屬精品，LeakCanary的官方地址爲https://github.com/square/leakcanar，咱們能夠在Gradle裏引用它。

Android Lint 工具

Android Lint 是Android Sutido種集成的一個Android代碼提示工具，它能夠給佈局、代碼提供很是強大的幫助。若是在佈局文件中寫了三層冗餘的LinearLayout佈局，就會在編輯器右邊看到提示。固然這個是一個簡單的舉例，Lint的功能很是強大，你們應該養成寫完代碼查看Lint的習慣，這不只讓你及時發現代碼種隱藏的一些問題，更能讓你養成良好的代碼風格，要知道，這些Lint提示可都是Google大牛們汗水合智慧的結晶。

其餘建議

在Android應用開發中，影響穩定性的緣由不少，好比內存使用不合理、代碼異常場景考慮不周全、代碼邏輯不合理等，都會對應用的穩定性形成影響。 其中最多見的兩個場景是：Crash 和 ANR，這兩個錯誤將會使得程序沒法使用。因此作好Crash監控，把崩潰信息、異常信息收集記錄起來，以便後續分析；合理使用主線程處理業務，不要在主線程中作耗時操做，防止ANR程序無響應發生。 具體能夠參考下面的文章連接： Android系統穩定性問題總結

交互優化

交互是與用戶體驗最直接的方面，交互場景大概能夠分爲四個部分：UI 繪製、應用啓動、頁面跳轉、事件響應。對於上面四個方面，大體能夠從如下兩個方面來進行優化：

• 界面繪製：主要緣由是繪製的層級深、頁面複雜、刷新不合理，因爲這些緣由致使卡頓的場景更多出如今 UI 和啓動後的初始界面以及跳轉到頁面的繪製上。
• 數據處理：致使這種卡頓場景的緣由是數據處理量太大，通常分爲三種狀況，一是數據在處理 UI 線程，二是數據處理佔用 CPU 高，致使主線程拿不到時間片，三是內存增長致使 GC 頻繁，從而引發卡頓。

咱們知道，Android的繪製須要通過onMeasure、onLayout、onDraw等幾個步驟，因此佈局的層級越深、元素越多、耗時也就越長。還有就是Android 系統每隔 16ms 發出 VSYNC 信號，觸發對 UI 進行渲染，若是每次渲染都成功，這樣就可以達到流暢的畫面所需的 60FPS。若是某個操做花費的時間是 24ms ，系統在獲得 VSYNC 信號時就沒法正常進行正常渲染，這樣就發生了丟幀現象。

之因此出現卡頓現象，是由於有兩個緣由：

• 繪製任務過重，繪製一幀內容耗時太長
• 主線程太忙，根據系統傳遞過來的 VSYNC 信號來時還沒準備好數據致使丟幀

基於問題產生的緣由，咱們能夠從如下幾個方面進行優化：

佈局優化

在Android種系統對View進行測量、佈局和繪製時，都是經過對View數的遍從來進行操做的。若是一個View數的高度過高就會嚴重影響測量、佈局和繪製的速度。Google也在其API文檔中建議View高度不宜哦過10層。如今版本種Google使用RelativeLayout替代LineraLayout做爲默認根佈局，目的就是下降LineraLayout嵌套產生布局樹的高度，從而提升UI渲染的效率。 在佈局優化方面，咱們能夠從如下幾個方面進行優化：

• 佈局複用，使用<include>標籤重用layout；
• 提升顯示速度，使用<ViewStub>延遲View加載；
• 減小層級，使用<merge>標籤替換父級佈局；
• 注意使用wrap_content，會增長measure計算成本；
• 刪除控件中無用屬性；

渲染優化

過分繪製是指在屏幕上的某個像素在同一幀的時間內被繪製了屢次。在多層次重疊的 UI 結構中，若是不可見的 UI 也在作繪製的操做，就會致使某些像素區域被繪製了屢次，從而浪費了多餘的 CPU 以及 GPU 資源。咱們能夠經過開啓手機的過渡繪製功能來檢測頁面是否被過分繪製。

爲了不過分繪製，咱們能夠從如下幾個方面進行優化：

• 佈局上的優化，移除 XML 中非必須的背景，移除 Window 默認的背景、按需顯示佔位背景圖片。
• 自定義View優化，使用 canvas.clipRect()來幫助系統識別那些可見的區域，只有在這個區域內纔會被繪製。

啓動優化

應用通常都有閃屏頁，優化閃屏頁的 UI 佈局，能夠經過 Profile GPU Rendering 檢測丟幀狀況。 也能夠經過啓動加載邏輯優化。能夠採用分佈加載、異步加載、延期加載策略來提升應用啓動速度。 數據準備。數據初始化分析，加載數據能夠考慮用線程初始化等策略。

刷新優化

Android開發中，一般是異步操做頁面的，所以須要能夠從刷新優化上來優化應用，主要有兩個原則：

• 減小刷新次數；
• 縮小刷新區域；

動畫優化

在實現動畫效果時，須要根據不一樣場景選擇合適的動畫框架來實現。有些狀況下，能夠用硬件加速方式來提供流暢度。

耗電優化

在移動設備中，電池的重要性不言而喻，沒有電什麼都幹不成。對於操做系統和設備開發商來講，耗電優化一致沒有中止，去追求更長的待機時間，而對於一款應用來講，並非能夠忽略電量使用問題，特別是那些被歸爲「電池殺手」的應用，最終的結果是被卸載。所以，應用開發者在實現需求的同時，須要儘可能減小電量的消耗。

在 Android5.0 之前，在應用中測試電量消耗比較麻煩，也不許確，5.0 以後專門引入了一個獲取設備上電量消耗信息的 API，即Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系統電量分析工具，和Systrace 同樣，是一款圖形化數據分析工具，直觀地展現出手機的電量消耗過程，經過輸入電量分析文件，顯示消耗狀況，最後提供一些可供參考電量優化的方法。

網絡優化

對於網絡的優化，能夠從如下幾個方面着手進行：

圖片網絡優化

例如，針對網絡狀況，返回不一樣的圖片數據，一種是高清大圖，一種是正常圖片，一種是縮略小圖。當用戶處於wifi下給控件設置高清大圖，當4g或者3g模式下加載正常圖片，當弱網條件下加載縮略圖。

網絡數據優化

移動端獲取網絡數據優化能夠從如下幾點着手：

• 鏈接複用：節省鏈接創建時間，如開啓 keep-alive。 對於Android來講默認狀況下HttpURLConnection和HttpClient都開啓了keep-alive。只是2.2以前HttpURLConnection存在影響鏈接池的Bug，具體可見：Android HttpURLConnection及HttpClient選擇
• 請求合併：即將多個請求合併爲一個進行請求，比較常見的就是網頁中的CSS Image Sprites。若是某個頁面內請求過多，也能夠考慮作必定的請求合併。
• 減小請求數據的大小：對於post請求，body能夠作gzip壓縮的，header也能夠作數據壓縮。返回數據的body也能夠作gzip壓縮，body數據體積能夠縮小到原來的30%左右。

異常攔截優化

在獲取數據的流程中，訪問接口和解析數據時都有可能會出錯，咱們能夠經過攔截器在這兩層攔截錯誤。

• 在訪問接口時，咱們不用設置攔截器，由於一旦出現錯誤，Retrofit會自動拋出異常。好比，常見請求異常404，500，503等等。
• 在解析數據時，咱們設置一個攔截器，判斷Result裏面的code是否爲成功，若是不成功，則要根據與服務器約定好的錯誤碼來拋出對應的異常。好比，token失效，禁用同帳號登錄多臺設備，缺乏參數，參數傳遞異常等等。

APK瘦身

應用安裝包大小對應用使用沒有影響，但應用的安裝包越大，用戶下載的門檻越高，特別是在移動網絡狀況下，用戶在下載應用時，對安裝包大小的要求更高，所以，減少安裝包大小可讓更多用戶願意下載和體驗產品。

在Android Studio工具欄裏，打開build–>Analyze APK, 選擇要分析的APK包 ，能夠看到apk的相關信息，以下所示：

Android的apk主要有如下信息構成：

• assets文件夾。存放一些配置文件、資源文件，assets不會自動生成對應的 ID，而是經過 AssetManager 類的接口獲取。
• res。res 是 resource 的縮寫，這個目錄存放資源文件，會自動生成對應的 ID 並映射到 .R 文件中，訪問直接使用資源ID。
• META-INF。保存應用的簽名信息，簽名信息能夠驗證 APK 文件的完整性。
• AndroidManifest.xml。這個文件用來描述 Android 應用的配置信息，一些組件的註冊信息、可以使用權限等。
• classes.dex。Dalvik 字節碼程序，讓 Dalvik 虛擬機可執行，通常狀況下，Android 應用在打包時經過Android SDK 中的 dx 工具將 Java 字節碼轉換爲 Dalvik 字節碼。
• resources.arsc。記錄着資源文件和資源 ID 之間的映射關係，用來根據資源 ID 尋找資源。

基於上面的組成部分，那麼優化也能夠從如下幾個方面着手：

• 代碼混淆。使用proGuard 代碼混淆器工具，它包括壓縮、優化、混淆等功能。
• 資源優化。好比使用 Android Lint 刪除冗餘資源，資源文件最少化等。
• 圖片優化。好比利用 AAPT 工具對 PNG 格式的圖片作壓縮處理，下降圖片色彩位數等。
• 避免重複功能的庫，使用 WebP圖片格式等。
• 插件化，好比功能模塊放在服務器上，按需下載，能夠減小安裝包大小。