对于Android的性能这方面评估,大部分都是有超级兔子去比跑分的,还是不能反映全面的问题。就我知道的而言,应用启动时间是很影响用户体验的一个性能方面问题。 最近的一个项目,别人都说应用启动慢,我师傅看我没什么事,叫我看一下。以前也看过一次,但那次是当学习,只是看看整流程是怎么走的,这次确不一样了。开始的一天,按以前的方式再看了一下,感觉没有什么异常的地方,不过时间确实比对比机慢了很多,但不知道是时间是发哪块了。从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最复杂的一块,管他呢,玩玩而已!
阅读(345) | 评论(0) | 转发(0) |