- 应用启动速度慢
- 页面加载慢
- 交互卡顿
- Crash
- ANR
针对这些问题，可以逐一进行优化
1.启动优化
Android应用启动分为冷启动和热启动以及初次安装启动，此处只分析冷启动及热启动
冷启动：当设备无该应用进程时，用户操作拉起应用，Android系统会先给应用创建进程，然后创建Application（每个应用进程有且仅有一个Application），并在完成Application相关任务之后才会拉起对应Activity，然后渲染Activity界面，完成冷启动
热启动：即冷启动后，用户推出应用所有页面（Activity）回到设备桌面，此时正常情况下系统不会立马杀掉进程及Application，还会保留一段时间，此时再拉起应用，系统直接初始化对应Activity页面，不会再创建Application，这就是热启动。所以，热启动一定比冷启动速度更快
了解了Android应用的启动机制，就可以针对性优化。
首先需要明确一个启动优化的和核心思想：启动过程中尽量少做事。根据这个思维逻辑进行优化。
冷启动，创建进程，这是系统的事，我们干预不了，那就要在Application中做文章。
随着应用的业务日益复杂，使用到的模块日益增多，就可能会有越来越多的模块在Application中完成，这些模块任务也是导致应用启动速度慢的原因之一，为此，我们总结了几条优化经验：
- 必要且耗时的，考虑放到子线程中处理
- 非必要且耗时的，考虑使用异步加载或按需加载，即使用到了再去执行对应模块任务
接下来是Activity的启动加载，这是冷启动、热启动都需要处理的事情。根据activity的生命周期，我们知道，activity要执行到onResume方法页面才算启动完成并显示，所以需要对其前面的生命周期方法减少耗时，根据这个逻辑，我们就到了第二条需要优化的方面，即页面加载慢问题优化
2.页面加载慢优化
根据前面叙述，我总结了几条优化经验，欢迎补充
- 使用懒加载：针对主页UI比较复杂的应用，考虑使用懒加载的方式，比如，典型的页面由Tab+Viewpager+Fragmeng组成，启动时只加载当前可见的Fragment数据，其他Fragment使用懒加载方式加载
- 减少页面布局层级：合理使用RelativeLayout和LinearLayout等容器布局，比如：LinearLayout加载效率要高于RelativeLayout，那在布局层级相同的情况下，就使用LinearLayout，但有时使用LinearLayout时可能会比使用RelativeLayout多几个层级，综合考虑之下，就需要使用RelativeLayout比较合适，此外，针对自定义控件，我们还可以考虑使用merge标签减少布局层级。
- 提高显示速度：使用ViewStub标签，按需加载，仅加载我们需要显示的UI。ViewStub是一个轻量级的View，它是一个看不见的，并且不占布局位置，只有ViewStub会被初始化，然后当ViewStub被设置为可见时，或是调用了ViewStub.inflate()时，ViewStub所指向的布局才会被加载和实例化，然后ViewStub的布局属性都会传给它指向的布局。
- 避免过度绘制：移除xml中非必要的背景，移除Window的默认背景以及按需展示背景图片
3.交互卡顿
应用启动后用户肯定是需要交互的，交互的过程中如果出现页面卡顿，比如：页面滑动不流畅、点击事件响应迟钝等问题，就有必要对此进行优化，对此，我也总结了几条优化经验
-
合理的刷新机制：减少UI的刷新次数，比如，刷新进度条，在符合产品要求的基础上，只有在进度变化>=1时进行进度刷新，否则拦截刷新操作；然后，避免后台线程影响前台操作，比如在一个带有图片的列表中，用户正在滑动列表，滑动过程中可以考虑暂停列表中图片的下载和加载，等滑动停止后再恢复；最后是减少刷新区域，比如删除操作一个Item，UI刷新控制在当前Item区域
-
提升动画性能：优先考虑使用属性动画完成需求，属性动画相比补间动画有更好的性能，然后尽量少用帧动画，帧动画非常吃内存，特别是图片多而且大的时候
-
其他基本的，不要在主线程执行耗时任务，数据一次性不要加载过多，使用懒加载方式，分页加载
4.Crash
安卓应用程序crash主要有两大因素
1.内存溢出（OOM）导致crash。需要知道，Android应用也是一个Java程序，所以也是运行在Java虚拟机里的。而虚拟机分配给我们应用的内存也是有限的，所以，当应用使用的内存占用超过了虚拟机分配使用的内存，就会造成内存溢出，进而导致程序异常（Crash）。所以作为开发者就有必要关注程序运行过程中内存的使用。另外，内存的高占用还会导致频繁的GC操作，导致内存抖动，GC期间还会影响到工作线程使其停顿，也就间接导致了应用的卡顿，此时就涉及内存的优化。内存的优化涉及好多方面，包括如内存泄漏处理、图片内存优化等
2.程序设计逻辑缺陷导致crash，这个没什么说的，暴露一个修改一个，开发者开发时多注意按开发质量要求进行。
5.ANR
ANR，即应用无响应，这也是我们开发中容忍度比较低的一个问题，总的 来说，引起ANR的根本原因有以下两种：
1.应用程序自身有逻辑缺陷，或者在某些异常场景触发了此缺陷，导致的ANR，比如主线程执行了耗时任务、主线程阻塞、死循环、死锁等，针对这些问题导致的ANR，一般可以通过trace日志查看堆栈就可以定位出问题代码，一样地，这种问题发现一个改一个。另外，有一个常见的因系统层的问题导致的ANR，我们是不好处理的，就是Binder响应不及时，这种问题据我所知应用层没有比较好的解决方法（若某位大佬清楚，望告知）
2.由于Android设备其他进程导致的CPU占用高，导致当前应用进程无法抢到CPU时间片，导致了ANR，这类ANR与设备硬件属性有关，应用层没有太多的操作空间
