Shulou(Shulou.com)06/02 Report--

Activity and life cycle example analysis, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

Introduction

The Activity life cycle does not take effect only after the user runs the application, but in fact it also affects the different feedback that users get when they cut out and switch back to the application. When we develop an application, we first need to keep in mind that users often switch frequently during execution and between our application and other applications. Depending on how the user operates, the same application sometimes runs in the foreground and sometimes in the background. You must ensure that your applications can handle this kind of situation, and save and recover data in a timely manner during such switching. Again, this process is slightly different for some specific applications; for example, functional components.

1. The first step of callback method

In order to control the way the application runs when the Activity is in different states, for example, when the user cuts out or switches back to the application, we can choose a variety of processing methods. Such methods are also known as Activity lifecycle callback methods. The Android system invokes these methods after our Activity enters a certain state, thus ensuring that our application continues to work, does not lose data, and does not use non-essential resources when users do not interact with it. Each callback method puts our application into a possible state.

If you have been exposed to the programming of Java applications before, you should have found that Android applications are launched in a different way. Unlike Java applications that directly use the main method, Android first executes the onCreate method in the main Activity class after startup. Keep in mind that we have designated this class as the primary launch Activity in the listing. Activity first calls back the onCreate method, which is equivalent to repeating the process after the user starts the application. At this point, the onCreate method puts the application into the Created state.

The concepts of life cycle, callback method, and state are intuitively introduced in the developer's guide through a schematic diagram. The onResume method is responsible for providing the Resumed state, and our application can accept the direct action of the user. Other callback methods focus on onResume, which bootstraps the application to or from the Resumed state, starts it, or stops it.

For most applications, we only need to use part of the callback method, but at least use onCreate. Although it is not used frequently, understanding the role of all callbacks and status will help us understand how our Android system will be affected when our applications run and stop running. In general, we need to ensure that users can successfully return to their previous running state after switching out of any operation; if they choose to move forward or backward through navigation, the application needs to save all the necessary data and release unnecessary hardware resources.

Step two

Our application may be in the following five states: Created, Started, Resumed, Paused, and Stopped. There are seven other callback methods that can bring the application into or out of the above state: onCreate, onStart, onRestart, onResume, onPause, onStop, and onDestroy. These methods allow our applications to switch between possible states, and in some cases quickly. Generally speaking, you can think of your application as being in resumed, paused, or stopped all the time, because the other states are temporary.

When our application is running and the user interacts with it, the application status is Resumed; when another Activity is in the foreground but only makes our application partially hidden, the application status is Paused-- in this state the user can no longer interact with the application. When our application is completely in the background, and the user can neither operate nor view it, its status is Stopped. In this state, Activity retains all previous data, but cannot execute it.

two。 Enter the Resumed state

As we know, the main Activity starts running when the application starts, and the onCreate method executes, allowing us to prepare the Activity UI and all the data entries needed for this class. Most of the applications we create contain more than one Activity, and other Activity starts when the user interacts with the application. You can use the following code to start another non-master Activity through the Intent class:

This represents another Activity class in the application package called "About". You can select your own source package and then select "File", "New", "Class" to create a new Activity in Eclipse, and then select the Android Activity class as the super class. Keep in mind that every Activity must be listed in our application listing. You can also use the Intent class to transfer data between different Activity.

When an Activity is running, the onCreate method is also executed at the same time, so in addition to listing other Activity classes, you can also deal with them in the application in a similar manner to the main Activity. We can also create a layout file for each Activity and set it to use the same technical mechanism as the main Activity.

After the execution of the onCreate method of an Activity, the onStart and onResume methods also begin to execute, leaving the Activity in the Resumed state and transitioning to the Created and Started state as appropriate during subsequent execution.

Our Activity can enter the Resumed state in more than one way, and application startup is only the most basic way. If the Activity is in the Paused or Stopped state, the Activity goes directly to the foreground running mode after the application switches to the current state, and there is no need to call the onCreate method repeatedly. If your application switches from Paused state to Resumed state, the onResume method of Activity will start to execute. If the application switches from the Stopped state to the running state, the onRestart method is executed, followed by the onStart method and the onResume method.

3. The first step in entering the Destroyed state

When our application is exited or hidden, Resumed changes to Destroyed. At this point, the onPause method transitions the applied Activity from the runtime Resumed state to the Paused state. In onPause, you should stop any resource-consuming tasks, such as animation playback, sensor data processing, broadcast reception, and so on. If onPause is executing, then onStop can also start execution, because the user has usually exited our application by navigation at this time. You can also use the onPause method for data preservation-although it is generally most appropriate for the onStop method to take care of the data preservation.

As we mentioned earlier, your Activity can return from the Paused state to the Resumed state through the onResume method. This means that we can use onResume to restore any content we have previously stopped or published in onPause. However, you also need to keep in mind that onResume is also implemented in other situations, such as when the application starts.

Step two

After onPause, if the application enters the Stopped state, the onStop will also start execution. In this case, methods such as onRestart, onStart, and onResume can still bring the application back to the Resumed state. In onStop, you should try to compress operations that are only necessary for data, such as writing content to the database. Please make sure that all the resources used by the application are included in the onStop, so as to avoid memory overflow problems after the application is completely closed.

This system saves specific data, such as what needs to be displayed in the view, after the application switches from the resumed state to the stopped state. When an Activity is restored from the Stopped state to the Resumed state, the onRestart, onStart, and onResume methods all begin to execute. However, the performance of onStart is different from that of onResume-- for example, when the application starts. The onRestart method is executed only after the application is restored from the Stopped state to the foreground, so that you can use it to restore any running content saved in the onStop.

Tip: when you start another Activit from under another Activity, the former will enter the Stopped state. If the user then uses the back button to return the latter to the previous Activity, then the onRestart method of the former will begin execution.

Step three

If your application is about to shut down completely, for example, our current Activity is removed from the system, the onDestroy method will begin to execute. Although this is a method that is implemented before our Activity disappears completely, you should not simply erase everything. In fact, we need to use onStop or onPause to handle the closing work. There are exceptions, of course, if the background process of the application is still running, then you should stop it in onDestroy.

After the onDestroy execution, if the user navigates back to the application Activity, the corresponding onCreate method will be started again. In general, you can assume that onPause and onStop will be executed before onDestroy. However, if you explicitly call the finish method to end an Activity, only onDestroy will be executed.

In most cases, we don't need to put too much effort into lifecycle callbacks in applications, because you can use the parameters of the onCreate method to achieve data retention. In the Activity onCreate method, the Bundle parameter is responsible for automatically saving view information as mentioned earlier. However, you can also use this object to save more data content, such as recording variable updates resulting from the interaction between the user and the application. To achieve this goal, you can use the onSaveInstanceState method in the Activity class, and after you have finished writing the data key-value pair, we may restore it in onCreate.

Tip: when the user changes the display mode of the device, that is, switching between portrait and landscape modes, our Activity will actually be recreated and the onCreate will be executed again. This process is called configuration change. In this case, the system will assume that you need to recreate the Activity, such as using a different layout scheme in each display mode. In most cases, however, you may not want the system to follow suit. To avoid recreating our Activity during display mode conversion, you can choose from two solutions: add the "android:configChanges" attribute to the Activity in the list, or adjust our Activity structure to take advantage of the Fragments we keep when configuring variables.

The answers to the sample analysis questions about Activity and life cycle are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.