本章介紹android高級開發(fā)中，對于性能方面的處理。主要包括電量，視圖，內(nèi)存三個(gè)性能方面的知識點(diǎn)。

1.視圖性能

(1)Overdraw簡介

    Overdraw就是過度繪制，是指在一幀的時(shí)間內(nèi)（16.67ms）像素被繪制了多次，理論上一個(gè)像素每次只繪制一次是最優(yōu)的，但是由于重疊的布 局導(dǎo)致一些像素會被多次繪制，而每次繪制都會對應(yīng)到CPU的一組繪圖命令和GPU的一些操作，當(dāng)這個(gè)操作耗時(shí)超過16.67ms時(shí)，就會出現(xiàn)掉幀現(xiàn)象，表現(xiàn)為應(yīng)用卡頓，所以對重疊不可見元素的重復(fù)繪制會產(chǎn)生額外的開銷，需要盡量減少Overdraw的發(fā)生。

(2)Overdraw檢測

    Android提供了測量Overdraw的選項(xiàng)，在開發(fā)者選項(xiàng)－調(diào)試GPU過度繪制（Show GPU Overdraw），打開選項(xiàng)就可以看到當(dāng)前頁面Overdraw的狀態(tài)，就可以觀察屏幕的繪制狀態(tài)。該工具會使用三種不同的顏色繪制屏幕，來指示 overdraw發(fā)生在哪里以及程度如何，其中：

 •沒有顏色： 意味著沒有overdraw。像素只畫了一次。

 •藍(lán)色： 意味著overdraw 1倍。像素繪制了兩次。大片的藍(lán)色還是可以接受的（若整個(gè)窗口是藍(lán)色的，可以擺脫一層）。 

•綠色： 意味著overdraw 2倍。像素繪制了三次。中等大小的綠色區(qū)域是可以接受的但你應(yīng)該嘗試優(yōu)化、減少它們。

•淺紅： 意味著overdraw 3倍。像素繪制了四次，小范圍可以接受。

 •暗紅： 意味著overdraw 4倍。像素繪制了五次或者更多。這是錯(cuò)誤的，要修復(fù)它們。

提高程序在視圖方面的性能， 總的原則就是：盡量避免重疊不可見元素的繪制。

(3)Overdraw改良

1)合理選擇控件容器

    Android提供的Layout控件主要包括 LinearLayout、TableLayout、FrameLayout、RelativeLayout。同一個(gè)界面可以使用不同的容器控件來表達(dá)，但是各個(gè)容器控件描述界面的復(fù)雜度是不一樣的。一般來LinearLayout最易，RelativeLayout較復(fù)雜。 LinearLayout只能用來描述一個(gè)方向上連續(xù)排列的控件，而RelativeLayout幾乎可以用于描述任意復(fù)雜度的界面。。綜上所述： LinearLayout易用，效率高，表達(dá)能力有限。RelativeLayout復(fù)雜，表達(dá)能力強(qiáng)，效率低。從減少overdraw的角度來看，LinearLayout會增加控件數(shù)的層級，自然是RelativeLayout 更優(yōu)，但是當(dāng)某一界面在使用LinearLayout并不會比RelativeLayout帶來更多的控件數(shù)和控件層級時(shí)，LinearLayout則是首選。

2)去掉window的默認(rèn)背景

   當(dāng)使用Android自帶的一些主題時(shí)，window會被默認(rèn)添加一個(gè)純色的背景，這個(gè)背景是被DecorView持有的。當(dāng)自定義布局時(shí)又添加了一張背景圖或者設(shè)置背景色，那么DecorView的background此時(shí)是無用的，但是它會產(chǎn)生一次Overdraw，帶來繪制性能損耗。去掉window的背景可以在onCreate()中setContentView()之后調(diào)用 getWindow().setBackgroundDrawable(null);或者在theme中添加 android:windowbackground="null"。

