App启动卡慢会影响一个App的卸载率和使用率。启动速度快会给人一种轻快的感觉，减少用户等待时间。如果一个App从点击桌面图标到看到主界面花了10秒，请问你能接受么？忍耐不好的估计直接就卸载了，或者没等打开就直接Home键按出去，然后杀进程了。这样一来App卸载率提升了，使用率下降了。所以对于有大量用户的App来说，这些性能细节是很重要的，毕竟用户就是钱啊。
三、启动速度优化方案
3.1减少应用启动时的耗时
针对冷启动时候的一些耗时，如上测得这个应用算是中型的app，在冷启动的时候耗时已经快700ms了，如果项目再大点在Application中配置了更多的初始化操作，这样将可能达到1s，这样每次启动都明显感觉延迟，所以在进行应用初始化的时候采取以下策略：
· 1、在Application的构造器方法、attachbaseContext()、onCreate()方法中不要进行耗时操作的初始化，一些数据预取放在异步线程中，可以采取Callable实现。
· 2、对于sp的初始化，因为sp的特性在初始化时候会对数据全部读出来存在内存中，所以这个初始化放在主线程中不合适，反而会延迟应用的启动速度，对于这个还是需要放在异步线程中处理。
· 3、对于MainActivity，由于在获取到第一帧前，需要对contentView进行测量布局绘制操作，尽量减少布局的层次，考虑StubView的延迟加载策略，当然在onCreate、onStart、onResume方法中避免做耗时操作。
遵循上面三种策略可明显
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
提高app启动速度。
优化应用启动时的体验
对于应用的启动时间，只能是尽量的避免一些耗时的、非必要的操作在主线程中，这样相对可以缩减一部分启动的耗时，另外一方面在等待第一帧显示的时间里，可以加入一些配置以增加体验，比如加入Activity的background，这个背景会在显示第一帧前提前显示在界面上。
1、先为主界面单独写一个主题style，设置一张待显示的图片，这里我设置了一个颜色，然后在manifest中设置给MainActivity：
//…
android:name=".MainActivity"
android:label="@string/app_name"
android:theme="@style/AppTheme.Launcher">
2、然后在MainActivity中加载布局前把AppTheme重新设置给MainActivity：
@Override
protected void onCreate(Bundle savedInstanceState) {
setTheme(R.style.AppTheme);
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
这样在启动时会先显示background，然后待界面绘制完成再显示主界面：
3.2Glide及其他图片框架
Glide是一个很好用的图片加载框架，除了常用的图片加载、缓存功能以外，Glide支持对网络层进行定制，比如换成OkHttp来支持HTTP 2.0。不过，如果在追求启动速度的情况下，在Splash页或主界面加载某一张图片时，往往是第一次使用Glide，由于Glide没有初始化，会导致这次图片加载的时间比较长（不管本地还是网络），特别是在其他操作也在同时抢占CPU资源的时候，慢的特别明显！而后面再使用Glide加载图片时，还是比较快的
Glide初始化耗时分析：Glide的初始化会加载所有配置的Module，然后初始化RequestManager（包括网络层、工作线程等，比较耗时），最后还要应用一些解码的选项（Options）
解决方案：在Application的onCreate方法中，在工作线程调用一次GlideApp.get(this)
override fun onCreate() { super.onCreate() // 使用Anko提供的异步工作协程，或者自行创建一个并发线程池
doAsync {
GlideApp.get(this) // 获取一个Glide对象，Glide内部会进行初始化操作
}
}
3.3TraceView的使用 - 数据采集与数据分析
TraceView是什么，TraceView 是 Android平台特有的数据采集和分析工具，主要用做热点分析，找出最需要优化的点。TraceView 从代码层面分析性能问题，针对每个方法来分析，比如当我们发现我们的应用出现卡顿的时候，我们可以来分析出现卡顿时在方法的调用上有没有很耗时的操作，通过TraceView，可以得到两种数据。
· 单次执行最耗时的方法
· 执行次数最多的方法
要打开上面的面板，代码中一般有两种方式:
· 第一种方式:
- 首先选择跟踪范围，在想要根据的代码片段之间使用以下两句代码
Debug.startMethodTracing(“hello”);
Debug.stopMethodTracing();
生成的traceview文件会自动放在SDCARD上，没有SDCARD卡会出现异常，所以使用这种方式需要确保应用的AndroidMainfest.xml中的SD卡的读写权限是打开的，其中hello是traceview文件的名字，
- 然后用adb导出traceview文件。
adb pull sdcard/hello.trace C:UserslwfDesktop
2. 然后启动Android Device Monitor–>File–>openFile,打开traceview文件即可。
· 第二种方式:
1.同样是要先打开Android Device Monitor
2.先选择应用进程，然后点击Start Method Profiling（开启方法分析），按钮会变为Stop Method Profiling（停止方法分析），开启方法分析后，对应用的目标页面进行测试操作，测试完毕后停止方法分析，界面会自动跳转到 DDMS 的 trace 分析界面。
两种方式的对比：第一种方式更精确到方法，起点和终点都是自己定，不方便的地方是自己需要添加方法并且要导出文件，第二种方式的优缺点刚好相反。
四、总结
