Epoxy——RecyclerView的绝佳助手

Posted 2023-03-03

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Epoxy——RecyclerView的绝佳助手相关的知识，希望对你有一定的参考价值。

参考技术A

android真响应式架构系列文章：

Android真响应式开发——MvRx
Epoxy——RecyclerView的绝佳助手
Android真响应式架构——Model层设计
Android真响应式架构——数据流动性
Android真响应式架构——Epoxy的使用
Android真响应式架构——MvRx和Epoxy的结合

什么是Epoxy？ Epoxy 是Airbnb开源的一个库，主要帮助我们构建复杂的RecyclerView，使用Epoxy可以让我们在毫无感知的情况下构建出复杂的多ViewType的RecyclerView。这么形容这个库有点太平淡了，实际上Epoxy是响应式框架MvRx的重要组成部分，是实现响应式界面的关键（强行安利， MvRx 是Airbnb开源的一个另一个库，简单来说它是一套Android响应式MVVM开发框架，具体可以查看 Android真响应式架构——MvRx ）。
我因为使用MvRx而接触到这个库，由衷地觉得其异常强大，大大简化了界面的开发。但是这么个强大的库，在国内几乎没啥人知道，也没几篇与之相关的文章，因此我决定写一篇文章来介绍它的使用方式，做个布道者。

试问使用RecyclerView的关键是什么，无外乎两点：

数据是千变万化的，显示更是形形色色的。众所周知，要让RecyclerView显示多种ViewType，还是一件比较繁琐的事。Epoxy的第一个重要作用就是简化了复杂多ViewType的开发流程，使我们专注在数据与显示的绑定上就可以了，剩下的Epoxy会帮我们处理。实际上，无论RecyclerView是单ViewType还是多ViewType，在Epoxy的帮助下，两者对于开发者而言是一模一样的，就是这么的无感。
你以为这就完了，too young。以上只描述了一半，也就是数据不变动的情形，还有另一半内容，即在数据发生变化的情况下，RecyclerView如何更新。又众所周知了，手动跟踪数据的变动然后通知RecyclerView更新是很费劲的，要不然就得无脑地 notifyDataSetChanged ，这都不是我们想要的，理想情况下应该是这样的：

这不是巧了这不是，Epoxy刚好可以帮我们完成上述任务的后两步。我们要做的就是声明数据的变化。

总结：Epoxy的主要作用有两个，第一，简化RecyclerView多ViewType的开发（简化到毫无感知的地步）；第二，如果数据变化，帮我们找出差别，然后做出对应的更新。因此，在Epoxy的帮助下，我们使用RecyclerView的主要任务就变成了：

Epoxy有两个重要组件：

使用RecyclerView绕不开就是数据如何在View中显示的问题，这一步任何库都帮不了我们，必须自己定义。原来我们使用RecyclerView是在 onBindViewHolder 中完成的这一步，在Epoxy中，使用EpoxyModel来完成这一步。当然EpoxyModel的功能还远不止于此。上面提到，Epoxy会帮我们找出“数据”的差别，然后做出对应更新，这里说的“数据”指的就是EpoxyModel。找出“数据”差别的前提就是知晓“数据”的同与不同，也就是说，该“数据”需要有 hashCode 和 equals 方法，刚好，EpoxyModel中有这样的方法。以上是EpoxyModel的作用，关于其定义，下面会有介绍。
EpoxyModel定义了item显示的基础，EpoxyController则决定了item的显示顺序。通过EpoxyController的 buildModel 方法提交“当前状态”下的EpoxyModels，Epoxy会帮我们和上一次EpoxyModels（如果有的话）进行比较，然后更新RecyclerView。如果数据发生变化，调用EpoxyController的 requestModelBuild 方法，EpoxyController的 buildModel 方法会再次被调用，创建“当前状态”下的EpoxyModels，如此反复（注意，不能直接调用 buildModel ）。
可以看出EpoxyController本身就是为了适应/鼓励MVVM的模式。数据只能单向流动：

Epoxy帮我们实现了从数据State到EpoxyModels到RecyclerView显示的黏合，至于如何操纵数据State，以及何时调用 requestModelBuild 方法则取决于我们（推荐MvRx，它完美地解决了这个问题）。

有四种方式可以创建EpoxModel：

这里只介绍第一种推荐的方式。例如，item如下所示：

假如我们已经定义好layout叫 item_lottery.xml ，那么EpoxyModel可以这么定义：

以上就定义了一个基本的EpoxyModel。虽说叫自定义view的方式，但是我们往往都是直接 extends 某个布局，因此为了避免不必要的View嵌套， item_lottery.xml 会这么定义：

使用merge标签作为根。

下面解释一下以自定义View的方式创建EpoxyModel的要点：

完成 LotteryView 这一“自定义View”之后，（构建工程后）Epoxy会帮我们生成一个名为 LotteryViewModel_ 的类，原类名加上 Model_ 后缀，然后 LotteryViewModel_ 就可以在EpoxyController中使用了。

