Android review--Activity

life cycle

Life cycle under normal conditions

That is, the life cycle of Activity from normal startup to final destruction.

  • onCreate() : Activity is being created. Some initialization work can be done here, such as loading layouts, initializing data, and so on.
  • onRestart() : Activity is restarting. When the Activity changes from invisible to visible (the current Activity presses the Home button to return to the desktop or opens a new Activity and then returns to this Activity, if its instance has not been destroyed), this method will be called.
  • onStart() : Activity is starting. Activity is already visible at this time, but it is still in the background , you can not interact with the user.
  • onResume() : Activity is already visible, and has been in the foreground and started the activity.
  • onPause() : Activity is stopping. Then onStop will be called. Some operations such as storing data and stopping animation can be done here, but it should not be too time-consuming, because the onResume of the new activity will only be executed after the onPause method of the old activity is executed.
  • onStop() : Activity is about to stop. You can do some heavyweight recycling work, but it can't be too time-consuming.
  • onDestroy() : Activity is about to be destroyed. Some recycling can also be done.

onPause()和onStop()的区别:onPause can be understood as the current Activity loses focus, and onStop means that the current Activity is not visible. If the new activity started is a dialog activity (transparent theme), then onPause will be called, but onStop will not.

Specific scenario

  • Activity is started for the first time / Activity is reopened by the system after the life cycle callback: onCreate→onStart→onResume
  • Activity A starts Activity B, and B rolls back to A, the life cycle of the two changes

A starts B:

B goes back to A:

The reason why A's onStop method is executed after B starts when A starts B above is: new activities are started faster, and user experience is improved; when B rolls back to A, onStop and onDestroy are executed after A restarts.

  • When starting a new Activity or switching to the desktop: onPause→onStop.
    Special case : if the new Activity uses a transparent theme, the current Activity will not call back onStop.
  • Go back to the original Activity again: onRestart→onStart→onResume
  • onCreate and onDestroy will only be called once in the entire life cycle of the Activity; starting from whether the Activity is visible, onStart and onPause are paired and may be called multiple times; from whether the Activity is in the foreground, onResume and onStop are paired and may be called Called multiple times.

Life cycle under abnormal conditions

The abnormal situation refers to:

  • System configuration changes cause the Activity to be killed and recreated.
    For example, rotating the screen causes the system configuration to change. By default, the Activity will be destroyed and recreated. But it can also prevent the system from recreating the Activity.

The life cycle of the screen rotation when the configChanges property is not set :
running state → onSaveInstanceState() → onStop() → onDestroy() → onCreate() → onStart() → onRestoreInstanceState() → onResume() The
screen rotates when the configChanges property is set The life cycle of the case:
running status → onConfigChanged()

  • Insufficient mobile phone memory causes low-priority activities to be killed.
    Activity priority division:
    1. Foreground Activity : The activity that is interacting with the user, with the highest priority.
    2. Visible but non-foreground Activity : For example, an activity that pops up a dialog box.
    3. Background Activity : The activity that has been suspended has the lowest priority.

onSaveInstanceState and onRestoreInstanceState methods

These two methods will only be called when the Activity terminates abnormally. You can use the onRestoreInstanceState or onCreate method to determine whether the Activity has been rebuilt.

The difference between onCreate and onRestoreInstanceState methods :

The onRestoreInstanceState callback indicates that the Bundle object is non-empty, and there is no need to add non-empty judgment.

onCreate requires non-empty judgment. It is recommended to use onRestoreInstanceState.

  • When to call

onSaveInstanceState is called before the onStop method, but it has no timing relationship with onPause;

onRestoreInstanceState is after the onStart method.

  • Save and restore View hierarchy

When the Activity is abnormally terminated, it will entrust Window to save the data, and it will entrust the top-level container (DecorView) to save the data, and it will traverse the child elements and notify them to save the data in turn, that is, call the corresponding onSaveInstanceState and onRestoreInstanceState methods.

Prevent the activity from rebuilding when the system configuration is changed

By specifying **configChanges**attributes in the corresponding Activity in the AndroidMenifest.xml file , when the system configuration changes specified in configChanges occur, the Activity will not be rebuilt, the onConfigurationChangedmethod will be called back at this time , and no other life cycle methods will be called.

