1. UI布局的優(yōu)化

• 使用include,merge,ViewStub標(biāo)簽優(yōu)化布局
• 盡量不存在冗余嵌套及過于復(fù)雜的布局(譬如10層布局嵌套就會(huì)異常)
• 盡量使用GONE替換INVISIBLE
• 使用weight后盡量width和height設(shè)置成0dp減少運(yùn)算
• Item存在非常復(fù)雜的嵌套時(shí)考慮使用自定義ItemView來取代，減少measure與layout的次數(shù)
• Overdraw(過度繪制)描述的是屏幕上的某個(gè)像素點(diǎn)在同一幀的時(shí)間內(nèi)被繪制了多次。在多層次的UI結(jié)構(gòu)里面，如果不可見的UI也在做繪制的操作，這就會(huì)導(dǎo)致某些像素區(qū)域被繪制了多次，這就浪費(fèi)了大量的cpu以及gpu的資源。

2.代碼中的優(yōu)化

• android與java的差異api使用

  1. 枚舉
     避免在android中使用java的枚舉類型，因?yàn)榫幾g后不但占空間，加載也費(fèi)時(shí)，完全沒有static final的變量好用、高效

  2. SparseArray與HashMap
     (1)SparseArray(LongSparseArray)比HashMap更省內(nèi)存，在某些條件下性能更好，主要是因?yàn)樗苊饬藢ey的自動(dòng)裝箱（int轉(zhuǎn)換為Integer），它內(nèi)部則是通過兩個(gè)數(shù)組進(jìn)行數(shù)據(jù)存儲的
     (2)內(nèi)部對數(shù)據(jù)還采取了壓縮的方式來表示稀疏數(shù)組的數(shù)據(jù)，從而節(jié)省內(nèi)存空間
     (3)SparseArray在存儲和讀取數(shù)據(jù)的時(shí)候，使用的是二分查找法，SparseArray存儲的元素都是按元素的key值從小到大排列好的，而在獲取數(shù)據(jù)的時(shí)候，也是使用二分查找法判斷元素的位置，所以在獲取數(shù)據(jù)的時(shí)候非?？?，比HashMap快的多
     (4)雖說SparseArray性能比較好，但是由于其添加、查找、刪除數(shù)據(jù)都需要進(jìn)行一次二分查找，所以在數(shù)據(jù)量大的情況下性能會(huì)降低，最好在數(shù)據(jù)量千級以下使用

  3. ArrayMap與HashMap
     (1)ArrayMap是一個(gè)<key,value>映射的數(shù)據(jù)結(jié)構(gòu)，它的設(shè)計(jì)上更多是考慮內(nèi)存的優(yōu)化，內(nèi)部也是使用兩個(gè)數(shù)組進(jìn)行數(shù)據(jù)存儲
     (2)和SparseArray一樣，也會(huì)對key使用二分查找法進(jìn)行從小到大的排序，在添加、刪除、查找的時(shí)候都是先使用二分查找法得到相應(yīng)的index
     (3)和SparseArray一樣，在數(shù)量大的情況下性能會(huì)降低

  4. Parcelable與Serializable
     Serializable的作用是將數(shù)據(jù)對象存入字節(jié)流當(dāng)中，在需要時(shí)重新生成對象，主要應(yīng)用是利用外部存儲設(shè)備保存對象狀態(tài)，以及通過網(wǎng)絡(luò)傳輸對象等，而Parcelable是直接在內(nèi)存中讀寫，很明顯內(nèi)存的讀寫速度通常大于IO讀寫，而且Serializable在序列化的時(shí)候會(huì)產(chǎn)生大量的臨時(shí)變量，從而引起頻繁的GC，所以在android中的序列化通常優(yōu)先使用Parcelable

• StringBuilder和StringBuffer

  大部分不考慮線程安全的時(shí)候直接使用StringBuilder要更高效

• Handler的內(nèi)存泄漏

  發(fā)送消息時(shí)盡量使用obtain去獲取已經(jīng)存在的message對象進(jìn)行復(fù)用，而不是new Message對象，這樣可以節(jié)省內(nèi)存
  退出時(shí)注意調(diào)用Handler的removeCallbacks和removeMessages避免內(nèi)存泄漏

