Android性能優(yōu)化-布局優(yōu)化

今天，繼續(xù)Android性能優(yōu)化 一 編碼細(xì)節(jié)優(yōu)化。

編碼細(xì)節(jié)，對(duì)于程序的運(yùn)行效率也是有很多的影響的。今天這篇主題由于技術(shù)能力有限，所以也不敢在深層去和大家分享。我將這篇主題分為以下幾個(gè)小節(jié)：

（1）緩存

（2）數(shù)據(jù)

（3）延遲加載和優(yōu)先加載

1> 緩存

在Android中緩存可以用在很多的地方：對(duì)象、IO、網(wǎng)絡(luò)、DB等等。。對(duì)象緩存能減少內(nèi)存分配，IO緩存能對(duì)磁盤(pán)的讀寫(xiě)訪問(wèn)，網(wǎng)絡(luò)緩存能減少對(duì)網(wǎng)絡(luò)的訪問(wèn)，DB緩存能減少對(duì)數(shù)據(jù)庫(kù)的操作。

緩存針對(duì)的場(chǎng)景在Android開(kāi)發(fā)中也很明顯：

（1）圖片緩存

Android中提供了LruCache緩存機(jī)制。我們可以使用LruCache來(lái)進(jìn)行圖片的緩存。對(duì)圖片的緩存處理步驟一般是：

加載圖片 -> 判斷緩存中是否存在 ->存在，直接取出設(shè)置到ImageView ->不存在，則請(qǐng)求網(wǎng)絡(luò)下載圖片 -> 圖片下載成功，將圖片緩存，設(shè)置到ImageView

在Android中有很多優(yōu)秀的第三方開(kāi)源庫(kù)，所以我們也不必去重復(fù)造輪子。例如：Fresco（FaceBook的產(chǎn)品）、Picasso、Glide、UIL。

（2）不經(jīng)常改變的數(shù)據(jù)

 對(duì)于不需要經(jīng)常改變的數(shù)據(jù)，例如App中的一些產(chǎn)品分類(lèi)。我們就可以將其緩存起來(lái)。不用每次都去請(qǐng)求網(wǎng)絡(luò)來(lái)加載數(shù)據(jù)。這個(gè)比較容易理解，不多說(shuō)了。

（3）ListView的緩存

ListView Item數(shù)據(jù)的緩存，相信大家都比較清楚。就是利用Adapter類(lèi)的getView方法中convertView復(fù)用原理，創(chuàng)建ViewHolder實(shí)現(xiàn)復(fù)用。Material Design 中也提供了RecyclerView來(lái)替代ListView。它會(huì)強(qiáng)制你在Adapter中使用ViewHolder來(lái)復(fù)用View。

（4）消息緩存

此處消息是指Handler中發(fā)送的Message。系統(tǒng)為我們提供了obtainMessage()來(lái)復(fù)用一個(gè)Message。我們來(lái)看下源碼：

/**
 * Return a new Message instance from the global pool. Allows us to
 * avoid allocating new objects in many cases.
 */
public static Message obtain() {
 synchronized (sPoolSync) {
 if (sPool != null) {
  Message m = sPool;
  sPool = m.next;
  m.next = null;
  m.flags = 0; // clear in-use flag
  sPoolSize--;
  return m;
 }
 }
 return new Message();
}

上述代碼中，sPool就是被緩存的一個(gè)Message實(shí)例，首先判斷如果不為null，直接拿來(lái)復(fù)用，否則創(chuàng)建新的Message實(shí)例。

（5）IO緩存

       其實(shí)Java中就為我們提供了一些具有緩存策略的IO流：

BufferedReader、BufferedWriter。使用該類(lèi)IO流來(lái)代替 InputStream、Reader 和OutputStream、Writer等等。

2> 數(shù)據(jù)

對(duì)于數(shù)據(jù)存儲(chǔ)的優(yōu)化可以從數(shù)據(jù)類(lèi)型和結(jié)構(gòu)來(lái)劃分。

（1）使用StringBuilder或StringBuffer來(lái)拼接字符串，減少對(duì)象的臨時(shí)分配。StringBuilder和StringBuffer的區(qū)別其實(shí)就一點(diǎn)：在并發(fā)操作下，StringBuffer是線程安全的。有利也有弊，線程安全的同時(shí)也導(dǎo)致了執(zhí)行的速度下降。所以，如果不是在多線程操作的情況下，就使用StringBuilder。StringBuilder和StringBuffer的構(gòu)造函數(shù)都允許你傳入一個(gè)數(shù)量級(jí)來(lái)初始化它的空間大小。從而可以分配一定的空間大小，節(jié)省內(nèi)存資源。

