界面

界面非常简单，如下图

界面非常简单，但因为一些效果显示的问题，套了六层的布局(老项目接手，这是一个坑，听说上一个Android开发是后端转过来的)。

效果，当屏幕向上滚动时，tab最后要悬停在顶部，不用关注的地方的布局比较复杂，单纯的LinearLayout不能满足需求，再加上可能不会使用ConstraintLayout，所以嵌套了六层布局，使用起来不会感觉卡顿，所以在接手时没想着优化。

场景复现

当data数据量比较大的时候，点击tab更新recyclerview的数据的时候，发现tab的下划线的动画出现0.1秒的卡顿现象。

如下图所示

在第三个第四个标签之间切换的时候，因为第四个标签下的数据量非常大，会导致下划线动画出现卡顿现象。

下图是开启GPU渲染模式时切换两个标签

可以看到在切换两个标签的时候，柱状图陡然拔高。现在，就需要优化这个问题。

其实也不算是BUG，只是一个影响体验的优化。

这里首先要确认到底是哪个地方这么占资源，什么地方这么的绘制需要这么多帧。

从代码的逻辑可以看到，点击tab后，tab的字体加粗，同时网络请求接口获取recyclerview的数据，释放tab后字体变回普通。

我用本办法，把网络请求的部分注释了，不卡顿了。//因为从代码逻辑上大概能猜出来是哪个地方比较耗费资源。

那么，大概就应该知道了，是recycleview加载数据和tab动画同时在占用资源导致卡顿的原因。

item的布局是RelativeLayout嵌套两个LinearLayout实现的，两个LinearLayout一个横向一个纵向。这个简单，把最外层换成ConstraintLayout就可以了。

重新运行，发现切换的时候仍然会卡顿一下。

点击tab调用网络请求接口，然后根据接口获得的数据刷新列表，那么，将接口数据缓存下来，减少网络请求的消耗。

不过这个直接被产品pass了，因为列表的数据需要实时。

既然是因为tab动画和网络请求+recyclerview数据刷新同时占用资源，那么，把网络请求延后100ms，这样同样能解决卡顿问题。

scss 复制代码

CoroutineScope(Dispatchers.IO).launch {
    delay(100)
    mPresenter.getData(position)
}

实测过来发现，tab动画不会卡顿，同时列表加载数据也是正常的。这么完美的方案，产品不同意。

产品提出，取消tab的动画效果，这样也能处理卡顿效果。

但是，网上的文章都是tablayout+viewpager结合的例子，取消动画用的也是viewpager.setCurrentItem(position, false)这个方法。

这就又引出另一个问题了--为什么都用到tablayout了，为什么不跟着用上viewpager+fragment+recyclerview，而是仅仅只使用了一个recyclerview呢？

这里还有一段故事，具体不细说，大概就是，二级页面触发进程回收，回到一级页面后发现ViewPager显示空白，无法创建Fragment。没有具体的细节了，因为当时忘了记录下来。

虽然没有tab的取消动画效果的方法，不过，可以取巧设置tab的动画时间为0，app:tabIndicatorAnimationDuration="0"，同样也能实现取消tab动画效果的结果(我真是机智).

recyclerview还有一个DiffUtil，不过因为紧急上线的缘故没有用。同样的，也可以对网络请求的数据进行分页处理。