前言
前一片文章讲了Systrace的基本用发，本片文章讲解通过一个例子的分析，如何在生成的trace信息中找到你想要的内容。
一. App启动方式以及启动流程
1.1 App启动方式
1>冷启动：app没有启动过或者进程被杀死，系统不存在该app进程，此时启动为冷启动。
2>热启动：app进程只是出于后台，系统只是把它从后台带到前台，展示给用户。
1.2 App启动流程
上图来自https://my.oschina.net/jdking/blog/3019829/print
大致就是Lancher与AMS通信，AMS检查是否存在当前启动的进程；如果对应进程不存在，AMS与Zygote通信，Zygote孵化出来新进程；新进程中ActivityThread的main方法执行，加载资源，启动looper等，最后渲染出帧，完成应用的启动。
二. App启动的trace分析
这里只讲一下冷启动的方式，热启动类似，上篇文件文章也将了如何抓起这个过程的trace信息，这里我们简单说一下，在点击应用图标的之前，我们需要打开DDMS，将Systrace的设置选项勾选好之后，点击ok，接着点击app图标，完全启动几秒之后，我们找到对应生成的trace.html文件用Google Chrom打开，我这里如下图（以下截图是Pixel(API:R)模拟器抓取的trace）
首先我们从Luncher的进程开始分析，Luncher向AMS发送打开应用的的Event事件，AMS检查目标进程还没有启动，请求Zygote孵化新进程，ActivityThread发起bindApplication同时加载对应apk资源，最后启动Activity
如想了解具体启动流程可以参考这篇文章
http://www.manongjc.com/article/25244.html
接下来就是开始渲染对应应用的UI啦，Systrace以每一针的方式展示出来，我们看下面的图，在冷启动的方式下到界面完全显示出来，大约花了575ms，在正常启动时间的范围内（应用冷启动1m的规定内）
总结
如果在启动的过程花费了很长时间，超出了规定的1m，我就可以通过这个流程，查看没一段执行的时间，分析那一个环节出现了比较耗时的操作，更方便的定位问题的根本原因。
当让Systrace在分析UI卡顿上可能会更有优势，后续会给大家分享一片关于UI卡顿的分析
