Android内存优化实践

                                               谈谈Android内存优化

     引起Android内存泄露的情况有很多，但是很多都是我们代码不规范引起的。只要我们平时代码规范点我们都能开发出性能比较高的APP应用。

    引起泄露的原因大都是，由于不适当的引用，导致内存较大的对象没有及时释放，导致内存居高不下，严重的时候可能会引起OOM。在Android开发中泄露的原因，总结下来，大都是由于Activity Context和bitmap对象使用不当引起的。下面就来与大家分享下我在开发一个TV项目中遇到的内存泄露的情况。

(一) adapter中保留对Activity的引用

     在创建adapter的时候传入Activity，并把Activity作为成员变量保存下来

    if (mAdapter == null) {
                        mAdapter = new ChannelDetailAdapter(this, mDataList,  mPageGridView);
                        mPageGridView.setAdapter(mAdapter);
                    } else {
                        mAdapter.setDataList(mDataList);
                        mPageGridView.notifyDataSetChanged(false);
                        mPageGridView.setSelectionPositionNotFocus(0);//重置 position
                    }

 

public class ChannelDetailAdapter extends BaseGridViewAdapter<AlbumModel> {
    private Context mContext;
    public ChannelDetailAdapter(Context mContext, List<AlbumModel> mDataList, PageGridView mPageGridView) {
        super(mContext, mDataList, mPageGridView);
        this.mContext = mContext;
    }
}

 

为什么会泄露呢？

      因为adapter对Activity进行了引用，而在我们finish Activity的时候，adapter并没有置为null，这样就会导致Activity内存无法及时释放。(补充：adapter的生命周期和Activity的生命周期是一致的，但是把Adapter置为null的话会让Activity的资源及时释放)

解决办法：

(1)adapter中保留非要保存一个Context对象的话，在我们new Adapter的时候传入Application   Context

(2)adapter中一定要保存一个Activity Context的话，比如在adapter中有点击跳转的逻辑。一定要在onDestroy方法中把adapter置为null

(二) listener回调引起的泄露

   (1)Activity中添加了回调监听，而没有把listener给干掉

    项目中为了方便处理网络请求的各种情况，我们自定义了一个数据异常的View，并给出相应的回调处理，例如重试操作，因为实现回调接口的是当前的Activity，所以listener就无形中对Activity进行了引用，所以我们必须在activityonDestroy前，把listener置为null，这样更容易让Activity的资源回收

this.mDataErrorView.setErrorListener(this);

 (2) 使用Volley的回调导致的内存泄露

     volley创建的时候会保留2个listener变量，一个错误的回调和一个正确的回调，如果我们在Activity结束的时候，没有把这2个回调给干掉，也有可能会导致内存泄露。但是Volley并没有提供相应的方法清理回调。下面我就来分析下问题是怎么产生的，并给出相应的解决方法。

先看看Request的构造方法，保留了mErrorListener

 

  public Request(int method, String url, Response.ErrorListener listener) {
        mMethod = method;
        mUrl = url;
        mIdentifier = createIdentifier(method, url);
        mErrorListener = listener;
        setRetryPolicy(new DefaultRetryPolicy());
        mDefaultTrafficStatsTag = findDefaultTrafficStatsTag(url);
    }

 

再看看Request的子类StringRequest的构造方法

 

 public StringRequest(int method, String url, Listener<String> listener,
            ErrorListener errorListener) {
        super(method, url, errorListener);
        mListener = listener;
    }

 

 

     说明每个请求都保留了mErrorListener和mListener对象，那我们就可以说，每个对象都有可能间接持有对Activity的引用

如何解决这个问题

    Volley提供了一个取消请求的方法，google官网是建议我们在Activity onStop的时候，cancel掉每个请求，这个时候我就想到在每个请求cancel的时候，把listener干掉。但是由于把请求取消的时候，不会触发回调，用的时候要注意。

由于请求队列一般都在application中取消的，所以在application中可以提供一个取消请求的方法

  /**
     * 网络请求优化，取消请求
     * @param tag
     */
    public  void  cancelRequest(String tag){
        try {
            mRequestQueue.cancelAll(tag);
        }catch (Exception e){
            Logger.e("LeSportsApplication","tag =="+ tag + "的请求取消失败");
        }
    }

真正取消请求的，实际上调用的方法是Request的cancel这个方法

 /**
     * Cancels all requests in this queue with the given tag. Tag must be non-null
     * and equality is by identity.
     */
    public void cancelAll(final Object tag) {
        if (tag == null) {
            throw new IllegalArgumentException("Cannot cancelAll with a null tag");
        }
        cancelAll(new RequestFilter() {
            @Override
            public boolean apply(Request<?> request) {
                return request.getTag() == tag;
            }
        });
    }

 最终调用的request的cancel方法，其实就是把mCaceled方法设为false，最终会触发请求将不会分发，  最后回调也就无效了

 public void cancelAll(RequestFilter filter) {
        synchronized (mCurrentRequests) {
            for (Request<?> request : mCurrentRequests) {
                if (filter.apply(request)) {
                    request.setTag(null);
                    request.cancel();
                }
            }
        }
    }

