Android performance optimization of intractable disease solutions, U-APM performance monitoring analysis

contents

1. Slow startup/white screen/black screen optimization
1. Modify the theme/background image
2. Timing of initialization
3. Child thread initialization
4.ConstraintLayout
2. Crash/ANR/OOM
1. Crash
2.ANR
Three. U-APM
1. Integration
2. Use
4. Author introduction

Regarding the development of Android so far, with various functions being very mature, we are paying more and more attention to the performance optimization of the App and the user experience. This is related to the basis for the continuous growth of the DAU of an online application and the issue of user reputation. Today, Liu Someone will take everyone to analyze how to solve the problems such as crash/carton/ANR/OOM/slow startup, and the convenience of using U-Meng performance monitoring platform U-APM.

1. Slow startup/white screen/black screen optimization
When we develop applications, we often initialize some data and functions in advance to ensure that there will be no additional stay or waiting time during the user's use. Then when a project is very large, there will be a lot of initialized data. In addition, due to various reasons such as the performance of the device, the rendering mechanism, etc., there will often be white screens, black screens, etc. due to slow startup. Based on this situation, let's see how to solve it.

1. Modify the theme/background image
Let's first look at the structure of Activity

To modify the theme, you only need to modify the theme of the startup page to be transparent or picture, so that before the ContentView is loaded, we will see the desktop through the launched Activity, and there will be no black/white screen. Then remove the title bar and set the Activity to full screen. The effect is pretty good. The disadvantage is that if you start an Activity with complex and time-consuming operations, there will be a feeling of delay.

Set the theme background to a picture, remove the title bar, and set the Activity to full screen, so that we can see a default background image before the ContentView is loaded, but the screen adaptation of the picture needs to be considered , The background image in the theme will be automatically stretched, which may cause distortion or imbalance. The solution is to use a .9 image.

code show as below
<!--The transparent theme of the startup page, if you want to set it as the background, modify windowBackground-->
<style name="SplashStyleTransparent" parent="Theme.TestPerformance">

<item name="android:windowBackground">@android:color/transparent</item>
<item name="android:windowFullscreen">true</item>
<item name="android:navigationBarColor">@android:color/transparent</item>
<item name="android:statusBarColor">@android:color/transparent</item>
<item name="windowNoTitle">true</item>
<item name="windowActionBar">false</item>
<item name="android:windowContentOverlay">@null</item>
<item name="android:windowDisablePreview">false</item>

</style>

2. Timing of initialization
Our common initialization is nothing more than initialization in the onCreate of the Application or the onCreate creation callback of the startup page, but you can find out about the life cycle that in fact onCreate is still performing the rendering operation, so we can put the initialization action in In onResume, but onResume is called back multiple times, so we still need to judge the initialization.

code show as below
@Override
protected void onResume() {

super.onResume();
//未初始化才进行初始化
if (!ThirdSDK.getInstance().isInit()) {
    ThirdSDK.getInstance().init();
}

}

3. Child thread initialization
If it is not mandatory to use in the main thread, or if it is not mandatory to initialize and call the function quickly, we can optimize the initialization of a large number of functions by initializing in the child thread

code show as below
public class BaseApp extends Application {

@Override
public void onCreate() {
    super.onCreate();
    //多进程的情况下，只在主进程进行一次初始化
    if (CommonUtils.isMainProcess()) {
        new Thread(() -> {
            if (!ThirdSDK.getInstance().isInit()) {
                ThirdSDK.getInstance().init();
            }
        }).start();
    }
}

}
4.ConstraintLayout
Constraint layout has become the default parent layout in the official Android Studio template, which shows its status, ConstraintLayout
Allows you to create complex large layouts using a flat view hierarchy (no nested view groups). It is similar to RelativeLayout, in which all views are laid out according to the relationship between the sibling view and the parent layout, but its flexibility is higher than that of RelativeLayout, and it is easier to use with Android Studio's layout editor. He is not only aiming at the optimization of the startup page, so at the end, ConstraintLayout can reduce the level of layout rendering, and it can also play a certain optimization role.

For specific usage, please refer to the Google document:
https://developer.android.google.cn/training/constraint-layout?hl=zh_cn

