Android進階-Android性能優化總結

1、Android性能優化的方面

針對Android的性能優化，主要有如下幾個有效的優化方法：

1.佈局優化

2.繪製優化

3.內存泄漏優化

4.響應速度優化

5.ListView/RecycleView及Bitmap優化

6.線程優化

7.其餘性能優化的建議

下面咱們具體來介紹關於以上這幾個方面優化的具體思路及解決方案。

 

2、佈局優化

關於佈局優化的思想很簡單，就是儘可能減小布局文件的層級。這個道理很淺顯，佈局中的層級少了，就意味着Android繪製時的工做量少了，那麼程序的性能天然就提升了。

如何進行佈局優化？

①刪除佈局中無用的控件和層次，其次有選擇地使用性能比較低的ViewGroup。

關於有選擇地使用性能比較低的ViewGroup,這就須要咱們開發就實際靈活選擇了。

例如：若是佈局中既可使用LinearLayout也可使用RelativeLayout，那麼就採用LinearLayout，這是由於RelativeLayout的功能比較複雜，它的佈局過程須要花費更多的CPU時間。FrameLayout和LinearLayout同樣都是一種簡單高效的ViewGroup，所以能夠考慮使用它們，可是不少時候單純經過一個LinearLayout或者FrameLayout沒法實現產品效果，須要經過嵌套的方式來完成。這種狀況下仍是建議採用RelativeLayout,由於ViewGroup的嵌套就至關於增長了佈局的層級，一樣會下降程序的性能。

②採用標籤,標籤,ViewStub。

標籤主要用於佈局重用。

標籤通常和配合使用，能夠下降減小布局的層級。

ViewStub提供了按需加載的功能，當須要時纔會將ViewStub中的佈局加載到內存，提升了程序初始化效率。

③避免過分繪製

過分繪製（Overdraw）描述的是屏幕上的某個像素在同一幀的時間內被繪製了屢次。在多層次重疊的 UI 結構裏面，若是不可見的 UI 也在作繪製的操做，會致使某些像素區域被繪製了屢次，同時也會浪費大量的 CPU 以及 GPU 資源。

以下所示，有些部分在佈局時，會被重複繪製。

關於過分繪製產生的通常場景及解決方案，參考：Android 過分繪製優化

 

3、繪製優化

繪製優化是指View的onDraw方法要避免執行大量的操做，這主要體如今兩個方面：

①onDraw中不要建立新的局部對象。 

由於onDraw方法可能會被頻繁調用，這樣就會在一瞬間產生大量的臨時對象，這不只佔用了過多的內存並且還會致使系統更加頻繁gc，下降了程序的執行效率。

②onDraw方法中不要作耗時的任務，也不能執行成千上萬次的循環操做，儘管每次循環都很輕量級，可是大量的循環仍然十分搶佔CPU的時間片，這會形成View的繪製過程不流暢。

按照Google官方給出的性能優化典範中的標準，View的繪製頻率保證60fps是最佳的，這就要求每幀繪製時間不超過16ms(16ms = 1000/60)，雖然程序很難保證16ms這個時間，可是儘可能下降onDraw方法中的複雜度老是切實有效的。

 

 

 

4、內存泄漏優化

內存泄漏是開發過程當中的一個須要重視的問題，可是因爲內存泄露問題對開發人員的經驗和開發意識有較高的要求，所以也是開發人員最容易犯的錯誤之一。

內存泄露的優化分爲兩個方面：

①在開發過程當中避免寫出有內存泄漏的代碼

②經過一些分析工具好比MAT來找出潛在的內存泄露，而後解決。

 對應於兩種不一樣狀況，一個是瞭解內存泄漏的可能場景以及如何規避，二是怎麼查找內存泄漏。

 

1.那麼咱們就先了解什麼是內存泄漏?這樣咱們才能知道如何避免。

你們都知道，java是有垃圾回收機制的，這使得java程序員比C++程序員輕鬆了許多，存儲申請了，不用心心念念要加一句釋放，java虛擬機會派出一些回收線程兢兢業業不定時地回收那些再也不被須要的內存空間（注意回收的不是對象自己，而是對象佔據的內存空間）。

Q1：什麼叫再也不被須要的內存空間？

答：Java沒有指針，全憑引用來和對象進行關聯，經過引用來操做對象。若是一個對象沒有與任何引用關聯，那麼這個對象也就不太可能被使用到了，回收器即是把這些「無任何引用的對象」做爲目標，回收了它們佔據的內存空間。

Q2：如何分辨爲對象無引用？

答：2種方法

引用計數法直接計數，簡單高效，Python即是採用該方法。可是若是出現 兩個對象相互引用，即便它們都沒法被外界訪問到，計數器不爲0它們也始終不會被回收。爲了解決該問題，java採用的是b方法。

