I found a good article, including ANR, activity overload... And so on

Even if your application is fast and responsive, some designs still pose problems to users-unexpected data loss due to unplanned interaction with other applications or dialogs, unexpected blocking, etc.
. Avoiding these problems helps you understand the context of the application program and the interaction process of the system, which is affecting your application. In short, you should do your best to develop a system and other applications
Applications that interact smoothly with each other.

A common smoothness problem is the background processing of an application, for example, a service or broadcastreceiver. A dialog box is displayed to respond to some problems.
. This may not seem serious, especially when you build and test your application on the simulator alone. However, when your application runs on a real machine, it is possible that your application does not obtain
A dialog box is displayed in the background for user focus processing. Therefore, a dialog box for your application may appear after an active application, or a dialog box is displayed to capture the focus from the current application,
Regardless of what the current user is doing (for example, calling ). That behavior should not appear for applications or users.

To avoid these problems, your application should use appropriate system resources to notify users of the notification class. With notification, your application can display an icon in the status bar to notify users of what has happened, instead of capturing focus and interrupting users.

Another example of smoothness problems is the failure to correctly implement the onpause () and other life cycle methods of the activity, resulting in accidental loss of status or user data. Or, if your application
If a program wants to expose data to other applications, you should expose it through contentprovider, rather than (for example) using a readable raw file or database.

What these examples have in common is that they should all work together with the system and other applications. During Android system design, applications are considered as a bunch of loosely coupled components, rather than a bunch of black box code.
As developers, we can regard the entire system as a larger set of components. This helps us to achieve clear and seamless integration with other applications. Therefore, in return, we should better design our
.

This article will discuss common fluency issues and how to avoid them. It will cover these topics:

1) do not discard data

2) do not expose raw data

3) do not interrupt the user

4) Are there too many things to do? Done in the thread

5) Do not overload an activity

6) extended system themes

7) design your UI to handle multiple screen resolutions

8) assume that the network is slow.

9) do not assume the touch screen or keyboard

10) Saving Device batteries

1) do not discard data

Remember that android is a mobile platform. Obviously, other activities (for example, "incoming phone
The call application may pop up to hide your activity at any time. It is important to remember this fact. Because this process will trigger
The onsaveinstancestate () and onpause () methods may cause your application to be killed.

If other activities appear when the user is editing data in your application, the data may be lost when your application is killed. Unless you save
. The "android method" is used in this way: Android applications that can receive and edit user input should rewrite the onsaveinstancestate () side.
And save their status in an appropriate way. When the user re-accesses the application, she can get her data.

The most typical example of this processing method is the mail application. If the user is entering an email, and other activities are started, the mail application should save the edited email as a draft.

2) do not expose raw data

If you don't want to wear your underwear on the street, your data shouldn't be like this. Although some form of application may be exposed to other applications, this is usually not the best idea. Expose raw data and require other applications to understand the format of your data. If you change the format, you will destroy those applications that are not synchronously updated.

The "android method" is to create a contentprovider to expose your data to other applications in a clear, thoughtful, and maintainable API method. Use
Contentprovider is like inserting a Java interface to separate and assemble two highly coupled codes. This means that you can modify the internal data format without modifying
Contentprovider exposes the interface, so that it does not affect other applications.

3) do not interrupt the user

If the user is running an application (such as the phone Program), it is determined that the purpose of user operations is safe. This is why you must avoid creating an activity, but directly respond to user input in the current activity.

That is to say, do not call callactivity () in broadcastreceiver or in a service running in the background (). This operation will interrupt the currently running application.
Program, and cause the user to get angry. Even worse, your activity may become a "button robber", stealing the input that the user wants to provide to the previous activity. Depending on your application
What you do may be bad news.

Instead of directly creating the activity UI in the background, you should use notificationmanager to set notification. They appear in the status bar, and users can click them when they are idle to view what your application shows to him.

(Note: If your activity is already in the foreground, the above will not apply: at this time, for user input, the user expects to see the next activity to respond .)

4) Are there too many things to do? Done in the thread

If your application needs to perform some expensive or time-consuming computing, you should try to move it to the thread as much as possible. This will prevent users from displaying the Terrible "application not responding" dialog box. If you do not do this, the final result will cause your application to be completely terminated.