3)去掉其他不必要的背景

    父容器若已經(jīng)有了背景，可不設(shè)置對應(yīng)子控件的背景，及大的布局背景已經(jīng)設(shè)置，應(yīng)避免設(shè)置局部重復(fù)的背景。

4)自定義View處理

    對于自定義的view視圖，可以通過canvas.clipRect()來幫助系統(tǒng)識別那些可見的區(qū)域。這個(gè)方法可以指定一塊矩形區(qū)域，只有在這個(gè)區(qū)域內(nèi)才會被繪制，其他的區(qū)域會被忽視。這個(gè)API可以很好的幫助那些有多組重疊組件的自定義View來控制顯示的區(qū)域。同時(shí)clipRect方法還可以幫助節(jié)約CPU與GPU資源，在clipRect區(qū)域之外的繪制指令都不會被執(zhí)行，那些部分內(nèi)容在矩形區(qū)域內(nèi)的組件，仍然會得到繪制。除了clipRect方法之外，我們還可以使用canvas.quickreject()來判斷是否沒和某個(gè)矩形相交，從而跳過那些非矩形區(qū)域內(nèi)的繪制操作。

5)ViewStub高效占位符

    當(dāng)遇到這樣的情況，運(yùn)行時(shí)動(dòng)態(tài)根據(jù)條件來決定顯示哪個(gè)View或布局。常用的做法是把View都寫在上面，先把它們的可見性都設(shè)為 View.GONE，然后在代碼中動(dòng)態(tài)的更改它的可見性。這種模式的缺點(diǎn)是耗費(fèi)資源。雖然把View 的初始View.GONE但是在Inflate布局的時(shí)候View仍然會被Inflate，程序運(yùn)行時(shí)仍然會創(chuàng)建對象，會被實(shí)例化，會被設(shè)置屬性，會耗費(fèi)內(nèi)存等資源。

   推薦的做法是使用android.view.ViewStub，ViewStub是一個(gè)輕量級的View，它一個(gè)看不見的，不占布局位置，占用資源非常小的控件?？梢詾閂iewStub指定一個(gè)布局，在Inflate布局的時(shí)候，只有ViewStub會被初始化，然后當(dāng)ViewStub被設(shè)置為可見的時(shí)候，或是調(diào)用了ViewStub.inflate()的時(shí)候，ViewStub所向的布局就會被Inflate和實(shí)例化，然后ViewStub的布局屬性都會傳給它所指向的布局。這樣，就可以使用ViewStub來方便的在運(yùn)行時(shí)，要還是不要顯示某個(gè)布局。

6)善用draw9patch

    給ImageView加一個(gè)邊框，通常在ImageView后面設(shè)置一張背景圖，露出邊框便完美解決問題，此時(shí)這個(gè) ImageView，設(shè)置了兩層drawable，兩層drawable的重疊區(qū)域去繪制了兩次，導(dǎo)致 overdraw。優(yōu)化方案： 將背景drawable制作成draw9patch，并且將和前景重疊的部分設(shè)置為透明。由于Android的2D渲染器會優(yōu)化draw9patch中的透明區(qū)域，從而優(yōu)化了這次overdraw。

7)Merge 

    使用Merge標(biāo)簽來做容器控件。第一種子視圖不需要指定任何針對父視圖的布局屬性，就是說父容器僅僅是個(gè)容器，子視圖只需要直接添加到父視圖上用于顯示 就 行。另外一種是假如需要在LinearLayout里面嵌入一個(gè)布局 （或者視圖），而恰恰這個(gè)布局（或者視圖）的根節(jié)點(diǎn)也是LinearLayout，這樣就多了一層沒有用的嵌套，無疑這樣只會拖慢程序速度。而這個(gè)時(shí)候如 果我們使用merge根標(biāo)簽就可以避免那樣的問題。

2.內(nèi)存性能