可達性分析法這個方法設置了一系列的「GC Roots」對象做爲索引發點，若是一個對象 與起點對象之間均無可達路徑，那麼這個不可達的對象就會成爲回收對象。這種方法處理 兩個對象相互引用的問題，若是兩個對象均沒有外部引用，會被判斷爲不可達對象進而被回收（以下圖）。

Q3：有了回收機制，放心大膽用不會有內存泄漏？

答：答案固然是No！

雖然垃圾回收器會幫咱們幹掉大部分無用的內存空間，可是對於還保持着引用，但邏輯上已經不會再用到的對象，垃圾回收器不會回收它們。這些對象積累在內存中，直到程序結束，就是咱們所說的「內存泄漏」。 固然了，用戶對單次的內存泄漏並無什麼感知，但當泄漏積累到內存都被消耗完，就會致使卡頓，崩潰。

下面這張圖能夠幫助咱們更好地理解對象的狀態，以及內存泄漏的狀況

左邊未引用的對象是會被GC回收的，右邊被引用的對象不會被GC回收，可是未使用的對象中除了未引用的對象，還包括已被引用的一部分對象，那麼內存泄漏久發生這部分已被引用但未使用的對象。

2.Android通常在什麼狀況下會出現內存泄漏？

①集合類泄漏 ②單例/靜態變量形成的內存泄漏 ③匿名內部類/非靜態內部類 ④資源未關閉形成的內存泄漏

大概能夠分爲以上幾類，還有一些常常會聽到的Hanlder,AsyncTask引發內存泄漏，都屬於上述③中的狀況。

那麼上述四種狀況是怎麼形成的內存泄漏，具體是什麼緣由，以及Android中一些知名的引發內存泄漏的緣由，以及解決方法是怎麼樣的？

3.Android怎麼分析內存泄漏？

上面介紹了內存泄漏的場景，對應的有一些解決方案。

那麼在內存泄漏已經發生的狀況下，咱們該如何解決呢？

咱們能夠經過MAT(Memory Analyzer Tool)，或者 LeakCanary來檢測Android中的內存泄漏。

 

5、響應速度優化

響應速度優化的核心思想就是避免在主線程中作耗時操做。

若是有耗時操做，能夠開啓子線程執行，即採用異步的方式來執行耗時操做。

若是在主線程中作太多事情，會致使Activity啓動時出現黑屏現象，甚至ANR。

Android規定，Activity若是5秒鐘以內沒法響應屏幕觸摸事件或者鍵盤輸入事件就會出現ANR，而BroadcastReceiver若是10秒鐘以內還未執行完操做也會出現ANR。

爲了不ANR，能夠開啓子線程執行耗時操做，可是子線程不能更新UI，因此須要子線程與主線程進行通訊來解決子線程執行耗時任務後，通知主線程更新UI的場景。關於這部分，須要掌握Handler消息機制，AsyncTask，IntentService等內容。

然而，在實際開發中，ANR仍然不可避免的發生了，並且很難從代碼上發現，這時候就要用到ANR日誌分析。當一個進程發生了ANR以後，系統會在/data/anr目錄下建立一個文件traces.txt，經過分析這個文件就能定位出ANR的緣由。

 

6、ListView/RecycleView及Bitmap優化

 

ListView/RecycleView的優化思想主要從如下幾個方面入手：

①使用ViewHolder模式來提升效率

②異步加載：耗時的操做放在異步線程中

③ListView/RecycleView的滑動時中止加載和分頁加載

具體優化建議及詳情，參考：ListView的優化

Bitmap優化

主要是對加載圖片進行壓縮，避免加載圖片多大致使OOM出現。

 

7、線程優化

線程優化的思想就是採用線程池，避免程序中存在大量的Thread。線程池能夠重用內部的線程，從而避免了線程的建立和銷燬鎖帶來的性能開銷，同時線程池還能有效地控制線程池的最大並法術，避免大量的線程因互相搶佔系統資源從而致使阻塞現象的發生。所以在實際開發中，儘可能採用線程池，而不是每次都要建立一個Thread對象。

 

 

8、其餘性能優化

①避免過分的建立對象

②不要過分使用枚舉，枚舉佔用的內存空間要比整型大

③常量請使用static final來修飾

④使用一些Android特有的數據結構，好比SparseArray和Pair等

⑤適當採用軟引用和弱引用

⑥採用內存緩存和磁盤緩存

⑦儘可能採用靜態內部類，這樣能夠避免潛在的因爲內部類而致使的內存泄漏。

以上是關於Android性能優化方面，咱們一些入手點。從這些方面，咱們能夠在平時的開發中注意，避免相似錯誤，提升Android程序的性能，可是其中一些方面的要求則須要咱們不斷的學習，以及平時良好的意識與習慣。因爲本身開發經驗幾乎爲0，沒辦法根據實際經驗來講明，只能寫下這篇文章來提醒本身之後開發的時候須要注意和培養的地方。

 

 

 

 

轉載自：https://lrh1993.gitbooks.io/android_interview_guide/content/android/advance/performance-optimization.html