在Android應用優(yōu)化方面，主要從以下4個方面進行優(yōu)化：

• 穩(wěn)定（內(nèi)存溢出、崩潰）
• 流暢（卡頓）
• 耗損（耗電、流量、網(wǎng)絡）
• 安裝包（APK瘦身）

內(nèi)存優(yōu)化

由于Android應用的沙箱機制，每個應用所分配的內(nèi)存大小是有限度的，可用內(nèi)存太低就會觸發(fā)LMK(Low Memory Killer)機制，進而會出現(xiàn)閃退現(xiàn)象。

分析工具

Memory Monitor

Memory Monitor是Android Studio自帶的一個內(nèi)存監(jiān)視工具，它可以很好地幫助我們進行內(nèi)存實時分析。通過點擊Android Studio右下角的Memory Monitor標簽，打開工具可以看見較淺藍色代表free的內(nèi)存，而深色的部分代表使用的內(nèi)存從內(nèi)存變換的走勢圖變換，可以判斷關于內(nèi)存的使用狀態(tài)，例如當內(nèi)存持續(xù)增高時，可能發(fā)生內(nèi)存泄漏；當內(nèi)存突然減少時，可能發(fā)生GC等。

Memory Analyzer

MAT 是一個快速，功能豐富的 Java Heap 分析工具，通過分析 Java 進程的內(nèi)存快照 HPROF 分析，從眾多的對象中分析，快速計算出在內(nèi)存中對象占用的大小，查看哪些對象不能被垃圾收集器回收，并可以通過視圖直觀地查看可能造成這種結果的對象。

LeakCanary

LeakCanary是一個內(nèi)存監(jiān)測工具，該工具是Square公司出品的，所謂Square出品必屬精品，LeakCanary的官方地址為https://github.com/square/leakcanar，我們可以在Gradle里引用它。

Android Lint

Android Lint 是Android Sutido種集成的一個Android代碼提示工具，它可以給布局、代碼提供非常強大的幫助。如果在布局文件中寫了三層冗余的LinearLayout布局，就會在編輯器右邊看到提示。當然這個是一個簡單的舉例，Lint的功能非常強大，大家應該養(yǎng)成寫完代碼查看Lint的習慣，這不僅讓你及時發(fā)現(xiàn)代碼種隱藏的一些問題，更能讓你養(yǎng)成良好的代碼風格。

交互優(yōu)化

交互是與用戶體驗最直接的方面，交互場景大概可以分為四個部分：UI 繪制、應用啟動、頁面跳轉、事件響應。對于上面四個方面，大致可以從以下兩個方面來進行優(yōu)化：

• 界面繪制：主要原因是繪制的層級深、頁面復雜、刷新不合理，由于這些原因?qū)е驴D的場景更多出現(xiàn)在 UI 和啟動后的初始界面以及跳轉到頁面的繪制上。
• 數(shù)據(jù)處理：導致這種卡頓場景的原因是數(shù)據(jù)處理量太大，一般分為三種情況，一是數(shù)據(jù)在處理 UI 線程，二是數(shù)據(jù)處理占用 CPU 高，導致主線程拿不到時間片，三是內(nèi)存增加導致 GC 頻繁，從而引起卡頓。

Android的繪制需要經(jīng)過onMeasure、onLayout、onDraw等幾個步驟，所以布局的層級越深、元素越多、耗時也就越長。還有就是Android 系統(tǒng)每隔 16ms 發(fā)出 VSYNC 信號，觸發(fā)對 UI 進行渲染，如果每次渲染都成功，這樣就能夠達到流暢的畫面所需的 60FPS。如果某個操作花費的時間是 24ms ，系統(tǒng)在得到 VSYNC 信號時就無法正常進行正常渲染，這樣就發(fā)生了丟幀現(xiàn)象。
之所以出現(xiàn)卡頓現(xiàn)象，是因為有兩個原因：

• 繪制任務太重，繪制一幀內(nèi)容耗時太長
• 主線程太忙，根據(jù)系統(tǒng)傳遞過來的 VSYNC 信號來時還沒準備好數(shù)據(jù)導致丟幀

基于問題產(chǎn)生的原因，我們可以從以下幾個方面進行優(yōu)化：

布局優(yōu)化

在Android中系統(tǒng)對View進行測量、布局和繪制時，都是通過對View樹的遍歷來進行操作的。如果一個View樹的高度太高就會嚴重影響測量、布局和繪制的速度。Google也在其API文檔中建議View高度不宜超過10層。現(xiàn)在版本中Google使用RelativeLayout替代LineraLayout作為默認根布局，目的就是降低LineraLayout嵌套產(chǎn)生布局樹的高度，從而提高UI渲染的效率。
在布局優(yōu)化方面，我們可以從以下幾個方面進行優(yōu)化：

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

