Probe into AGP implementation method by inserting piles

2, costTime

The plugin will scan all the methods under the class to see if there is @COST annotation. If there is, the method will be staked. The effect of staking is as follows:

System.out.println("========start=========");
TimeUtil.setsStartTime("newFunc", System.nanoTime());
// The implementation of the original method
TimeUtil.setEndTime("newFunc", System.nanoTime());
System.out.println(TimeCache.getCostTime("newFunc"));
System.out.println("========end=========");
Copy the code

CostTime only supports the current App Module. See transfrom for details. The jar part generated by the library is not staked.

4, Mamba

The implementation of Mamba is similar to Matrix, but the content of piling is not methodId, but the current class, method name and method parameters. The effect of piling is as follows:

   public void test(a) {
        long start = System.currentTimeMillis();
        Class<Test> cls = Test.class;
        Mamba.i(cls, "test");
		// The original method body
        Mamba.i(cls, "test");
    }
Copy the code

Mamba does no logic of its own, leaving the start and end of the method body to the class that implements IMambaLoader. Mamba also provides the function of using @track annotation to capture method information, which is used to assist in obtaining parameter values of traceless burying point scheme. The effect of pile insertion is as follows:

/ / the original method
@Track
private void open(String t, float a, double b, long c) {
        Toast.makeText(this."What can I say? Mamba out", Toast.LENGTH_SHORT).show();
}

// Insert the pile after the effect
private void open(String str, float f, double d, long j) {
        Class<TrackActivity> cls = TrackActivity.class;
        Mamba.i(cls, "open", str, Float.valueOf(f), Double.valueOf(d), Long.valueOf(j));
        Toast.makeText(this."What can I say? Mamba out".0).show();
}
Copy the code

The downside is that the base type needs to be boxed as a reference type and stored in an Object array

Tell me more about Method Params

In business practice, it is impossible to achieve a traceless burying point scheme. Some burying points are context-dependent and record the current value of variables, so we have to hardcode the burying point in business code.

One solution I came up with to solve the hardknitting problem was: Write the places that need to be buried into function calls, and then take the variables that need to be recorded as the parameters of the function, and mark @track for the function. Then Mamba will automatically implement the plugging of methods and parameters according to @track annotation. We only need to bury the data in Mamba’s implementation class.

Here is an example of how to do this: Log the userName variable in the click event

public class MyActivity{
    public void onClick(View view){
         String userName = editUserName.getText().toString();
         updateUser(userName);
         // in general, we might hardcode directly, such as trackmanager.get ().logevent (" get userName ",userName)
    }
   /* * Update the user name */
    private void updateUser(String userName){... }}Copy the code

Let’s change it:

public class MyActivity{
    public void onClick(View view){
         String userName = editUserName.getText().toString();
         updateUser(userName)
    }
    // Add a Track annotation to the update user
    @Track
    private void updateUser(String userName){... }}Copy the code

The bytecode generation results in:

public class MyActivity{
    public void onClick(View view){
         String userName = editUserName.getText().toString();
         updateUser(userName)
    }
    
    @Track
    private void updateUser(String userName){
        Class<MyActivity> cls = MyActivity.class;
        Mamba.i(cls, "updateUser", userName); . }}Copy the code

Class = MyActivity; method = updateUser; params = MyActivity; method = updateUser;

  override fun methodEnter(clazz: Class<*>? , methodName: String? , args: Array
       
        ?)
        {
        when (clazz) {
            MyActivity::class.java -> {
                  trackMyActivity(methodName, args)
            }
        }
  }

  private fun trackMyActivity(methodName: String? , args: Array
       
        ?)
       {
        when(methodName){
            "updateUser"- > {// Get the userName valueval userName = args!! [0] as String
              // Use TrackManager to bury points}}}Copy the code

Although @track still needs to be edited in the business code, it is already a minimal intrusion into the business code. Even if the user name does not need to be recorded in the future, we do not need to delete the @track annotation, just remove the judgment of updateUser in the Mamba implementation class. The reader may ask, why don’t you just automate collecting method parameters instead of using annotations to invade the business? In fact, I also thought of this solution, but for the base type parameter is very unfriendly, if I want to collect uniform method parameters, you must use a everyone some parent container to save, so here defines the Object array to store the parameters, but the problem again, the base type what would you do without a parent class, only the base type packing into a reference type, That is, wrapping float as float.valueof () and storing it in an Object array consumes memory. Imagine wrapping all method arguments and collecting them, and performance becomes a problem. So, use @track to annotate what you think you need to collect.

conclusion

Overall, the solution implementations are similar, with slight differences in business implementations.

Mamba also provides two default implementation classes:

• CostTimeLoader: Statistics method time
• TrackLoader: Captures method information

See Mamba README: github.com/MRwangqi/Ma…