一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第27天，点击查看活动详情。
1.应用抓包工具chucker
我们项目抓包工具分为两种：借助第三方软件Fiddler抓包和Okhttp拦截器：
-
前者借助第三方软件的形式比较麻烦，尤其是抓取
https请求，还要安装证书等等； -
后者的方式就比较方便了，直接定义一个
拦截器抓取即可
我们项目中使用的okhttp拦截器的抓包工具是chunk，不过这个库已经好长时间没维护了：
直接看了一个老哥所写文章的评论，说是使用chucker来代替
chunk，所以就赶紧研究了下chucker接入。
dependencies {
debugImplementation "com.github.chuckerteam.chucker:library:3.5.2"
releaseImplementation "com.github.chuckerteam.chucker:library-no-op:3.5.2"
}
目前chucker的最新版本为3.5.2，但是我们项目不能直接使用，主要的原因有两个：
-
chucker依赖的一些库的版本太高了，比如kotlin插件使用的1.6、lifecycle相关组件使用的2.4之后的版本，项目直接使用报错； -
在1的基础上想要依赖
chucker低版本来解决这个问题，然后发现死活下载不了...，应该是其不支持下载低版本了；
由于上面的两个问题，如今唯一的解决办法就只能是拿到3.5.2的chucker源码进行重连编译打包了，核心就是降低其依赖库的版本，顺便将其原来的发布插件改成了maven-publish就解决了这个问题。
2.LeakCanary2.8.1升级
leakcanary的使用就不再这个过多阐述了，可以直接看官方文档：LeakCanary。 主要是将版本版本升级到了2.8.1之后会报一个错误：
LeakCanary中使用到了WindowCallbackWrapper对象，但是项目一开启混淆，就直接NPE崩溃。
然后在其github上的issue中找到了解决答案：只需要在混淆规则中keep下WindowCallbackWrapper即可。
PS：目前leakcanary发布了2.9.1的版本，已经修复了这个问题。
3.wxapi库使用内存泄漏
主要是使用到wxapi的Activity出现内存泄漏，然后通过leakcanary发现泄漏的引用链存在两个：
1.
这个主要是使用不规范造成的，当Activity销毁时，在其onDestroy中需要手动调用：
WXAPIFactory.createWXAPI所创建对象的detach()方法
这个内存泄漏的引用链主要是由于wxapi中的一个aaaa.g.V对象持有了业务方Activity导致的，这个问题我从网上看到的方案就是：反射调用com.tencent.a.a.a.a.g类，手动将static变量V置空解决。
