上一篇说了,内存分析的基本思路。没看的点这里 但只是说,不通过实践毕竟理解不深。这篇通过我在工作中遇到的一个实例来说一下具体的操作。
正如上篇所说的,我给应用加了LeakCanary后检测到了内存泄漏,而没有分析出原因。这时我就用Android Monitor来分析具体哪出错了。dump内存的.hprof文件后,我们直接点击右侧的Analyzer Tasks(直接帮我们分析出泄漏的acivity),结果如图:
可以看到帮我们分析出了有5个泄漏实例(所以为了结果明显,我们可以多次进入自己怀疑的activity.通过内存变化也能猜的差不多)。ok,现在我们知道是哪个activity泄漏了。那么为什么泄漏呢,我们点击其中一个并展开成如图所示:
可以看到引用链是CordovaWebVieActivity被webview引用并最终被application的mComponentCallbacks引用的。可以看出是webview作为中间人引起的这场流血事件。ok,我们网上搜一下webview的内存泄漏。[很高兴我们找到了一个很详细的](http://www.2cto.com/kf/201605/507075.html)。
于是我们在activity中加入以下代码
@Override
protected void onDestroy() {
if (webView_ != null) {
if (webView_.getParent() instanceof ViewGroup)
((ViewGroup) webView_.getParent()).removeView(webView_);
webView_.destroy();
webView_ = null;
}
super.onDestroy();
}
然后多次进入CordovaWebVieActivity后dump文件并点击Analyzer Tasks,这是你会发现第一张图的没有leaked Activitys了。也就是我们修复成功了。