Android性能優(yōu)化

我們都知道Android 應(yīng)用是很消耗內(nèi)存的 我們應(yīng)該如果避免以及提高對Android 性能的優(yōu)化呢？

我們首先可以從以下幾個方面開始：

內(nèi)存優(yōu)化 、布局 ，電量、 流量 啟動

首先來說一下眾所周知的 內(nèi)存泄漏 內(nèi)存溢出問題

1.內(nèi)存泄漏:

內(nèi)存泄漏 了解一下小編的：Android內(nèi)存優(yōu)化——常見內(nèi)存泄露及優(yōu)化方案

內(nèi)存抖動：

2.內(nèi)存抖動

什么是內(nèi)存抖動呢？Android里內(nèi)存抖動是指內(nèi)存頻繁地分配和回收，而頻繁的gc會導(dǎo)致卡頓，嚴(yán)重時還會導(dǎo)致OOM。

一個很經(jīng)典的案例是string拼接創(chuàng)建大量小的對象(比如在一些頻繁調(diào)用的地方打字符串拼接的log的時候), 見Android優(yōu)化之String篇[9]。

而內(nèi)存抖動為什么會引起OOM呢？

主要原因還是有因為大量小的對象頻繁創(chuàng)建，導(dǎo)致內(nèi)存碎片，從而當(dāng)需要分配內(nèi)存時，雖然總體上還是有剩余內(nèi)存可分配，而由于這些內(nèi)存不連續(xù)，導(dǎo)致無法分配，系統(tǒng)直接就返回OOM了。

比如我們坐地鐵的時候，假設(shè)你沒帶公交卡去坐地鐵，地鐵的售票機就只支持5元，10元，而哪怕你這個時候身上有1萬張1塊的都沒用(是不是覺得很反人類..)。當(dāng)然你可以去兌換5元，10元，而在Android系統(tǒng)里就沒那么幸運了，系統(tǒng)會直接拒絕為你分配內(nèi)存，并扔一個OOM給你(有人說Android系統(tǒng)并不會對Heap中空閑內(nèi)存區(qū)域做碎片整理，待驗證)。

3. 圖片壓縮

BitmapFactory 在解碼圖片時，可以帶一個Options，有一些比較有用的功能，比如：

inTargetDensity 表示要被畫出來時的目標(biāo)像素密度

inSampleSize 這個值是一個int，當(dāng)它小于1的時候，將會被當(dāng)做1處理，如果大于1，那么就會按照比例（1 / inSampleSize）縮小bitmap的寬和高、降低分辨率，大于1時這個值將會被處置為2的倍數(shù)。例如，width=100，height=100，inSampleSize=2，那么就會將bitmap處理為，width=50，height=50，寬高降為1 / 2，像素數(shù)降為1 / 4

inJustDecodeBounds 字面意思就可以理解就是只解析圖片的邊界，有時如果只是為了獲取圖片的大小就可以用這個，而不必直接加載整張圖片。

inPreferredConfig 默認(rèn)會使用ARGB_8888,在這個模式下一個像素點將會占用4個byte,而對一些沒有透明度要求或者圖片質(zhì)量要求不高的圖片，可以使用RGB_565，一個像素只會占用2個byte，一下可以省下50%內(nèi)存。

inPurgeable和inInputShareable 這兩個需要一起使用，BitmapFactory.java的源碼里面有注釋，大致意思是表示在系統(tǒng)內(nèi)存不足時是否可以回收這個bitmap，有點類似軟引用，但是實際在5.0以后這兩個屬性已經(jīng)被忽略，因為系統(tǒng)認(rèn)為回收后再解碼實際會反而可能導(dǎo)致性能問題

inBitmap 官方推薦使用的參數(shù)，表示重復(fù)利用圖片內(nèi)存，減少內(nèi)存分配，在4.4以前只有相同大小的圖片內(nèi)存區(qū)域可以復(fù)用，4.4以后只要原有的圖片比將要解碼的圖片大既可以復(fù)用了。

