Android-内存泄漏处理

Android-内存泄漏处理

前言

内存泄漏指的是程序运行时未能正确回收部分内存，导致这些内存既不能被自身使用，又不能被其他程序使用，从而变成垃圾内存。一旦内存泄漏无法得到控制，该程序占用的内存就会越来越大，最终只能强行结束，否则会导致系统死机。

内存泄漏的检测

要对内存泄漏问题进行优化，首先得检测APP是否发生内存泄漏。正常情况下，一个APP占用的内存有一个峰值，达到这个峰值后，只要退出APP界面，占用的内存大小就会降下来。但是如果发生了内存泄漏，这个APP占用的内存大小是没有峰值的，随着页面的重复打开或时间的不断流逝，该APP消耗的内存越变越大，这便表示出现了内存泄漏的状况。因此，只要能监控APP的运行内存变化情况，即可间接判断这个APP是否发生泄漏。下面来看通过studio查看泄漏的步骤：

1. 先通过操作产生泄漏，这时内存已经发生了泄漏

2. 点击Profiler如图：
   

3. 下面我们手动触发GC来回收无用的内存，如图：

4. 反复的打开和关闭界面，如果发现App占用的内存只增不减，那么就是发生了内存泄漏。

内存泄漏的发生

之前讲述了如何检测发生了内存泄漏，为进一步观察内存泄漏现象，下面举个例子：
未能移除定时的Runnable任务
通常有需要延时处理时，常常调用Handler对象的postDelayed方法，由该方法延迟一段时间后执行设定好的Runnable任务。若要实现动画效果，则循环执行若干次postDelayed方法。这里蕴含着不晓得内存泄露风险，如不谨慎，App可能多跑几次就挂了。
比如下面的代码每隔两秒打一行日志，并在onDestroy页面退出时根据开关来判断是否移除任务，
代码如下:

public class RemoveTaskActivity extends AppCompatActivity implements OnClickListener{
     private CheckBox ck_remove;
     private TextView tv_remove;
     private Button btn_remove;
     private String mDesc="";
     private boolean isRunning=false; //定时任务是否在运行
     private Handler mHandler=new Handler(); //声明一个处理器对象

protected void onCreate(Bundle savedInstanceState){
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_remove_task);
     ck_remove=findViewById(R.id.ck_remove);
     tv_remove=findViewById(R.id.tv_remove);
     btn_remove=findViewById(R.id.btn_remove);
     btn_remove.setOnClickListener(this);
     TextView tv_start=findViewById(R.id.tv_start);
     tv_start.setText("页面打开的时间为:"+DateUtil.getNowTime());
}
public void onClick(View v)
     if(v.getId()==R.id.btn_remove){
         if(!isRunning){
         btn_remove.setText("取消定时任务");
         //立即启动定时任务
         mHandler.post(mTask);
         }else{
         btn_remove.setText("开始定时任务");
         //移除定时任务
         mHandler.removeCallbacks(mTask);
         }
         isRunning=!isRunning;
     }
 }
 protected void onDestroy(){
     super.onDestroy();
     if(ck_remove.isChecked()){
          //移除定时任务
          mHandler.removeCallbacks(mTask);
     }
}
//定义一个定时任务，用于定时发送广播
private Runnable mTask=new Runnable(){
     @Override
     public void run{
          Intent intent=new Intent(TASK_EVENT);
          //通过本地的广播管理器来发送广播
          LocalBroadcastManager.getInstance(RemoveTaskActivity.this).sendBroadcast(intent);
          //延迟2秒后再次启动定时任务
          mHandler.postDelayed(this,2000);
          }
};

public void onStart(){
    super.onStart();
    //创建一个定时任务的广播接收器
    taskReceiver=new TaskReceiver();
    //创建一个意图过滤器，只处理指定事件来源的广播
    IntentFilter filter=new Intentfilter(TASK_EVENT);
    //注册广播接收器，注册之后才能正常接受广播
    LocalBroadcastManager.getInstance(this).registerReceiver(taskReceiver,filter);
}

public void onStop(){
    //注销广播接收器，注销之后就不再接受广播
    LocalBroadcastManager.getInstance(this).registerReceiver(taskReceiver,filter);
}

//声明一个定时任务广播事件的标识串
private String TASK_EVENT="com.example.performance.task";
//声明一个定时任务的广播接收器
private TaskReceiver taskReceiver;

//定义一个广播接收器，用于处理定时任务事件
private class TaskReceiver extends BroadcastReceiver{
    //在收到定时任务的广播时触发
    public void onReceive(Context contect,Intent intent){
        if(intent !=null){
           mDesc=String.format("%s%s 打印了一行测试日志\n",mDesc,DateUtil.getNowTime());
           tv_remove.setText(mDesc);
           }
    }
}

进入测试页面，点击开始执行任务按钮，页面会每隔2秒打印一行日志。然后不停止也不移除定时任务，直接退出该页面，按道理原测试页面上的内存都应该回收，不过接着进入测试页面，还没点击开始执行任务按钮，页面已经在自己打印日志了，很明显上次退出页面时系统未能自动的回收内存。