Generally, all the code in the activity, including its view, runs in the same thread. In this thread, you also need to handle UI events. For example, when you press
A key-down event is added to the main thread queue of the activity. The event processing system needs to quickly list and process the event. If not, the system determines that
The application has been suspended and provides users with the opportunity to kill the application.

If there is time-consuming code that runs inline on the activity, that is, it runs in the event processing thread, which largely blocks event processing. This will delay the input processing and cause the ANR dialog box. To avoid this, move your computing to the thread. The article on responsive design has discussed how to do this.

5) Do not overload an activity

Any worthwhile application may have several different screens. When designing the UI screen, you must use multiple activity object instances.

Depending on your development background, you may understand that activity is similar to Java
Applet, which is the entry point of your application. However, it is not accurate: the applet subclass is a Java
The single entry point of the applet, and an activity should be considered as one of multiple potential entry points of your application. The only difference between your "Main" activity and others
The "Main" activity happens to be the only pair of "android. Intent. Action. Main" in the androidmanifest. xml file"
Activity that you are interested in.

Therefore, when designing your application, consider your application as a collection of activity objects. In the long run, this will make your code easier to maintain.

6) extended system themes

When talking about the UI view, it is very important to skillfully blend. Users will feel unpleasant when using apps with the opposite UI as they expected. When designing your UI, you should try to avoid too many
Your subject. On the contrary, the same topic is used. You can rewrite or extend the theme part you need, but at least start with the same UI as other applications. For details, refer to "application style and topic ".
Points.

7) design your UI to cope with multiple screen resolutions

Different Android devices may support different screen resolutions. You can change the resolution, for example, switch to the Landscape mode. Make sure that your layout and images are flexibly displayed on different device screens.

Fortunately, this is easy to do. In short, what you need to do is to provide different versions of work for the main resolution, and then design your layout for different sizes. (For example, avoid using a hard-coded location with a relative layout .) If you do that, the system will process the rest, and your application looks great on any device.

8) assume that the network is slow.

Android devices have multiple network connection options. All of them provide data access, but they must be faster. Among them, the slowest speed is the non-3G data service of GPRS and GSM network. Even if a device with 3G capability spends a lot of time on a non-3G network, the slow network is still a long term.

This is why you should write your code according to the minimal network access and bandwidth. You cannot assume that the network is fast, so you should always plan that it is slow. If your users happen to be in a fast
That's good on the network-their user experience will be improved. You need to avoid the opposite: at different places and at different times, applications are sometimes available, sometimes slow, and such programs may not be affected.
Welcome.

Another potential is that if you are using a simulator, you are easily confused because the simulator uses a computer's network connection. This is much faster than the mobile network, so you need to modify the simulator settings
To simulate a low network speed. You can do this in eclipse, set in the simulator settings page of the startup options, or set through the command line option when starting the simulator.

9) do not assume the touch screen or keyboard

Android supports multiple appearance shapes. That is to say, some Android devices have full "qwerty" keyboards, while others may have 40 keys, 12 keys, or other keyboard settings. Similarly, some devices may have touch screens, but some may not.

Remember this when creating your application. Do not assume a specific keyboard layout-unless you really want to limit that your application only runs on certain devices.

10) Saving Device batteries

If a mobile device is often inserted in a wall, it is not very "mobile ". Mobile devices are powered by batteries. If we can make each battery charged more persistent, then everyone will be more open.
Heart, especially the user. The two major power-consuming hardware are processor and wireless. That is why we need to write as few applications as possible to use the network as much as possible.

To minimize the CPU usage of your applications, you must write efficient code. To reduce the consumption of wireless power, make sure that the error conditions are correctly handled and only get what you want. Example
For example, if a network operation fails, do not retry. If you fail once, the user may not be welcome. Therefore, if you perform the operation in the correct way, the operation may fail.
It is a waste of battery.

Users are very smart: If your program consumes high power, they will certainly find out. At that point, the only thing you can be sure of is that your program will soon be uninstalled.

