Android Instance profiling notes (iii)

Summary: Points describe the life cycle of activity and explore the mechanism of state transitions through a simple experiment

Life cycle of activity

The activity class has many onxxx forms of functions that can be overloaded, such as oncreate,onstart,onstop,onpause, so what is the order of their invocation? The following is an experiment to analyze. Before we do this experiment, we need to know how to do the log output in Android. We're going to use the Android.util.log class, which is pretty easy to do because it provides all the static methods:

LOG.V (string tag, string msg); VERBOSE
LOG.D (string tag, string msg); DEBUG
LOG.I (string tag, string msg); INFO
LOG.W (string tag, string msg); WARN
LOG.E (string tag, string msg); ERROR

The preceding tag is an identity defined by us and can generally be defined by the "class name _ Method name". To view the log information for the output in eclipse, you need to open Logcat (windowàshow viewàotheràandroidàlogcat to open)

Experiment One

The experiment we're going to do is very simple: there are two activity (I'm called Frmlogin and Hello2, respectively), and they each have a button that can jump from the first to the second, or from the second to the first one. The configuration file Androidmanifest.xml is very simple, and the second activity has no unnecessary information to specify.

<application android:icon= "@drawable/icon" android:label= "@string/app_name" >
<activity android:name= ". Frmlogin"
Android:label= "@string/app_name" >
<intent-filter>
<action android:name= "Android.intent.action.MAIN"/>
<category android:name= "Android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
<activity android:name= "Hello2" android:label= "@string/app_name" >
</activity>
</application>

The code for the first activity is as follows:

public class Frmlogin extends Activity
{
Private final static String TAG = "Frmlogin";

/** called when the activity is first created. */
@Override
public void OnCreate (Bundle savedinstancestate)
{
Super.oncreate (savedinstancestate);
LOG.V (TAG, "onCreate");
Setcontentview (R.layout.main);
This.setviewonecommand ();
}

public void Setviewonecommand ()
{
Button btn = (button) Findviewbyid (R.id.btngo);
Btn.setonclicklistener (New View.onclicklistener ()
{
public void OnClick (View v)
{
Intent Intent = new Intent ();
Intent.setclass (Frmlogin.this, Hello2.class);
StartActivity (Intent);
Finish ();
}
});
Button btnexit= (button) Findviewbyid (r.id.btnexit);
Btnexit.setonclicklistener (New View.onclicklistener ()
{
public void OnClick (View v)
{
FrmLogin.this.finish ();
}
});
}

@Override
protected void OnDestroy ()
{
Super.ondestroy ();
LOG.V (TAG, "OnDestroy");
}

@Override
protected void OnPause ()
{
Super.onpause ();
LOG.V (TAG, "onPause");

}

@Override
protected void Onrestart ()
{
Super.onrestart ();
LOG.V (TAG, "Onrestart");
}

@Override
protected void Onresume ()
{
Super.onresume ();
LOG.V (TAG, "Onresume");
}

@Override
protected void OnStart ()
{
Super.onstart ();
LOG.V (TAG, "OnStart");
}

@Override
protected void OnStop ()
{
Super.onstop ();
LOG.V (TAG, "onStop");
}
}

I've added the log method to every OnXxx method, and it's worth noting that the button clicked event handler, and at the end I called finish (); I'll comment out this line for a comparison experiment later. The second activity code is exactly the same as the first one, just setclass the two parameters, so that you can simply implement the function of switching back and forth in the two activity interface. Starting with the experiment, the first lab jumps from the first activity to the second activity (the first one closes), and then jumps back from the second to the first (at which point the second one closes). After running, observe the Logcat and get the following screen:

Then, for the second experiment, the code was adjusted, we commented out the first activity's finish (), jumped from the first activity to the second (when the first one was not closed), and then the second closed directly (then the first one came back to the front), and the result, You can see that the Frmlogin Onrestart is called instead of OnStart, because the first activity is just a stop, and it is not destory out.

