| Comments
Google前幾天剛發(fā)布了Android性能優(yōu)化典范第2季的課程，一共20個短視頻，包括的內(nèi)容大致有：電量優(yōu)化，網(wǎng)絡(luò)優(yōu)化，Wear上如何做優(yōu)化，使用對象池來提高效率，LRU Cache，Bitmap的縮放，緩存，重用，PNG壓縮，自定義View的性能，提升設(shè)置alpha之后View的渲染性能，以及Lint，StictMode等等工具的使用技巧。
下面是對這些課程的總結(jié)摘要，認知有限，理解偏差的地方請多多指教！
對于手機程序，網(wǎng)絡(luò)操作相對來說是比較耗電的行為。優(yōu)化網(wǎng)絡(luò)操作能夠顯著節(jié)約電量的消耗。在性能優(yōu)化第1季里面有提到過，手機硬件的各個模塊的耗電量是不一樣的，其中移動蜂窩模塊對電量消耗是比較大的，另外蜂窩模塊在不同工作強度下，對電量的消耗也是有差異的。當(dāng)程序想要執(zhí)行某個網(wǎng)絡(luò)請求之前，需要先喚醒設(shè)備，然后發(fā)送數(shù)據(jù)請求，之后等待返回數(shù)據(jù)，最后才慢慢進入休眠狀態(tài)。這個流程如下圖所示：
在上面那個流程中，蜂窩模塊的電量消耗差異如下圖所示：
從圖示中可以看到，激活瞬間，發(fā)送數(shù)據(jù)的瞬間，接收數(shù)據(jù)的瞬間都有很大的電量消耗，所以，我們應(yīng)該從如何傳遞網(wǎng)絡(luò)數(shù)據(jù)以及何時發(fā)起網(wǎng)絡(luò)請求這兩個方面來著手優(yōu)化。
首先我們需要區(qū)分哪些網(wǎng)絡(luò)請求是需要及時返回結(jié)果的，哪些是可以延遲執(zhí)行的。例如，用戶主動下拉刷新列表，這種行為需要立即觸發(fā)網(wǎng)絡(luò)請求，并等待數(shù)據(jù)返回。但是對于上傳用戶操作的數(shù)據(jù)，同步程序設(shè)置等等行為則屬于可以延遲的行為。我們可以通過Battery Historian這個工具來查看關(guān)于移動蜂窩模塊的電量消耗（關(guān)于這部分的細節(jié)，請點擊Android性能優(yōu)化之電量篇）。在Mobile Radio那一行會顯示蜂窩模塊的電量消耗情況，紅色的部分代表模塊正在工作，中間的間隔部分代表模塊正在休眠狀態(tài)，如果看到有一段區(qū)間，紅色與間隔頻繁的出現(xiàn)，那就說明這里有可以優(yōu)化的行為。如下圖所示：
對于上面可以優(yōu)化的部分，我們可以有針對性的把請求行為捆綁起來，延遲到某個時刻統(tǒng)一發(fā)起請求。如下圖所示：
經(jīng)過上面的優(yōu)化之后，我們再回頭使用Battery Historian導(dǎo)出電量消耗圖，可以看到喚醒狀態(tài)與休眠狀態(tài)是連續(xù)大塊間隔的，這樣的話，總體電量的消耗就會變得更少。
當(dāng)然，我們甚至可以把請求的任務(wù)延遲到手機網(wǎng)絡(luò)切換到WiFi，手機處于充電狀態(tài)下再執(zhí)行。在前面的描述過程中，我們會遇到的一個難題是如何把網(wǎng)絡(luò)請求延遲，并批量進行執(zhí)行。還好，Android提供了JobScheduler來幫助我們達成這個目標(biāo)。
關(guān)于這部分主要會涉及到Prefetch(預(yù)取)與Compressed(壓縮)這兩個技術(shù)。對于Prefetch的使用，我們需要預(yù)先判斷用戶在此次操作之后，后續(xù)零散的請求是否很有可能會馬上被觸發(fā)，可以把后面5分鐘有可能會使用到的零散請求都一次集中執(zhí)行完畢。對于Compressed的使用，在上傳與下載數(shù)據(jù)之前，使用CPU對數(shù)據(jù)進行壓縮與解壓，可以很大程度上減少網(wǎng)絡(luò)傳輸?shù)臅r間。
想要知道我們的應(yīng)用程序中網(wǎng)絡(luò)請求發(fā)生的時間，每次請求的數(shù)據(jù)量等等信息，可以通過Android Studio中的Networking Traffic Tool來查看詳細的數(shù)據(jù)，如下圖所示：
在Android Wear上會大量的使用Sensors來實現(xiàn)某些特殊功能，如何在盡量節(jié)約電量的前提下利用好Sensor會是我們需要特別注意的問題。下面會介紹一些在Android Wear上的最佳實踐典范。
盡量減少刷新請求，例如我們可以在不需要某些數(shù)據(jù)的時候盡快注銷監(jiān)聽，減小刷新頻率，對Sensor的數(shù)據(jù)做批量處理等等。那么如何做到這些優(yōu)化呢？
更對關(guān)于Sensors的知識，可以點擊這里
Android Material Design風(fēng)格的應(yīng)用采用了大量的動畫來進行UI切換，優(yōu)化動畫的性能不僅能夠提升用戶體驗還可以減少電量的消耗，下面會介紹一些簡單易行的方法。
在Android里面一個相對操作比較繁重的事情是對Bitmap進行旋轉(zhuǎn)，縮放，裁剪等等。例如在一個圓形的鐘表圖上，我們把時鐘的指針摳出來當(dāng)做單獨的圖片進行旋轉(zhuǎn)會比旋轉(zhuǎn)一張完整的圓形圖的所形成的幀率要高56%。
另外盡量減少每次重繪的元素可以極大的提升性能，假如某個鐘表界面上有很多需要顯示的復(fù)雜組件，我們可以把這些組件做拆分處理，例如把背景圖片單獨拎出來設(shè)置為一個獨立的View，通過setLayerType()方法使得這個View強制用Hardware來進行渲染。至于界面上哪些元素需要做拆分，他們各自的更新頻率是多少，需要有針對性的單獨討論。
如何使用Systrace等工具來查看某些View的渲染性能，在前面的章節(jié)里面有提到過，感興趣的可以點擊這里
對于大多數(shù)應(yīng)用中的動畫，我們會使用PropertyAnimation或者ViewAnimation來操作實現(xiàn)，Android系統(tǒng)會自動對這些Animation做一定的優(yōu)化處理，在Android上面學(xué)習(xí)到的大多數(shù)性能優(yōu)化的知識同樣也適用于Android Wear。
想要獲取更多關(guān)于Android Wear中動畫效果的優(yōu)化，請點擊WatchFace這個范例。
在Android Training里面有關(guān)于Wear上面如何利用Wearable API與Phone進行溝通協(xié)作的課程(詳情請點擊這里)。因為Phone的CPU與電量都比Wear要強大，另外Phone還可以直接接入網(wǎng)絡(luò)，而Wear要接入網(wǎng)絡(luò)則相對更加困難，所以我們在開發(fā)Wear應(yīng)用的時候需要盡量做到把復(fù)雜的操作交給Phone來執(zhí)行。例如我們可以讓Phone來獲取天氣信息，然后把數(shù)據(jù)返回Wear進行顯示。更進一步，在之前的性能優(yōu)化課程里面我們有學(xué)習(xí)過如何使用JobScheduler來延遲批量處理任務(wù)，假設(shè)Phone收到來自Wear的其中一個任務(wù)是每隔5分鐘檢查一次天氣情況，那么Phone使用JobScheduler執(zhí)行檢查天氣任務(wù)之后，先判斷這次返回的結(jié)果和之前是否有差異，僅僅當(dāng)天氣發(fā)生變化的時候，才有必要把結(jié)果通知到Wear，或者僅僅把變化的某一項數(shù)據(jù)通知給Wear，這樣可以更大程度上減少Wear的電量消耗。
下面我們總結(jié)一下如何優(yōu)化Wear的性能與電量：
在程序里面經(jīng)常會遇到的一個問題是短時間內(nèi)創(chuàng)建大量的對象，導(dǎo)致內(nèi)存緊張，從而觸發(fā)GC導(dǎo)致性能問題。對于這個問題，我們可以使用對象池技術(shù)來解決它。通常對象池中的對象可能是bitmaps，views，paints等等。關(guān)于對象池的操作原理，不展開述說了，請看下面的圖示：
使用對象池技術(shù)有很多好處，它可以避免內(nèi)存抖動，提升性能，但是在使用的時候有一些內(nèi)容是需要特別注意的。通常情況下，初始化的對象池里面都是空白的，當(dāng)使用某個對象的時候先去對象池查詢是否存在，如果不存在則創(chuàng)建這個對象然后加入對象池，但是我們也可以在程序剛啟動的時候就事先為對象池填充一些即將要使用到的數(shù)據(jù)，這樣可以在需要使用到這些對象的時候提供更快的首次加載速度，這種行為就叫做預(yù)分配。使用對象池也有不好的一面，程序員需要手動管理這些對象的分配與釋放，所以我們需要慎重地使用這項技術(shù)，避免發(fā)生對象的內(nèi)存泄漏。為了確保所有的對象能夠正確被釋放，我們需要保證加入對象池的對象和其他外部對象沒有互相引用的關(guān)系。
遍歷容器是編程里面一個經(jīng)常遇到的場景。在Java語言中，使用Iterate是一個比較常見的方法?？墒窃贏ndroid開發(fā)團隊中，大家卻盡量避免使用Iterator來執(zhí)行遍歷操作。下面我們看下在Android上可能用到的三種不同的遍歷方法：
使用上面三種方式在同一臺手機上，使用相同的數(shù)據(jù)集做測試，他們的表現(xiàn)性能如下所示：
從上面可以看到for index的方式有更好的效率，但是因為不同平臺編譯器優(yōu)化各有差異，我們最好還是針對實際的方法做一下簡單的測量比較好，拿到數(shù)據(jù)之后，再選擇效率最高的那個方式。
這小節(jié)我們要討論的是緩存算法，在Android上面最常用的一個緩存算法是LRU(Least Recently Use)，關(guān)于LRU算法，不展開述說，用下面一張圖演示下含義：
LRU Cache的基礎(chǔ)構(gòu)建用法如下：
為了給LRU Cache設(shè)置一個比較合理的緩存大小值，我們通常是用下面的方法來做界定的：
使用LRU Cache時為了能夠讓Cache知道每個加入的Item的具體大小，我們需要Override下面的方法：
使用LRU Cache能夠顯著提升應(yīng)用的性能，可是也需要注意LRU Cache中被淘汰對象的回收，否者會引起嚴(yán)重的內(nèi)存泄露。
Lint是Android提供的一個靜態(tài)掃描應(yīng)用源碼并找出其中的潛在問題的一個強大的工具。
例如，如果我們在onDraw方法里面執(zhí)行了new對象的操作，Lint就會提示我們這里有性能問題，并提出對應(yīng)的建議方案。Lint已經(jīng)集成到Android Studio中了，我們可以手動去觸發(fā)這個工具，點擊工具欄的Analysis -> Inspect Code，觸發(fā)之后，Lint會開始工作，并把結(jié)果輸出到底部的工具欄，我們可以逐個查看原因并根據(jù)指示做相應(yīng)的優(yōu)化修改。
Lint的功能非常強大，他能夠掃描各種問題。當(dāng)然我們可以通過Android Studio設(shè)置找到Lint，對Lint做一些定制化掃描的設(shè)置，可以選擇忽略掉那些不想Lint去掃描的選項，我們還可以針對部分掃描內(nèi)容修改它的提示優(yōu)先級。
建議把與內(nèi)存有關(guān)的選項中的嚴(yán)重程度標(biāo)記為紅色的Error，對于Layout的性能問題標(biāo)記為黃色Warning。
這小節(jié)會介紹如何減少透明區(qū)域?qū)π阅艿挠绊?。通常來說，對于不透明的View，顯示它只需要渲染一次即可，可是如果這個View設(shè)置了alpha值，會至少需要渲染兩次。原因是包含alpha的view需要事先知道混合View的下一層元素是什么，然后再結(jié)合上層的View進行Blend混色處理。
在某些情況下，一個包含alpha的View有可能會觸發(fā)改View在HierarchyView上的父View都被額外重繪一次。下面我們看一個例子，下圖演示的ListView中的圖片與二級標(biāo)題都有設(shè)置透明度。
大多數(shù)情況下，屏幕上的元素都是由后向前進行渲染的。在上面的圖示中，會先渲染背景圖(藍，綠，紅)，然后渲染人物頭像圖。如果后渲染的元素有設(shè)置alpha值，那么這個元素就會和屏幕上已經(jīng)渲染好的元素做blend處理。很多時候，我們會給整個View設(shè)置alpha的來達到fading的動畫效果，如果我們圖示中的ListView做alpha逐漸減小的處理，我們可以看到ListView上的TextView等等組件會逐漸融合到背景色上。但是在這個過程中，我們無法觀察到它其實已經(jīng)觸發(fā)了額外的繪制任務(wù)，我們的目標(biāo)是讓整個View逐漸透明，可是期間ListView在不停的做Blending的操作，這樣會導(dǎo)致不少性能問題。
如何渲染才能夠得到我們想要的效果呢？我們可以先按照通常的方式把View上的元素按照從后到前的方式繪制出來，但是不直接顯示到屏幕上，而是使用GPU預(yù)處理之后，再又GPU渲染到屏幕上，GPU可以對界面上的原始數(shù)據(jù)直接做旋轉(zhuǎn)，設(shè)置透明度等等操作。使用GPU進行渲染，雖然第一次操作相比起直接繪制到屏幕上更加耗時，可是一旦原始紋理數(shù)據(jù)生成之后，接下去的操作就比較省時省力。
如何才能夠讓GPU來渲染某個View呢？我們可以通過setLayerType的方法來指定View應(yīng)該如何進行渲染，從SDK 16開始，我們還可以使用ViewPropertyAnimator.alpha().withLayer()來指定。如下圖所示：
另外一個例子是包含陰影區(qū)域的View，這種類型的View并不會出現(xiàn)我們前面提到的問題，因為他們并不存在層疊的關(guān)系。
為了能夠讓渲染器知道這種情況，避免為這種View占用額外的GPU內(nèi)存空間，我們可以做下面的設(shè)置。
通過上面的設(shè)置以后，性能可以得到顯著的提升，如下圖所示：
我們都知道應(yīng)該避免在onDraw()方法里面執(zhí)行導(dǎo)致內(nèi)存分配的操作，下面講解下為何需要這樣做。
首先onDraw()方法是執(zhí)行在UI線程的，在UI線程盡量避免做任何可能影響到性能的操作。雖然分配內(nèi)存的操作并不需要花費太多系統(tǒng)資源，但是這并不意味著是免費無代價的。設(shè)備有一定的刷新頻率，導(dǎo)致View的onDraw方法會被頻繁的調(diào)用，如果onDraw方法效率低下，在頻繁刷新累積的效應(yīng)下，效率低的問題會被擴大，然后會對性能有嚴(yán)重的影響。
如果在onDraw里面執(zhí)行內(nèi)存分配的操作，會容易導(dǎo)致內(nèi)存抖動，GC頻繁被觸發(fā)，雖然GC后來被改進為執(zhí)行在另外一個后臺線程(GC操作在2.3以前是同步的，之后是并發(fā))，可是頻繁的GC的操作還是會影響到CPU，影響到電量的消耗。
那么簡單解決頻繁分配內(nèi)存的方法就是把分配操作移動到onDraw()方法外面，通常情況下，我們會把onDraw()里面new Paint的操作移動到外面，如下面所示：
UI線程被阻塞超過5秒，就會出現(xiàn)ANR，這太糟糕了。防止程序出現(xiàn)ANR是很重要的事情，那么如何找出程序里面潛在的坑，預(yù)防ANR呢？很多大部分情況下執(zhí)行很快的方法，但是他們有可能存在巨大的隱患，這些隱患的爆發(fā)就很容易導(dǎo)致ANR。
Android提供了一個叫做Strict Mode的工具，我們可以通過手機設(shè)置里面的開發(fā)者選項，打開Strict Mode選項，如果程序存在潛在的隱患，屏幕就會閃現(xiàn)紅色。我們也可以通過StrictMode API在代碼層面做細化的跟蹤，可以設(shè)置StrictMode監(jiān)聽那些潛在問題，出現(xiàn)問題時如何提醒開發(fā)者，可以對屏幕閃紅色，也可以輸出錯誤日志。下面是官方的代碼示例：
1234567891011121314151617 | |
Android系統(tǒng)有提供超過70多種標(biāo)準(zhǔn)的View，例如TextView，ImageView，Button等等。在某些時候，這些標(biāo)準(zhǔn)的View無法滿足我們的需要，那么就需要我們自己來實現(xiàn)一個View，這節(jié)會介紹如何優(yōu)化自定義View的性能。
通常來說，針對自定義View，我們可能犯下面三個錯誤：
最后請時刻牢記，盡量提高View的繪制性能，這樣才能保證界面的刷新幀率盡量的高。更多關(guān)于這部分的內(nèi)容，可以看這里
優(yōu)化性能時大多數(shù)時候討論的都是如何減少不必要的操作，但是選擇何時去執(zhí)行某些操作同樣也很重要。在第1季以及上一期的性能優(yōu)化之電量篇里面，我們有提到過移動蜂窩模塊的電量消耗模型。為了避免我們的應(yīng)用程序過多的頻繁消耗電量，我們需要學(xué)習(xí)如何把后臺任務(wù)打包批量，并選擇一個合適的時機進行觸發(fā)執(zhí)行。下圖是每個應(yīng)用程序各自執(zhí)行后臺任務(wù)導(dǎo)致的電量消耗示意圖：
因為像上面那樣做會導(dǎo)致浪費很多電量，我們需要做的是把部分應(yīng)用的任務(wù)延遲處理，等到一定時機，這些任務(wù)一并進行處理。結(jié)果如下面的示意圖：
執(zhí)行延遲任務(wù)，通常有下面三種方式：
使用AlarmManager設(shè)置定時任務(wù)，可以選擇精確的間隔時間，也可以選擇非精確時間作為參數(shù)。除非程序有很強烈的需要使用精確的定時喚醒，否者一定要避免使用他，我們應(yīng)該盡量使用非精確的方式。
我們可以使用SyncAdapter為應(yīng)用添加設(shè)置賬戶，這樣在手機設(shè)置的賬戶列表里面可以找到我們的應(yīng)用。這種方式功能更多，但是實現(xiàn)起來比較復(fù)雜。我們可以從這里看到官方的培訓(xùn)課程：http://developer.android.com/training/sync-adapters/index.html
這是最簡單高效的方法，我們可以設(shè)置任務(wù)延遲的間隔，執(zhí)行條件，還可以增加重試機制。
常見的png,jpeg,webp等格式的圖片在設(shè)置到UI上之前需要經(jīng)過解碼的過程，而解壓時可以選擇不同的解碼率，不同的解碼率對內(nèi)存的占用是有很大差別的。在不影響到畫質(zhì)的前提下盡量減少內(nèi)存的占用，這能夠顯著提升應(yīng)用程序的性能。
Android的Heap空間是不會自動做兼容壓縮的，意思就是如果Heap空間中的圖片被收回之后，這塊區(qū)域并不會和其他已經(jīng)回收過的區(qū)域做重新排序合并處理，那么當(dāng)一個更大的圖片需要放到heap之前，很可能找不到那么大的連續(xù)空閑區(qū)域，那么就會觸發(fā)GC，使得heap騰出一塊足以放下這張圖片的空閑區(qū)域，如果無法騰出，就會發(fā)生OOM。如下圖所示：
所以為了避免加載一張超大的圖片，需要盡量減少這張圖片所占用的內(nèi)存大小，Android為圖片提供了4種解碼格式，他們分別占用的內(nèi)存大小如下圖所示：
隨著解碼占用內(nèi)存大小的降低，清晰度也會有損失。我們需要針對不同的應(yīng)用場景做不同的處理，大圖和小圖可以采用不同的解碼率。在Android里面可以通過下面的代碼來設(shè)置解碼率：
盡量減少PNG圖片的大小是Android里面很重要的一條規(guī)范。相比起JPEG，PNG能夠提供更加清晰無損的圖片，但是PNG格式的圖片會更大，占用更多的磁盤空間。到底是使用PNG還是JPEG，需要設(shè)計師仔細衡量，對于那些使用JPEG就可以達到視覺效果的，可以考慮采用JPEG即可。我們可以通過Google搜索到很多關(guān)于PNG壓縮的工具，如下圖所示：
這里要介紹一種新的圖片格式：Webp，它是由Google推出的一種既保留png格式的優(yōu)點，又能夠減少圖片大小的一種新型圖片格式。關(guān)于Webp的更多細節(jié)，請點擊這里
對bitmap做縮放，這也是Android里面最遇到的問題。對bitmap做縮放的意義很明顯，提示顯示性能，避免分配不必要的內(nèi)存。Android提供了現(xiàn)成的bitmap縮放的API，叫做createScaledBitmap()，使用這個方法可以獲取到一張經(jīng)過縮放的圖片。
上面的方法能夠快速的得到一張經(jīng)過縮放的圖片，可是這個方法能夠執(zhí)行的前提是，原圖片需要事先加載到內(nèi)存中，如果原圖片過大，很可能導(dǎo)致OOM。下面介紹其他幾種縮放圖片的方式。
inSampleSize能夠等比的縮放顯示圖片，同時還避免了需要先把原圖加載進內(nèi)存的缺點。我們會使用類似像下面一樣的方法來縮放bitmap：
另外，我們還可以使用inScaled，inDensity，inTargetDensity的屬性來對解碼圖片做處理，源碼如下圖所示：
還有一個經(jīng)常使用到的技巧是inJustDecodeBounds，使用這個屬性去嘗試解碼圖片，可以事先獲取到圖片的大小而不至于占用什么內(nèi)存。如下圖所示：
我們知道bitmap會占用大量的內(nèi)存空間，這節(jié)會講解什么是inBitmap屬性，如何利用這個屬性來提升bitmap的循環(huán)效率。前面我們介紹過使用對象池的技術(shù)來解決對象頻繁創(chuàng)建再回收的效率問題，使用這種方法，bitmap占用的內(nèi)存空間會差不多是恒定的數(shù)值，每次新創(chuàng)建出來的bitmap都會需要占用一塊單獨的內(nèi)存區(qū)域，如下圖所示：
為了解決上圖所示的效率問題，Android在解碼圖片的時候引進了inBitmap屬性，使用這個屬性可以得到下圖所示的效果：
使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經(jīng)存在的內(nèi)存區(qū)域，新解碼的bitmap會嘗試去使用之前那張bitmap在heap中所占據(jù)的pixel data內(nèi)存區(qū)域，而不是去問內(nèi)存重新申請一塊區(qū)域來存放bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要占用屏幕所能夠顯示的圖片數(shù)量的內(nèi)存大小。下面是如何使用inBitmap的代碼示例：
使用inBitmap需要注意幾個限制條件：
我們可以創(chuàng)建一個包含多種典型可重用bitmap的對象池，這樣后續(xù)的bitmap創(chuàng)建都能夠找到合適的“模板”去進行重用。如下圖所示：
Google介紹了一個開源的加載bitmap的庫：Glide，這里面包含了各種對bitmap的優(yōu)化技巧。
大多數(shù)開發(fā)者在沒有發(fā)現(xiàn)嚴(yán)重性能問題之前是不會特別花精力去關(guān)注性能優(yōu)化的，通常大家關(guān)注的都是功能是否實現(xiàn)。當(dāng)性能問題真的出現(xiàn)的時候，請不要慌亂。我們通常采用下面三個步驟來解決性能問題。
我們可以通過Android SDK里面提供的諸多工具來收集CPU，GPU，內(nèi)存，電量等等性能數(shù)據(jù)，
通過上面的步驟，我們獲取到了大量的數(shù)據(jù)，下一步就是分析這些數(shù)據(jù)。工具幫我們生成了很多可讀性強的表格，我們需要事先了解如何查看表格的數(shù)據(jù)，每一項代表的含義，這樣才能夠快速定位問題。如果分析數(shù)據(jù)之后還是沒有找到問題，那么就只能不停的重新收集數(shù)據(jù)，再進行分析，如此循環(huán)。
定位到問題之后，我們需要采取行動來解決問題。解決問題之前一定要先有個計劃，評估這個解決方案是否可行，是否能夠及時的解決問題。
雖然前面介紹了很多調(diào)試的方法，處理技巧，規(guī)范建議等等，可是這并不意味著所有的情況都適用，我們還是需要根據(jù)當(dāng)時的情景做特定靈活的處理。
圍繞Android生態(tài)系統(tǒng)，不僅僅有Phone，還有Wear，TV，Auto等等。對這些不同形態(tài)的程序進行性能優(yōu)化，都離不開內(nèi)存調(diào)試這個步驟。這節(jié)中介紹的內(nèi)容大部分和Android性能優(yōu)化典范與Android性能優(yōu)化之內(nèi)存篇重合，不展開了。
首發(fā)于CSDN：Android性能優(yōu)化典范（二）
