谈谈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进行了引用，所以我们必须在activity
onDestroy前，把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