一. 内存泄漏的 Bug 猛增

最近在 App 进行 mokey 测试的时候检测到一些内存泄漏问题。在前天的测试中，楼主一瞬间收到了4个这样的 Bug 单，瞬间心理无比纠结，真有千万只羊驼向我奔来。

登录页面出现内存泄漏??!!楼主的代码是如此的***而无懈可击，这么可能出现这么多泄漏的问题?

插播什么是 Activity 泄漏：Android 中 Activity 代表一个页面，拥有一段生命周期，生命周期结束后，Activity 对象应当在之后某个合适的时机被 VM 回收内存。出现了泄漏就意味着 Activity 生命周期结束后，VM发现 Activity 一直被持有，没有回收这些无用的内存。

按照以往的经验，大部分 Activity 泄漏的原因都是由于 Handler 内部类长时间挂在线程中导致的。而这块我们 App 已经考虑便处理了。究竟是哪泄漏了?

二. WebView 导致内存泄漏众所周知

带着怀疑的心态并且为了证明清白，我一个个点进去看了，总共有三条不同的引用链。为了后续说明，这里取了个名字：

① AuthDialog 引用链

② BrowserFrame 引用链

③ IClipboradDataPaste 引用链

看来这次情况有点不同!由于 Monkey 测试的机型比较少，这里所有的 Bug 都来自一部三星 GT-I9300@android+4.3 手机。

为了快速解决问题，楼主询问了其他同事和 StackOverflow，发现这其中有三个类 CookieSyncManager, WebView, WebViewClassic 已经被很多人提起过，它们会导致内存泄漏!初步有如下的结论如下：

1.CookieSyncManager 是个全局静态单例，操作系统内部使用了 App 的 Activity 作为 Context 构造了它的实例。我们应该在 App 启动的时候，抢先帮系统创建这个单例，而且要用 applicationContext，让它不会引用到 Activity。

2.使用 WebView 的页面(Activity)，在生命周期结束页面退出(onDestory)的时候，需要主动调用 WebView.onPause()以及 WebView.destory()以便让系统释放 WebView 相关资源。

4.WebView 内存泄漏是众所周知的，建议另外启动一个进程专门运行 WebView。不要9998，不要9999，我们要100%!WebView 用完之后就把进程杀死，即使泄漏了也无碍。

按照以上的种种结论，我们