内存泄漏的预防

App开发中的内存泄露还常见于以下5个场景：
（1）数据库查询操作后没有关闭游标Cursor。
（2）适配器Adapter刷新数据时没有重用convertView对象。
（3）Bitmap对象使用完毕没有调用recycle方法回收内存。
（4）Activity引用了耗时对象，造成页面关闭时无法释放被引用的对象。
（5）给系统服务注册了监听任务，却没有及时注销。
要想避免出现内存泄漏，最好的办法就是防患于未然。针对以上5个内存泄漏场景，相应的预防措施分别如下：

1. 关闭游标–游标Cursor不只用于数据库SQLite查询记录，也可用于内容解析器ContentResolver查询内容数据，还可以用于下载管理器DownloadManager查询下载进度。若要预防游标产生的内存泄漏，则可在每次查询操作结束后调用Cursor对象的close方法关闭游标。
2. 重用适配–App网列表视图ListView或网格视图GirdView中填充数据都是通过适配器BaseAdapter的getView方法展示列表元素。列表元素较多时，系统只会加载屏幕上可见元素，其他元素只有滑动到屏幕区域内才会及时加载并显示。当列表元素多次处于“展示—>隐藏—>展示—>隐藏·····”时，有必要重用每个元素的视图如果不重用，那么每次展示可视元素都得重新分配视图对象，这便产生了内存泄漏。下面是重要列表元素的代码示例：

ViewHolder holder;
if(convertView==null){
holder=new ViewHolder();
convertView=mInflater.inflate(R.layout.list_title,null);
holder.tv_seq=(TextView)convertViewById(R.id.tv_seq);
 holder.iv_title=(TextView)convertViewById(R.id.iv_title);
 convertView.setTag(holder);
}else{
    holder=(ViewHolder)convertView.getTag();
}

3. 回收图像–若想避免图像操作引起的内存泄漏，可在Bitmap对象使用完毕后调用recycle方法。
4. 释放引用–下面是预防这种内存泄漏的3个方法：
   （1）如果异步任务时由Handler对象的postDelayed方法发起的，那么可能对应的removeCallbacks方法回收，把消息对象从消息队列移除就行了。
   （2）按Android官方的推荐做法，可把Handler类改为静态类，同时Handler内部使用WeakReference关键字持有目标的引用。
   之所以使用静态类，是因为静态类不持有目标的引用，不会影响内存自动回收机制。但是不持有目标的引用，Handler内部就无法操作Activity上面的控件。为解决该问题，在构造Handler类时需要初始化目标的弱引用。不同于前面的强引用，弱引用相当于一个指针，指针指向的地址随时可以回收。这又出现新的问题，即弱引用指向的对象可能是空的，所以Handler内部在使用目标活动前要先判断弱引用对象是否为空。以下是代码示例：

 private WeakHandler mHandler=new WeakHandler(this);
 private static class WeakHandler extends Handler{
       public static WeakReference<ReferWeakActivity>mActivity;
       public WeakHandler(ReferWeakActivity activity){
       mActivity=new WeakReference<ReferWeakActivity>(activity);
 }
 
 public void handleMessage(Message msg){
     ReferWeakActivity act=mActivity.get();
     if(act !=null){
     act.mDesc=String.format("%s%s 打印了一行测试日志\n",act.mDesc,DateUtil.getNowTime());
      act.tv_weak.setText(act.mDesc);
 }
 }
 }

（3）把Handler对象作为App的全局变量，即把Handler对象作为自定义Application类的成员变量。这样只要App在运行，该对象就一直存在。既然避免为Handler对象重复分配内存，也就间接避免了内存泄露的可能。

  5. **注销监听**--App的某些功能依赖于Android的系统服务，比如定位功能依赖于系统的定位管理器，定时功能依赖于系统的闹钟管理器。App若想接收系统服务的消息，要么注册监听器，在回调方法中处理信息；要么注册广播接收器，在接收广播时处理消息。既然有注册操作，就存在对应的注销操作，不过如果不注意，就会忘记在代码中做注销处理。所以在进行页面编码时，千万要记得再检查一遍，确保onDestroy方法中已经包含相关的注销代码。
    不同的的系统服务拥有不同的注销方法常见的系统服务注销方法见表：

系统服务的管理器	注销操作说明	注销函数
AlarmManager	取消定时广播	cancel
ConnectivityManager	取消监听网络状态	unregisterNetworkCallback
DownloadManager	移除下载任务	remove
LocationManager	取消监听位置信息的变化	removeUpdates
LocationManager	取消监听定位状态的变化	removeGpsStatusListener
NotificationManager	取消通知	cancel
TelephonyManager	取消监听电话状态	使用listen方法注册一个空事件PhoneStateListener.LISTEN_NONE
Vibrator	取消震动	cancel

作者：暴何丽
原文地址：https://blog.csdn.net/weixin_44527241/article/details/90724311