Thinking brought by strictmode -strictmode principle (5)

5. StrictMode The thinking that comes with

StrictMode in general , It is a reflection of the idea of inserting piles , It's also AOP Commonly used technology , Put stakes in various functions of the system that may cause problems , Wait for the problem to happen , Expose problems to StrictMode. The same idea can be applied to calculate the execution time of functions , Exposure occurs when a certain value is exceeded

There are two common ways to insert code , They are similar StrictMode This kind of static pile insertion , The other is at compile time , adopt ASM Other framework , Automatic pile insertion .

5.1 Automatic pile insertion

ASM Dynamic pile insertion , It can prevent developers from inserting piles into each function , Let's take the example of calculating function time , We can write two static functions , Then insert before and after the function starts .

fun sum(){
    
    CalculateTime.start()
    for loop(0 .. 100)
    CalculateTime.start()  
 }

Similar to this , For some functions that do not need statistics , You can uninstall the blacklist of the configuration file , To filter , Of course, when it is actually used , More details , But in general

5.2 Dynamic pile insertion

Dynamic pile insertion , It can be understood as dynamic proxy , It can also be understood as Hook technology , We analyze the memory LeakCanary For example , analysis Service In case of leakage , In fact, it applies to dynamic agents , When a leak occurs , The stake works , Let's take a look at the source code

// Get one ActivityThread object 
private val activityThreadClass by lazy {
     Class.forName("android.app.ActivityThread") }

// perform ActivityThread Of currentActivityThread Method 
private val activityThreadInstance by lazy {
    
    activityThreadClass.getDeclaredMethod("currentActivityThread").invoke(null)!!
}

// The function variables , Storage uninstall uninstallActivityThreadHandlerCallback function 
private var uninstallActivityThreadHandlerCallback: (() -> Unit)? = null
// The function variables , Storage uninstallActivityManager function 
private var uninstallActivityManager: (() -> Unit)? = null
// Replace callback
 swapActivityThreadHandlerCallback {
     
   mCallback -> // Returned from the call mCallback
         // assignment uninstallActivityThreadHandlerCallback This function variable , Used to do uninstall
        uninstallActivityThreadHandlerCallback = {
    
          swapActivityThreadHandlerCallback {
    
            mCallback
          }
        }
         // take Handler.Callback As swap The return value of , Pass to swapActivityThreadHandlerCallback 
         //kotlin Implicit return of , The last sentence 
        Handler.Callback {
     msg ->
          if (msg.what == STOP_SERVICE) {
    
            val key = msg.obj as IBinder
            activityThreadServices[key]?.let {
    
              onServicePreDestroy(key, it)
            }
          }
          mCallback?.handleMessage(msg) ?: false
        }
      }

In fact, the code here is mainly , To his own CallBack Replace ActivityThread Inside CallBack To monitor ActivityThread It monitors STOP_SERVICEd The news of , After that, an analysis of memory leakage is carried out

Okay ,StrictMode The whole series is finished . Hope you can get something