六、性能及優(yōu)化
1、App優(yōu)化之性能分析工具
2、ListView優(yōu)化
Android性能優(yōu)化之提高ListView性能的技巧
分析篇：ListView優(yōu)化
問題：ListView卡頓的原因與性能優(yōu)化，越多越好
重用convertView： 通過復(fù)用converview來減少不必要的view的創(chuàng)建，另外Infalte操作會(huì)把xml文件實(shí)例化成相應(yīng)的View實(shí)例，屬于IO操作，是耗時(shí)操作。
減少findViewById()操作： 將xml文件中的元素封裝成viewholder靜態(tài)類，通過converview的setTag和getTag方法將view與相應(yīng)的holder對(duì)象綁定在一起，避免不必要的findviewbyid操作
避免在 getView 方法中做耗時(shí)的操作: 例如加載本地 Image 需要載入內(nèi)存以及解析 Bitmap ，都是比較耗時(shí)的操作，如果用戶快速滑動(dòng)listview，會(huì)因?yàn)間etview邏輯過于復(fù)雜耗時(shí)而造成滑動(dòng)卡頓現(xiàn)象。用戶滑動(dòng)時(shí)候不要加載圖片，待滑動(dòng)完成再加載，可以使用這個(gè)第三方庫glide
Item的布局層次結(jié)構(gòu)盡量簡(jiǎn)單，避免布局太深或者不必要的重繪
盡量能保證 Adapter 的 hasStableIds() 返回 true這樣在 notifyDataSetChanged() 的時(shí)候，如果item內(nèi)容并沒有變化，ListView 將不會(huì)重新繪制這個(gè) View，達(dá)到優(yōu)化的目的
在一些場(chǎng)景中，ScollView內(nèi)會(huì)包含多個(gè)ListView，可以把listview的高度寫死固定下來。由于ScollView在快速滑動(dòng)過程中需要大量計(jì)算每一個(gè)listview的高度，阻塞了UI線程導(dǎo)致卡頓現(xiàn)象出現(xiàn)，如果我們每一個(gè)item的高度都是均勻的，可以通過計(jì)算把listview的高度確定下來，避免卡頓現(xiàn)象出現(xiàn)
使用 RecycleView 代替listview： 每個(gè)item內(nèi)容的變動(dòng)，listview都需要去調(diào)用notifyDataSetChanged來更新全部的item，太浪費(fèi)性能了。RecycleView可以實(shí)現(xiàn)當(dāng)個(gè)item的局部刷新，并且引入了增加和刪除的動(dòng)態(tài)效果，在性能上和定制上都有很大的改善
ListView 中元素避免半透明： 半透明繪制需要大量乘法計(jì)算，在滑動(dòng)時(shí)不停重繪會(huì)造成大量的計(jì)算，在比較差的機(jī)子上會(huì)比較卡。 在設(shè)計(jì)上能不半透明就不不半透明。實(shí)在要弄就把在滑動(dòng)的時(shí)候把半透明設(shè)置成不透明，滑動(dòng)完再重新設(shè)置成半透明。
盡量開啟硬件加速： 硬件加速提升巨大，避免使用一些不支持的函數(shù)導(dǎo)致含淚關(guān)閉某個(gè)地方的硬件加速。當(dāng)然這一條不只是對(duì) ListView。
3、OOM系列問題
問題：什么OOM？
OOM全稱是Out Of Merrory，Android系統(tǒng)的每一個(gè)應(yīng)用程序都設(shè)置一個(gè)硬性的Dalvik Heap Size最大限制閾值，如果申請(qǐng)的內(nèi)存資源超過這個(gè)限制，系統(tǒng)就會(huì)拋出OOM錯(cuò)誤
問題：如何避免 OOM 問題的出現(xiàn)
1. 使用更加輕量的數(shù)據(jù)結(jié)構(gòu)例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)。通常的HashMap的實(shí)現(xiàn)方式更加消耗內(nèi)存，因?yàn)樗枰粋€(gè)額外的實(shí)例對(duì)象來記錄Mapping操作。另外，SparseArray更加高效，在于他們避免了對(duì)key與value的自動(dòng)裝箱（autoboxing），并且避免了裝箱后的解箱。
2. 避免在Android里面使用EnumAndroid官方培訓(xùn)課程提到過“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具體原理請(qǐng)參考《Android性能優(yōu)化典范（三）》，所以請(qǐng)避免在Android里面使用到枚舉。
3. 減小Bitmap對(duì)象的內(nèi)存占用Bitmap是一個(gè)極容易消耗內(nèi)存的大胖子，減小創(chuàng)建出來的Bitmap的內(nèi)存占用可謂是重中之重，，通常來說有以下2個(gè)措施：inSampleSize：縮放比例，在把圖片載入內(nèi)存之前，我們需要先計(jì)算出一個(gè)合適的縮放比例，避免不必要的大圖載入。decode format：解碼格式，選擇ARGB_6666/RBG_545/ARGB_4444/ALPHA_6，存在很大差異
4.Bitmap對(duì)象的復(fù)用縮小Bitmap的同時(shí)，也需要提高BitMap對(duì)象的復(fù)用率，避免頻繁創(chuàng)建BitMap對(duì)象，復(fù)用的方法有以下2個(gè)措施LRUCache: “最近最少使用算法”在Android中有極其普遍的應(yīng)用。ListView與GridView等顯示大量圖片的控件里，就是使用LRU的機(jī)制來緩存處理好的Bitmap，把近期最少使用的數(shù)據(jù)從緩存中移除，保留使用最頻繁的數(shù)據(jù)，inBitMap高級(jí)特性:利用inBitmap的高級(jí)特性提高Android系統(tǒng)在Bitmap分配與釋放執(zhí)行效率。使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經(jīng)存在的內(nèi)存區(qū)域，新解碼的Bitmap會(huì)嘗試去使用之前那張Bitmap在Heap中所占據(jù)的pixel data內(nèi)存區(qū)域，而不是去問內(nèi)存重新申請(qǐng)一塊區(qū)域來存放Bitmap。利用這種特性，即使是上千張的圖片，也只會(huì)僅僅只需要占用屏幕所能夠顯示的圖片數(shù)量的內(nèi)存大小
4. 使用更小的圖片在涉及給到資源圖片時(shí)，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用更小的圖片。盡量使用更小的圖片不僅可以減少內(nèi)存的使用，還能避免出現(xiàn)大量的InflationException。假設(shè)有一張很大的圖片被XML文件直接引用，很有可能在初始化視圖時(shí)會(huì)因?yàn)閮?nèi)存不足而發(fā)生InflationException，這個(gè)問題的根本原因其實(shí)是發(fā)生了OOM。
5.StringBuilder在有些時(shí)候，代碼中會(huì)需要使用到大量的字符串拼接的操作，這種時(shí)候有必要考慮使用StringBuilder來替代頻繁的“+”。
4.避免在onDraw方法里面執(zhí)行對(duì)象的創(chuàng)建類似onDraw等頻繁調(diào)用的方法，一定需要注意避免在這里做創(chuàng)建對(duì)象的操作，因?yàn)樗麜?huì)迅速增加內(nèi)存的使用，而且很容易引起頻繁的gc，甚至是內(nèi)存抖動(dòng)。
5. 避免對(duì)象的內(nèi)存泄露android中內(nèi)存泄漏的場(chǎng)景以及解決辦法，參考上一問
4、ANR 系列問題
問題：什么是ANR
ANR全稱Application Not Responding，意思就是程序未響應(yīng)。如果一個(gè)應(yīng)用無法響應(yīng)用戶的輸入，系統(tǒng)就會(huì)彈出一個(gè)ANR對(duì)話框，用戶可以自行選擇繼續(xù)等待亦或者是停止當(dāng)前程序。一旦出現(xiàn)下面兩種情況，則彈出ANR對(duì)話框
應(yīng)用在5秒內(nèi)未響應(yīng)用戶的輸入事件（如按鍵或者觸摸）
BroadcastReceiver未在10秒內(nèi)完成相關(guān)的處理
問題：ANR是怎么引起的？
主線程中存在耗時(shí)的計(jì)算-
主線程被IO操作（從4.0之后網(wǎng)絡(luò)IO不允許在主線程中）阻塞。-
主線程中錯(cuò)誤的操作，比如Thread.wait或者Thread.sleep等
問題：如何避免ANR問題的出現(xiàn)
基本思路就是把一些耗時(shí)操作放到子線程中處理
使用AsyncTask處理耗時(shí)IO操作。
降低子線程優(yōu)先級(jí)使用Thread或者HandlerThread時(shí)，調(diào)用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)設(shè)置優(yōu)先級(jí)，否則仍然會(huì)降低程序響應(yīng)，因?yàn)槟J(rèn)Thread的優(yōu)先級(jí)和主線程相同。
使用Handler處理子線程結(jié)果，而不是使用Thread.wait()或者Thread.sleep()來阻塞主線程。
Activity的onCreate和onResume回調(diào)中盡量避免耗時(shí)的代碼
BroadcastReceiver中onReceive代碼也要盡量減少耗時(shí)操作建議使用IntentService處理。IntentService是一個(gè)異步的，會(huì)自動(dòng)停止的服務(wù)，很好解決了傳統(tǒng)的Service中處理完耗時(shí)操作忘記停止并銷毀Service的問題
5、如何優(yōu)化一個(gè)app（性能優(yōu)化、布局優(yōu)化、代碼優(yōu)化、算法優(yōu)化、網(wǎng)絡(luò)優(yōu)化、體驗(yàn)上）
參考1
6、內(nèi)存優(yōu)化相關(guān)
問題：安卓采用自動(dòng)垃圾回收機(jī)制，請(qǐng)說下安卓?jī)?nèi)存管理的原理
問題：內(nèi)存回收機(jī)制與GC算法(各種算法的優(yōu)缺點(diǎn)以及應(yīng)用場(chǎng)景)；
問題：內(nèi)存泄露場(chǎng)景及解決方法；LeakCanary的實(shí)現(xiàn)原理。
LeakCanay的入口是在application的onCreate()方法中聲明的，其實(shí)用的就是Application的ActivityLifecycleCallbacks回調(diào)接口監(jiān)聽所有activity的onDestory()的，在這個(gè)方法進(jìn)行RefWatcher.watch對(duì)這個(gè)對(duì)象進(jìn)行監(jiān)控。
具體是這樣做的，封裝成帶key的弱引用對(duì)象，然后GC看弱引用對(duì)象有沒有回收，沒有回收的話就懷疑是泄漏了，需要二次確認(rèn)。然后生成HPROF文件，分析這個(gè)快照文件有沒有存在帶這個(gè)key值的泄漏對(duì)象，如果沒有，那么沒有泄漏，否則找出最短路徑，打印給我們，我們就能夠找到這個(gè)泄漏對(duì)象了。
7、圖片優(yōu)化
問題：圖片緩存的優(yōu)化；
問題：一張Bitmap所占內(nèi)存以及內(nèi)存占用的計(jì)算；
用skia庫壓縮圖片
8、Webview優(yōu)化
9、布局優(yōu)化
布局性能優(yōu)化：布局性能優(yōu)化(include, viewstub, merge)