渲染優(yōu)化

過度繪制是指在屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次。在多層次重疊的 UI 結構中，如果不可見的 UI 也在做繪制的操作，就會導致某些像素區(qū)域被繪制了多次，從而浪費了多余的 CPU 以及 GPU 資源。我們可以通過開啟手機的過渡繪制功能來檢測頁面是否被過度繪制。
為了避免過度繪制，我們可以從以下幾個方面進行優(yōu)化：

• 布局上的優(yōu)化，移除 XML 中非必須的背景，移除 Window 默認的背景、按需顯示占位背景圖片。
• 自定義View優(yōu)化，使用 canvas.clipRect()來幫助系統(tǒng)識別那些可見的區(qū)域，只有在這個區(qū)域內(nèi)才會被繪制。

啟動優(yōu)化

應用一般都有閃屏頁，優(yōu)化閃屏頁的 UI 布局，可以通過 Profile GPU Rendering 檢測丟幀情況。
也可以通過啟動加載邏輯優(yōu)化。可以采用分布加載、異步加載、延期加載策略來提高應用啟動速度。
數(shù)據(jù)準備。數(shù)據(jù)初始化分析，加載數(shù)據(jù)可以考慮用線程初始化等策略。

刷新優(yōu)化

Android開發(fā)中，通常是異步操作頁面的，因此需要可以從刷新優(yōu)化上來優(yōu)化應用，主要有兩個原則：

• 減少刷新次數(shù)；
• 縮小刷新區(qū)域；

動畫優(yōu)化

在實現(xiàn)動畫效果時，需要根據(jù)不同場景選擇合適的動畫框架來實現(xiàn)。有些情況下，可以用硬件加速方式來提供流暢度。

耗電優(yōu)化

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

網(wǎng)絡優(yōu)化

對于網(wǎng)絡的優(yōu)化，可以從以下幾個方面著手進行：

圖片網(wǎng)絡優(yōu)化

例如，針對網(wǎng)絡情況，返回不同的圖片數(shù)據(jù)，一種是高清大圖，一種是正常圖片，一種是縮略小圖。當用戶處于wifi下給控件設置高清大圖，當4g或者3g模式下加載正常圖片，當弱網(wǎng)條件下加載縮略圖。

網(wǎng)絡數(shù)據(jù)優(yōu)化

• 連接復用：節(jié)省連接建立時間，如開啟 keep-alive。
  對于Android來說默認情況下HttpURLConnection和HttpClient都開啟了keep-alive。只是2.2之前HttpURLConnection存在影響連接池的Bug，具體可見：Android HttpURLConnection及HttpClient選擇
• 請求合并：即將多個請求合并為一個進行請求，比較常見的就是網(wǎng)頁中的CSS Image Sprites。如果某個頁面內(nèi)請求過多，也可以考慮做一定的請求合并。
• 減少請求數(shù)據(jù)的大小：對于post請求，body可以做gzip壓縮的，header也可以做數(shù)據(jù)壓縮。返回數(shù)據(jù)的body也可以做gzip壓縮，body數(shù)據(jù)體積可以縮小到原來的30%左右。

異常攔截優(yōu)化

在獲取數(shù)據(jù)的流程中，訪問接口和解析數(shù)據(jù)時都有可能會出錯，我們可以通過攔截器在這兩層攔截錯誤。

• 在訪問接口時，我們不用設置攔截器，因為一旦出現(xiàn)錯誤，Retrofit會自動拋出異常。比如，常見請求異常404，500，503等等。
• 在解析數(shù)據(jù)時，我們設置一個攔截器，判斷Result里面的code是否為成功，如果不成功，則要根據(jù)與服務器約定好的錯誤碼來拋出對應的異常。比如，token失效，禁用同賬號登陸多臺設備，缺少參數(shù)，參數(shù)傳遞異常等等。

APK瘦身

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

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

基于上面的組成部分，那么優(yōu)化也可以從以下幾個方面著手：

• 代碼混淆。使用proGuard 代碼混淆器工具，它包括壓縮、優(yōu)化、混淆等功能。
• 資源優(yōu)化。比如使用 Android Lint 刪除冗余資源，資源文件最少化等。
• 圖片優(yōu)化。比如利用 AAPT 工具對 PNG 格式的圖片做壓縮處理，降低圖片色彩位數(shù)等。
• 避免重復功能的庫，使用 WebP圖片格式等。
• 插件化，比如功能模塊放在服務器上，按需下載，可以減少安裝包大小。