(1)內(nèi)存分配與回收

    每一個(gè)進(jìn)程的Dalvik Heap都反映了使用內(nèi)存的占用范圍。這就是通常邏輯意義上提到的Dalvik Heap Size，它可以隨著需要進(jìn)行增長，但是增長行為會有一個(gè)系統(tǒng)為它設(shè)定上限。

    邏輯上講的Heap Size和實(shí)際物理意義上使用的內(nèi)存大小是不對等的，Proportional Set Size(PSS)記錄了應(yīng)用程序自身占用以及與其他進(jìn)程進(jìn)行共享的內(nèi)存。

    Android 系統(tǒng)并不會對Heap中空閑內(nèi)存區(qū)域做碎片整理。系統(tǒng)僅僅會在新的內(nèi)存分配之前判斷Heap的尾端剩余空間是否足夠，如果空間不夠會觸發(fā)GC操作，從而騰 出更多空閑的內(nèi)存空間。在Android的高級系統(tǒng)版本里面針對Heap空間有一個(gè)Generational Heap Memory的模型，最近分配的對象會存放在Young Generation區(qū)域。當(dāng)這個(gè)對象在該區(qū)域停留的時(shí)間達(dá)到一定程度，它會被移動(dòng)到Old Generation，最后累積一定時(shí)間再移動(dòng)到Permanent Generation區(qū)域。系統(tǒng)會根據(jù)內(nèi)存中不同的內(nèi)存數(shù)據(jù)類型分別執(zhí)行不同的GC操作。例如，剛分配到Y(jié)oung Generation區(qū)域的對象通常更容易被銷毀回收，同時(shí)在Young Generation區(qū)域的GC操作速度會比Old Generation區(qū)域的GC操作速度更快（如圖1所示）。

圖1  根據(jù)不同內(nèi)存數(shù)據(jù)類型執(zhí)行不同GC操作

    每一個(gè)Generation的內(nèi)存區(qū)域都有固定的大小。隨著新的對象陸續(xù)被分配到此區(qū)域，當(dāng)對象總的大小臨近這一級別內(nèi)存區(qū)域的閥值時(shí)，會觸發(fā)GC操作，以便騰出空間來存放其他新的對象（如圖2所示）。

圖2  對象值臨近閥值觸發(fā)GC操作

    通常情況下，GC發(fā)生的時(shí)候，所有的線程都是會被暫停的。執(zhí)行GC所占用的時(shí)間和它發(fā)生在哪一個(gè)Generation也有關(guān)系，Young Generation中的每次GC操作時(shí)間是最短的，Old Generation其次，Permanent Generation最長。執(zhí)行時(shí)間的長短也和當(dāng)前Generation中的對象數(shù)量有關(guān)，遍歷樹結(jié)構(gòu)查找20000個(gè)對象比起遍歷50個(gè)對象自然是要慢 很多的。

(2)內(nèi)存測試插件

1）LeakCanary簡介

    LeakCanary是一個(gè)用于檢測內(nèi)存泄漏的工具，可以用于Java和Android，是由著名開源組織Square貢獻(xiàn)。

2）LeakCanary工作原理

 •RefWatcher.watch()創(chuàng)建一個(gè)KeyedWeakReference到北監(jiān)控的對象。

 •接下來，在后臺線程中檢測這個(gè)引用是否被清除，如果沒有將會觸發(fā)GC。

•如果引用仍然沒有清除，將heap內(nèi)存dump到一個(gè).hprof的文件存放到手機(jī)系統(tǒng)里。

 •HeapAnalyzerService在另外一個(gè)獨(dú)立的進(jìn)程中啟動(dòng)，使用HeapAnalyzer解析heap內(nèi)存通過HAHA這個(gè)項(xiàng)目

 •HeapAnalyzer計(jì)算出到GC ROOTs的最短強(qiáng)引用路徑?jīng)Q定是否發(fā)生Leak,然后建立導(dǎo)致泄漏的引用鏈。 結(jié)果被回傳到應(yīng)用程序進(jìn)程的DisplayLeakService中，然后顯示一個(gè)泄漏的通知。

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