2. Crash/ANR/OOM
1. Crash
The problem of the crash is generated at runtime, and an Exception will be thrown. The most common exceptions are null pointers, arrays out of bounds and other exceptions. If a crash occurs during debugging, I believe that some basic students know how to solve it. For the problem, search for AndroidRuntime in logcat, and fix it according to the error prompt. If it is not in the debugging state but online, then we need to collect the logs. If the crash log collection is generally localized, it will increase in vain. For a lot of workload, I would recommend Youmeng’s mobile statistics U-App to collect logs. See below for the usage method.
2.ANR
The performance of ANR will pop up a prompt box on the old Android version (the application has stopped), but now the mainstream version generally crashes directly. The processing method of ANR is more complicated, and it needs to be analyzed step by step according to the overflow information of the stack. Performance as shown

The main thread of the application responsible for updating the interface cannot handle user input events or drawing operations, which will cause user dissatisfaction. Therefore, the system will wait according to the current scene and stop responding after waiting for a timeout. Generally, the following situations will lead to ANR.

1. When your Activity is in the foreground, your application does not respond to input events or BroadcastReceiver (such as key presses or screen tap events) within 5 seconds.
2. Although there is no Activity in the front desk, your BroadcastReceiver has taken a long time to execute but it hasn't been completed.

Android provides some ways to help us analyze the problem, you can check the official document for details
https://developer.android.google.cn/topic/performance/vitals/anr?hl=zh-cn

Of course, when there is a problem with the online App, we need to use the U-App of Youmeng to collect logs so that we can analyze the problem. See below for how to use it.

3.OOM
OOM memory overflows. Most of the situations that occur are problems with referenced pictures. The full name is "Out Of Memory". The most common OOM situations are as follows:
 java.lang.OutOfMemoryError: Java heap space
 Java heap memory overflow. This is the most common situation, usually caused by memory leaks or improper heap size settings. For memory leaks, the leaked code in the program needs to be found through the memory monitoring software, and the heap size can be modified through the virtual machine parameters -Xms, -Xmx, etc.
 java.lang.OutOfMemoryError: PermGen space
 Java permanent generation overflow, that is, the method area overflows. It usually occurs in a large number of Class or jsp pages, or when a reflection mechanism such as cglib is used, because the above situation will generate a large amount of Class information to be stored in the method area. This situation can be solved by changing the size of the method area, using a form similar to -XX:PermSize=64m -XX:MaxPermSize=256m. In addition, too many constants, especially strings, can also cause the method area to overflow.
 java.lang.StackOverflowError
 No OOM error will be thrown, but it is also a common Java memory overflow. JAVA virtual machine stack overflow is generally caused by the existence of infinite loops or deep recursive calls in the program. This type of overflow may also occur if the stack size is set too small. The size of the stack can be set by the virtual machine parameter -Xss.

We usually use heapdump to analyze the waveform of the memory to find problems. Of course, we can also collect logs first, see below

Three. U-APM
1. Integration
We can use Umeng’s APM to collect the logs first, so that we can solve the problem. U-APM is a new and independent product upgraded on the basis of the original U-App stability analysis, so the students who have been included can upgrade directly: https ://at.umtrack.com/LrKb0f

According to the document description, we will access, the process steps of access are shown in the figure

1. We first add the Umeng warehouse in the build.gradle of the project, as shown in the code

2. Add dependency in app/build.gradle

3. Add permissions

4. Initialization, you need to call the pre-initialization first, and then call the initialization

Ok, everything is ready, we can simulate the wrong collection, but please note that APP_KEY needs to be applied for by yourself, and APP_CHANNEL corresponds to the channel tag. If there are no multiple channels, you can ignore it, if there are multiple channels For packaging and statistics, then the corresponding channel name can be passed in.

2. Use

Come to the Umeng APM management platform

You can see that the DEMO I created shows that APM has been integrated. Let me simulate a null pointer error

As you can see, it is displayed in real time, and the captured logs are more accurate. Let’s take a look at the details.

In this way, you're done. If there is a crash, ANR and OOM can be captured, and based on the basic capabilities of Umeng, we can count daily activities in real time, event reporting and other functions, which is quite good.

Of course, the logs collected, including the detection of anomalies, are analyzed by ourselves. The process of this analysis still requires personal experience, as well as care and patience. The road to solving bugs is boring and tedious. Only by taking care of it can you experience the beauty of code.

Author: Liu Guilin
CSDN blog expert, CSDN blog star, CSDN/Mukenet certified lecturer, with many years of experience in Android software development, mainly engaged in the car pre-installation industry, Internet advertising industry, proficient in Android, willing to share, publishing original blog articles on the Internet is highly regarded Praise, love new technology, have almost harsh requirements for technology, fluent in teaching language, clear thinking, eloquent and humorous, three practical courses have been released on MOOC.com.