随着Android的发展，在各项功能十分成熟的情况下，我们越来越重视App的性能优化和用户体验，这是关于在线App应用DAU持续增长的基础和用户声誉的问题。 今天，刘先生带大家来分析如何解决崩溃/gxdxxm/ANR/OOM/启动慢等问题，使用友爱性能监测平台U-APM
一、慢启动/白屏幕/黑屏幕优化我们在开发APP应用时，往往会提前初始化一些数据和功能，避免用户在使用过程中出现多余的停留、等待时间。 那么，一个项目非常大的时候，初始化的数据也非常多，而且由于设备的性能、渲染机制等各种原因，经常会出现启动慢、白、黑的画面等。 基于这种情况，我们决定
1 .修改主题/背景图，先看看活动的结构
要更改主题，只需将启动页的主题更改为透明或图像。 这样，在加载ContentView之前，您可以从启动的Activity中看到桌面，而不会出现黑色/白色屏幕。 如果取消标题栏并将Activity设置为全屏，则效果会更好。 缺点是，启动复杂且耗时的活动会有延迟感。
将主题背景设置为一张图像，去除标题栏，并将Activity设置为全屏。 这样可以在加载ContentView之前查看默认背景图，但必须考虑图像的屏幕拟合问题。 主题中的背景图像会自动拉伸，可能会引起扭曲和比例问题。 解决方法是使用. 9的图像。
代码如下
！ -启动页面透明主题， 如果要设置为背景，则窗口后台--style name=' splashstyletransparent ' parent=' theme.test performance ' itemname=' androion item itemname=' Android :窗口完整屏幕' true/item itemname=' Android 3360 navigation barcolor ' @ Android 3360 navigation barcolor ' @ Android item itemname=' Android 3360 statutuatus transparent/item itemname=' window notitle ' true/item item itemname=' Android : windowcontentoverlay ' @ null/item itemname=' Android 3360 windowdisablepreview ' false/item APP的onCreate或启动页的onCreate创建回调初始化，但知道生命周期后很快就会发现实际上，由于onCreate还执行渲染操作，因此可以将初始化行为放入onResume中，但onResume会多次回调，需要做出初始化判断。
代码如下
@Overrideprotected void onResume () { super.onResume )； //因为没有初始化，所以初始化if (！ ThirdSDK.getInstance(.isinit ) ) thirdSDK.getinstance ).init )； }3.子线程初始化如果不需要在主线程中使用或不需要快速初始化，可以通过在子线程中初始化快速调用的函数来优化大量函数的初始化
代码如下
publicclassbaseappextendsapplication { @ overridepublicvoidoncreate (} { super.oncreate )； //对于多进程，在主进程中只初始化一次if(commonutils.ismainprocess () { new Thread ) ) (- { if )！ ThirdSDK.getInstance(.isinit ) ) thirdSDK.getinstance ).init )； () ).start )； } }} 4.ConstraintLayout约束布局已经成为Android Studio官方模板中的默认父布局，您可以看到它的地位。 约束布局
可以使用非嵌套的平面视图层次结构创建复杂的视图
大型布局。它与 RelativeLayout 相似，其中所有的视图均根据同级视图与父布局之间的关系进行布局，但其灵活性要高于 RelativeLayout，并且更易于与 Android Studio 的布局编辑器配合使用。 他针对的不光是启动页的优化，所以放在最后，ConstraintLayout能减少布局渲染的层级，也能起到一定的优化作用。具体使用方式可以参考Google文档：
https://developer.android.google.cn/training/constraint-layout?hl=zh_cn
崩溃的问题是运行时所产生的，并且会抛出Exception，最常见的就是空指针，数组越界等异常了，如果是调试过程中出现崩溃，我相信稍微有一些基础的同学都知道如何去解决问题，在logcat中搜索AndroidRuntime即可，解决起来根据错误提示修复即可，如果非调试状态，而是在线上，那我们就需要日志的采集了，崩溃日志采集一般本地化做的话，徒增了很多的工作量，我比较推荐友盟的移动统计U-App来采集日志，使用方法见下文
2.ANRANR的表现在老的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.OOMOOM内存溢出，出现的情况大多数是在引用图片上出的问题，全称“Out Of Memory”,最常见的OOM情况有以下三种：
java.lang.OutOfMemoryError: Java heap spacejava堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。java.lang.OutOfMemoryError: PermGen spacejava永久代溢出，即方法区溢出了，一般出现于大量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的道路是枯燥且乏味的，默默的河马，才能体验代码之美。