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

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

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

1.修改主题/背景图
我们先来看下Activity的结构

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

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

代码如下

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.goo...

二.崩溃/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.goo...

当然，关于线上的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来分析内存的波形查找问题，当然，我们也可以先采集日志，见下文

三.U-APM
1.集成
我们可以使用友盟的APM先把日志采集了，便于我们解决问题，U-APM是在原U-App 稳定性分析基础上全新升级的独立产品,所以已计入的同学直接升级即可：https://at.umtrack.com/LrKb0f

按照文档描述我们来接入，接入的流程步骤如图

1.我们首先在project的build.gradle中添加友盟的仓库，如图示代码

2.在app/build.gradle中添加依赖

3.添加权限

4.初始化，需要先调用预初始化，再调用初始化

好的，一切准备就绪，我们就可以来模拟下错误的采集了，但是要注意，APP_KEY是需要自己去申请的，而APP_CHANNEL对应的是渠道标记，如果没有多渠道，可以无视，如果有多渠道的打包和统计，那么传入对应渠道名即可。

2.使用

来到友盟APM管理平台

可以看到我创建的DEMO显示已集成APM，我来模拟一条空指针的错误

可以看到，实时显示，并且抓到的日志是比较精准的，我们来看下详情

这样就大功告成了，再有崩溃，ANR，OOM都能捕捉到了，而且可以基于友盟的基础能力，我们可以实时统计日活，事件上报等功能，还是蛮不错的。

当然，采集到日志，包括检测到异常，我们拿到日志，都是要自己分析的，这个分析的过程，还是需要个人的经验，以及细心和耐心，解决Bug的道路是枯燥且乏味的，静下心来，才能体验代码之美。

作者：刘桂林
CSDN博客专家，CSDN博客之星，CSDN/慕课网认证讲师，具有多年Android软件开发经验，主要从事车载前装行业，互联网广告行业，精通Android，乐于分享，在网络上发表原创博客文章备受好评，热爱新技术，对技术有着近乎苛刻的要求，讲课语言流畅，思路清晰，口才幽默，已在慕课网发布三门实战课程。

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

目录

2.使用

你可能感兴趣的:(Android性能优化之疑难杂症解决方案,U-APM的性能监控分析)