Android性能优化第（八）篇---App启动速度优化之耗时检测处理

应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？

成都创新互联是一家专业提供云南企业网站建设,专注与成都网站设计、成都网站建设、HTML5、小程序制作等业务。10年已为云南众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。

2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。

3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

执行成功后将返回三个测量到的时间：

这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。

总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。

从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。

Application的构造器方法——attachBaseContext()——onCreate()——Activity的构造方法——onCreate()——配置主题中背景等属性——onStart()——onResume()——测量、布局、绘制显示在界面上。

因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些 不得以的任务 又必须在UI显示之前执行。所以我们要将 任务 划分优先级。

对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。

极力推荐用第二种，在窗口完成以后进行加载，这里面的run方法是在onResume之后运行的。关于这种懒加载机制，参考 Android应用启动优化:一种DelayLoad的实现和原理(上篇) ，给出了详细的解释。

通过上面我们知道一种懒加载机制，所以我们可以将Application中和首页的onCreate中的有些耗时任务，放到首页渲染完毕后加载。如何找出这些耗时任务，TraceView就派上用场了，TraceView的用法，移步我的前面的博客 Android性能优化第（六）篇---TraceView 分析图怎么看？

比如在首页的onCreate中我们进行了用户启动上报，这个进行懒加载是不是分分钟减少139毫秒呢？

在比如在Application里面用到了GSON，将String转化成json,我将这个移动到懒加载里面，是不是又减少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用户又不会一打开App就要支付，放在Application中加载干嘛？

此处我们这里举得例子是优化了139毫秒和100毫秒的，其实真正耗时的任务有的有1秒多，都被我优化完了，所以trace图中看不到了，就举个了这两个例子，还有SharedPreferences也是耗时大户，经过检测保存一个boolean变量耗时120+毫秒以上。

利用TraceView可以清楚我们每一个方法的耗时时间，极大的帮助了我们做优化工作。

五、优化思路总结

1、UI渲染优化，去除重复绘制，减少UI重复绘制时间，打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；

2、根据优先级的划分，KoMobileApplication的一些初始化工作能否将任务优先级划分成3,在首页渲染完成后进行加载，比如：PaySDKManager。

3、主线程中的所有SharedPreference能否在非UI线程中进行，SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。

4、检查BaseActivity,不恰当的操作会影响所有子Activity的启动。

5、对于首次启动的黑屏问题，对于“黑屏”是否可以设计一个.9图片替换掉，间接减少用户等待时间。

6、对于网络错误界面，友好提示界面，使用ViewStub的方式，减少UI一次性绘制的压力。

7、任务优先级为2，3的，通过下面这种方式进行懒加载的方式

8、Multidex的使用，也是拖慢启动速度的元凶，必须要做优化。后面有空专门写一篇Multidex。

相关链接：

Android应用启动优化:一种DelayLoad的实现和原理(上篇)

Android性能优化之加快应用启动速度

手机淘宝性能优化全记录

Android客户端性能优化（魅族资深工程师毫无保留奉献）

Please accept mybest wishes for your happiness and success !

Android开发 ：Fragment懒加载的几种方式与性能对比

TabLayout+ViewPager+Fragment是我们开发常用的组合。ViewPager的默认机制就是把全部的Fragment都加载出来，而为了保障一些用户体验，我们使用懒加载的Fragment，就是让我们再用户可见这个Fragment之后才处理业务逻辑。

而我们在一些设备或版本中可能就出现懒加载失效的问题。其实谷歌早就把一些懒加载的方案都标记弃用了，我们一直都用的老的随时会失效的Api。万一哪天彻底失效了就会导致线上事故。

接下来我们就看看Fragment的懒加载是如何演变的。谷歌又是推荐我们如何使用的。

在AndroidX还没出来的时候，大家的懒加载应该都是这样。判断setUserVisibleHint的方法，当用户可见的时候才回调方法去加载逻辑。

例如的我封装：

使用的示例：

扩展方法：

Fragment:

到此就实现了onLazyInitData的回调，只有出现Fragment显示在前台的时候才会调用方法，执行逻辑。

每次判断 setUserVisibleHint 和 onHiddenChanged 也麻烦，并且他们并不稳定，我也遇到过不回调的时候。

Android出来之后，给 FragmentStatePagerAdapter 添加了一个 @Behavior int behavior 的参数。

其本质就是内部帮你处理和切换MaxLifecycle：

如何使用呢：

之前的扩展方法以及预留了 behavior 参数，当为1的时候就不会回调 setUserVisibleHint 方法了，我们直接监听 OnResume 即可。

注意这个页面继承的就不是我们自定义的懒加载Fragment了。普通的Fragment 回调 onResume 即可。

ViewPager2出来之后。我们的 FragmentStatePagerAdapter 退出历史舞台。

即便能用，即便效果还是和ViewPage2的效果一样，但是还是标记废弃了。具体原因我也不知道，据说是因为老版本会出现问题导致数据丢失，页面空白。

ViewPage2我们都知道内部是通过RV实现的。但是对于Fragment的处理有单独的Adapter实现。

扩展方法：

使用：

使用的方式和ViewPager差不多，这里的Fragment也是使用普通的Fragment即可。

内存占用分别取三组数据

ViewPager数据

ViewPager2数据

结论 ViewPager2基于RV实现的效果还是比老版ViewPager要骚好一点。

并且老版本标记废弃，大家如果是用ViewPager2的话，还是推荐使用ViewPager2实现。如果大家还是用的老版本的ViewPager也推荐使用behavor参数。使用 onResume 实现懒加载的实现。以后再换到ViewPager2的话，可以无缝切换过来。

说明一下，测试数据仅供参考，毕竟我也不是专业测试，测试数据源也不不多。如有不对的地方，也望大家指正。

Android 性能优化之启动加速

当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的

windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，

应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。所以，总结一下，应用的启动流程如下：

Application的构造器方法——attachBaseContext()——onCreate()——Activity的构造方法——onCreate()——配置主题中背景等属性——onStart()——onResume()——测量布局绘制显示在界面上。

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。

2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动

1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。

2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application

黑白屏产生原因：当我们在启动一个应用时，系统会去检查是否已经存在这样一个进程，如果不存在，系统的服务会先检查startActivity 中的intent 的信息，然后在去创建进程，最后启动Acitivy，即冷启动。

而启动出现白黑屏的问题，就是在这段时间内产生的。系统在绘制页面加载布局之前，首先会初始化窗口（Window），而在进行这一步操作时，系统会根据我们设

置的Theme 来指定它的Theme 主题颜色，我们在Style 中的设置就决定了显示的是白屏还是黑屏。

1.Application 优化(懒加载,延时加载)

2.UI效果，背景图

3.fragment的懒加载

4.延时加载

安卓中viewpager+tablayout+fragment懒加载怎么做

viewpager的预加载是无法取消的。 但我们可以换一种思路来实现。取消预加载无非就是你的页面没有准备齐全，数据上或其它的还不足以加载一个正确的视图。 你可以对这样的页面只写一个空视图，viewpager需要的List你可以组装好

当前文章：android懒加载,懒加载如何实现
网站路径：http://myzitong.com/article/dsdpogd.html