針對Android的性能優(yōu)化，主要有以下幾個有效的優(yōu)化方法：

1. 布局優(yōu)化
2. 繪制優(yōu)化
3. 內(nèi)存泄漏優(yōu)化
4. 響應速度優(yōu)化
5. ListView/RecycleView及Bitmap優(yōu)化
6. 線程優(yōu)化
7. 其他性能優(yōu)化的建議

布局優(yōu)化

關于布局優(yōu)化的思想很簡單，就是盡量減少布局文件的層級。這個道理很淺顯，布局中的層級少了，就意味著Android繪制時的工作量少了，那么程序的性能自然就提高了。
1. 刪除布局中無用的控件和層次，其次有選擇地使用性能比較低的ViewGroup。
關于有選擇地使用性能比較低的ViewGroup,這就需要我們開發(fā)就實際靈活選擇了。
例如：如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，這是因為RelativeLayout的功能比較復雜，它的布局過程需要花費更多的CPU時間。FrameLayout和LinearLayout一樣都是一種簡單高效的ViewGroup，因此可以考慮使用它們，但是很多時候單純通過一個LinearLayout或者FrameLayout無法實現(xiàn)產(chǎn)品效果，需要通過嵌套的方式來完成。這種情況下還是建議采用RelativeLayout,因為ViewGroup的嵌套就相當于增加了布局的層級，同樣會降低程序的性能。
2. ViewStub
ViewStub提供了按需加載的功能，當需要時才會將ViewStub中的布局加載到內(nèi)存，提高了程序初始化效率。
3. 避免過度繪制
過度繪制（Overdraw）描述的是屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次。在多層次重疊的 UI 結構里面，如果不可見的 UI 也在做繪制的操作，會導致某些像素區(qū)域被繪制了多次，同時也會浪費大量的 CPU 以及 GPU 資源。
如下所示，有些部分在布局時，會被重復繪制：

過度繪制.png

繪制優(yōu)化

繪制優(yōu)化是指View的onDraw方法要避免執(zhí)行大量的操作，這主要體現(xiàn)在兩個方面：
1. onDraw中不要創(chuàng)建新的局部對象。
因為onDraw方法可能會被頻繁調(diào)用，這樣就會在一瞬間產(chǎn)生大量的臨時對象，這不僅占用了過多的內(nèi)存而且還會導致系統(tǒng)更加頻繁gc，降低了程序的執(zhí)行效率。
2. onDraw方法中不要做耗時的任務，也不能執(zhí)行成千上萬次的循環(huán)操作，盡管每次循環(huán)都很輕量級，但是大量的循環(huán)仍然十分搶占CPU的時間片，這會造成View的繪制過程不流暢。
按照Google官方給出的性能優(yōu)化典范中的標準，View的繪制頻率保證60fps是最佳的，這就要求每幀繪制時間不超過16ms(16ms = 1000/60)，雖然程序很難保證16ms這個時間，但是盡量降低onDraw方法中的復雜度總是切實有效的。

內(nèi)存泄漏優(yōu)化

內(nèi)存泄漏是開發(fā)過程中的一個需要重視的問題，但是由于內(nèi)存泄露問題對開發(fā)人員的經(jīng)驗和開發(fā)意識有較高的要求，因此也是開發(fā)人員最容易犯的錯誤之一。
內(nèi)存泄露的優(yōu)化分為兩個方面：
1. 在開發(fā)過程中避免寫出有內(nèi)存泄漏的代碼
2. 通過一些分析工具比如MAT來找出潛在的內(nèi)存泄露，然后解決。

什么是內(nèi)存泄漏?
java是有垃圾回收機制的。java虛擬機會派出一些回收線程不定時地回收那些不再被需要的內(nèi)存空間（注意回收的不是對象本身，而是對象占據(jù)的內(nèi)存空間）。
Q：什么是不再被需要的內(nèi)存空間？
Java沒有指針，全憑引用來和對象進行關聯(lián)，通過引用來操作對象。如果一個對象沒有與任何引用關聯(lián)，那么這個對象也就不太可能被使用到了，回收器便是把這些“無任何引用的對象”作為目標，回收了它們占據(jù)的內(nèi)存空間。
Q：如何分辨為對象無引用？

1. 引用計數(shù)法。直接計數(shù)，簡單高效，Python便是采用該方法。但是如果出現(xiàn) 兩個對象相互引用，即使它們都無法被外界訪問到，計數(shù)器不為0它們也始終不會被回收。為了解決該問題，java采用的是方法2。
2. 可達性分析法。這個方法設置了一系列的“GC Roots”對象作為索引起點，如果一個對象 與起點對象之間均無可達路徑，那么這個不可達的對象就會成為回收對象。這種方法處理 兩個對象相互引用的問題，如果兩個對象均沒有外部引用，會被判斷為不可達對象進而被回收（如下圖）。