1）謹(jǐn)慎使用large heap

    Android設(shè)備根據(jù)硬件與軟件的設(shè)置差異而存在不同大小的內(nèi)存空間，他們?yōu)閼?yīng)用程序設(shè)置了不同大小的Heap限制閾值。設(shè)計(jì)時(shí)可以通過調(diào)用getMemoryClass()來獲取應(yīng)用的可用Heap大小。在一些特殊的情景下，你可以通過在manifest的application標(biāo)簽下添加 largeHeap=true的屬性來為應(yīng)用聲明一個(gè)更大的heap空間。然后，你可以通過getLargeMemoryClass()來獲取到這個(gè)更大的heap size閾值。

    然而，聲明得到更大Heap閾值的本意是為了一小部分會消耗大量RAM的應(yīng)用(例如一個(gè)大圖片的編輯應(yīng)用)。不要輕易的因?yàn)槟阈枰褂酶嗟膬?nèi)存而去請求一個(gè)大的Heap Size。只有當(dāng)你清楚的知道哪里會使用大量的內(nèi)存并且知道為什么這些內(nèi)存必須被保留時(shí)才去使用large heap。因此請謹(jǐn)慎使用large heap屬性。使用額外的內(nèi)存空間會影響系統(tǒng)整體的用戶體驗(yàn)，并且會使得每次gc的運(yùn)行時(shí)間更長。

2）綜合考慮設(shè)備內(nèi)存閾值與其他因素設(shè)計(jì)合適的緩存大小

    例如，在設(shè)計(jì)ListView或者GridView的Bitmap LRU緩存的時(shí)候，需要考慮的點(diǎn)有：

 •應(yīng)用程序剩下了多少可用的內(nèi)存空間?

 •有多少圖片會被一次呈現(xiàn)到屏幕上？有多少圖片需要事先緩存好以便快速滑動(dòng)時(shí)能夠立即顯示到屏幕？

 •設(shè)備的屏幕大小與密度是多少? 一個(gè)xhdpi的設(shè)備會比hdpi需要一個(gè)更大的Cache來hold住同樣數(shù)量的圖片。

 •不同的頁面針對Bitmap的設(shè)計(jì)的尺寸與配置是什么，大概會花費(fèi)多少內(nèi)存？

 •頁面圖片被訪問的頻率？是否存在其中的一部分比其他的圖片具有更高的訪問頻繁？如果是，也許你想要保存那些最常訪問的到內(nèi)存中，或者為不同組別的位圖(按訪問頻率分組)設(shè)置多個(gè)LruCache容器。

3）資源文件需要選擇合適的文件夾進(jìn)行存放

   hdpi/xhdpi/xxhdpi等等不同dpi的文件夾下的圖片在不同的設(shè)備上會經(jīng)過scale的處理。例如我們只在hdpi的目錄下放置了一 張100100的圖片，那么根據(jù)換算關(guān)系，xxhdpi的手機(jī)去引用那張圖片就會被拉伸到200200。需要注意到在這種情況下，內(nèi)存占用是會顯著提高 的。對于不希望被拉伸的圖片，需要放到assets或者nodpi的目錄下。

4）Try catch某些大內(nèi)存分配的操作

    在某些情況下，我們需要事先評估那些可能發(fā)生OOM的代碼，對于這些可能發(fā)生OOM的代碼，加入catch機(jī)制，可以考慮在catch里面嘗試一次降級的內(nèi)存分配操作。例如decode bitmap的時(shí)候，catch到OOM，可以嘗試把采樣比例再增加一倍之后，再次嘗試decode。

5）謹(jǐn)慎使用static對象

    因?yàn)閟tatic的生命周期過長，和應(yīng)用的進(jìn)程保持一致，使用不當(dāng)很可能導(dǎo)致對象泄漏，在Android中應(yīng)該謹(jǐn)慎使用static對象。

6）特別留意單例對象中不合理的持有

    雖然單例模式簡單實(shí)用，提供了很多便利性，但是因?yàn)閱卫纳芷诤蛻?yīng)用保持一致，使用不合理很容易出現(xiàn)持有對象的泄漏。

