Android性能优化之疑难杂症解决方案,U-APM的性能监控分析

Posted 2021-11-10 刘某人程序员

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Android性能优化之疑难杂症解决方案,U-APM的性能监控分析相关的知识，希望对你有一定的参考价值。

关于android发展至今，在各项功能十分成熟的情况下，我们越来越重视App的性能优化，以及用户体验，这关乎一个线上应用的DAU持续增长的基础，以及用户口碑的问题，今天刘某人带大家来一起分析一下崩溃/卡顿/ANR/OOM/启动慢等问题是如何解决的，以及使用友盟性能监控平台U-APM的便捷。

一.启动慢/白屏/黑屏优化

我们在应用开发的时候，常常会提前初始化一些数据和功能，来保证用户使用的过程中，不会产生额外的停留，等待时间，那么当一个项目十分庞大的时候，初始化的数据也非常的多，另外由于设备的性能，渲染的机制等各种原因，时常会出现启动慢导致白屏，黑屏等情况，基于此情况，我们来看下如何解决。

1.修改主题/背景图

我们先来看下Activity的结构

修改主题只需要将启动页的主题修改为透明或者图片，这样在ContentView加载出来之前，我们会透过启动的Activity看到桌面，就不会有黑/白屏的现象。再把标题栏去掉，把Activity设置成全屏的，效果挺不错，缺点是如果启动的是一个有复杂耗时操作的Activity，那么会有一种延迟的感觉。

将主题背景设置成一张图片，把标题栏去掉，把Activity设置成全屏的，这这样在ContentView加载出来之前，我们就能看到一张默认背景图，但是图片的屏幕适配问题就需要考虑了，主题里的背景图片会自动拉伸，可能会导致失真或者比例失调的问题，解决办法是使用一张.9的图片。

代码如下

<!--启动页透明主题，如果想设置为背景，则修改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.初始化时机

我们常见的初始化，无外乎在Application的onCreate或者启动页的onCreate创建回调中进行初始化，但是了解生命周期你可以发现，实际上onCreate还在进行渲染的操作，所以我们可以把初始化的动作放在onResume中，但是onResume是多次回调的，所以我们还需要进行初始化的判断。

代码如下

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

3.子线程初始化

如果非强制必要在主线程使用，或者非强制要快速初始化，快速调用的函数，我们可以通过在子线程初始化的方式来优化大量函数初始化的情况

代码如下

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

约束布局已经成为Android Studio官方模板中默认的父布局了，可见其地位，ConstraintLayout
可让您使用扁平视图层次结构（无嵌套视图组）创建复杂的大型布局。它与 RelativeLayout 相似，其中所有的视图均根据同级视图与父布局之间的关系进行布局，但其灵活性要高于 RelativeLayout，并且更易于与 Android Studio 的布局编辑器配合使用。他针对的不光是启动页的优化，所以放在最后，ConstraintLayout能减少布局渲染的层级，也能起到一定的优化作用。

具体使用方式可以参考Google文档：
https://developer.android.google.cn/training/constraint-layout?hl=zh_cn

二.崩溃/ANR/OOM

1.崩溃

崩溃的问题是运行时所产生的，并且会抛出Exception，最常见的就是空指针，数组越界等异常了，如果是调试过程中出现崩溃，我相信稍微有一些基础的同学都知道如何去解决问题，在logcat中搜索AndroidRuntime即可，解决起来根据错误提示修复即可，如果非调试状态，而是在线上，那我们就需要日志的采集了，崩溃日志采集一般本地化做的话，徒增了很多的工作量，我比较推荐友盟的移动统计U-App来采集日志，使用方法见下文

2.ANR

ANR的表现在老的Android版本上会弹出一个提示框（应用已停止），但是现在主流的版本一般都是直接闪退了，ANR的处理方式比较复杂，需要根据堆栈的溢出信息来逐步分析，表现如图

负责更新界面的应用主线程无法处理用户输入事件或绘制操作，这样会引起用户的不满，所以系统会根据当前的场景等待，等待超时则停止响应，一般以下几种情况会导致ANR。

1.当您的 Activity 位于前台时，您的应用在 5 秒钟内未响应输入事件或 BroadcastReceiver（如按键或屏幕轻触事件）。
2.虽然前台没有 Activity，但您的 BroadcastReceiver 用了相当长的时间仍未执行完毕。

Android 提供了一些方式来帮助我们分析出问题，详情可以查看下官方的文档
https://developer.android.google.cn/topic/performance/vitals/anr?hl=zh-cn

当然，关于线上的App出现问题，我们就需要借助友盟的U-App来采集日志，才方便我们分析问题，使用方法见下文。

3.OOM

OOM内存溢出，出现的情况大多数是在引用图片上出的问题，全称“Out Of Memory”,最常见的OOM情况有以下三种：

java.lang.OutOfMemoryError: Java heap space
java堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
java.lang.OutOfMemoryError: PermGen space
java永久代溢出，即方法区溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。
java.lang.StackOverflowError
不会抛OOM error，但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。

我们通常使用heapdump来分析内存的波形查找问题，当然，我们也可以先采集日志，见下文