Android效能最佳化之巧用軟引用與弱引用最佳化記憶體使用量

標籤：

前言：

      從事Android開發的同學都知道行動裝置的記憶體使用量是非常敏感的話題，今天我們來看下如何使用軟引用與弱引用來最佳化記憶體使用量。下面來理解幾個概念。

1.StrongReference（強引用）

   強引用是我們最最常見的一種，一般我們在代碼中直接通過new出來的對象等，都是強引用，強引用只要存在沒有被銷毀，記憶體就不會被系統回收。我們以產生Bitmap為例如下:

Bitmap imageBitmap = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);

  產生Bitmap代碼：

    public Bitmap readBitmapFromResource(Resources resources, int resourcesId) {        BitmapFactory.Options options = new BitmapFactory.Options();        return BitmapFactory.decodeResource(resources, resourcesId, options);    }

2.SoftReference（軟引用）

  軟引用是用來描述一些有用但並不是必需的對象，在記憶體嚴重不足的情況下會被系統回收，如果該對象可能會經常使用的，就盡量用軟引用。因此，這一點可以很好地用來解決OOM的問題，並且這個特性很適合用來實現緩衝：比如網頁緩衝、圖片緩衝等。這裡還是以緩衝Bitmap為例：

 SoftReference<Bitmap> softReference = new SoftReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5)); Bitmap bitmap = softReference.get();

3.WeakReference（弱引用）

  弱引用也是用來描述非必需對象的，當JVM進行記憶體回收時，無論記憶體是否充足，都會回收被弱引用關聯的對象，WeakReference 的強度又明顯低於 SoftReference，所以如果該對象不被使用的可能性更大些，就可以用弱引用。還是以緩衝Bitmap為例：

 WeakReference<Bitmap> weakReference = new WeakReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5)); Bitmap bitmap1 = weakReference.get();

4.PhantomReference（虛引用）

 虛引用和前面的軟引用、弱引用不同，它並不影響對象的生命週期。如果一個對象與虛引用關聯，則跟沒有引用與之關聯一樣，在任何時候都可能被記憶體回收行程回收。還是以緩衝Bitmap為例：

 ReferenceQueue<Bitmap> queue = new ReferenceQueue<Bitmap>(); PhantomReference<Bitmap>  phantomReference = new PhantomReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5),queue); Bitmap bitmap2 = phantomReference.get();

5.幾種引用被回收概念測試

  從上面的分析可以看出記憶體被系統回收的機率從小到大是：虛引用--弱引用--軟引用--強引用，我們寫個程式來驗證一下。

public class MainActivity extends AppCompatActivity {    private LinearLayout request_layout;    private PhantomReference<Bitmap> phantomReference;    private WeakReference<Bitmap> weakReference;    private SoftReference<Bitmap> softReference;    private Bitmap strongReference;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        request_layout = (LinearLayout) findViewById(R.id.request_layout);        findViewById(R.id.request_btn).setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                testReference();            }        });    }    private void testReference() {        //類比記憶體使用量 往一個布局中不斷加入ImageView來類比記憶體使用量        ImageView imageView = new ImageView(this);        Bitmap imageBitmap = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);        imageView.setImageBitmap(imageBitmap);        request_layout.addView(imageView);        if (strongReference == null) {            strongReference = readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5);        }        Log.e("Reference", "StrongReference---->" + strongReference);        if (softReference == null) {            softReference = new SoftReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));        }        Bitmap bitmap = softReference.get();        Log.e("Reference", "SoftReference---->" + bitmap);        if (weakReference == null) {            weakReference = new WeakReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5));        }        Bitmap bitmap1 = weakReference.get();        Log.e("Reference", "WeakReference---->" + bitmap1);        if (phantomReference == null) {            ReferenceQueue<Bitmap> queue = new ReferenceQueue<Bitmap>();            phantomReference = new PhantomReference<Bitmap>(readBitmapFromResource(getResources(), R.mipmap.bg_post_activity_5), queue);        }        Bitmap bitmap2 = phantomReference.get();        Log.e("Reference", "PhantomReference---->" + bitmap2);    }    public Bitmap readBitmapFromResource(Resources resources, int resourcesId) {        BitmapFactory.Options options = new BitmapFactory.Options();        return BitmapFactory.decodeResource(resources, resourcesId, options);    }}

第一次點擊列印資訊：

通過列印資訊可以虛引用直接回收掉了，或者可以說直接不存在引用。

接下來多次點擊列印資訊：

  在類比記憶體使用量越來越緊張的情況下，並沒有出現先回收弱引用，再回收軟引用，而是兩個一併回收掉了，其實按照Java正常引用順序是軟引用強於弱引用，但是從 Android 2.3 (API Level 9)開始，記憶體回收行程會更傾向於回收持有軟引用或弱引用的對象，這讓軟引用像弱引用一樣變得不再可靠。所以圖片緩衝不再使用軟引用而採用LRU演算法。但是強引用一直毅力不倒。

 總結：

   從上面的介紹及測試對比可以得知，如果我們比較在意APP的效能的話，我們可以把哪些不常用並且佔用記憶體比較大的對象用軟引用或者弱引用來做緩衝處理，鑒於保險起見，可以酌情選擇使用弱引用還是軟引用，實測下來二者被回收的機率相差無幾。

Android效能最佳化之巧用軟引用與弱引用最佳化記憶體使用量