看看request中的finish方法，把mErrorListener置为空

 public void finish(final String tag) {
        if (mRequestQueue != null) {
            mRequestQueue.finish(this);
        }
        if (MarkerLog.ENABLED) {
            final long threadId = Thread.currentThread().getId();
            if (Looper.myLooper() != Looper.getMainLooper()) {
                // If we finish marking off of the main thread, we need to
                // actually do it on the main thread to ensure correct ordering.
                Handler mainThread = new Handler(Looper.getMainLooper());
                mainThread.post(new Runnable() {
                    @Override
                    public void run() {
                        mEventLog.add(tag, threadId);
                        mEventLog.finish(this.toString());
                    }
                });
                return;
            }
            mEventLog.add(tag, threadId);
            mEventLog.finish(this.toString());
        } else {
            long requestTime = SystemClock.elapsedRealtime() - mRequestBirthTime;
            if (requestTime >= SLOW_REQUEST_THRESHOLD_MS) {
                VolleyLog.d("%d ms: %s", requestTime, this.toString());
            }
        }
        mErrorListener = null;
    }

   重新Request子类的finish方法，Volley是没有重写这个方法，你要改下源码就好

 

 public void finish(final String tag) {
        super.finish(tag);
        mListener = null;
    }

 

     总结：取消请求最终调用的方法是request的finish方法，只要在这个方法中把mErrorListener和mListener2个回调置为空，那么泄露问题就解决了。

 (三) 使用Handler导致的泄露

    如果handler保留了对Acitity的引用，那么同样也有可能导致内存泄露。我们都知道handler发送消息的时候，消息会放到消息队列里面，然后由Lopper来不断循环消息，直到把消息发送给消息的target(也就是发送消息的handler)，而Lopper的生命周期跟Application是一样的，那么Lopper就会间接持有Activity的引用，所以会导致内存泄露。解决方法如下：

  (1) 用static 修饰handler，并用WeakRefrerence修饰Activity

 

 private static class MsgHandler extends Handler {  
     private WeakReference<Activity> mActivity;  
  
     MsgHandler(Activity activity) {  
         mActivity = new WeakReference<Activity>(activity);  
     }  
   
     @Override  
    public void handleMessage(Message msg) {  
        Activity activity = mActivity.get();  
        if (activity != null) {  
            activity.handleMessage(msg);  
        }  
    }  
 }  
   
 private Handler mHandler = new MsgHandler(this);

(2) 在onDestroy的方法中，把handler中运行的线程和消息全都

remove掉

 @Override
    public void onDestroy() {
        super.onDestroy();
        if(mHandler != null){
            mHandler.removeCallbacks(mPreloadingRunnable);
            mHandler.removeMessages(DERECTLY_SEARCH);
        }
        Logger.e(TAG, "onDestroy");
    }

 

(四) 在单例类中持有Activity的引用

      由于单例的生命周期是和Application保持一致的，当Activity被销毁的时候，而这个单例类并没有回收掉，也就是说Activity由于该单例类还持有对它的引用，导致Activity不能被回收掉。

 解决方法：在单例中使用ApplicationContext作为成员变量

public SingleInstance(Context contex){
   mContext = context.getApplicationContext();
}

(五) 养成良好的编码习惯

    虽然说Java内存回收线程会自动帮我们回收不需要的内存，但是这种回收的方式还是比较迟钝的。最好遵循谁用谁释放的原则，这样会更有利于内存的回收。我们new出一个对象的时候，一定要考虑在Activity或者fragment退出时把这些对象置为空，使这些对象的生命周期和Activity和Fragment的生命周期保持一致，这样就可以保证在Activity退出的时候，内存得到充分释放。

      最近刚刚完成了一个TV项目，我们在开发中，程序经常会莫名的OOM，用MAT就发现，程序中有许多的内存泄露问题。解决了一部分的内存泄露问题，但是还是会经常OOM。网上找了一篇比较不错的内存优化博客，然后按照该文章实践，果然内存泄露导致的OOM问题，终于解决了。

文章地址分享给大家：http://bugly.qq.com/blog/?p=884

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

评论

2 楼 砺雪凝霜 2016-02-04  

可以加我QQ:1029457926  一起交流，一起进步，一起开发性能最优的APP

1 楼 zhu_jinlong 2016-01-31  

非常好的文章，做到这些并牢记处理原则，可以远离memory leak了