Activity start mode

For examples, see https://www.jianshu.com/p/b4472dc6911e

  • standard: Standard mode , which is also the default startup mode of Activity. Every time an Activity is started, an instance of it will be created and added to the top of the task stack, regardless of whether it already exists.
    For example: there is a button in Activity A, pressing it will start Activity A through startActivity. If you click twice in a row, a total of three Activity instances will be created, and you need to press the return key three times to exit to the desktop.
  • singleTop: Stack top multiplexing mode . If the new Activity to be started is already at the top of the task stack, no new instances will be created, and its onNewIntent method will be called back; if it is not at the top of the task stack, a new instance will be created.
    应用: Activity jumped by notification in the notification bar . There is also to prevent two consecutive clicks from creating two Activity instances.
  • singleTask: Multiplexing mode in the stack . Each time the activity is started, the system will first check whether there is an instance of the activity in the return stack, if it already exists, use the instance directly, and pull all activities above this activity out of the stack , and call back onNewIntent() ; If not found, a new activity instance will be created and added to the top of the task stack.
    应用: Activity on the main page of most apps
  • singleInstance: Single instance mode . The newly started Activity will be placed separately in a newly created task stack.
    应用: Incoming call or alarm page

onNewIntent()

Under normal circumstances, if the startup mode of an Activity is singleTask or singleTop, when the Activity is started for the first time, a new instance will be created in the stack, that is, onCreate()→onStart()→onResume() will be called ; If there is already an instance of this Activity in the stack (singleTop corresponds to the top of the stack), it will call: onNewIntent()→onResart()→onStart()→onResume().

onNewIntent()的陷阱

Calling getIntent() in onNewIntent() will always only get the first Intent object. But we can call setIntent() in it to update the Intent object.

That is, the following way of writing will get the latest Intent every time:

@Override
protected void onNewIntent(Intent intent) {
    
    
    super.onNewIntent(intent);
    setIntent(intent);         //设置新的intent
    int data = getIntent().getIntExtra("tanksu", 0);//此时的到的数据就是正确的了
}

taskAffinity

Each Activity has a taskAffinity property, which indicates the Task it wants to enter. If an Activity does not explicitly specify the taskAffinity of the Activity, then its attribute is equal to the taskAffinity specified by the Application. If the Application does not specify either, then the value of the taskAffinity is equal to the package name

SingleTask and taskAffinity are used together to specify which stack the started Activity is added to

Specify the startup mode for the Activity

Two methods, but the priority of setting the flag bit is higher than specifying the startup mode in xml.
Secondly, there are differences between the two methods: the first one cannot directly set the FLAG_ACTIVITY_CLEAR_TOP flag for the activity; the second one cannot specify the singleInstance for the activity.

  • Specify the launchMode attribute for the Activity in the manifest file
  • Set the flag bit in the Intent. That is, the Intent object passed in startActivity is addFlagsset by ** ** method.

Flags commonly used in Activity

  • FLAG_ACTIVITY_SINGLE_TOP : same as singleTop startup mode
  • FLAG_ACTIVITY_NEW_TASK : Same as the start mode of singleTask
  • FLAG_ACTIVITY_CLEAR_TOP : Generally need to be used in conjunction with FLAG_ACTIVITY_NEW_TASK, and the **singleTask**effect is the same at this time . If the started Activity is set to the standard mode, it and the Activity instance on it will be popped out of the stack, and an instance of this Activity will be recreated to the top of the stack.
  • FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS : Activities with this mark will not appear in the list of historical activities.

The difference between startup mode and Flags

The main difference between the startup mode and the FLAG is that the former is fixed and hard-coded in the xml file;

The latter is composable and more flexible.

For example: when you are not suitable to use SingleTask in most scenarios, but some scenarios require its feature of clearing the upper Activity in the stack, then you choose the combination of singleTop mode + clearTop FLAG, so, in the list you configure It is singleTop, only in the scene where you need to clear the effect, dynamically add FLAG to the code to use in combination.

Guess you like

Origin blog.csdn.net/why1092576787/article/details/114947742