7）珍惜Services資源

    應(yīng)用需要在后臺使用service，除非它被觸發(fā)并執(zhí)行一個(gè)任務(wù)，否則其他時(shí)候Service都應(yīng)該是停止?fàn)顟B(tài)。另外需要注意當(dāng)這個(gè)service 完成任務(wù)之后因?yàn)橥Ｖ箂ervice失敗而引起的內(nèi)存泄漏。 當(dāng)你啟動(dòng)一個(gè)Service，系統(tǒng)會傾向?yàn)榱吮Ａ暨@個(gè)Service而一直保留Service所在的進(jìn)程。這使得進(jìn)程的運(yùn)行代價(jià)很高，因?yàn)橄到y(tǒng)沒有辦法把 Service所占用的RAM空間騰出來讓給其他組件，另外Service還不能被Paged out。這減少了系統(tǒng)能夠存放到LRU緩存當(dāng)中的進(jìn)程數(shù)量，它會影響應(yīng)用之間的切換效率，甚至?xí)?dǎo)致系統(tǒng)內(nèi)存使用不穩(wěn)定，從而無法繼續(xù)保持住所有目前正在運(yùn)行的service。 建議使用IntentService，它會在處理完交代給它的任務(wù)之后盡快結(jié)束自己。

8）使用ProGuard來剔除不需要的代碼

   ProGuard能夠通過移除不需要的代碼，重命名類，域與方法等等對代碼進(jìn)行壓縮，優(yōu)化與混淆。使用ProGuard可以使得你的代碼更加緊湊，這樣能夠減少mapping代碼所需要的內(nèi)存空間。

9）使用更加輕量的數(shù)據(jù)結(jié)構(gòu)

   考慮使用ArrayMap/SparseArray而不是HashMap等傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)。

   HashMap的容器，相比起 Android專門為移動(dòng)操作系統(tǒng)編寫的ArrayMap容器，在大多數(shù)情況下，都顯示效率低下，更占內(nèi)存。通常的HashMap的實(shí)現(xiàn)方式更加消耗內(nèi)存，因?yàn)樗枰粋€(gè)額外的實(shí)例對象來記錄Mapping操作。另外，SparseArray更加高效，在于他們避免了對key與value的自動(dòng)裝箱 （autoboxing），并且避免了裝箱后的解箱。

10）避免在Android里面使用Enum

  Android 官方培訓(xùn)課程提到過“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具體原理請參考《Android性能優(yōu)化典范（三）》，所以請避免在Android里面使用到枚舉。

11）減小Bitmap對象的內(nèi)存占用

    Bitmap是一個(gè)極容易消耗內(nèi)存的大胖子，減小創(chuàng)建出來的Bitmap的內(nèi)存占用可謂是重中之重，通常來說有以下2個(gè)措施：
 •inSampleSize：縮放比例，在把圖片載入內(nèi)存之前，我們需要先計(jì)算出一個(gè)合適的縮放比例，避免不必要的大圖載入。
 •decode format：解碼格式，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差異。

12）使用更小的圖片

    在涉及給到資源圖片時(shí)，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用更小的圖片。盡量使用更小的圖片不僅可以減少內(nèi)存的使用，還能避免出現(xiàn)大量的InflationException。假設(shè)有一張很大的圖片被XML文件直接引用，很有可能在初始化視圖時(shí)會因?yàn)閮?nèi)存不足而發(fā)生InflationException，這個(gè)問題的根本原因其實(shí)是發(fā)生了OOM。

13）內(nèi)存對象的重復(fù)利用

  大多數(shù)對象的復(fù)用，最終實(shí)施的方案都是利用對象池技術(shù)，要么是在編寫代碼時(shí)顯式地在程序里創(chuàng)建對象池，然后處理好復(fù)用的實(shí)現(xiàn)邏輯。要么就是利用系統(tǒng)框架既有的某些復(fù)用特性，減少對象的重復(fù)創(chuàng)建，從而降低內(nèi)存的分配與回收。

