Causes of ANR

ANR can only be caused when the UI thread response of the application times out, and there are two common reasons for timeout.

1, the current event has no chance to be processed, for example, the UI thread is responding to another event, and the current event is blocked for some reason.

2. The current event is being processed, but cannot be completed in time because it takes too long. Timeout events vary according to the causes of ANR.

Essentially, there are three ways ANR can occur, roughly corresponding to three of the four main components of Android (Activity/View, BroadcastReceiver, and Service).

KeyDispatchTimeout 1, the most common type, is when the View’s click or touch event is not responded to for a specified period of time (5s).

BroadcastTimeout 2: the BroadcastReceiver onReceive() function runs on the main thread and cannot complete processing within a specified period of 10 seconds.

ServiceTimeout 3, a less common type, because the various life cycle functions of the Service cannot complete processing within a certain time (20s).

Location and analysis of ANR

When ANR occurs, it can be analyzed and located by combining Logcat logs with the generated /data/ ANR/tetrace.tex file stored in the internal storage of the phone.

Caton principle

The Android system signals VSYNC every 16ms to trigger a rendering of the UI, and if each rendering is successful, it achieves the 60fps required for smooth graphics. (in order to achieve 60fps, this means that most of the program’s operations have to be done in 16ms.) if one of your operations takes longer than 16ms, the system won’t be able to render properly when it gets the VSYNC signal, resulting in frame loss. Then the user still sees the last frame in the current frame.

Catton detects blockcanary

Principle Introduction:

1. The stall occurs in the main thread, and all the event handling of the main thread is handled in the main thread looper

Loop method of 2, which, in the call MSG. Target. DispatchMessage (MSG); Printer will be used to print message information before and after message processing.

3. Set the self-defined printer. Record the start time T1 in the first call, record the end time T2 in the second call, and the time before and after the message processing.

Causes and optimization of stalling

(1) The interface layout is complicated, resulting in overdrawing of the interface (using debugging GPU to overdraw to view the interface) (background)

Layout optimization

(2) Too many animations or the animation execution process is complicated

Simplified animation; Using property animation

(3) View rendering process is time-consuming (GPU rendering mode analysis)

To simplify the logic

(4) Gc takes up the calculation time of the program (The Memory Monitor checks that several Memory fluctuations occur in a short period of time, which means Memory jitter is likely to occur, so we allocate the Tracker to check the same objects in and out of the same stack in a short period of time).

Object reuse

(5) Memory leak (Memory leak refers to the object that is no longer used by the program is not recognized by the GC, thus causing the object to remain in memory, occupying valuable memory space. Obviously, this also makes the memory area available for each level of Generation smaller, which makes the GC more likely to be triggered, indirectly causing the leakcanary problem.

(6) List optimization, using local refresh

reference

BlockCanary — Easy to find the culprit behind Android App interface delays