更优秀的延迟初始化方案

1、

2、

3、

背景：梳理了application和mainactivity的代码之后，有些任务，它的优先级其实并没有那么高，所以，可以将它进行延迟初始化。延迟到界面显示后再进行加载。

最简单的方案是将代码移动到界面显示之后，界面显示之后再进行调用。

或者使用new Handler().postDelayer(),延迟发送一个消息

4、

常规方法在代码中的实现：

界面显示第1帧才算是界面第一次加载完成。例如，在这个地方加埋点，进行上报等等一些操作。

 

添加界面第一次显示后的回调

 

其次，给adapter添加界面第一次显示后的回调方法

5、

在mainactivity中进行方法的调用

 

在onFeedShow()中模拟进行了一系列的操作

 

在adapter中，会看一下是否有设置监听，如果有的话，会回调这个方法

 

这样的代码最主要的问题时，adapter中回调onFeedShow()方法后，发生在主线程，如果在mainactivity中的onFeedShow()方法花费了10s中执行任务，那么任务就会卡在这里10s钟。如果用户打开首页之后，想马上进行滑动，不管是左滑、右滑还是上下滑动，此时会发现应用滑动不了，也就是说，这个性能体验存在一个问题是，界面打开了，应用启动了，但是，界面滑动不了，给用户的体验也。非常差。那这些卡顿可不可以经过一些优化呢？当然可以，这里可以通过postdelay这样的方式发一个消息，这个消息通过handler发送出去，延时100ms，这种方式是可以的。但是，真正来想象这样一个问题，这种方式有没有什么问题？假设onFeedShow()有100行代码，然后对前10行代码postDelay()100ms,对第10行到第100行代码postDelay()200ms,在一定意义上确实缓解了一些卡顿，但是，一是这种方式不够优雅，第二，它的可维护性比较差。

6、

7、

8、

更优方案在代码中的执行

通过idleHandler对onFeedShow()中的代码进行执行

分批执行，每次只取出一个任务，只取出一个任务的好处是占用系统的cpu是非常非常短暂的。

addTask()方法DelayInitDispatcher自己，方便继续添加任务，任务都被添加到了队列当中。queueIdle()方法会在系统空闲时自动调用该方法。

 

queueIdle()方法返回false，系统就会将handler移除，如果返回ture，就一直保留。所以返回值根据delayTask是否为空进行判断，如果为空，则移除，不为空则需要idlehandler继续存活下去。

 

添加开启任务执行的方法

 

在代码中开启任务的延迟执行

 

如果不使用空闲任务的话，任务A如果需要执行200ms，那么就会卡顿200ms。但是如果使用DelayInitDispatcher的话，是add了两个任务进来，同时对这两个任务进行了分别的处理。真正的执行时机是系统空闲的时候，也就是说用户在某个滑动过程中停下来了，才会去执行任务。

9、

有效缓解卡顿的原因，第一个是，每次只执行一个task，比如，一下add进去100个任务，不会像之前那种常规的方式，一下全部执行，一次只执行1个。第二点是，即便是只执行一个，也是在系统空闲的时候执行的，所以，不会在用户滑动过程中去执行，使用户感觉卡顿。

10、

将任务延迟初始化，可能会造成当界面展示出来了，但是造成用户不能操作界面。