14）復(fù)用系統(tǒng)自帶的資源

    Android 系統(tǒng)本身內(nèi)置了很多的資源，比如字符串、顏色、圖片、動(dòng)畫、樣式以及簡單布局等，這些資源都可以在應(yīng)用程序中直接引用。這樣做不僅能減少應(yīng)用程序的自身負(fù)重，減小APK的大小，還可以在一定程度上減少內(nèi)存的開銷，復(fù)用性更好。但是也有必要留意Android系統(tǒng)的版本差異性，對那些不同系統(tǒng)版本上表現(xiàn)存在很大差異、不符合需求的情況，還是需要應(yīng)用程序自身內(nèi)置進(jìn)去。

15）注意Cursor對象是否及時(shí)關(guān)閉

    在程序中我們經(jīng)常會進(jìn)行查詢數(shù)據(jù)庫的操作，但時(shí)常會存在不小心使用Cursor之后沒有及時(shí)關(guān)閉的情況。這些Cursor的泄露，反復(fù)多次出現(xiàn)的話會對內(nèi)存管理產(chǎn)生很大的負(fù)面影響，我們需要謹(jǐn)記對Cursor對象的及時(shí)關(guān)閉。

16）避免在onDraw方法里面執(zhí)行對象的創(chuàng)建

   類似onDraw等頻繁調(diào)用的方法，一定需要注意避免在這里做創(chuàng)建對象的操作，因?yàn)樗麜杆僭黾觾?nèi)存的使用，而且很容易引起頻繁的gc，甚至是內(nèi)存抖動(dòng)。

17）StringBuilder

    在有些時(shí)候，代碼中會需要使用到大量的字符串拼接的操作，這種時(shí)候有必要考慮使用StringBuilder來替代頻繁的“+”。

18）注意Activity的泄漏

 通常來說，Activity的泄漏是內(nèi)存泄漏里面最嚴(yán)重的問題，它占用的內(nèi)存多，影響面廣，需要特別注意以下兩種情況導(dǎo)致的Activity泄漏：

 •內(nèi)部類引用導(dǎo)致Activity的泄露

   最典型的場景是Handler導(dǎo)致的Activity泄漏，如果Handler中有延遲的任務(wù)或者是等待執(zhí)行的任務(wù)隊(duì)列過長，都有可能因?yàn)镠andler繼 續(xù)執(zhí)行而導(dǎo)致Activity發(fā)生泄漏。此時(shí)的引用關(guān)系鏈?zhǔn)荓ooper -> MessageQueue -> Message -> Handler -> Activity。為了解決這個(gè)問題，可以在UI退出之前，執(zhí)行remove Handler消息隊(duì)列中的消息與runnable對象?；蛘呤鞘褂肧tatic + WeakReference的方式來達(dá)到斷開Handler與Activity之間存在引用關(guān)系的目的。

•Activity Context被傳遞到其他實(shí)例中，這可能導(dǎo)致自身被引用而發(fā)生泄漏。

    內(nèi)部類引起的泄漏不僅僅會發(fā)生在Activity上，其他任何內(nèi)部類出現(xiàn)的地方，都需要特別留意！可以考慮盡量使用static類型的內(nèi)部類，同時(shí)使用WeakReference的機(jī)制來避免因?yàn)榛ハ嘁枚霈F(xiàn)的泄露。

19）考慮使用Application Context而不是Activity Context

    對于大部分非必須使用Activity Context的情況（Dialog的Context就必須是Activity Context），都可以考慮使用Application Context而不是Activity的Context，這樣可以避免不經(jīng)意的Activity泄露。

(3)電量優(yōu)化

    電量其實(shí)是目前手持設(shè)備最寶貴的資源之一，大多數(shù)設(shè)備都需要不斷的充電來維持繼續(xù)使用。不幸的是，對于開發(fā)者來說，電量優(yōu)化是他們最后才會考慮的的事情。但是可以確定的是，千萬不能讓你的應(yīng)用成為消耗電量的大戶。

