所有一切众生之类：若卵生若胎生若湿生若化生；若有色若无色；若有想若无想若非有想非无想，我皆令入无余涅盘而灭度之。如是灭度无量无数无边众生，实无众生得灭度者。

                                                                                                                                ----佛说

代码优化

在构建APP时，我们经常需要应用一些第三方的SDK，而项目业务越多，引用的第三方也越多，有些第三方库会要求我们在Application的oncreate方法中对其初始化，着意味着：在Application的oncreate方法中执行时间越长，首个activity布局渲染的时间也会相应的拉长。同理，如果我们在首个activity的oncreate，onstart,onResume方法中执行的任务时间过长，同样也会导致布局的渲染时间越长。这样直接导致的问题就是，用户感觉页面迟迟没有加载出来，用户体验极差。

App启动时间的检测

adb shell am start -W com.example.test/.SplashActivity

运行结果

TotalTime:一系列Activity启动的时间

WaitTime:总启动时间，包含系统在冷启动时，需要加载App信息到内存的时间

通过以上命令可以检测Activity的启动时间，一般情况下开发者只需要关注TotalTime，因为TotalTime这个时间是可控的，而WaitTime是系统在冷启动时，需要加载App信息到内存的时间这个时间开发者是不可控的。如果通过以上方式发现APP的启动时间没有在一个合理的范围之内那应该怎么定位到底是哪个代码出了问题呢？？？？？？

问题代码定位

示例代码

通过Debug.startMethodTracing（）方法和Debug.stopMethodTracing();方法包裹业务逻辑代码块，当代码执行完毕的时候会生成一个app.trace文件，通过命令adb pull /storage/emulated/0//Android/data/com.example.test/files/app.trace 将生成的文件导入到项目下面。

将工程目录下面生成的app.track文件拖入到AndroidStudio，可以将app.track的信息读取出来，会显示如下页面

Cpu usage details unavailable区域代表整个APP方法的调用情况，向右拖动可以截取某一段代码片段查看

Call Chart模块图分析，第一行显示的init方法的调用以及test方法调用的耗时情况，由前面的代码示例可以看出init方法调用了a方法，a方法调用了b方法和方法总共耗时3.2，此时Call Chart分析模块第一行显示init方法耗时3.2s，test方法耗时200ms，第二行显示调用的a方法，因为在init方法里面只调用了a方法，a方法里面先是睡眠500ms，紧接着又调用了b方法和test方法，所以耗时跟init方法一样也是3.2s....依次分析，如果觉得上图的分析不够直观也可以切换到Top Down模块进行分析，如下图

通过以上的分析，我们已经可以很准确的定位到那些代码是比较耗时的，针对耗时的代码我总结了如下的解决方案。

一  针对初始化比较耗时的代码，我们可以通过异步线程的方式对其进行初始化。

异步初始化代码需要注意：

1在异步线程中调用的初始化的API不允许创建Handler

2 不能有更新UI的操作。

3 对异步要求不高，（什么叫对异步要求不高？？？？？，比如说我们在A acitvity里面做一个对数据的处理，A activity处理完数据以后要跳转到B activity，B activity需要拿到A activity的数据，那如果我们的A activity在处理数据的时候使用的是这样一个异步线程，这个时候很有可能导致在做页面跳转的时候异步线程还没执行完毕导致B activity，拿不到数据从而出现异常）

二 针对初始化比较耗时的代码，我们可以通过懒加载的方式对其进行初始化。

什么是懒加载？就是在使用的时候对其进行初始化，什么时候用什么时候初始化，没必要在程序刚开始启动的时候就对其进行初始化。