This may happen. The code you write passes all the performance tests in the world, but it still makes users feel uncomfortable when they try to use your application. Some areas where the application is not responsive include: slow response, long suspension or freezing, or a long time to process input.

In
On Android, if your application is not responsive for a period of time, the system will display a dialog box to the user. This dialog box is called "No response for the application ".
(ANR: application not
Responding) dialog box. You can choose to keep the program running, but they do not want to process this dialog box every time they use your application. Therefore, the responsiveness in the program
An effective design is very important. In this way, the system will not display ANR to users.

Generally, if the application cannot respond to user input, the system displays an ANR. For example, an application blocks some I/O operations (usually network access ).
The main thread can no longer process user input events. After a certain period of time, the system considers the application has been suspended and displays ANR to allow the user to choose to kill the application.

Similarly, if your application spends too much time building a detailed memory structure, or maybe it takes too much time in the game to calculate the next move, then, the system will think that your application has been suspended. Therefore, it is often important to ensure that these computations are efficient, but even the most efficient code still takes time to run.

In both cases, the solution is to create a sub-thread and then perform most of your work in the thread. This keeps the main thread (driving the UI event loop) Running and prevents the system from believing that your
The Code has been frozen. Because these threads are generally completed at the class level, you can consider the response performance issue as a class issue. (Compared with basic performance, basic performance problems are considered as method-level questions.
Question)

This article will discuss how the Android system judges that an application is unresponsive and provides a wizard to ensure the responsiveness of the application.

This article covers these topics:

What triggers ANR?

How to Avoid ANR?

Enhanced Response Sensitivity

1) what triggers ANR?

In Android, the responsiveness of applications is monitored by the system services of activity manager and window manager. When it detects one of the following situations, Android displays ANR for specific applications:

Events that do not respond to input within 5 seconds (for example, pressing a button or touching the screen)

Broadcastreceiver is not executed within 10 seconds.

An ANR dialog box is displayed to the user.

2) How to Avoid ANR?

Considering the above ANR definition, let's take a look at why it occurs in Android applications and how to best build applications to avoid ANR.

Android applications usually run in a separate thread (for example, main. This means that if your application takes too long in the main thread, the ANR dialog box will be triggered, because your application does not have the opportunity to handle input events or intent broadcasts.

Therefore, any method running in the main thread should do as little as possible. In particular, the activity should be in its key lifecycle methods (such as oncreate () and
Create as few operations as possible in onresume. Potential time-consuming operations, such as network or database operations, or high-time computing, such as changing the bitmap size, should be in the Child thread (or using data
Library operations, for example, through asynchronous requests. However, it does not mean that your main thread is blocked and waits for the completion of the sub-thread-it is not to call thread. Wait () or
Thread. Sleep (). The alternative is that the main thread should provide a handler for the sub-thread so that it can be submitted to the main thread upon completion. Design your application in this way
Ensure that your main thread is responsive to the input and avoid the ANR dialog box caused by the 5-second input event timeout. This approach should be followed in other display UI threads because they are all subject to the same
.

Intentreceiver
The Special execution time limit means that it should do: do small, trivial work in the background, such as saving settings or registering a notification. Like other methods called in the main thread
The program should avoid time-consuming operations or computing in broadcastreceiver. But it is no longer doing these tasks in the Child thread (because of the life of broadcastreceiver
Short Cycle). The alternative is that if you need to perform a time-consuming action in response to intent broadcast, the application should start a service. By the way, you should also avoid
Intent
Start an activity in the consumer, because it creates a new screen and grabs the focus from the program that the current user is running. If your application is responding to a wide range of intent
You should use notification manager to demonstrate what needs to be presented to users during playback.

3) enhanced response sensitivity

In general, 100 to MS is the time threshold for the user to perceive the block in the application. Therefore, here are some additional tips to avoid ANR and help make your application look like there are
Responsiveness. If your application inputs the background work for the response user, the progress of the work can be displayed (progressbar and progressdialog are very good for this situation.
Useful ). Especially for games, mobile computing is performed in sub-threads. If your application has a time-consuming initialization process, consider displaying a splash
Screen or quickly display the main screen and asynchronously fill in the information. In both cases, you should display the progress in progress so that users do not think the application is frozen.