EpoxyModel另一个重要概念是ID。每个EpoxyModel都应该有唯一确定的ID来标识它，这个ID被用来diff和保存state。作为所有Model的基类 EpoxyModel ，它包含了以下方法：

可见生成ID的方法非常多

ID是以64位的 long 值表示的，除了 model.id(id) 这种最直接的方式，其它方式会以hash的方式计算ID，存在冲突的可能性，假如有几百个Model，都使用hash的方式生成ID，那么冲突的可能性是100万亿分之一（可比你写bug的概率小太多了）。可以选择过滤掉ID相同的EpoxyModel，具体内容请查看文档。

EpoxyModel中的属性可以是任意的，不一定非得是primitive type，但是该属性必须提供 equals 和 hashCode 方法，否则会产生编译错误。

属性可以分组：

对于以上的Image属性，我们提供url或者drawableRes就可以了。

上面提到 @ModelProp 注解的方法只能有一个参数，有些情况下需要有多个属性共同决定View的显示，这时可以用 @AfterPropsSet 注解：

还可以为属性提供默认值，或者设定属性为可选的（即可以不设置该属性）。具体可以查看文档。

以你想要的顺序向EpoxyController中添加EpoxyModel，就可以确定RecyclerView中应该显示哪些items。使用EpoxyController的关键在于重写其 buildModel 方法， buildModel 方法只需要根据其调用时刻的数据状态构建EpoxyModels即可。例如：

如上所示，每当数据发生变化时，调用EpoxyController的 requestModelBuild 方法就会通知EpoxyController重新构建EpoxyModels（即 buildModel 方法被调用），完成diff之后，RecyclerView被更新。
如 requestModelBuild 的名称一样，只是请求Model的构建，并不保证构建会立即完成（除了第一次请求），新的请求会取消掉旧的请求（debounced），所以我们不用担心多余的 requestModelBuild ，任意数据的变化都应该发起 requestModelBuild ，不用考虑优化的问题。
每次的 buildModels 都是完全独立的（之前一次的EpoxyModels不会保存），每次都是从空的models列表开始的，所以每次 buildModels 都要构建完整的EpoxyModels列表。
默认情况下构建Models和diff都发生在主线程，显然这可能会引起界面的卡顿（尤其是diff操作），所以应该把他们都放在子线程，有个开箱即用的方式：

如果采用这种方式就要保证在 buildModels 中访问数据是线程安全的，并且不能在该方法中更新View（例如根据数据状态改变title什么的）。也可以选择构建Models仍在主线程，diff放在子线程，可以去查看文档。

为了保证EpoxyController的正确运行，必须保证：

Epoxy提供了一个RecyclerView的子类EpoxyRecyclerView，它使得Epoxy和RecyclerView的结合变得更加简单，推荐使用。
EpoxyRecyclerView做了如下改进：

如果item还在RecyclerView中显示，此时代表该item的EpoxyModel如果更新了，那么只会进行局部的更新，不会更新整个item。以如下界面为例：

假设生成的EpoxyModel叫 PayWayModel_ 。

整体流程如上图所示，其中diff操作会把ID相同的 PayWayModel_ 进行比较，例如从微信支付切换到支付宝支付，前者的check属性从true变为false，前者的check属性从false变为true，其它属性无变化，那么就只有这两个item的CheckBox会刷新，其它的都不会刷新。如果按照我们传统的方式，一般会调用 notifyItemChanged 方法，这会使这两个item重新绑定，item中所有View均会刷新，导致item轻微闪烁，相反，Epoxy的局部更新就不会有这样的问题。

以上以一个实际事例描述了Epoxy的更新流程，在这个例子中，由于 PayWayModel_ 始终只有三个，只是属性会更新，并且一般情况下这三个item会始终显示在RecyclerView中，因此Epoxy会仅仅进行局部更新。不过，diff的功能绝不仅仅是比较相同ID的Model属性的变化这么简单，EpoxyModels的增加、删除甚至是顺序调整都会被diff比较出来，然后做出对应界面更新。

Epoxy是RecylerView的绝佳助手，大大简化了RecyclerView的使用。有了Epoxy的帮助，你会发现RecyclerView的使用范围也被大大扩展了，几乎一切界面的主体部分都可以使用RecyclerView来承载。界面开发就变成了定义一个又一个的EpoxyModel，界面被拆分成一个又一个的EpoxyModel后，界面元素的复用也变得异常简单，整个界面的开发就跟搭积木一样。
如前所述，Epoxy完成了从数据State到EpoxyModels到RecyclerView显示的黏合，至于如何操纵数据State以及通知更新则取决于我们，但是，这并不是一项简单的任务，这也可能是为啥Epoxy并不太流行的原因。还好MvRx帮我们完美地解决了这个问题，所以还是强烈推荐结合 MvRx 一起使用的，你会体验到不同以往的Android开发流程。