4. 緩存池大小

現(xiàn)在很多圖片加載組件都不僅僅是使用軟引用或者弱引用了，實際上類似Glide 默認(rèn)使用的事LruCache，因為軟引用 弱引用都比較難以控制，使用LruCache可以實現(xiàn)比較精細(xì)的控制，而默認(rèn)緩存池設(shè)置太大了會導(dǎo)致浪費內(nèi)存，設(shè)置小了又會導(dǎo)致圖片經(jīng)常被回收，所以需要根據(jù)每個App的情況，以及設(shè)備的分辨率，內(nèi)存計算出一個比較合理的初始值，可以參考Glide的做法。

5. MAT 內(nèi)存分析工具

MAT 內(nèi)存分析工具

4. LeakCanary

2.LeakCanary

第一步使用LeakCanary 我們需要先導(dǎo)入兩個依賴

debugImplementation'com.squareup.leakcanary:leakcanary-android:1.5.4'

releaseImplementation'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'

image

第二步在我們自定義繼承Application類的onCreate()方法里面

image

如果需要具體的檢查內(nèi)存泄漏的時候：

image

完成以上操作之后會在我們的手機或者模擬器上生成此應(yīng)用

image

LeakCanary會找到并修復(fù) 多個內(nèi)存泄漏問題 將OOM崩潰的幾率降低94%。

詳解:

https://blog.csdn.net/qq_20280683/article/details/77964208

https://www.cnblogs.com/fuyaozhishang/p/7753013.html

7. 通過Android Studio 自帶的工具 Android Profilter 找到MEMORY這個欄目 進行檢測

image

電量優(yōu)化

Android應(yīng)用開發(fā)中的網(wǎng)絡(luò)、定位、傳感器等都是比較耗電的特性，我們應(yīng)該正確使用API來有效降低應(yīng)用的耗電量。

1.BroadcastReceiver：

在代碼實現(xiàn)中需要盡量避免無用操作代碼的執(zhí)行，減少應(yīng)用損耗的電量。

對于BroadcastReceiver，通常的做法是在界面onPasuse之后取消廣播監(jiān)聽器的監(jiān)聽操作，同時根據(jù)具體業(yè)務(wù)需求選擇當(dāng)應(yīng)用位于后臺時是否禁用廣播接收器。

2.數(shù)據(jù)傳輸：

數(shù)據(jù)傳輸方式：藍牙傳輸，Wi-Fi傳輸，移動網(wǎng)絡(luò)傳輸?shù)取?/p>

優(yōu)化：

后臺數(shù)據(jù)傳輸?shù)墓芾恚焊鶕?jù)具體業(yè)務(wù)需求，嚴(yán)格限制應(yīng)用位于后臺時是否禁用某些數(shù)據(jù)傳輸，盡量能夠避免無效的數(shù)據(jù)傳輸。

數(shù)據(jù)傳輸?shù)念l度問題：通過經(jīng)驗值或者數(shù)據(jù)統(tǒng)計的方法確定好數(shù)據(jù)傳輸?shù)念l度，避免冗余重復(fù)的數(shù)據(jù)傳輸，數(shù)據(jù)傳輸過程中要壓縮數(shù)據(jù)大小，合并網(wǎng)絡(luò)請求，避免輪詢等。

3.位置服務(wù)：

三種位置服務(wù)：

GPS定位:通過接收全球定位系統(tǒng)的衛(wèi)星提供的經(jīng)緯度坐標(biāo)信息實現(xiàn)位置服務(wù)，精度是最高的，通常在10米以內(nèi)，在時間和電量的消耗上也是最高的。

網(wǎng)絡(luò)定位：通過移動通信的基站信號差異來計算出手機所在的位置，精度比GPS定位差很多，通常在幾百米范圍內(nèi)。

被動定位：最省電的定位服務(wù)，如果應(yīng)用使用被動定位服務(wù)，這個應(yīng)用會等待手機中其他應(yīng)用、服務(wù)或者系統(tǒng)組件發(fā)出定位請求，并和這些組件的監(jiān)聽器一起接收位置更新。