• Service和IntentService

  在使用后臺Service時(shí)盡量將能夠替換為IntentService的地方替換掉，這樣可以減少系統(tǒng)壓力，省電，省內(nèi)存，省cpu占用

• 變量引用的優(yōu)化

  在當(dāng)前類內(nèi)部中盡量不用通過自己的getXXX、setXXX對自己的內(nèi)部成員進(jìn)行操作，而是直接使用，這樣可以提高代碼執(zhí)行效率，不要一味的為了設(shè)計(jì)模式而過分的抽象代碼，因?yàn)榇a抽象系數(shù)與代碼加載執(zhí)行時(shí)間成正比

• 使用LocalBroadcastManager代替BroadcastReceiver

  LocalBradcastManager發(fā)送的廣播只會(huì)在App內(nèi)傳播，不會(huì)泄露給其他App，確保隱私數(shù)據(jù)不會(huì)泄露，其他App也無法向你的App發(fā)送該廣播，不用擔(dān)心其他App過來搞破壞，而且LocalBroadcastManager比BroadcastReceiver更高效

• 盡量避免在經(jīng)常調(diào)用的方法、循環(huán)中new對象

  由于系統(tǒng)不僅要花費(fèi)時(shí)間來創(chuàng)建對象，而且還要花時(shí)間對這些對象進(jìn)行垃圾回收和處理，在我們可以控制的范圍內(nèi)，最大限度的重用對象，最好能用基本數(shù)據(jù)類型或數(shù)組來代替對象

• 對Map和List初始化的時(shí)候，如果知道容量大小，最好把容量填上

  如：ArrayList<String> list = new ArrayList<String>(100);
  避免在容量不夠的時(shí)候自動(dòng)擴(kuò)容(2倍擴(kuò)容)浪費(fèi)內(nèi)存

• 避免非靜態(tài)內(nèi)部類

  當(dāng)你創(chuàng)建并實(shí)例化一個(gè)非靜態(tài)內(nèi)部類的時(shí)候，你就建造了一個(gè)指向外部類的隱含引用，如果這個(gè)內(nèi)部類的實(shí)例比外部類存活的時(shí)間還要長，那即使不需要這個(gè)外部類，它還是會(huì)保存在內(nèi)存中。例如，在Activity類中創(chuàng)建了一個(gè)擴(kuò)展AsynTask的非靜態(tài)類，開始處理異步任務(wù)，在運(yùn)行過程中殺掉了這個(gè)Activity，只要這個(gè)異步任務(wù)還在運(yùn)行，這個(gè)Activity也會(huì)一直存活，無法釋放內(nèi)存

• Activity的內(nèi)存泄漏

  這是android中最常見的的內(nèi)存泄漏，也是非常昂貴的泄漏，因?yàn)樗麄兝锩姘薝I中所有的視圖層級，這占用了很多內(nèi)存空間，有很多操作都需要一個(gè)Context對象，通常用一個(gè)Acitivty來傳遞這些信息，要確保你理解了那個(gè)Activity上發(fā)生了什么，如果一個(gè)指向他的引用被緩存了，而且這個(gè)對象要比Activity生成時(shí)間更長，若不清除這個(gè)引用，就會(huì)造成內(nèi)存泄漏，所以大部分時(shí)候能用Application太代替很多地方的Context傳值
  例如static Resources res = activity.getResources();把這個(gè)緩存為一個(gè)全局靜態(tài)變量，則會(huì)造成activity無法被回收

• Json與XML

  網(wǎng)絡(luò)數(shù)據(jù)通常使用Json格式，而不選xml，同樣的數(shù)據(jù)，json的格式比xml的數(shù)據(jù)量要小，而且解析速度也更快

• 有很多優(yōu)化，其實(shí)就是時(shí)間和空間的平衡問題，有時(shí)候需要以時(shí)間換空間，有時(shí)候需要以空間換時(shí)間。經(jīng)常需要在內(nèi)存使用和運(yùn)行效率的中間尋找一個(gè)平衡點(diǎn)