Epoxy——RecyclerView的绝佳助手

前言

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而接触到这个库，由衷地觉得其异常强大，大大简化了界面的开发。但是这么个强大的库，在国内几乎没啥人知道，也没几篇与之相关的文章，因此我决定写一篇文章来介绍它的使用方式，做个布道者。

Epoxy这个名字起得很有意思，Epoxy的原意是环氧树脂，一听就不是一个常用的单词，环氧树脂的一个重要用途是黏合，我猜起这个名字也是这个意思，黏合数据与item，item与RecyclerView。

1. Epoxy的作用

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

数据是什么
数据如何显示

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

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

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

绑定数据与View（定义数据如何显示）
按照顺序声明数据
数据变化后重新声明数据

2. 基本概念

Epoxy有两个重要组件：

EpoxyModel：描述了某个view如何在RecyclerView中显示
EpoxyController：确定哪些item显示在RecyclerView中

使用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，它完美地解决了这个问题）。

Epoxy比较前后两次EpoxyModels找出差别的过程，以下简称为diff

3. 创建EpoxyModel

有四种方式可以创建EpoxModel：

通过自定义View（推荐的方式）
通过DataBinding
通过ViewHolder
Kotlin可以通过data class直接继承EpoxyModel（非官方方式）

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

item

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

@ModelView(autoLayout = ModelView.Size.MATCH_WIDTH_WRAP_HEIGHT)class LotteryView @JvmOverloads constructor(        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0) : ConstraintLayout(context, attrs, defStyleAttr) {    private val ivLottery by lazy {        findViewById(R.id.ivLottery)    }    private val tvName by lazy {        findViewById(R.id.tvName)    }    private val tvTag by lazy {        findViewById(R.id.tvTag)    }    private val tvPoints by lazy {        findViewById(R.id.tvPoints)    }    init {        //setPadding(...)        inflate(context, R.layout.item_lottery, this)    }    @ModelProp    fun setImgUrl(imgUrl: String) {        //show image with you own way    }    @TextProp    fun setName(name: CharSequence?) {        tvName.text = name    }    @TextProp    fun setTag(tag: CharSequence?) {        tvTag.text = tag    }    @ModelProp    fun setPoints(points: Int) {        tvPoints.text = resources.getString(R.string.points, points)    }    @CallbackProp    fun onClickListener(listener: View.OnClickListener?) {        tvTag.setOnClickListener(listener)    }}

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

<?xml version="1.0" encoding="utf-8"?>

使用merge标签作为根。

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

用@ModelView注解该class，其中的autoLayout = Size.MATCH_WIDTH_WRAP_HEIGHT属性决定了该item加入到RecyclerView时的宽高。
用@ModelProp注解一个方法（方法只能有一个参数）可以为该EpoxyModel增加一个属性，该属性决定了View的某种显示，这就是Epoxy绑定数据与显示的方式。
一个比较特殊的属性是字符串，因为我们经常需要Android String resources的支持。这时可以用@TextProp注解一个方法（该方法参数类型必须为CharSequence），生成的EpoxyModel会包含若干该属性的重载方法，方便我们直接使用Android String resources。
除了属性以外还需要有回调接口，例如OnClickListener。回调接口之所以不同于普通属性，是因为它们并不会影响View的显示，并且需要在item滚动出屏幕之外时解绑（设为null防止内存泄漏），@CallbackProp注解的方法刚好帮我们完成这一切。

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

LotteryViewModel_是扩展自EpoxyModel的子类，包含了我们注解的所有属性，它代表了数据与View的绑定关系。此外，LotteryViewModel_中还包含了equals和hashCode方法（比较我们定义的属性），这两个方法是diff的基础。

3.1 EpoxyModel的ID

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

public EpoxyModel id(long id)public EpoxyModel id(@Nullable Number... ids)  public EpoxyModel id(long id1, long id2)public EpoxyModel id(@Nullable CharSequence key)  public EpoxyModel id(@Nullable CharSequence key, @Nullable CharSequence... otherKeys)public EpoxyModel id(@Nullable CharSequence key, long id)

可见生成ID的方法非常多

//例如来自数据库主键model.id(id)//通过字符串model.id("header")//组合的方式，类似名称空间的概念model.id("photo", photoId)model.id("video", videoId)

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

3.2 更多EpoxyModel的使用

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

//MyObject类必须实现 equals和 hashCode方法@ModelPropfun setImg(param: MyObject) {    //...}

属性可以分组：

/*** 重载的方式*/@ModelPropfun setImage(url: String)@ModelPropfun setImage(@DrawableRes drawableRes: Int)/*** 显式的指定*/@ModelProp(group = "image")fun setImageUrl(url: String)@ModelProp(group = "image")fun setImageDrawable(@DrawableRes drawableRes: Int)

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

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

var point = 0    @ModelProp setvar originPoint: Int = 0    @ModelProp set//在所有属性都设置后调用@AfterPropsSetfun setupPoints() {    val ss = SpannableString("$point $originPoint")    //...    tvPoints.text = ss}

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

4. EpoxyController的使用

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

public class PhotoController extends EpoxyController {   private List photos = Collections.emptyList();   private boolean loadingMore = true;   public void setLoadingMore(boolean loadingMore) {      this.loadingMore = loadingMore;      requestModelBuild();   }   public void setPhotos(List photos) {      this.photos = photos;      requestModelBuild();   }    @Override    protected void buildModels() {      new HeaderModel_()          .id("header model")          .title("My Photos")          .addTo(this); //通过addTo添加到EpoxyController中      for (Photo photo : photos) {        new PhotoModel_()              .id(photo.getId())              .url(photo.getUrl())              .comment(photo.getComment())              .addTo(this);      }      new LoadingModel_()          .id("loading model")          .addIf(loadingMore, this); //选择性添加到EpoxyController    }}controller = new PhotoController();recyclerView.setAdapter(controller.getAdapter());controller.requestModelBuild();

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

public class PhotoController extends AsyncEpoxyController {    //...}

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

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

所有的EpoxyModels必须有唯一的ID
EpoxyModels一旦被添加到EpoxyController之后就不能更改
以上两条是为了保证diff的正常工作，Epoxy也会帮我们验证这两条规则（可以在线上版本时关闭）。

5. EpoxyRecyclerView

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

所有EpoxyRecyclerView共享的view回收池
默认设定了LinearLayoutManager
提供了辅助方法可以不用自己创建EpoxyController
更加简单的设定EpoxyController的方式
支持添加item之间的间隔距离
等等

6. 有用的局部更新

如果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开发流程。

前言