好久没更新技术博客了，这几天积攒了很多技术问题，今天要说的是内存泄漏定位和解决。在新公司做了一个多月了，接手前面的代码，多多少少都会有些坑，但是内存泄漏这种问题一直以来都很让人头疼，这里就拿出一个内存泄漏的问题来讲一下抓内存泄漏的方法和定位。
首先叙述我遇到的这个bug吧，在实现的一个列表页SwipeRefreshLayout.OnRefreshListener, BaseQuickAdapter.RequestLoadMoreListener 的一个activity, 实现了监听方法：
mAdapter.setOnItemClickListener(new BaseQuickAdapter.OnItemClickListener() { @Override public void onItemClick(BaseQuickAdapter adapter, View view, int position) {
Intent intent = new Intent(MySignUpActivity.this, NewEventMatchDetailsActivity.class);
startActivity(intent);
finish(); }});
在此方法里，跳转任意一个activity, 在新activity页面停留2-5分钟，就出现了ANR, 一开始一直怀疑是这个列表页面出现的内存泄漏问题，
于是各种代码检查，发现没用handler，网络请求也处理的很好，也没有其他的主线程耗时操作，此时就很纳闷这个问题了，于是继续对问题定位，发现不管哪个列表界面只要是有这个监听方法的都会这样，于是这时候就发觉并不是某个界面代码的问题，而是一个通病，也就归结到了基类上。这时候用as自带的内存检测工具，做了下检测：发现只有在列表页被遮挡住以后才会内存一路飙升，而在跳转时添加finish（）方法，也就是将列表页kill掉后，却发现内存会很平稳，没异常状态。下图是检测的内存 飙升情况：
可以看到java内存从250M，一路升到半个多G，很可怕的数据，从数据可以看出肯定是有递归或是死循环重复创建对象的操作，根据这个情况我去查看了基类，怀疑基类里的onPause方法里有什么不妥的操作，经过检查基类，果真onPause里有一行统计api：MobclickAgent.onPause(this); 但是去掉后发现情况仍然存在，排除onPause的问题。
于是继续问题跟踪，更换测试机，更换模拟器，发现模拟器不存在这个问题，而真机是存在的，但是对解决问题并没什么太大的帮助。
于是继续查找，把列表页的父类 ，框架，实现类全部都去掉，再次重新了这个问题，此时我就挠头了，排除基类，排除框架问题，还会有什么能控制页面跳转啊，突然想起来那个onPuase里的统计类，难道说还有其他的统计api在服务里操控这些界面的跳转？
想到这里，再次打开工具，定位这个重复创建的对象。下图是定位到的重复创建的对象。
就是这个jsonObject，但是发现我并没有使用这个类啊，继续点开查询他的结构，发现：
走了一个线程，里面重复调用了很多a()、c()、d()这些方法，而init执行的却正是jsonObject的一个操作，这里我就蒙了，我何曾这样操作过代码，但是转眼一看所属包名，是第三方包，又是三方的东西，终于算找到元凶了，但是此时纠结的是具体是哪个第三方的框架在捣乱呢，网上查了一下包名，原来是xx的统计框架，原来项目不止用了一个框架作为统计，这时候没别的说的，直接去程序入口，找到那个该死的api, StatService.autoTrace(App.sApp,true,true);
就直接禁用，再次跑通，发现问题迎刃而解，果真是这个框架在捣鬼，再回头想一下，它在程序启动就开启服务，实时对界面跳转做监控，不知道是因为更新的原因还是什么，导致内部他在搜集统计数据写入json时发生死循环了。
至此问题算是解决，但是我还得问一下产品是不是之前这个统计通道有没有用到，不能给人家乱改呀。最后附上内存监控的操作流程：
箭头指向就是内存监控。双击后进入：
这是内存的详细信息：
想要抓到具体哪个类发生的问题：需要点击左上角的小红点，他会：
然后获取到想抓取的内容后再点击一下小红点，就会这样：
这样就拿到具体的对象和类，就能轻松确定具体谁是元凶，当然这过程中你必须时时刻刻去分析猜测，解决bug之路永无止境，希望大家在bug道路上越走越顺！（字体先不调了，比较忙，有时间会调整的！）