The previous two experiments are very well understood, but the third experiment let me not understand, the process is as follows: from the first activity to jump to the second activity (at this time the first does not close), and then the second jump back to the first (at which time the second does not close), and then the first jump back to the second (at this time the first , according to the above to infer, should still call Onrestart, but actually it is called onstart,why???

Let's take a look at the official documentation about the activity life cycle, without discussing an example.

1. Android uses activity stacks to manage multiple activity, so at the same time only the topmost activity is in active or running state. The rest of the activity is under pressure.

2. If inactive activity is still visible (that is, if a non-full-screen activity or transparent activity is pressed above), it is in the paused state. In the case of low system memory, the activity of paused state can be killed by the system. Just do not understand, if it was killed, the interface of the display will become what shape? It seems necessary to look into this situation next.

3. The pairing of several events can clearly understand their relationship. Create and destroy are paired, called Entrie lifetime, when the resource is allocated at the time of creation, the resource is freed when it is destroyed; there is a start and a stop pair, called the visible lifetime, which is a process of visibility and non-visibility. The top is the resume and pause this pair, called foreground lifetime, expressed whether the process is in the active state.

4. Therefore, we implement the activity derived class, to overload two important methods: OnCreate () to initialize the operation, OnPause () Save the results of the current operation. In addition to activity lifecycle, Android also has a process lifecycle description:

In the low-memory time, Android will be active to clean the portal, then it is how to determine which process can be cleared out? The document also mentions its importance ordering:

1. The most easily cleared is empty process, which is a process that has no activity bound to it, and no application components (such as services or intentreceiver) are bound to it. This means that there are no activity or service items in this process, they are just as a cache and can be used to speed up new activity. They are going to be cleared out of priority. It is therefore recommended that our background operations, preferably in the form of service, should start a service in the activity to perform these operations.

2. Next is the background activity, that is, stop off those activity in the process, those invisible activity is cleared is indeed safe, the system maintains an LRU list, Multiple activity in background is here, and the system can determine which activity can be cleared from the LRU list and which one should be cleared first. However, the document mentions that when this cleared activity is re-created, its oncreate is called, and the argument is the bundle at Onfreeze. But what is not clear here is that when the activity is killed, will android help it keep the bundle?

3. Then it's turn to service process, which is a service-bound process that is started by the StartService method. While they are not visible to the user, they are typically handled for long periods of time (such as MP3 playback) and the system will protect it unless there is really no memory available.

4. Then it's the visible activity, or visible process. As mentioned earlier, the paused activity is also likely to be cleared by the system, but relatively speaking, it is in a relatively safe position.

5. The safest should be the foreground activity, and it will not be cleared away. This process includes not only the activity after the resume, but also the Intentreceiver instances after the onreceiveintent. In the discussion of the life cycle of Android application, the documentation also mentions some things to note: Because the Android app's lifetime is not directly controlled by the app itself, but is managed by the Android platform, so for our developers, Need to understand the different components of activity, service, and Intentreceiver life, remember: If the component is chosen improperly, it is likely that the system will kill a process that is doing important work.

Custom controls

Here is the main introduction to the "Edit log" in the use of a custom EditText control, its effects such as:

The main function is to draw split lines between text statements.

public static class Linededittext extends EditText
{
Private Rect Mrect;
Private Paint Mpaint;
We need this constructor for Layoutinflater
Public Linededittext (context context, AttributeSet attrs)
{
Super (context, attrs);
Mrect = new Rect ();
Mpaint = new Paint ();
Mpaint.setstyle (Paint.Style.STROKE);
Mpaint.setcolor (0X800000FF);
}
@Override
protected void OnDraw (canvas canvas)
{
int count = Getlinecount ();
Rect r = mrect;
Paint paint = mpaint;
for (int i = 0; i < count; i++)
{
int baseline = Getlinebounds (i, R);
Canvas.drawline (r.left, Baseline + 1, r.right, Baseline + 1, paint);
}
Super.ondraw (canvas);
}
}

The main task is to overload the OnDraw method, take advantage of the Getlinecount function inherited from the TextView to get the number of lines that the text occupies, and getlinebounds to get the datum height value of a particular row, and the second parameter of the function returns the "outer wrapper" value of this line. These values are then used to draw the lines of this line. In order for the view of the interface to use the custom EditText class, it must be set in the configuration file

<view xmlns:android= "Http://schemas.android.com/apk/res/android"
Class= "Com.example.android.notepad.noteeditor$linededittext"
Android:id= "@+id/note"
Android:layout_width= "Fill_parent"
android:layout_height= "Fill_parent"
Android:background= "@android: Color/transparent"
Android:padding= "5dip"
android:scrollbars= "Vertical"
Android:fadingedge= "Vertical"
android:gravity= "Top"
Android:textsize= "22SP"
android:capitalize= "sentences"
/>

The class= "Com.example.android.notepad.noteeditor$linededittext" here indicates that a custom Linededittext class should be used.

Android Instance profiling notes (iii)