5. StrictMode带来的思考
StrictMode总的来说,是一个插桩思想的体现,也是AOP常用到的技术,在系统的各个可能产生问题的函数埋上桩子,等问题发生,将问题暴露到StrictMode。同种思想可以运用到计算函数执行时间,超过某个数值即进行暴露
常用的代码插桩方式有两种,分别是类似StrictMode这种的静态插桩,另一种这是在编译时,通过ASM等框架,自动插桩的。
5.1 自动插桩
ASM动态插桩,可以避免开发者自己每个函数都进行插桩,还是举计算函数时间的例子,我们完全可以写好两个静态函数,之后再函数开始前与结束来插入。
fun sum(){
CalculateTime.start()
for loop(0 .. 100)
CalculateTime.start()
}
类似此种,对于一些不需要统计的函数,则可以卸载配置文件的黑名单里面,进行过滤,当然实际使用到时,细节会更多,但是大体如此
5.2 动态插桩
动态插桩,可以理解为动态代理,也可以理解为Hook技术,我们以分析内存的LeakCanary为例,分析Service泄漏时,其实就运用到了动态代理,当发生泄漏,桩子就起作用了,我们稍微来看一下源代码
//获取一个ActivityThread对象
private val activityThreadClass by lazy { Class.forName("android.app.ActivityThread") }
//执行ActivityThread的currentActivityThread方法
private val activityThreadInstance by lazy {
activityThreadClass.getDeclaredMethod("currentActivityThread").invoke(null)!!
}
//函数变量,存储卸载uninstallActivityThreadHandlerCallback函数
private var uninstallActivityThreadHandlerCallback: (() -> Unit)? = null
//函数变量,存储uninstallActivityManager函数
private var uninstallActivityManager: (() -> Unit)? = null
//替换callback
swapActivityThreadHandlerCallback {
mCallback -> //调用处返回的mCallback
//赋值uninstallActivityThreadHandlerCallback这个函数变量,用来做uninstall
uninstallActivityThreadHandlerCallback = {
swapActivityThreadHandlerCallback {
mCallback
}
}
//将Handler.Callback作为swap的返回值,传递给swapActivityThreadHandlerCallback
//kotlin的隐式返回,最后一个语句
Handler.Callback { msg ->
if (msg.what == STOP_SERVICE) {
val key = msg.obj as IBinder
activityThreadServices[key]?.let {
onServicePreDestroy(key, it)
}
}
mCallback?.handleMessage(msg) ?: false
}
}
其实这里面的代码主要是,将自己的CallBack替换ActivityThread里面的CallBack从而达到监听ActivityThread里面监听STOP_SERVICEd的消息,之后在进行内存泄漏的一个分析
好了,StrictMode整个系列就分析完了。希望您能有所收获