StrictMode带来的思考-StrictMode原理(5)-CSDN博客

本文探讨了StrictMode在Android开发中的应用，它是静态插桩的一种形式，用于检测潜在的问题。同时介绍了动态插桩，如ASM框架，用于自动插入代码以监控函数执行时间。以LeakCanary为例，解释了动态代理和Hook技术如何实现内存泄漏检测。通过替换ActivityThread的回调函数，监听STOP_SERVICE消息，从而分析内存状态。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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
        }
      }