冷启动的流程_wmshell.main

U的流程

第一个阶段从点击事件到添加startingwindow

1.System_server 进程中找iq泳道，点击事件会分发到桌面。

2.桌面进程看主线程处理点击执行binder调用，对端是System_server .execeteActivity.

通过异步binder 调用prev_addStartingWindow. 添加启动页窗口。

3.startingwindow绘制一帧后。通过异步binder 触发WMS 大的刷新。

第二阶段 System_server 唤醒 launcher 远程动画流程

1.onTransitionReady 会通过异步binder调用SystemUi子线程执行AIDL::java::ITransitionPlayer::onTransitionReady::server方法。该方法会唤醒SystemUI 里面的wmshell.main线程。该线程通过异步调用桌面的AIDL::java::IRemoteTransition::startAnimation::server.该线程会唤醒桌面UI线程执行远程动画.

第三阶段 执行桌面远程动画 从trace看时间为750ms.

和桌面沟通动画时间太长了进行了修改。原来的适中 760ms ，现在的适中 460ms。原来的增强  570ms，现在的增强  405ms 。动画波动一两帧属于正常范围。

第四阶段移除startingwindow

桌面远程动画的最后一帧会唤醒桌面UIThreadHelper线程，该线程唤醒SystemUI子线程，唤醒systemui中的wmshell.main线程。该线程会唤醒ll.splashscreen 执行MSG_DIE 移除Startingwindow。

第五阶段移除startingwindow 动画

对端 AIDL::java::IWindowSession::remove::server ，移除Startingwindow 会执行一个窗口移除动画。150ms 的透明度从1.0到0.0的动画。因为是透明度变化的动画，不用等到动画结束人眼就可以看到main window的出帧。

也就是说冷启的时间是从iq抬手到移除splashscreen 动画结束前的两帧左右作为冷启的结束点。这个过程的时间做为用户对冷启的感知时间。（startingingwindow 的窗口层级高于应用window ）

T的流程和上面的流程有三个差异

1.桌面远程动画的触发。APPTransitionReady 调用桌面子线，该线程调用桌面主线程触发远程动画

2.远程动画时间

3.startingwindow的移除在应用绘制第一帧后触发

1.后面遇到冷启问题看Android App StartUps 泳道 的应用冷启时间小于startingwindow 移除动画的倒数第2帧。将不再是问题。

2.远程动画时间的修改同样会影响热启动和Home键back键侧边手势退出回桌面的时间。

3.上面分析U的trace是StartUps 泳道 的应用冷启时间小于远程动画的时间。应用冷启的时间超过动画的问题目前还没有分析样本。后面遇到再补充

4.T上因为是首帧绘制后移除startingwindow。如果冷启时间很快。会遇到一种情况就是远程动画还未结束就开始移除startingwindow。这样动画时间会有一段重叠。后面遇到再补充。