UploadDbHelp.getInstance().getAllTaskSyn(new UploadDbHelp.DbCallback<UploadInfo>() { @Override  public void getResult(List<? extends UploadInfo> list) { if (list != null && !list.isEmpty()) { addTaskList((List<UploadInfo>) list, false);  } } });

fun getAllTaskSyn(dbCallback: DbCallback<UploadInfo>): List<UploadInfo>? {var list: List<UploadInfo>? = null
    GlobalScope.launch {withContext(Dispatchers.IO) {BNLog.d(TAG, "getAllTaskSyn before")list = getAllTask()BNLog.d(TAG, "getAllTaskSyn after get 线程 ing ：" + Thread.currentThread().name + "大小：" + list?.size)}withContext(Dispatchers.Main) {BNLog.d(TAG, "getAllTaskSyn main " + Thread.currentThread().name)dbCallback.getResult(list)}}BNLog.d(TAG, "getAllTaskSyn return")return list
}

lazy:委托函数

lazy使用:lateinit 只用于变量 var，而 lazy 只用于常量 val

lazy 应用于单例模式(if-null-then-init-else-return)，而且当且仅当变量被第一次调用的时候，委托方法才会执行。

val transferDB by lazy { Room.databaseBuilder( CloudServiceApp.getInstance(),  TransferDatabase::class.java, "transfer.db"  ) .fallbackToDestructiveMigration() .allowMainThreadQueries().build() }

object UserInfoLiveData {val loginEntity: MutableLiveData<UserInfoEntity> by lazy {MutableLiveData<UserInfoEntity>()}
}

1）首先说下RecycleView的缓存结构：

Recycleview有四级缓存，分别是mAttachedScrap(屏幕内)，mCacheViews(屏幕外)，mViewCacheExtension(自定义缓存)，mRecyclerPool(缓存池)

• mAttachedScrap(屏幕内)，用于屏幕内itemview快速重用，不需要重新createView和bindView
• mCacheViews(屏幕外)，保存最近移出屏幕的ViewHolder，包含数据和position信息，复用时必须是相同位置的ViewHolder才能复用，应用场景在那些需要来回滑动的列表中，当往回滑动时，能直接复用ViewHolder数据，不需要重新bindView。
• mViewCacheExtension(自定义缓存)，不直接使用，需要用户自定义实现，默认不实现。
• mRecyclerPool(缓存池)，当cacheView满了后或者adapter被更换，将cacheView中移出的ViewHolder放到Pool中，放之前会把ViewHolder数据清除掉，所以复用时需要重新bindView。

2）四级缓存按照顺序需要依次读取。所以完整缓存流程是：

1. 保存缓存流程：

• 插入或是删除itemView时，先把屏幕内的ViewHolder保存至AttachedScrap中
• 滑动屏幕的时候，先消失的itemview会保存到CacheView，CacheView大小默认是2，超过数量的话按照先入先出原则，移出头部的itemview保存到RecyclerPool缓存池（如果有自定义缓存就会保存到自定义缓存里），RecyclerPool缓存池会按照itemview的itemtype进行保存，每个itemType缓存个数为5个，超过就会被回收。

1. 获取缓存流程：

• AttachedScrap中获取，通过pos匹配holder——>获取失败，从CacheView中获取，也是通过pos获取holder缓存
  ——>获取失败，从自定义缓存中获取缓存——>获取失败，从mRecyclerPool中获取
  ——>获取失败，重新创建viewholder——createViewHolder并bindview。

3）了解了缓存结构和缓存流程，我们再来看看具体的问题
滑动10个，再滑回去，会有几个执行onBindView？

• 由之前的缓存结构可知，需要重新执行onBindView的只有一种缓存区，就是缓存池mRecyclerPool。

所以我们假设从加载RecyclView开始盘的话（页面假设可以容纳7条数据）：

• 首先，7条数据会依次调用onCreateViewHolder和onBindViewHolder。
• 往下滑一条（position=7），那么会把position=0的数据放到mCacheViews中。此时mCacheViews缓存区数量为1，mRecyclerPool数量为0。然后新出现的position=7的数据通过postion在mCacheViews中找不到对应的ViewHolder，通过itemtype也在mRecyclerPool中找不到对应的数据，所以会调用onCreateViewHolder和onBindViewHolder方法。
• 再往下滑一条数据（position=8），如上。
• 再往下滑一条数据（position=9），position=2的数据会放到mCacheViews中，但是由于mCacheViews缓存区默认容量为2，所以position=0的数据会被清空数据然后放到mRecyclerPool缓存池中。而新出现的position=9数据由于在mRecyclerPool中还是找不到相应type的ViewHolder，所以还是会走onCreateViewHolder和onBindViewHolder方法。所以此时mCacheViews缓存区数量为2，mRecyclerPool数量为1。
• 再往下滑一条数据（position=10），这时候由于可以在mRecyclerPool中找到相同viewtype的ViewHolder了。所以就直接复用了，并调用onBindViewHolder方法绑定数据。
• 后面依次类推，刚消失的两条数据会被放到mCacheViews中，再出现的时候是不会调用onBindViewHolder方法，而复用的第三条数据是从mRecyclerPool中取得，就会调用onBindViewHolder方法了。

4）所以这个问题就得出结论了（假设mCacheViews容量为默认值2）：

• 如果一开始滑动的是新数据，那么滑动10个，就会走10个bindview方法。然后滑回去，会走10-2个bindview方法。一共18次调用。
• 如果一开始滑动的是老数据，那么滑动10-2个，就会走8个bindview方法。然后滑回去，会走10-2个bindview方法。一共16次调用。

但是但是，实际情况又有点不一样。因为Recycleview在v25版本引入了一个新的机制，预取机制。

预取机制，就是在滑动过程中，会把将要展示的一个元素提前缓存到mCachedViews中，所以滑动10个元素的时候，第11个元素也会被创建，也就多走了一次bindview方法。但是滑回去的时候不影响，因为就算提前取了一个缓存数据，只是把bindview方法提前了，并不影响总的绑定item数量。

所以滑动的是新数据的情况下就会多一次调用bindview方法。

5）总结，问题怎么答呢？

• 四级缓存和流程说一下。
• 滑动10个，再滑回去，bindview可以是19次调用，可以是16次调用。
• 缓存的其实就是缓存item的view，在Recycleview中就是viewholder。
• cachedView就是mCacheViews缓存区中的view，是不需要重新绑定数据的。

IdleHandler 是 MessageQueue 的静态内部接口。

IdleHandler，这是一种在只有当消息队列没有消息时或者是队列中的消息还没有到执行时间时才会执行的 IdleHandler，它存放在mPendingIdleHandlers队列中。

平时是如何使用的：

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {

@Override

public boolean queueIdle(){

//空闲时处理逻辑

return false;

}

});

从之前的类定义可以看出，返回 false 表示执行后就将该回调移除掉，返回 true 表示该 IdleHandler 一直处于活跃状态，只要空闲就会被回调。