最近的一个项目，别人都说应用启动慢，我师傅看我没什么事，叫我看一下。以前也看过一次，但那次是当学习，只是看看整流程是怎么走的，这次确不一样了。开始的一天，按以前的方式再看了一下，感觉没有什么异常的地方，不过时间确实比对比机慢了很多，但不知道是时间是发哪块了。从InputReader到ViewRootImpl，从ViewRootImpl到Lanucher startActivity，从Launcher到ActivityManagerService把Activity显示出来，整个流程走了一遍，没有发现异常的地方，小郁闷了一下。

第二天想了一下，觉得不对，自己对比的方式有问题，没有把慢的手机跟对比机都进行相同的操作，导致知道时间慢了，也不知道慢在什么地方了，于是，两款手机我都只进电话界面，并且在两个手机上都打了LOG，发现慢的那款手机怎么都比好的那款手机慢200~300ms，我对比了一下整个时间，发现在AMS的scheduler到displayed　 Activity 时间特别长，确定那段时间是那这段了。

其实这段流程还有好多步骤，要把原来的Activity　OnPause掉,压入Activity Stack,然后在新的Activity显示出来,整个Activity的生命周期都走了一遍,这让群我情何以堪呀！没招，只好采用分的方式，继续打LOG。

历经了千难万险，最后终于发现在ActivityThread.java的 mInstrumentation.callActivityOnPause(r.activity)耗时最长，正常那款机型是不要时间的，而慢的那个手机，确要200~300ms，刚好是整个周期所慢下来的时间，是Lanucher在OnPause的时候慢下来了，在负责Lanucher同事问了下，最近Launcher改什么了，才发现，Launcher在OnPause的时候，做动态壁纸的同事，添加了截屏的代码，要截屏Lancher的Item，以便显示出来。

折腾了两三天，就得到了个这样的结果，幸亏把问题找出来了。做性能的都说，环境一定要一样，我也知道，可惜做起来未必会实行的，要不然第一天就不会白忙乎了！还有一点是重要的，原来二分法真的是那么的神，以前重来没发现过，这次自己是用了一下，效果相当不错呀！把有O(n)的问题变成O(lon)的，看来效率真的会提升很大！

最近对Android GUI很来劲，希望自己好好的学习，能弄明白，听说是Android最复杂的一块，管他呢，玩玩而已！