有下面一些措施能夠顯著減少電量的消耗：

 •我們應(yīng)該盡量減少喚醒屏幕的次數(shù)與持續(xù)的時(shí)間，使用WakeLock來處理喚醒的問題，能夠正確執(zhí)行喚醒操作并根據(jù)設(shè)定及時(shí)關(guān)閉操作進(jìn)入睡眠狀態(tài)。
 •某些非必須馬上執(zhí)行的操作，例如上傳歌曲，圖片處理等，可以等到設(shè)備處于充電狀態(tài)或者電量充足的時(shí)候才進(jìn)行。
 •觸發(fā)網(wǎng)絡(luò)請求的操作，每次都會保持無線信號持續(xù)一段時(shí)間，我們可以把零散的網(wǎng)絡(luò)請求打包進(jìn)行一次操作，避免過多的無線信號引起的電量消耗。關(guān)于網(wǎng)絡(luò)請求引起無線信號的電量消耗。

1)消耗電量的幾個(gè)主要原因、功能

 •大數(shù)據(jù)量的網(wǎng)絡(luò)傳輸（網(wǎng)絡(luò)）

 •不停的網(wǎng)絡(luò)切換（網(wǎng)絡(luò)）

 •解析大量的數(shù)據(jù)（CPU）

2)關(guān)于網(wǎng)絡(luò)方面的優(yōu)化

 •網(wǎng)絡(luò)請求之前，檢查網(wǎng)絡(luò)連接。沒有網(wǎng)絡(luò)連接不進(jìn)行請求

 •判斷網(wǎng)絡(luò)類型，針對特定的數(shù)據(jù)在特定的網(wǎng)絡(luò)下請求。例如：大量數(shù)據(jù)傳輸?shù)臅r(shí)候，在wifi下請求。wifi下下載數(shù)據(jù)耗電量只有2、3、4G的1/3.

 •使用效率高的解析工具。根據(jù)具體業(yè)務(wù)數(shù)據(jù)量的大小，選擇合適的解析工具。例如android上面的協(xié)議解析一般推薦json。

 •使用GZIP壓縮方式下載數(shù)據(jù)，能減少網(wǎng)絡(luò)流量，縮短下載時(shí)間

•合理使用緩存，避免重復(fù)操作

 •使用推送，代替循環(huán)請求

 •觸發(fā)網(wǎng)絡(luò)請求的操作，每次都會保持無線信號持續(xù)一段時(shí)間，我們可以把零散的網(wǎng)絡(luò)請求打包進(jìn)行一次操作，避免過多的無線信號引起的電量消耗。

 •是JobScheduler API所做的事情。它會根據(jù)當(dāng)前的情況與任務(wù)，組合出理想的喚醒時(shí)間，例如等到正在充電或者連接到WiFi的時(shí)候，或者集中任務(wù)一起執(zhí)行。我們可以通過這個(gè)API實(shí)現(xiàn)很多免費(fèi)的調(diào)度算法。

3)電量優(yōu)化策略

 •檢查全部喚醒鎖, 是否存在冗余或者無用的位置.

 •集中相關(guān)的數(shù)據(jù)請求, 統(tǒng)一發(fā)送; 精簡數(shù)據(jù), 減少無用數(shù)據(jù)的傳輸.

 •分析和統(tǒng)計(jì)等非重要操作, 可以在電量充足或連接WIFI時(shí)進(jìn)行, 參考JobScheduler.

 •精簡冗余的服務(wù)(Service), 避免長時(shí)間執(zhí)行耗電操作.

 •注意定位信息的獲取, 使用后及時(shí)關(guān)閉.

以上所述是小編給大家介紹的Android高級開發(fā)之性能優(yōu)化典范的相關(guān)知識，希望對大家有所幫在，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論