Q：有了回收機制，為什么還會發(fā)生內(nèi)存泄漏？
雖然垃圾回收器會幫我們回收大部分無用的內(nèi)存空間，但是對于還保持著引用，但邏輯上已經(jīng)不會再用到的對象，垃圾回收器不會回收它們。這些對象積累在內(nèi)存中，直到程序結束，這就是所說的“內(nèi)存泄漏”。 當然了，用戶對單次的內(nèi)存泄漏并沒有什么感知，但當泄漏積累到內(nèi)存都被消耗完，就會導致卡頓，崩潰。
下面這張圖可以幫助我們更好地理解對象的狀態(tài)，以及內(nèi)存泄漏的情況

內(nèi)存泄漏.jpg

Android一般在什么情況下會出現(xiàn)內(nèi)存泄漏？
①集合類泄漏
②單例/靜態(tài)變量造成的內(nèi)存泄漏
③匿名內(nèi)部類/非靜態(tài)內(nèi)部類
④資源未關閉造成的內(nèi)存泄漏
大概可以分為以上幾類，還有一些經(jīng)常會聽到的Hanlder, AsyncTask引起內(nèi)存泄漏，都屬于上述③中的情況。

Android怎么分析內(nèi)存泄漏？
可以通過 MAT(Memory Analyzer Tool)，或者 LeakCanary 來檢測 Android 中的內(nèi)存泄漏。

內(nèi)存泄漏可參考：Android應用內(nèi)存泄漏的定位、分析與解決策略

響應速度優(yōu)化

響應速度優(yōu)化的核心思想就是避免在主線程中做耗時操作。
如果有耗時操作，可以開啟子線程執(zhí)行，即采用異步的方式來執(zhí)行耗時操作。
如果在主線程中做太多事情，會導致Activity啟動時出現(xiàn)黑屏現(xiàn)象，甚至ANR。
Android規(guī)定，Activity如果5秒鐘之內(nèi)無法響應屏幕觸摸事件或者鍵盤輸入事件就會出現(xiàn)ANR，而BroadcastReceiver如果10秒鐘之內(nèi)還未執(zhí)行完操作也會出現(xiàn)ANR。

為了避免ANR，可以開啟子線程執(zhí)行耗時操作，但是子線程不能更新UI，所以需要子線程與主線程進行通信來解決子線程執(zhí)行耗時任務后，通知主線程更新UI的場景。關于這部分，需要掌握Handler消息機制，AsyncTask，IntentService等內(nèi)容。
然而，在實際開發(fā)中，ANR仍然不可避免的發(fā)生了，而且很難從代碼上發(fā)現(xiàn)，這時候就要用到ANR日志分析。當一個進程發(fā)生了ANR之后，系統(tǒng)會在/data/anr目錄下創(chuàng)建一個文件traces.txt，通過分析這個文件就能定位出ANR的原因。

ListView/RecycleView及Bitmap優(yōu)化

ListView/RecycleView的優(yōu)化思想主要從以下幾個方面入手：
① 使用ViewHolder模式來提高效率
② 異步加載：耗時的操作放在異步線程中
③ ListView/RecycleView的滑動時停止加載和分頁加載
Bitmap優(yōu)化
對加載圖片進行壓縮，避免加載圖片多大導致OOM出現(xiàn)。

線程優(yōu)化

線程優(yōu)化的思想就是采用線程池，避免程序中存在大量的Thread。線程池可以重用內(nèi)部的線程，從而避免了線程的創(chuàng)建和銷毀所帶來的性能開銷，同時線程池還能有效地控制線程池的最大并發(fā)數(shù)，避免大量的線程因互相搶占系統(tǒng)資源從而導致阻塞現(xiàn)象的發(fā)生。因此在實際開發(fā)中，盡量采用線程池，而不是每次都要創(chuàng)建一個Thread對象。

其他性能優(yōu)化

①避免過度的創(chuàng)建對象
②不要過度使用枚舉，枚舉占用的內(nèi)存空間要比整型大
③常量請使用static final來修飾
④使用一些Android特有的數(shù)據(jù)結構，比如SparseArray和Pair等
⑤適當采用軟引用和弱引用
⑥采用內(nèi)存緩存和磁盤緩存
⑦盡量采用靜態(tài)內(nèi)部類，這樣可以避免潛在的由于內(nèi)部類而導致的內(nèi)存泄漏。