正確有限地使用位置服務(wù)器，減少應(yīng)用耗電量。所以在代碼中使用位置服務(wù)時，需要注意：

有沒有及時注銷位置監(jiān)聽器：長時間的監(jiān)聽位置更新會耗費大量的電量，通過可以選擇在頁面的onPasuse中進行注銷操作，更好用且全局有效的做法是禁用位置監(jiān)聽器。

位置更新監(jiān)聽頻率的設(shè)定：根據(jù)具體的業(yè)務(wù)需求設(shè)置一個合適的更新頻率值，通常需要在定位精度和耗電量之間綜合考慮。

多種位置服務(wù)的選擇：綜合考慮應(yīng)用的具體需求在不同時機采用不同的定位服務(wù)或者選擇第三方的定位SDK。

4.AlarmManager:

AlarmManager的喚醒操作是比較耗電的，通常情況下需要保證兩次喚醒操作的時間間隔不要太短，在不需要使用喚醒功能的情況下盡早取消AlarmManager,否則應(yīng)用會一直處于耗電狀態(tài)。

5.WakeLock:

使用WakeLock時，需要切記及時釋放鎖，而且通常情況下，要盡早地釋放WakeLock。

布局優(yōu)化

在Android開發(fā)時，如果創(chuàng)建的布局層次結(jié)構(gòu)比較復(fù)雜，View樹嵌套的層次比較深，會使頁面展現(xiàn)的事件比較長，導(dǎo)致應(yīng)用運行起來越來越慢，所以需要進行布局優(yōu)化。

1.include標(biāo)簽共享布局：

將通用的布局抽取出來，獨立成一個XML文件，在需要用到的頁面中使用include標(biāo)簽引入進來，減少代碼量，便于修改。

2.ViewStub標(biāo)簽實現(xiàn)延遲加載：

ViewStub是一種不可視并且大小為0的視圖，可以延遲到運行時才填充布局資源。當(dāng)ViewStub設(shè)置為可見或者被inflate之后，會填充布局資源，ViewStub會被填充的視圖代替，和普通的視圖沒有區(qū)別。

ViewStub在需要顯示的時候才會進行視圖的填充，實現(xiàn)延遲加載的目的。

3.merge標(biāo)簽減少布局層次：

當(dāng)一個獨立的布局文件最外層是FrameLayout且這個布局不需要設(shè)置背景等屬性時或者當(dāng)前布局是另外一個布局的子布局時，可以使用merge來減少布局的層次。

4.盡量使用CompoundDrawable:

在LinearLayout布局中，如果存在相鄰的ImageView和TextView,可以使用compound drawable合二為一成為一個TextView,ImageView中的圖片變成TextVIew的drawableTop/drawableLeft/drawableRight/ddrawableBottom屬性,之間的間隔使用drawablePadding屬性來代替。

5.使用Lint:

Lint也可以用來檢查應(yīng)用的布局是否存在可優(yōu)化的地方，為優(yōu)化布局設(shè)置的規(guī)則如下：

AndroidLintUseCompoundDrawables:盡量使用CompoundDrawable。

MergeRootFrame:使用merge標(biāo)簽減少布局層次。

TooManyViews:單個布局中存在太多的View,默認(rèn)情況下，單個布局中View的個數(shù)最多只能是80個，可以考慮使用CompoundDdrawables等來減少View的個數(shù)。

TooDeepLayout:避免過深的布局嵌套，默認(rèn)情況下，單個布局中最多層級是10，可以考慮使用RelativeLayout來減少布局的層次。

UselessParent:當(dāng)一個布局不是一個SrcollView或者根布局，只有一個子View且沒有設(shè)置背景時可以將它移除掉，并將它的子View移動到它的父容器中，得到更扁平的布局層次。

