APM's Android App startup times (1)

Reprint please explain.

The number of launches of an application is undoubtedly an important test indicator for APM. But the number of Android launches takes into account an important factor. That's when you switch back to the front desk from the background. Is this a new startup?

Friends and Newrelic as the world's 2 leaders in the data testing, the approach is similar. But the means of implementation are completely different.

Newrelic and the implementation of the method:

Au requires the user to execute Newrelic logic in code, in which the user manually writes code embedded in the OnPause () and Onresume () methods of the activity life cycle.

Newrelic users do not have to care about this at all. It will automatically embed code in the OnStop () and OnStart () methods of the activity's lifecycle during the compile time.

It is considered that the time between the app's front and rear switch is different. Friend League is 30s,newrelic is 5s.

The implementation principle of Newrelic:

Through ASM technology. Dynamic embedding when the user packs the APK. The implementation of this feature will be talked about later.

If the user uses the Newrelic SDK, they will find that the OnCreate () and OnStop () in the activity subclass of the system are embedded in the OnStart () method. The OnCreate () method's embed code is related to the interaction trace of the activity. No discussion.

At the beginning.

 Scheduledthreadpoolexecutor executor = new Scheduledthreadpoolexecutor (1, new   Namedthreadfactory ("Appstatemon"));   This.activitysnoozetimeinmilliseconds = Snoozetimeinmilliseconds; Executor.scheduleatfixedrate (this, initialdelay, period, timeunit); The SDK initializes and executes the watchdog logic at a fixed frequency. Detects if the app is in the background. (Default 5s detection once, snooze more than 5s think into the background) 

 public  void   run () {synchronized ( this  .foregroundlock) { if  ((this . Fo regrounded) && (Getsnoozetime () >= this  .activitysnoozetimeinmilliseconds))        {//If the app is now in the foreground but the nap time is greater than the specified time. Think the app has entered the background.        Notifyapplicationinbackground ();  this . foregrounded = false  ; }    }  }

Private Long Getsnoozetime ()  //Nap time  {    synchronized (this.foregroundlock) {      synchronized ( This.snoozelock) {        if (this.snoozestarttime = = 0L) return 0L;        Return (System.currenttimemillis ()-This.snoozestarttime);}}}  

Embedded in the user's activity code. The OnStop () method is embedded in the applicationstatemonitor.activitystopped (), OnStart () Method embeds the applicationstatemonitor.activitystarted ().

So the activity executes 2 methods of the life cycle. Incidentally, the following 2 methods are performed.

  public void activitystopped ()  {    synchronized (this.foregroundlock) {      synchronized (this.snoozelock) {        This.count-= 1L;        if (This.count = = 0L)                                   //The most critical place. If the app goes backstage, nap time starts recording          this.snoozestarttime = System.currenttimemillis ();}    }  }  public void activitystarted ()  {    synchronized (this.foregroundlock) {      synchronized (this.snoozelock) {        This.count + = 1L;        if (This.count = = 1L)        {          this.snoozestarttime = 0L;        }      }      if (! ( this.foregrounded) {  //If the app was originally not in the foreground, notify the SDK that it has entered the foreground. Data collection is performed again.        Log.verbose ("application appears to being in the foreground");        Notifyapplicationinforeground ();        this.foregrounded = True;}}  }

One of the important reasons for the above logic walk is that one activitya switches to another activityb, and then walks the life cycle process as follows:

A.onstart ()---->b.oncreate ()-->b.onstart ()--->a.onstop ()-------(press the Home key to enter the background) >b.onstop ()-----> B.ondestroty ()

Count=1------------------->count=2--------->count=1---------------------------->count=0---> The initial value of the NAP time begins to determine the current time

The life cycle of the 2 activity is overlapping. So the activity switch doesn't think the app is napping. An activity's presentation is generated in the Onresume () of the life cycle. The user's interface is completely invisible to the onstop of the activity ( Method.

　　

APM's Android App startup times (1)