（2）使用WeakReference。弱引用帶來(lái)的好處想必大家都是清楚的。尤其是在Android這種內(nèi)存空間有限的設(shè)備中，對(duì)于內(nèi)存的分配和釋放是很重要的。WeakReference使用很典型的一個(gè)場(chǎng)景就是Handler。大家都清楚，在Activity或Fragment中使用Handler一般都是作為內(nèi)部類(lèi)來(lái)實(shí)現(xiàn)的。這樣就會(huì)引發(fā)一個(gè)問(wèn)題。如果handler中的某個(gè)任務(wù)執(zhí)行較長(zhǎng)的時(shí)間，那么在Activity或者Fragment需要被釋放的時(shí)候(onDestory)，由于handler所關(guān)聯(lián)的Message還沒(méi)有執(zhí)行完成。這時(shí)handler就不能被釋放，由于handler與Activity或Fragment所關(guān)聯(lián)，那么就會(huì)導(dǎo)致Activity或Fragment不能被有效釋放，最終導(dǎo)致其資源不能被釋放，結(jié)果可想而知：oom。所以，解決該問(wèn)題的辦法就是使用WeakReference或者將Handler定義成static。下面來(lái)看使用WeakReference的方式：

private final MyHandler myHandler = new MyHandler(this);
private static class MyHandler extends Handler {
 private final WeakReference<HomeFragment> m;
 public MyHandler(HomeFragment homeFragment){
 m = new WeakReference<HomeFragment>(homeFragment);
 }
 @Override
 public void handleMessage(Message msg) {
 HomeFragment homeFragment = m.get();
  if(homeFragment != null) {
  homeFragment.vpBanner.setCurrentItem(msg.arg1);;
 }
 }
}

代碼很簡(jiǎn)單，就是將Fragment放在WeakReference中。在handleMessage中直接取出來(lái)操作其中的View.

數(shù)據(jù)結(jié)構(gòu)方面就比較多了，例如ArrayList和LinkedList、LinkedHashMap和HashSet、WeakHashMap。

（1）ArrayList對(duì)于數(shù)據(jù)的查詢速度比較快，LinkedList對(duì)于數(shù)據(jù)的插入和刪除速度要比ArrayList快。

（2）LinkedHashMap可以記住數(shù)據(jù)存入的次序，HashSet不允許有重復(fù)的元素存在。WeakHashMap中的數(shù)據(jù)可以在適合的時(shí)候被系統(tǒng)GC自動(dòng)回收，適合在內(nèi)存吃緊的場(chǎng)景下。

（3）Collections工具類(lèi)中也提供了很多的適合多線程下操作的集合，并提高了性能，例如：

（4）Android中系統(tǒng)也提供了性能更優(yōu)的數(shù)據(jù)類(lèi)型，如：SparseArray，SparseBooleanArray，SparseIntArray，Pair。Sparse的key為Int類(lèi)型。采用二分查找及簡(jiǎn)單數(shù)組存儲(chǔ)。并且不需要泛型轉(zhuǎn)換的開(kāi)銷(xiāo)，相對(duì)于Map來(lái)說(shuō)性能更優(yōu)。

3>延遲加載

在Android中延遲加載的用途也比較廣泛，例如ViewPager中Fragment數(shù)據(jù)的延遲加載。因?yàn)閂iewPager默認(rèn)是初始化兩內(nèi)容的。所以我們需要來(lái)處理進(jìn)行延遲加載。

同樣，不在Activity或Fragment對(duì)時(shí)間敏感的函數(shù)中進(jìn)行耗時(shí)操作。避免出現(xiàn)ANR的異常發(fā)生。

Java中提供了ScheduledxecutorService作為延遲加載，其實(shí)Timer定時(shí)器的延時(shí)是有bug存在的。所以不推薦使用Timer。鴻洋博客有講該Timer的缺陷：Timer 缺陷

Android中可以使用handler的一些方法來(lái)延遲操作：

（1）postDelayed

（2）postAtTime

（3）sendMessageDelayed

以及View的postDelayed，AlarmManager定時(shí)等。

最新評(píng)論