NestedWeights:android:layout_weight屬性會使得View控件被測量兩次，當(dāng)一個LinearLayout擁有非0dp值的android:layout_weight屬性，這時如果將它嵌套在兩一個擁有非0dp的android:layout_weight的LinearLayout，這時測量的次數(shù)將呈指數(shù)級別增加。

UselessLeaf:一個布局如果沒有子View也沒有設(shè)置背景，通?？梢砸瞥?，可以得到更扁平和高效的布局層次。

InefficientWeight:當(dāng)LinearLayout中只有一個子View定義了android:layout_weight屬性，更高性能的做法是使用0dp的android:layout_height或者android:layout_weidth來替換它，這個子View就不需要測量它自身對應(yīng)的大小。

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

網(wǎng)絡(luò)優(yōu)化可以節(jié)省網(wǎng)絡(luò)流量，節(jié)省電量，提高應(yīng)用的響應(yīng)。

1.避免DNS解析：

DNS是域名系統(tǒng)，根據(jù)應(yīng)用請求所用的域名URL去網(wǎng)絡(luò)映射表中查找對應(yīng)的IP地址，這個過程可能會需要上百毫秒的時間，可能會存在DNS劫持的危險。所有根據(jù)具體的業(yè)務(wù)需求，可以采用增加動態(tài)更新能力的IP方式，或者在IP方式訪問失敗時切換到域名訪問方式。

2.合并網(wǎng)絡(luò)請求：

對于網(wǎng)絡(luò)請求應(yīng)該盡量減少請求的接口，能夠合并的網(wǎng)絡(luò)請求就盡量合并。

3.預(yù)先獲取數(shù)據(jù)：

預(yù)先獲取數(shù)據(jù)能夠?qū)⒕W(wǎng)絡(luò)請求集中在一次，其他時間段手機就可以切換到空閑狀態(tài)，避免經(jīng)常性的喚醒和空閑，起到節(jié)省電量的作用。

4.避免輪詢：

輪詢是指客戶端每隔一段時間就向服務(wù)端主動發(fā)起的網(wǎng)絡(luò)請求，存在需要的數(shù)據(jù)就拉取，沒有就等待下一次輪詢。一般情況下能使用推送替換的盡量使用推送，避免使用Thread.sleep()函數(shù)循環(huán)等待，可以使用系統(tǒng)AlarmMananger實現(xiàn)定時輪詢。

5.優(yōu)化重連機制：

盡量避免網(wǎng)絡(luò)請求失敗時，無限制循環(huán)重試連接，可以設(shè)定一個最大重連次數(shù)，超過次數(shù)限制之后結(jié)束重連，等一段時間后再嘗試連接。

6.離線緩存：

對于圖片，文件等數(shù)據(jù)，可以使用二級緩存策略，當(dāng)緩存中有對應(yīng)的圖片或者文件時，可以直接從緩存中讀取，不需要網(wǎng)絡(luò)請求，避免網(wǎng)絡(luò)延遲，節(jié)省流量。

7.壓縮數(shù)據(jù)大?。?/p>

對于客戶端來說，可以對發(fā)送給服務(wù)器的數(shù)據(jù)進行g(shù)zip壓縮，同時可以選用更優(yōu)的數(shù)據(jù)傳輸格式來減少網(wǎng)絡(luò)上面?zhèn)鬏數(shù)臄?shù)據(jù)。

8.不同的網(wǎng)絡(luò)環(huán)境使用不同的超時策略：

可以通過監(jiān)聽

ConnectivityMananger.CONNECTIVITY_ACTION的變化來獲取最新的網(wǎng)絡(luò)類型，動態(tài)調(diào)整網(wǎng)絡(luò)超時時間。

9.CDN的使用：

CDN，內(nèi)容發(fā)布網(wǎng)絡(luò)，盡可能避免網(wǎng)絡(luò)上可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的環(huán)節(jié)，實現(xiàn)更快，更穩(wěn)定的數(shù)據(jù)傳輸，其中CDN加速能夠緩解電信核心網(wǎng)絡(luò)延遲帶來的影響。