本文已授权 微信公众号 玉刚说 （@任玉刚）独家发布。

前言

我是一个崇尚 开源 的Android开发者，在过去的一段时间里，我研究了Github上的一些优秀的开源库，这些库源码中那些 天马行空 的 设计 和 ** 令我沉醉其中。

在我职业生涯的 伊始，我没有接触过 技术大牛, 但是 阅读源码 可以让我零距离碰撞 全球行业 内 最顶尖工程师们 的**，我渐渐爱上了 源码阅读。

在感叹这些 棒极了 的设计方式时，我也尝试去 模仿 他们的代码风格。后来朋友问我代码中为什么有这么多 设计模式 时，我才发现，单例 ，代理 ，工厂 ，装饰，Builder ，甚至更多，当初这些书上怎么也捋不清的设计模式，现在的我正在潜移默化使用它们，这不是 夸张，我在写这些代码时，它们似乎就应该这么用。

今年年初，我尝试开源了一个 灵活可高度定制 的Android图片选择框架 RxImagePicker 。这个库获得了部分认可，当然意见和建议也接踵而来，我很快认识到了自己目前能力的不足—— 通过 组合 的方式 将多个优秀的库封装在一起 ，并不是就意味着真正拥有了 组织架构 的能力，而自己对于架构的掌握能力，目前还有很多不足之处。

我意识到自己的不足，于是我积极寻找 更多优秀的架构，试图通过 源码 学习更多API之外的一些东西：编程** 和 架构设计 。

很快，我找到了一个很优秀的库，Paging—— 它同样做到了 业务层与UI层之间 的隔离，并且，它的设计更为 优秀。

Paging Libray

在不久前的Google 2018 I/O大会上，Google正式推出了AndroidJetpack ——这是一套组件、工具和指导，可以帮助开发者构建出色的 Android 应用，AndroidJetpack 隆重推出了一个新的分页组件：Paging Library。

我尝试研究了Paging Library，并分享给大家，本文的目标是阐述：

• 1.了解并如何使用 Paging
• 2.知道 Paging 中每个类的 职责，并了解掌握其 原理
• 3.站在设计者的角度，彻底搞懂 Paging 的 设计**

本文不是 Paging API 使用代码的展示，但通过本文 彻底搞懂 它的原理之后，API的使用也只是 顺手拈来。

它是什么，怎么用？

一句话概述： Paging 可以使开发者更轻松在 RecyclerView 中 分页加载数据。

1.官方文档

官方文档 永远是最接近 正确 和 核心理念 的参考资料 —— 在不久之后，本文可能会因为框架本身API的迭代更新而 毫无意义，但官方文档不会，即使在最恶劣的风暴中，它依然是最可靠的 指明灯：

https://developer.android.com/topic/libraries/architecture/paging/

其次，一个好的Demo能够起到重要的启发作用， 这里我推荐这个Sample:

项目地址：https://github.com/googlesamples/android-sunflower

因为刚刚发布的原因，目前Paging的中文教程 比较匮乏，许多资料的查阅可能需要开发者 自备梯子。

2.分页效果

在使用之前，我们需要搞明白的是，目前Android设备中比较主流的两种 分页模式，用我的语言概述，大概是：

• 传统的 上拉加载更多 分页效果
• 无限滚动 分页效果

从语义上来讲，我的描述有点不太直观，不了解的读者估计会很迷糊。

举个例子，传统的 上拉加载更多 分页效果，应该类似 淘宝APP 这种，滑到底部，再上拉显示footer，才会加载数据：

而无限滚动 分页效果，应该像是 京东APP 这样，如果我们慢慢滑动，当滑动了一定量的数据（这个阈值一般是数据总数的某个百分比）时，会自动请求加载下一页的数据，如果我们继续滑动，到达一定量的数据时，它会继续加载下一页数据，直到加载完所有数据——在用户看来，就好像是一次就加载出所有商品一样：

很明显，无限滚动 分页效果带来的用户体验更好，不仅是京东，包括 知乎 等其它APP，所采用的分页加载方式都是 无限滚动 的模式，而 Paging 也正是以无限滚动 的分页模式而设计的库。

3.Sample展示

我写了一个Paging的sample，它最终的效果是这样：

项目结构图如下，这可以帮你尽快了解sample的结构：

我把这个sample的源码托管在了我的github上，你可以通过 点我查看源码 。

4.使用Paging

现在你已经对 Paging 的功能有了一定的了解，我们可以开始尝试使用它了。

请注意，本小节旨在简单阐述Paging入门使用，读者不应该困惑于Kotlin语法或者Room库的使用——你只要能看懂基本流程就好了。

因此，我 更建议 读者 点击进入github，并将Sample代码拉下来阅读，仅仅是阅读—— 相比Kotlin语法和Room的API使用，理解代码的流程 更为重要。

① 在Module下的build.gradle中添加以下依赖：

    def room_version = "1.1.0"
    def paging_version = "1.0.0"
    def lifecycle_version = "1.1.1"

    //Paging的依赖
    implementation "android.arch.paging:runtime:$paging_version"
    //Paging对RxJava2的原生支持
    implementation "android.arch.paging:rxjava2:1.0.0-rc1"

    //我在项目中使用了Room，这是Room的相关依赖
    implementation "android.arch.persistence.room:runtime:$room_version"
    kapt "android.arch.persistence.room:compiler:$room_version"
    implementation "android.arch.persistence.room:rxjava2:$room_version"

    implementation "android.arch.lifecycle:extensions:$lifecycle_version"

② 创建数据源

我们要展示在list中的数据，主要以 网络请求 和 本地持久化存储 的方式获取，本文为了保证简单，数据源通过 Room数据库中 获得。

创建Student实体类：

@Entity
data class Student(@PrimaryKey(autoGenerate = true) val id: Int,
                   val name: String)

创建Dao:

@Dao
interface StudentDao {

    @Query("SELECT * FROM Student ORDER BY name COLLATE NOCASE ASC")
    fun getAllStudent(): DataSource.Factory<Int, Student>
}

创建数据库：

@Database(entities = arrayOf(Student::class), version = 1)
abstract class StudentDb : RoomDatabase() {

    abstract fun studentDao(): StudentDao

    companion object {

        private var instance: StudentDb? = null

        @Synchronized
        fun get(context: Context): StudentDb {
            if (instance == null) {
                instance = Room.databaseBuilder(context.applicationContext,
                        StudentDb::class.java, "StudentDatabase")
                        .addCallback(object : RoomDatabase.Callback() {
                            override fun onCreate(db: SupportSQLiteDatabase) {
                                ioThread {
                                    get(context).studentDao().insert(
                                            CHEESE_DATA.map { Student(id = 0, name = it) })
                                }
                            }
                        }).build()
            }
            return instance!!
        }
    }
}
private val CHEESE_DATA = arrayListOf(
        "Abbaye de Belloc", "Abbaye du Mont des Cats", "Abertam", "Abondance", "Ackawi",
        "Acorn", "Adelost", "Affidelice au Chablis", "Afuega'l Pitu", "Airag", "Airedale",
        "Aisy Cendre", "Allgauer Emmentaler", "Alverca", "Ambert", "American Cheese",
        "Ami du Chambertin", "Anejo Enchilado", "Anneau du Vic-Bilh", "Anthoriro", "Appenzell",
        "Aragon", "Ardi Gasna", "Ardrahan", "Armenian String", "Aromes au Gene de Marc",
        "Asadero", "Asiago", "Aubisque Pyrenees", "Autun", "Avaxtskyr", "Baby Swiss",
        "Babybel", "Baguette Laonnaise", "Bakers", "Baladi", "Balaton", "Bandal", "Banon",
        "Barry's Bay Cheddar", "Basing", "Basket Cheese", "Bath Cheese", "Bavarian Bergkase",
        "Baylough", "Beaufort", "Beauvoorde", "Beenleigh Blue", "Beer Cheese", "Bel Paese",
        "Bergader", "Bergere Bleue", "Berkswell", "Beyaz Peynir", "Bierkase", "Bishop Kennedy",
        "Blarney", "Bleu d'Auvergne", "Bleu de Gex", "Bleu de Laqueuille",
        "Bleu de Septmoncel", "Bleu Des Causses", "Blue", "Blue Castello", "Blue Rathgore",
        "Blue Vein (Australian)", "Blue Vein Cheeses", "Bocconcini", "Bocconcini (Australian)"
)

③ 创建Adapter和ViewHolder

这一步就很简单了，就像往常一样，我们创建一个item的layout布局文件(已省略，就是一个TextView用于显示Student的name)，同时创建对应的ViewHolder:

class StudentViewHolder(parent: ViewGroup) : RecyclerView.ViewHolder(
        LayoutInflater.from(parent.context).inflate(R.layout.student_item, parent, false)) {

    private val nameView = itemView.findViewById<TextView>(R.id.name)
    var student: Student? = null

    fun bindTo(student: Student?) {
        this.student = student
        nameView.text = student?.name
    }
}

我们的Adapter需要继承PagedListAdapter类：

class StudentAdapter : PagedListAdapter<Student, StudentViewHolder>(diffCallback) {

    override fun onBindViewHolder(holder: StudentViewHolder, position: Int) {
        holder.bindTo(getItem(position))
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): StudentViewHolder =
            StudentViewHolder(parent)

    companion object {
        private val diffCallback = object : DiffUtil.ItemCallback<Student>() {
            override fun areItemsTheSame(oldItem: Student, newItem: Student): Boolean =
                    oldItem.id == newItem.id

            override fun areContentsTheSame(oldItem: Student, newItem: Student): Boolean =
                    oldItem == newItem
        }
    }
}

④ 展示在界面上

我们创建一个ViewModel,它用于承载 与UI无关 业务代码：

class MainViewModel(app: Application) : AndroidViewModel(app) {

    val dao = StudentDb.get(app).studentDao()

    val allStudents = LivePagedListBuilder(dao.getAllStudent(), PagedList.Config.Builder()
            .setPageSize(PAGE_SIZE)                         //配置分页加载的数量
            .setEnablePlaceholders(ENABLE_PLACEHOLDERS)     //配置是否启动PlaceHolders
            .setInitialLoadSizeHint(PAGE_SIZE)              //初始化加载的数量
            .build()).build()

    companion object {
        private const val PAGE_SIZE = 15

        private const val ENABLE_PLACEHOLDERS = false
    }
}

最终，在Activity中，每当观察到数据源中 数据的变化，我们就把最新的数据交给Adapter去 展示：

class MainActivity : AppCompatActivity() {

    private val viewModel by lazy(LazyThreadSafetyMode.NONE) {
        ViewModelProviders.of(this, object : ViewModelProvider.Factory {
            override fun <T : ViewModel?> create(modelClass: Class<T>): T = MainViewModel(application) as T
        }).get(MainViewModel::class.java)
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val adapter = StudentAdapter()
        recyclerView.adapter = adapter
        // 将数据的变化反映到UI上
        viewModel.allStudents.observe(this, Observer { adapter.submitList(it) })
    }
}

到这里，Paging 最基本的使用就已经讲解完毕了。您可以通过运行预览和示例 基本一致 的效果，如果有疑问，可以点我查看源码 。

从入门到放弃？

阅读到这里，我相信不少朋友会有这样一个想法—— 这个库看起来感觉好麻烦，我为什么要用它呢？

我曾经写过一篇标题很浮夸的博客：0行Java代码实现RecyclerView—— 文中我提出了一种使用DataBinding 不需要哪怕一行Java代码就能实现列表/多类型列表的方式，但是最后我也提到了，这只是一种思路，这种简单的方式背后，可能会隐藏着 严重耦合 的情况—— "一行代码实现XXX" 的库屡见不鲜，它们看上去很 简单 ，但是真正做到 灵活，松耦合 的库寥寥无几，我认为这种方式是有缺陷的。

因此，简单并不意味着设计**的优秀，“看起来很麻烦” 也不能成为否认 Paging 的理由，本文不会去阐述 Paging 在实际项目中应该怎么用，且不说代码正确性与否，这种做法本身就会固定一个人的思维。但如果你理解了 Paging本身原理 的话，相信掌握其用法 也就不在话下了。

Paging原理详解

先上一张图

这是官方提供的非常棒的原理示意图，简单概括一下：

• DataSource： 数据源，数据的改变会驱动列表的更新，因此，数据源是很重要的
• PageList： 核心类，它从数据源取出数据，同时，它负责控制 第一次默认加载多少数据，之后每一次加载多少数据，如何加载等等，并将数据的变更反映到UI上。
• PagedListAdapter: 适配器，RecyclerView的适配器，通过分析数据是否发生了改变，负责处理UI展示的逻辑（增加/删除/替换等）。

1.创建数据源

我们思考一个问题，将数据作为列表展示在界面上，我们首先需要什么。

数据源，是的，在Paging中，它被抽象为 DataSource , 其获取需要依靠 DataSource 的内部工厂类 DataSource.Factory ，通过create()方法就可以获得DataSource 的实例：

public abstract static class Factory<Key, Value> {
     public abstract DataSource<Key, Value> create();
}

数据源一般有两种选择，远程服务器请求 或者 读取本地持久化数据——这些并不重要，本文我们以Room数据库为例:

@Dao
interface StudentDao {

    @Query("SELECT * FROM Student ORDER BY name COLLATE NOCASE ASC")
    fun getAllStudent(): DataSource.Factory<Int, Student>
}

Paging可以获得 Room的原生支持，因此作为示例非常合适，当然我们更多获取 数据源 是通过 API网络请求，其实现方式可以参考官方Sample,本文不赘述。

现在我们创建好了StudentDao,接下来就是展示UI了，在那之前，我们需要配置好PageList。

2.配置PageList

上文我说到了PageList的作用：

• 1.从数据源取出数据
• 2.负责控制 第一次默认加载多少数据，之后每一次加载多少数据，如何加载 等等
• 3.将数据的变更反映到UI上。

我们仔细想想，这是有必要配置的，因此我们需要初始化PageList:

 val allStudents = LivePagedListBuilder(dao.getAllStudent(), PagedList.Config.Builder()
            .setPageSize(15)                         //配置分页加载的数量
            .setEnablePlaceholders(false)     //配置是否启动PlaceHolders
            .setInitialLoadSizeHint(30)              //初始化加载的数量
            .build()).build()

我们按照上面分的三个职责来讲：

• 从数据源取出数据

很显然，这对应的是 dao.getAllStudent() ，通过数据库取得最新数据，如果是网络请求，也应该对应API的请求方法，返回值应该是DataSource.Factory类型。

• 进行相关配置

PageList提供了 PagedList.Config 类供我们进行实例化配置，其提供了4个可选配置：

 public static final class Builder {
            //  省略其他Builder内部方法
            private int mPageSize = -1;    //每次加载多少数据
            private int mPrefetchDistance = -1;   //距底部还有几条数据时，加载下一页数据
            private int mInitialLoadSizeHint = -1; //第一次加载多少数据
            private boolean mEnablePlaceholders = true; //是否启用占位符，若为true，则视为固定数量的item
}

• 将变更反映到UI上
  这个指的是 LivePagedListBuilder，而不是 PagedList.Config.Builder，它可以设置 获取数据源的线程 和 边界Callback,但是一般来讲可以不用配置，大家了解一下即可。

经过以上操作，我们的PageList设置好了，接下来就可以配置UI相关了。

3.配置Adapter

就像我们平时配置 RecyclerView 差不多，我们配置了ViewHolder和RecyclerView.Adapter，略微不同的是，我们需要继承PagedListAdapter：

class StudentAdapter : PagedListAdapter<Student, StudentViewHolder>(diffCallback) {
    //省略 onBindViewHolder() && onCreateViewHolder()  
    companion object {
        private val diffCallback = object : DiffUtil.ItemCallback<Student>() {
            override fun areItemsTheSame(oldItem: Student, newItem: Student): Boolean =
                    oldItem.id == newItem.id

            override fun areContentsTheSame(oldItem: Student, newItem: Student): Boolean =
                    oldItem == newItem
        }
    }
}

当然我们还需要传一个 DifffUtil.ItemCallback 的实例，这里需要对数据源返回的数据进行了比较处理, 它的意义是——我需要知道怎么样的比较，才意味着数据源的变化，并根据变化再进行的UI刷新操作。

ViewHolder的代码正常实现即可，不再赘述。

4.监听数据源的变更，并响应在UI上

这个就很简单了，我们在Activity中声明即可：

val adapter = StudentAdapter()
recyclerView.adapter = adapter

viewModel.allStudents.observe(this, Observer { adapter.submitList(it) })

这样，每当数据源发生改变，Adapter就会自动将 新的数据 动态反映在UI上。

分页库的设计美学

现在，我简单了解了它的原理，但是还不是很够—— 正如我前言所说的，从别人的 代码设计和** 中 取长补短，化为己用 ，这才是我的目的。

让我们回到最初的问题：

看起来很麻烦，那么我为什么用这个库?

我会有这种想法，我为什么不能把所有功能都封装到一个 RecyclerView的Adapter里面呢，它包含 下拉刷新，上拉加载分页 等等功能。

原因很简单，因为这样做会将 业务层代码 和 UI层 混在一起造 耦合 ，最直接就导致了 难以通过代码进行单元测试。

UI层 和 业务层 代码的隔离是优秀的设计，这样更便于 测试 ，我们可以从Google官方文档的目录结构中看到这一点：

接下来，我会尝试站在设计者的角度，尝试去理解 Paging 如此设计的原因。

1.PagedListAdapter：基于RecyclerView的封装

将分页数据作为List展示在界面上，RecyclerView 是首选，那么实现一个对应的 PagedListAdapter 当然是不错的选择。

Google对 PagedListAdapter 的职责定义的很简单，仅仅是一个被代理的对象而已，所有相关的数据处理逻辑都委托给了 AsyncPagedListDiffer：

public abstract class PagedListAdapter<T, VH extends RecyclerView.ViewHolder>
        extends RecyclerView.Adapter<VH> {

    protected PagedListAdapter(@NonNull DiffUtil.ItemCallback<T> diffCallback) {
        mDiffer = new AsyncPagedListDiffer<>(this, diffCallback);
        mDiffer.mListener = mListener;
    }

    public void submitList(PagedList<T> pagedList) {
        mDiffer.submitList(pagedList);
    }

    protected T getItem(int position) {
        return mDiffer.getItem(position);
    }

    @Override
    public int getItemCount() {
        return mDiffer.getItemCount();
    }

   public PagedList<T> getCurrentList() {
        return mDiffer.getCurrentList();
    }
}

当数据源发生改变时，实际上会通知 AsyncPagedListDiffer 的 submitList() 方法通知其内部保存的 PagedList 更新并反映在UI上：

//实际上内部存储了要展示在UI上的数据源PagedList<T>
public class AsyncPagedListDiffer<T> {
    //省略大量代码
    private PagedList<T> mPagedList;
    private PagedList<T> mSnapshot;
}

篇幅所限，我们不讨论数据是如何展示的（答案很简单，就是通过RecyclerView.Adapter的notifyItemChange()相关方法），我们有一个问题更需要去关注：

Paging 未滑到底部便开始加载数据的逻辑 在哪里？

如果你认真思考，你应该能想到正确的答案，在 getItem() 方法中执行。

public T getItem(int index) {
        //省略部分代码
        mPagedList.loadAround(index);  //如果需要，请求更多数据
        return mPagedList.get(index);  //返回Item数据
}

每当RecyclerView要展示一个新的Item时，理所应当的会通过 getItem() 方法获取相应的数据，既然如此，为何不在返回最新数据之前，判断当前的数据源是否需要 加载下一页数据 呢？

2.抽象类PagedList: 设计模式的组合美学

我们来看抽象类PagedList.loadAround(index)方法：

    public void loadAround(int index) {
        mLastLoad = index + getPositionOffset();
        loadAroundInternal(index);

        mLowestIndexAccessed = Math.min(mLowestIndexAccessed, index);
        mHighestIndexAccessed = Math.max(mHighestIndexAccessed, index);
        tryDispatchBoundaryCallbacks(true);
    }
    //这个方法是抽象的
    abstract void loadAroundInternal(int index);

需要再次重复的是，即使是PagedList,也有很多种不同的 数据分页策略:

这些不同的 PagedList 在处理分页逻辑上，可能有不同的逻辑，那么，作为设计者，应该做到的是，把异同的逻辑抽象出来交给子类实现（即loadAroundInternal方法），而把公共的处理逻辑暴漏出来，并向上转型交给Adapter（实际上是 AsyncPagedListDiffer）去执行分页加载的API，也就是loadAround方法。

好处显而易见，对于Adapter来说，它只需要知道，在我需要请求分页数据时，调用PagedList的loadAround方法即可，至于 是PagedList的哪个子类，内部执行什么样的分页逻辑，Adapter并不关心。

这些PagedList的不同策略的逻辑，是在PagedList.create()方法中进行的处理：

    private static <K, T> PagedList<T> create(@NonNull DataSource<K, T> dataSource,
            @NonNull Executor notifyExecutor,
            @NonNull Executor fetchExecutor,
            @Nullable BoundaryCallback<T> boundaryCallback,
            @NonNull Config config,
            @Nullable K key) {
        if (dataSource.isContiguous() || !config.enablePlaceholders) {
            //省略其他代码
            //返回ContiguousPagedList
            return new ContiguousPagedList<>(contigDataSource,    
                    notifyExecutor,
                    fetchExecutor,
                    boundaryCallback,
                    config,
                    key,
                    lastLoad);
        } else {
            //返回TiledPagedList
            return new TiledPagedList<>((PositionalDataSource<T>) dataSource,
                    notifyExecutor,
                    fetchExecutor,
                    boundaryCallback,
                    config,
                    (key != null) ? (Integer) key : 0);
        }
    }

PagedList是一个抽象类，实际上它的作用是 通过Builder实例化PagedList真正的对象：

通过Builder.build()调用create()方法，决定实例化哪个PagedList的子类：

        public PagedList<Value> build() {
            return PagedList.create(
                    mDataSource,
                    mNotifyExecutor,
                    mFetchExecutor,
                    mBoundaryCallback,
                    mConfig,
                    mInitialKey);
        }

Builder模式是非常耳熟能详的设计模式，它的好处是作为API的门面，便于开发者更简单上手并进行对应的配置。

不同的PagedList对应不同的DataSource，比如：

class ContiguousPagedList<K, V> extends PagedList<V> implements PagedStorage.Callback {

    ContiguousPagedList(
            //请注意这行，ContiguousPagedList内部需要ContiguousDataSource
            @NonNull ContiguousDataSource<K, V> dataSource,
            @NonNull Executor mainThreadExecutor,
            @NonNull Executor backgroundThreadExecutor,
            @Nullable BoundaryCallback<V> boundaryCallback,
            @NonNull Config config,
            final @Nullable K key,
            int lastLoad) {
            //.....
    }


abstract class ContiguousDataSource<Key, Value> extends DataSource<Key, Value> {
      //......
}

class TiledPagedList<T> extends PagedList<T> implements PagedStorage.Callback {

    TiledPagedList(
            //请注意这行，TiledPagedList内部需要PositionalDataSource
            @NonNull PositionalDataSource<T> dataSource,
            @NonNull Executor mainThreadExecutor,
            @NonNull Executor backgroundThreadExecutor,
            @Nullable BoundaryCallback<T> boundaryCallback,
            @NonNull Config config,
            int position) {
           //......
    }
}

public abstract class PositionalDataSource<T> extends DataSource<Integer, T> {
    //......
}

回到create()方法中，我们看到dataSource此时也仅仅是接口类型的声明：

private static <K, T> PagedList<T> create(
            //其实这时候dataSource只是作为DataSource类型的声明
            @NonNull DataSource<K, T> dataSource,
            @NonNull Executor notifyExecutor,
            @NonNull Executor fetchExecutor,
            @Nullable BoundaryCallback<T> boundaryCallback,
            @NonNull Config config,
            @Nullable K key) {
}

实际上，create方法的作用是，通过将不同的DataSource,作为依赖实例化对应的PagedList，除此之外，还有对DataSource的对应处理，或者Wrapper（再次包装，详情请参考源码的create方法，篇幅所限本文不再叙述）。

这个过程中，通过Builder，将 多种数据源（DataSource），多种分页策略（PagedList） 互相进行组合，并 向上转型 交给 适配器（Adapter） ，然后Adapter将对应的功能 委托 给了 代理类的AsyncPagedListDiffer 处理——这之间通过数种设计模式的组合，最终展现给开发者的是一个 简单且清晰 的API接口去调用，其设计的精妙程度，远非笔者这种普通的开发者所能企及。

3.更多

实际上，笔者上文所叙述的内容只是 Paging 的冰山一角，其源码中，还有很多很值得学习的优秀**，本文无法一一列举，比如 线程的切换（加载分页数据应该在io线程，而反映在界面上时则应该在ui线程），再比如库 对多种响应式数据类型的支持（LiveData，RxJava）,这些实用的功能实现，都通过 Paging 优秀的设计，将其复杂的实现封装了起来，而将简单的API暴露给开发者调用，有兴趣的朋友可以去研究一下。

小结

笔者水平有限，难免文中内容有理解错误之处，也希望能有朋友不吝赐教，共同讨论一起进步。

--------------------------广告分割线------------------------------

系列文章

争取打造 Android Jetpack 讲解的最好的博客系列：

• Android官方架构组件Lifecycle：生命周期组件详解&原理分析
• Android官方架构组件ViewModel:从前世今生到追本溯源
• Android官方架构组件LiveData: 观察者模式领域二三事
• Android官方架构组件Paging：分页库的设计美学
• Android官方架构组件Paging-Ex：为分页列表添加Header和Footer
• Android官方架构组件Paging-Ex：列表状态的响应式管理
• Android官方架构组件Navigation：大巧不工的Fragment管理框架
• Android官方架构组件DataBinding-Ex:双向绑定篇

Android Jetpack 实战篇：

• 开源项目：MVVM+Jetpack实现的Github客户端
• 开源项目：基于MVVM, MVI+Jetpack实现的Github客户端
• 总结：使用MVVM尝试开发Github客户端及对编程的一些思考

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的个人博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费

前言

本文是 Android官方架构组件 系列的番外篇，因为目前国内关于DataBinding双向绑定的博客，讲的实在是五花八门，很多文章看完之后仍然一头雾水，特此专门写一篇文章进行总结。

此外，前几天在CSDN上看到 貌似掉线 老师发布了一篇文章《我为什么放弃在项目中使用Data Binding》，里面针对性指出了目前DataBinding的使用中一些痛点，很多地方我感同身受，但鉴于 事物的存在必然存在两面性 ，特此也在 本文的末尾 写了一些我个人的理解， 阐述了为什么我个人 还在坚持使用DataBinding , 希望对读者能有所裨益。

本文默认读者对DataBinding的使用有了初步的了解。

什么是双向绑定？

DataBinding的本身是对View层状态的一种观察者模式的实现，通过让View与ViewModel层可观察的对象（比如LiveData）进行绑定，当ViewModel层数据发生变化，View层也会自动进行UI的更新。

上述我讲的是DataBinding最基础的用法，即 单向绑定 ，其优势在于，将View层抽象为一个纯Java的可观察者——这意味着ViewModel层相关代码是完全可直接用于进行 单元测试。

但实际的开发中，单向绑定并非是足够的，在一些特定的场景，我们也需要用到 双向绑定。

比如说，对于一个TextView的内容展示，一般情况下，我们只是用来通过将一个String类型的数据对其进行渲染：

显而易见，数据的流向是单向的，换句话说，我们认为TextView对DataSource只进行了 读 操作——如果此时进行了网络请求，我们需要用到DataSource某个属性作为参数，我们依然可以毫无顾忌从DataSource取值。

但是换一个场景，如果我们把TextView换成一个EditText，接下来我们需要面对的则截然不同，比如登录界面：

这似乎没有什么问题，我们依然通过一个LiveData对EditText进行了单向绑定：

问题发生了，当我们对 输入框 进行编辑，EditText的UI发生了变更，但是LiveData内的数据却没有更新，当我们想要在ViewModel层请求登录的API接口时，我们就必须要去通过editText.getText()才能获取用户输入的密码。

于是我们希望，即使是EditText的内容发生了变更，但是LiveData内的数据也能和EditText保持内容的同步——这样我们就不需要让ViewModel层持有View层的引用，在请求接口时，直接从LiveData中取值即可：

这就是双向绑定的意义。

使用场景是什么

什么适合使用 双向绑定 呢，还记得上文中的一句话吗：

对于单向绑定来说，数据的流向是单向的，换句话说，我们认为TextView对DataSource只进行了 读 操作。

现在我们定义，当 不确定的操作发生时 ——通常，这种操作代表着用户对UI控件的交互，这时UI的变化需要影响到ViewModel层的数据状态（除了 数据驱动视图 之外，视图也在驱动数据，以方便作为参数将来进行网络请求等等操作），这时 双向绑定 就可以大展身手了。

显然上文中的EditText的是 双向绑定 经典的使用场景之一，此外，双向绑定的使用场景非常常见，比如CheckBox：

当用户选中了CheckBox，我们当然希望ViewModel层的LiveData<Boolean>状态进行对应的更新，以便将来我们直接从LiveData中取值作为参数进行网络请求。

而如果没有双向绑定，用户操作了UI，我们就需要 手动添加代码保证状态的同步——比如checkBox.setOnCheckChangedListener()，否则，就会在接下来的操作中得到与预期不同的结果。

听起来好像很麻烦，那么究竟如何使用呢？

幸运的是，Android原生控件中，绝大多数的双向绑定使用场景，DataBinding都已经帮我们实现好了：

这意味着我们并不需要去手动实现复杂的双向绑定，以上文的EditText为例，我们只需要通过@={表达式}进行双向的绑定：

<EditText
	android:id="@+id/etPassword"
	android:layout_width="match_parent"
	android:layout_height="wrap_content"
	android:text="@={ fragment.viewModel.password }" />

相比单向绑定，只需要多一个=符号，就能保证View层和ViewModel层的 状态同步 了。

难点在哪？

双向绑定定义好之后，使用起来很简单，但定义却稍微比单向绑定麻烦一些，即使原生的控件DataBinding已经帮助我们实现好了，对于三方的控件或者自定义控件，还需要我们自己实现。

本文以SwipeRefreshLayout为例，让我们来看看其 双向绑定 实现的方式：

object SwipeRefreshLayoutBinding {

    @JvmStatic
    @BindingAdapter("app:bind_swipeRefreshLayout_refreshing")
    fun setSwipeRefreshLayoutRefreshing(
            swipeRefreshLayout: SwipeRefreshLayout,
            newValue: Boolean
    ) {
        if (swipeRefreshLayout.isRefreshing != newValue)
            swipeRefreshLayout.isRefreshing = newValue
    }

    @JvmStatic
    @InverseBindingAdapter(
            attribute = "app:bind_swipeRefreshLayout_refreshing",
            event = "app:bind_swipeRefreshLayout_refreshingAttrChanged"
    )
    fun isSwipeRefreshLayoutRefreshing(swipeRefreshLayout: SwipeRefreshLayout): Boolean =
            swipeRefreshLayout.isRefreshing

    @JvmStatic
    @BindingAdapter(
            "app:bind_swipeRefreshLayout_refreshingAttrChanged",
            requireAll = false
    )
    fun setOnRefreshListener(
            swipeRefreshLayout: SwipeRefreshLayout,
            bindingListener: InverseBindingListener?
    ) {
        if (bindingListener != null)
            swipeRefreshLayout.setOnRefreshListener {
                bindingListener.onChange()
            }
    }
}

有点晦涩，是不是？我们先不要纠结于细节的实现，先来看看代码中是如何使用的吧：

<androidx.swiperefreshlayout.widget.SwipeRefreshLayout
		android:layout_width="match_parent"
		android:layout_height="match_parent"
		app:bind_swipeRefreshLayout_refreshing="@={ fragment.viewModel.refreshing }">

            <androidx.recyclerview.widget.RecyclerView/>

</androidx.swiperefreshlayout.widget.SwipeRefreshLayout>

refreshing实际就只是一个LiveData：

val refreshing: MutableLiveData<Boolean> = MutableLiveData()

这里的双向绑定，意义在于，当我们为LiveData手动设置值时，SwipeRefreshLayout 的UI也会发生对应的变更；同理，当用户手动下拉执行刷新操作时，LiveData的值也会对应的变成为true(代表刷新中的状态)。

相比于其它的方式，双向绑定将SwipeRefreshLayout的刷新状态抽象成为了一个LiveData<Boolean> ——我们只需要在xml中定义好，之后就可以在ViewModel中围绕这个状态进行代码的编写，不同于view.setOnRefreshListener()的方式，这种代码是纯Java的，我们可以针对每一行代码进行纯JVM的单元测试。

本小节的所有代码你都可以在 这里 获取。

整理思路，按部就班实现双向绑定

说了这么多，但是我们一行代码都还没有实现，不着急，因为编码只是其中的一个步骤，最重要的是 整理一个流畅的思路，这样，在接下来的编码阶段，你会如有神助。

1.实现单向绑定

我们知道，双向绑定的前提是单向绑定，因此，我们先配置好对应单向绑定的接口：

@JvmStatic
@BindingAdapter("app:bind_swipeRefreshLayout_refreshing")
fun setSwipeRefreshLayoutRefreshing(
        swipeRefreshLayout: SwipeRefreshLayout,
        newValue: Boolean
) {
        swipeRefreshLayout.isRefreshing = newValue
}

我们通过将LiveData的值和DataBinding绑定在一起，每当LiveData的状态发生了变更，SwipeRefreshLayout的刷新状态也会发生对应的更新。

我们实现了数据驱动视图的效果，接下来我们需要思考的是，我们如何才能知道用户会执行下拉操作呢？

2.观察View层的状态变更

只有观察到View层的状态变更，我们才能驱动LiveData进行对应的更新，其实很简单，通过swipeRefreshlayout.setOnRefreshListener()即可：

@JvmStatic
@BindingAdapter(
        "app:bind_swipeRefreshLayout_refreshingAttrChanged",
        requireAll = false
)
fun setOnRefreshListener(
        swipeRefreshLayout: SwipeRefreshLayout,
        bindingListener: InverseBindingListener?
) {
    if (bindingListener != null)
        swipeRefreshLayout.setOnRefreshListener {
            bindingListener.onChange()   // 1
        }
}

注意我注释了 //1的地方，每当swipeRefreshLayout刷新状态被用户的操作改变，我们都能够在这里监听到，并交给InverseBindingListener这个 信使 去通知DataBinding：

嗨！View层的状态发生了变更，你快去通知LiveData也进行对应数据的更新呀！

新的问题来了，现在DataBinding已经知道需要去通知LiveData进行对应数据的更新了，关键是——

3. 我要把什么数据交给LiveData?

是的，即使LiveData需要进行更新，但是它并不知道要新的状态是什么。

LiveData: 老哥，你倒是把数据给我啊！

我们急需将SwipeRefreshLayout最新状态告诉LiveData，因此我们通过InverseBindingAdapter注解和 步骤二 中去进行对接：

@JvmStatic
@InverseBindingAdapter(
        attribute = "app:bind_swipeRefreshLayout_refreshing",
        event = "app:bind_swipeRefreshLayout_refreshingAttrChanged"   // 2 【注意！】
)
fun isSwipeRefreshLayoutRefreshing(swipeRefreshLayout: SwipeRefreshLayout): Boolean =
        swipeRefreshLayout.isRefreshing

注意到 //2 注释的那行代码没有，我们通过相同的tag（即app:bind_swipeRefreshLayout_refreshingAttrChanged这个字符串，步骤二中我们也声明了相同的字符串），和 步骤二 中的代码块形成了绑定对接。

现在，LiveData知道如何进行反向的数据更新了：

每当用户下拉刷新，InverseBindingListener通知DataBinding,LiveData就会从swipeRefreshLayout.isRefreshing得知最新的状态，并进行数据的同步更新。

4.不要忘了防止死循环！

细心的你多少已经感觉到了不对劲的地方，现在的双向绑定有一个致命的问题，那就是无限循环会导致的ANR异常。

当View层UI状态被改变，ViewModel对应发生更新，同时，这个更新又回通知View层去刷新UI，这个刷新UI的操作又会通知ViewModel去更新.......

因此，为了保证不会无限的死循环导致App的ANR异常的发生，我们需要在最初的代码块中加一个判断，保证，只有View状态发生了变更，才会去更新UI：

@JvmStatic
@BindingAdapter("app:bind_swipeRefreshLayout_refreshing")
fun setSwipeRefreshLayoutRefreshing(
        swipeRefreshLayout: SwipeRefreshLayout,
        newValue: Boolean
) {
    if (swipeRefreshLayout.isRefreshing != newValue)   // 只有新老状态不同才更新UI
        swipeRefreshLayout.isRefreshing = newValue
}

小结：我为什么还在坚守DataBinding

本文的初始计划中，还有一个模块是关于 双向绑定的源码分析，写到后来又觉得没有必要了，因为即使是 源码，也只是将上文中实现的思路啰嗦复述了一遍而已。

双向绑定本身是一个极具争议的功能；事实上，DataBinding本身也极具争议——DataBinding的好用与否，用或者不用都不重要，重要的是我们需要去正视它展现出来的**：即如何将一个 难以测试，状态多变 的View, 通过代码抽象为 易于维护和测试 的纯Java的状态？

DataBinding将烦不胜烦的View层代码抽象为了易于维护的数据状态，同时极大减少了View层向ViewModel层抽象的 胶水代码，这就是最大的优势。

当然，DataBinding并不一定就是正解，事实上，RxBinding就是另外一个优秀的解决方案，同样以SwipeRefreshLayout为例，我依然可以将其抽象为一个可观察的Observable<Boolean>——前者通过在xml中对数据进行绑定和观察，后者通过RxJava对View的状态抽象为一个流，但最终，两者在**上殊途同归。

系列文章

争取打造 Android Jetpack 讲解的最好的博客系列：

• Android官方架构组件Lifecycle：生命周期组件详解&原理分析
• Android官方架构组件ViewModel:从前世今生到追本溯源
• Android官方架构组件LiveData: 观察者模式领域二三事
• Android官方架构组件Paging：分页库的设计美学
• Android官方架构组件Paging-Ex：为分页列表添加Header和Footer
• Android官方架构组件Paging-Ex：列表状态的响应式管理
• Android官方架构组件Navigation：大巧不工的Fragment管理框架
• Android官方架构组件DataBinding-Ex:双向绑定篇

Android Jetpack 实战篇：

• 开源项目：MVVM+Jetpack实现的Github客户端
• 开源项目：基于MVVM, MVI+Jetpack实现的Github客户端
• 总结：使用MVVM尝试开发Github客户端及对编程的一些思考

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的个人博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费

本文已授权「玉刚说」微信公众号独家发布

概述

Paging是Google在2018年I/O大会上推出的适用于Android原生开发的分页库，随着越来越多的开发者着手使用Paging，越来越多的问题暴露出来，最直接的一个问题是：

如何管理列表额外的状态？

这样的需求随处可见，比如 侧滑删除、为评论点赞 等等：

本文将阐述：如何管理Paging分页列表的 状态，为何这样设计，以及设计的过程。

列表的状态问题

和市面上其它热门的分页库相比，Paging最大的亮点在于其 将列表分页加载的逻辑作为回调函数封装入 DataSource 中，开发者在配置完成后，无需通过代码手动控制分页的加载，列表会 自动加载 下一页数据并展示。

这种便利意味着开发者不需要自己持有 数据源 ，大多数时候这使得开发流程更加便利，但总有偶然，比如这样一个界面：

这种需求屡见不鲜，其本质是，列表本身展示服务端返回的列表数据之外，还需要 本地控制额外的状态。

什么叫 额外的状态 ? 我们先用简单的一张图展示没有额外状态的情形，这时，列表的所有UI元素都从服务端获取：

现在我们将上文Gif中的点赞效果也通过一张图表示：

读者可能还未认识到两种业务场景之间的差异性：对于列表的初始化来讲，所有UI元素都被服务端返回的数据渲染，每条评论是否已经被点赞，服务端都通过Comment进行了描述。

需要注意的是，在某一刻，用户发现某个评论非常有趣，因此他选择对该评论进行了点赞的操作。

在业务代码中，我们需要向服务端POST一个点赞的请求，服务端返回了一个200的成功码，但问题来了，接下来我们 如何让列表中的那条评论状态发生变化（即点赞的icon由灰色变成绿色高亮，已告知用户点赞成功）？

这就引发了文章最开始的那个问题，当列表的状态发生了变更，如何管理并更新列表？

方案1：再次刷新请求接口

最简单的方案是再次请求API，每当列表状态发生了变更，重新拉取评论列表，服务端返回的最新数据中，该评论自然已经被点赞了（即列表正确进行了更新）。

读者应该清楚，该方案实际并不可行，原因有二：

• 成本太高：某些操作对于用户来说，应该是非常 轻量级 的（比如点赞），他们甚至希望这些操作能够 立即被响应 在UI上 ，而请求API并刷新列表这一个过程太重了，即使不考虑服务器的负担，对于用户来说，UI的刷新需要数秒的等待也是非常糟糕的体验。
• 不符合逻辑：我们更需要注意的是，Paging是一个分页列表，而刷新请求行为对于分页列表来说，是一个不符合产品预期的行为（比如，我的点赞操作是针对第5页的某个评论执行的，产品的设计不可能允许每次点赞都重置为列表的第一页数据，这意味着极度糟糕的用户体验）。

现在我们理解了 每当列表状态发生了变更就刷新接口 并非良策，因为这种通过 远程重新拉取数据源 更新UI的方式成本太高了。

方案2：额外维护一个状态的列表

大概思路是在内存中为RecyclerView维护一个额外的List，用于一一映射对应position的Item状态：

class CommentPagedAdapter(
  private val likedList: ArrayList<Boolean>
)

通过在内存中维护这样一个List，的确可以实现需求，但读者需要认识到的是，Paging分页库本身最大的优点便是 随着列表的滚动自动加载分页数据，每次分页的行为开发者并不需要手动配置，并通过调用类似notifyItemRangeInserted()的方法更新UI。

很显然，每当分页数据获取后，开发者依然需要手动维护这个额外状态的List——方案2和选择使用Paging的初衷背道而驰，因此它并非最优先考虑的方案。

库本身设计的问题？

现在问题是，既不能通过 服务端 作为数据源，也不能在 内存中 额外维护一个状态的列表， 读者难免会质疑Paging库本身设计的问题。

我该如何控制列表额外的状态（包括修改、增加或者删除）？

事实上该问题已经在Github的这个 issue 中进行了讨论，Google的工程师的回复是：

从技术的角度而言 ,我们可以创建一个允许部分更改数据源的API，但之后我们需要记录这些改动并在主线程上重新传递给列表。这种方法的问题在于，如果你有一个已停止的RecyclerView（也就是后堆栈），它将不会（也不应该）接收任何更新，因此PagedList将保留这个可能很长的数据列表并重新应用于主线程上的每个观察者。

这使问题变得非常复杂，这就是我们使用单个列表的原因。

显然，Paging考虑到了更多，和市面上 什么都能做 的框架相比，它 敢于收紧开发者API的调用权限，在开发者们发挥更多奇思妙想之前，将其紧紧束缚到了可控制的范围之内，这也是笔者非常推崇Paging的原因之一。

那么我们该如何处理我们的业务？此时引入一个新的角色似乎是一个不错的选择，那就是 持久层（即缓存）。

通过架构解决业务问题

综上所述，对于分页列表的状态管理问题，需要做到的是：

• 1.将一个单独的List交给Paging去进行分页加载并渲染（不应在内存中手动维护一个额外状态的列表）;
• 2.不应该每次都通过重的操作刷新数据源（比如网络请求刷新接口）。

因此，我们需要一个 中间件 进行业务的调度——在需要刷新整个数据源的时候（比如用户的下拉刷新操作），从服务端拉取数据；在不需要繁重的操作时（比如用户针对某个评论进行点赞），仅仅需要针对单个数据源进行简单的修改。

这已经不单单是业务业务的问题，并且涉及到了项目本身的架构，接下来， 持久层 （即本地缓存）闪亮登场。

1.用持久层作为唯一的数据源

Android平台的数据库框架有很多种，本文以官方的架构组件Room为例。

为什么要为项目的架构额外添加一个持久层？事实上，随着项目体系的日益庞大，数据库是终究需要添加进入项目中的，因此，在设计项目的架构之前，提前将数据库的框架配置进来是一个不错的选择——未雨绸缪总不是坏事。

以列表的渲染为例，让我们来看看项目之前的结构：

回到本文，对于Paging来讲，我们并无法直接获取数据源，因此对于列表状态的管理，我们需要额外的角色帮助，那就是本地的持久化缓存。

让我们看看添加了持久层之后的结构：

添加了缓存之后，每当我们尝试初始化一个分页列表，框架会从服务器拉取数据，之后数据被存储到了Room中。

请注意！Paging原生提供了对Room数据库框架的支持，因此它总是可以第一时间响应到数据库中数据的变化，并自动渲染在UI上。

现在，我们将 请求服务器API 和 数据的渲染 两者通过持久层进行了隔离，对于RecyclerView来说，持久层是唯一的数据源，即：

列表只反应了数据库的变更。

现在列表的显示和服务端的请求已经 完全无关 了，读者也许会有这样的疑问——这样做的好处是什么？

2.列表状态的管理

现在我们回到文中最初的问题，如何管理列表的状态？

对于一个拥有复杂状态的分页列表，无论是 服务端 作为数据源，还是在 内存中 额外维护一个状态列表，都不是很好的选择；而现在我们加入了Room，并作为列表唯一的数据源，局势发生了怎样微妙的变化呢？

让我们来看看加入了持久层之后，下拉刷新的逻辑发生了怎样的变化：

• 1.下拉刷新意味着我们需要重置数据，因此我们手动清除了数据库内对应表中的数据；
• 2.当表中数据被清空时，Paging会自动响应到数据的变化，因为没有了数据，所以Paging会自动向服务器请求数据；
• 3.数据返回后，会再次将数据存储到数据库中；
• 4.这时Paging会再次响应到数据库的变化，并将最新的数据渲染到UI上。

看起来逻辑复杂了很多，实际上读者需要明确的是，步骤2、3、4都是我们作为开发者在初始化Paging时就配置好的，因此如果用户需要刷新页面，只需要进行第一步的操作即可，即类似这样的一行代码：

// 刷新操作，仅需清除表内的列表数据
fun swipeRefresh() {
  // 运行一个事务
  db.runInTransaction {
      // 清除列表数据
      db.getDao().clearDataList()
  }
}

现在我们将整个流程中，Paging自动执行的步骤用紫色标记出来：

瞧，除了我们手动执行的逻辑，所有流程都交给了Paging去 响应式 地执行。

我们总是下意识认为复杂的业务逻辑用过程式的编码更容易实现，Paging用事实证明了并非如此——如果说项目中的某个页面追加了下拉刷新的需求，过程式的编码也许会花费更多的时间，并且代码也许会更分散、啰嗦且易出错。

3.更灵活、且可高度扩展

接下来分析的是，对分页列表点赞这种相对 轻量级的行为 又该如何处理?

答案呼之欲出, 我们依然用熟悉的流程图表示代码的执行步骤：

即使是复杂的状态，在这种模式下也不再是难题：首先，我们将数据库对应表中对应评论的isLike（是否被点赞）设置为true：

// 1.对本地的评论数据点赞
fun likeCommentLocal(comment: Comment) {
  // 更新评论
  comment.isLike = true
  // 将评论更新到数据库中
  db.runInTransaction {
     db.getDao().updateLikeComment(o)
  }
}

与此同时，我们也向服务器请求接口，告知评论被用户点赞：

// 2.对评论点赞
fun likeCommentRemote(commentId: String) {
  service.likeComment(commentId)
  // ....
}

当数据库中数据发生了变更，Paging仍然会响应到数据的更新，并第一时间更新了UI，同时我们也向服务器发起了请求，一个完整的 点赞 操作相关的业务代码实现完毕。

有了持久层作为中间件，代码组织的灵活性大大提升，同时也具备了更高的扩展性。列表状态的管理不再是问题，诸如 点赞 、 下拉刷新 、 侧滑删除 等等等等，都可以通过对持久层的数据源进行修改，paging总是可以第一时间自动响应到变更并更新UI。

也正如Room官方文档第一句话所说的，对于Paging分页列表（对app也一样）复杂的状态的展示和管理，开发者应该 将缓存作为列表的唯一真实的数据源：

This cache, which serves as your app's single source of truth.

代码示例？

如读者所看到的，本文尽量避免展示大篇幅的业务代码，原因有二：

• 1.这会破坏文章整体思路的完整性，没有人喜欢阅读大篇幅、连续的代码片段；
• 2.实际开发中，项目的业务不同、架构选型不同，代码的实现方式也不尽相同，因此业务级别的代码展示没有意义。

比如，对于持久层框架的选型，Room、GreenDao、DBFlow都是非常优秀的框架，对于业务代码的实现，RxJava、LiveData、协程都是优秀的实现方案...

本文的目的是阐述笔者遇到问题的解决步骤和思路，读者了解整体的方案之后，可以根据实际项目进行技术选型。

当然，如果有相关的疑惑，欢迎参考下面两个项目的具体实现，这是笔者基于上文的Paging+Room组件，实现了一个简单的Github的客户端，本文不细述。

1.MVVM架构的Sample: https://github.com/qingmei2/MVVM-Rhine

2.MVI架构的Sample:https://github.com/qingmei2/MVI-Rhine

系列文章

争取打造 Android Jetpack 讲解的最好的博客系列：

• Android官方架构组件Lifecycle：生命周期组件详解&原理分析
• Android官方架构组件ViewModel:从前世今生到追本溯源
• Android官方架构组件LiveData: 观察者模式领域二三事
• Android官方架构组件Paging：分页库的设计美学
• Android官方架构组件Paging-Ex：为分页列表添加Header和Footer
• Android官方架构组件Paging-Ex：列表状态的响应式管理
• Android官方架构组件Navigation：大巧不工的Fragment管理框架
• Android官方架构组件DataBinding-Ex:双向绑定篇

Android Jetpack 实战篇：

• 开源项目：MVVM+Jetpack实现的Github客户端
• 开源项目：基于MVVM, MVI+Jetpack实现的Github客户端
• 总结：使用MVVM尝试开发Github客户端及对编程的一些思考

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费

反思｜Android 事件拦截机制的设计与实现

「反思」 系列是笔者一个新的尝试，其起源与目录请参考 这里 。

概述

完整的掌握 Android 事件分发体系并非易事，其整个流程涉及到了 系统启动流程（SystemServer）、输入管理(InputManager)、系统服务和UI的通信（ViewRootImpl + Window + WindowManagerService）、View层级的 事件分发机制 等等一系列的环节。

事件拦截机制 是基于View层级 事件分发机制 的一个进阶性的知识点，本文将对其进行更细致化的讲解。

事件拦截机制 本身就相对比较独立，因此本文不需要读者有 事件分发机制 相关的预备知识，对后者感兴趣的读者可以参考以下资料：

反思 | Android 事件分发机制的设计与实现

本文整体结构如下图：

从事件序列说起

1、什么是事件序列

想要说清 事件分发机制 和 事件拦截机制，事件序列 是首先要理解的概念。

什么是事件序列？Google官方文档中对其描述为 The duration of the touch，顾名思义，我们可以将其理解为 用户一次完整的触摸操作流程—— 举例来说，用户单击按钮、用户滑动屏幕、用户长按屏幕中某个UI元素等等，都属于该范畴。

2、缘由

为什么 事件序列 是一个非常重要的概念？

上一篇文章 中，读者已经了解事件分发的本质原理就是递归，对此简单的实现方式是：每接收一个新的事件，都需要进行一次递归才能找到对应消费事件的View，并依次向上返回事件分发的结果。

以每个触摸事件作为最基本的单元，都对View树进行一次遍历递归？这对性能的影响显而易见，因此这种设计是有改进空间的。

如何针对这个问题进行改进？将 事件序列 作为最基本的单元进行处理则更为合适。

首先，设计者根据用户的行为对MotionEvent中添加了一个Action的属性以描述该事件的行为：

• ACTION_DOWN：手指触摸到屏幕的行为
• ACTION_MOVE：手指在屏幕上移动的行为
• ACTION_UP：手指离开屏幕的行为
• ...其它Action，比如ACTION_CANCEL...

我们知道，针对用户的一次触摸操作，必然对应了一个 事件序列，从用户手指接触屏幕，到移动手指，再到抬起手指 ——单个事件序列必然包含ACTION_DOWN、ACTION_MOVE ... ACTION_MOVE、ACTION_UP 等多个事件，这其中ACTION_MOVE的数量不确定，ACTION_DOWN和ACTION_UP的数量则为1。

熟悉了 事件序列 的概念，设计者就可以着手对现有代码进行设计和改进，其思路如下：当接收到一个ACTION_DOWN时，意味着一次完整事件序列的开始，通过递归遍历找到真正对事件进行消费的Child，并将其进行保存，这之后接收到ACTION_MOVE和ACTION_UP行为时，则跳过遍历递归的过程，将事件直接分发对应的消费者：

由此可见，事件序列 在 事件分发 的知识体系中的确是非常重要的核心概念（甚至没有之一），其最重要的意义是 足够节省性能：用户一次正常的触摸行为，其 事件序列 包含了若干个触摸事件，这些事件并非每次都通过递归算法去找到事件的消费者，因为这会消耗非常多的内存——当事件序列越复杂、或者View树的层级嵌套越深，这种优势愈发明显。

那么，源码的设计者是如何保证通过一次递归算法找到View树中对应事件消费者的子View，其数据结构又是如何的呢？

认真思考，读者不难得出答案：链表。

为什么是链表

为什么采用链表，有没有更加简单粗暴的实现方案？

当然，最符合直觉 的实现方式似乎是：在通过递归完成第一次事件分发之后，将事件的消费者作为成员保存在当前父View中：

不可否认，这样的设计完全可以实现我们需要的效果，但读者仔细思考得知，这种设计最大的问题就是破坏了树形结构的 内部自治性。

最顶层View直接持有最下层某个View的引用合理吗？答案是否定的。首先，这导致View层级依赖之间的混乱；其次，顶层View本身持有了最下层某个View的引用，则这之间若干个层级的View的target属性都毫无意义。

更能将树结构应用淋漓尽致的方式是构建一个链表：

每个View节点都持有事件的下一级消费者，当同一事件序列后续的触摸事件抵达时，不再需要进行消耗性能的DFS算法，而是直接交给下一级的子View，子View则直接交给下下一级的子View，直到事件到达真正的消费者：

和链表的定义类似，设计者设计了TouchTarget类，同时为每一个ViewGroup都声明这样一个成员，作为链表的一个结点，以描述当前事件序列的传递方向：

public abstract class ViewGroup extends View {

  // 链表的下一级结点
  private TouchTarget mFirstTouchTarget;

  private static final class TouchTarget {
      // 描述接下来的触摸事件由哪一个子View接收并分发
      public View child;
  }
}

那么这个链表是怎么构建的呢？正如上文所说，当接收到一个ACTION_DOWN时，意味着一次完整事件序列的开始，通过递归遍历找到真正对事件进行消费的Child

读者需认真揣摩 事件序列 的相关概念，因为这个知识点贯穿了整个 事件分发机制 流程，可以说是非常核心的知识点；同时，掌握它也是下文快速掌握 事件拦截机制 的关键。

事件拦截机制

大多数Android开发者对 事件拦截机制 都不会陌生，读者应该都有了解，ViewGroup层级额外设计了onInterceptTouchEvent()函数并向外暴露给开发者，以达到让ViewGroup不再将触摸事件交给View处理，而是自身决定是否消费事件，并将结果反馈给上层级的ViewGroup。

1、缘由

为什么设计出这样一种拦截机制？其实这是有必要的，以常规的ScrollView对应的滑动页面为例，当用户抛出了一个列表的滑动操作，这时，对应的触摸事件序列是否还有必要交给ScrollView的子View进行处理？

答案是否定的，当ScrollView接收到滑动操作时，理所当然，本次滑动操作相关事件都不再需要交给子View，而是直接交给ScrollView去处理滑动操作。

读者同样需要明白，并非所有事件序列都会被拦截——当用户点击ScrollView中的某个按钮时，设计者又期望这次的点击操对应的系列事件能够被ScrollView分发给子Button去处理，这样开发者最终能够在按钮本身的OnClickListener中观察到这次点击事件，并进行对应的业务操作。

因此，对于不同类型的ViewGroup，开发者需要在不同的场景下，做出是否拦截事件的决定，这种 父控件根据本身职责去拦截指定场景的事件序列 的行为，我们称之为 事件拦截机制。

2、拦截函数：onInterceptTouchEvent()

那么开发者如何做，才能保证 不同场景的事件被合理的向下分发或直接拦截 呢？设计者据此提供了 onInterceptTouchEvent() 拦截函数：

public abstract class ViewGroup extends View {

  public boolean onInterceptTouchEvent(MotionEvent ev) {
      // ...
      return false;
  }
}

其定义是，当触摸事件到来时，事件首先作为参数传入onInterceptTouchEvent函数中，开发者自定义onInterceptTouchEvent内部逻辑，以决定是否对该事件进行拦截，并将boolean类型的结果进行返回。当返回值为true时，该事件序列接下来所有的事件都会被当前的ViewGroup拦截；通常情况下，ViewGroup的该函数默认返回false，即不对事件进行拦截。

以上文为例，我们可以对ScrollView添加类似如下策略——当用户发起一个 点击事件 的操作时，onInterceptTouchEvent返回false，将事件交给下游的子控件去决定消费与否；而当用户 滑动屏幕 时，则将事件序列进行拦截：

public class ScrollView extends ViewGroup {

  public boolean onInterceptTouchEvent(MotionEvent ev) {
      // 这里模拟一个抽象的函数代替实际的业务逻辑
      // 实际源码中，这里是根据对触摸事件序列的复杂判断，得出操作是否是滑动事件
      if (isUserScrollAction(ev)) {
        return true;
      } else {
        return false;
      }
  }
}

事件序列 在这个过程中再次起到了 至关重要 的作用。针对单独一个触摸事件——例如 ACTION_DOWN或ACTION_MOVE而言，我们都无法确定这是否是我们希望拦截的操作。而当我们获取到 事件序列 中连续若干个事件后，我们则可以根据手势操作的方向和距离（判断是否是滑动）、触摸屏幕的时间（判断是点击事件还是长按事件）对用户的这次行为进行定义，最终决定是否进行拦截。

——这意味着，当ScrollView接收到最初的ACTION_DOWN事件时，父控件并没有立即对事件进行拦截，而是交给了子Button去消费；而当接收了若干个ACTION_MOVE事件时，ScrollView的onInterceptTouchEvent()函数中判断得出 本次触摸行为方向朝下，是滑动事件，然后该函数返回true，导致本次和接下来的触摸事件都会被拦截。

等等！到了这里，读者似乎推断出了一个怪异的结论： 针对一个完整事件序列的向下分发过程而言，触摸事件的消费者并不一定只有一个角色——这似乎不太符合直觉。

但事实的确如此。

既然一个完整的 事件序列 其事件可能会交给不同的角色，这是否意味着极端情况下，用户的一次 滑动行为 不但会触发了父控件本身的 滑动 效果，用户也会同时接收到Button子控件的 点击 效果？

目前为止的设计中确实存在这个缺陷，因此接下来我们需要增加新的逻辑单元去弥补这个问题，ACTION_CANCEL闪亮登场。

3、ACTION_CANCEL：弥补与终结

终于来到了ACTION_CANCEL的舞台，报幕员对这名演员的介绍是两个单词：弥补 和 终结。

现在我们希望，当Button的父控件ScrollView对滑动操作进行了拦截时，Button的点击事件不再会被响应。

正常的逻辑处理中，Button需要在接收到ACTION_UP时，判断整个事件序列持续的时间，如果符合一系列单击操作的前置定义（比如touchable = true或clickable = true等等），就直接交给单击事件的监听器View.OnClickListener去处理。

我们可以将ACTION_UP视为 事件序列 中的 终止事件，但很明显，这个逻辑在 事件拦截机制 中并不适用，因为当父控件对事件进行了拦截后，接下来整个序列中所有的事件都转交给了父控件，子控件再也接受不到任何事件，包括ACTION_UP。

我们总是希望有始有终（比如期待面试结果的及时反馈），事件分发机制 中也是一样，当子控件事件被父控件拦截，子控件也需要一个 终止事件 的通知以作出对应的行为。

因此，设计者额外提供了ACTION_CANCEL事件，以通知当前的View作出对 事件被拦截 之后的收尾工作，比如取消点击事件或长按事件相关判断逻辑中的计时器（如果有的话，下同），或者对当前控件滑动距离计算的重置等等，避免了「既发生父控件滑动」又「触发子控件点击」的尴尬场景。

现在，当父控件拦截了触摸事件后，子控件立即接收到一个额外的ACTION_CANCEL作为弥补，并草草进行了相关的收尾工作，之后的业务逻辑则统统交给了父控件去处理。

事件拦截机制 到此似乎告一段落，读者认真思考，这样的逻辑处理目前已经是完美的了么？

拦截机制与反拦截机制

父控件:「我无效你的效果。」
子控件:「我无效你的无效。」

1、压迫与抗争

音乐播放器的进度条控件SeekBar提出了严重抗议。

当SeekBar与ScrollView搭配使用时，前者愕然发现，作为子控件，其最引以为豪的技能——滑动调整音频进度的功能完全被废掉了。

这是当然的，ScrollView接收到滑动事件时，会很自然的将接下来相关的所有事件都进行拦截，而作为子控件的SeekBar连汤都喝不上。

这是不合理的设计，父控件的权利实在太大了，而子控件对此完全束手无策。因此设计者为ViewGroup设计了一个另外一个API——requestDisallowInterceptTouchEvent(boolean)。

该函数的作用是，命令指定的ViewGroup 是否 不再针对事件序列进行拦截 ，而是正常将事件交给子控件去处理是否消费事件。

以SeekBar为例，其完全可以这样设计：

public abstract class AbsSeekBar extends ProgressBar {

   // ...代码大幅简化，具体逻辑请参考源码...
   @Override
   public boolean onTouchEvent(MotionEvent event) {
        switch (event.getAction()) {
          // 当接收到ACTION_DOWN事件时，命令父控件不能拦截事件序列
          case MotionEvent.ACTION_DOWN:
              mParent.requestDisallowInterceptTouchEvent(true);
              break;
          // ...
        }
   }
}

现在，即使ScrollView内部持有对 滑动操作 相关的拦截机制，但SeekBar依然可以通过更高等级的API对其进行压制，从而跳过父控件相关的拦截，并自己消费滑动事件——最终用户得到了他希望得到的操作体验（滑动调节播放进度）。

2、更深入性思考

上一小节的叙述本身是存在瑕疵的，通常来说，调节进度的SeekBar处理的是横向滑动，而ScrollView处理的则是竖向滑动，本质上两者逻辑并不冲突。

这样描述，只是为了让读者能够更容易的理解 反拦截机制 对应的requestDisallowInterceptTouchEvent()函数设计的目的及意义，对此读者不必深究——当然，读者也可自定义实现一个横向滑动的HorizontalScrollView，以得到上一小节中滑动冲突的效果，本文不赘述。

另外一点需要思考的是，当子控件调用了父控件的requestDisallowInterceptTouchEvent(true)函数无效化了父控件的拦截机制之后，父控件拦截机制的无效化需要一直存在吗 ？

答案是否定的，正确的方式是应该在某个时间点 对父控件拦截机制进行重启——即调用requestDisallowInterceptTouchEvent(false)，这样才能保证在触摸到其它子控件时，父控件依然能够对 事件拦截机制 进行正常的运转。

那么这个重置的时间点如何把握，在子控件接收到ACTION_UP时调用吗？

在子控件 事件序列的终止事件中重置状态，这听起来不错，但是需要注意的是，拦截机制被无效化的状态是存在父控件ViewGroup中的，因此换个思路，更好的时机会不会其实是隐藏在ViewGroup中的呢？

3、更好的时机

设计者最终将重置的时机放在了父控件 事件序列的起始事件——ACTION_DOWN的处理逻辑中。

public abstract class ViewGroup extends View {

  @Override
  public boolean dispatchTouchEvent(MotionEvent ev) {
      // ...
      if (actionMasked == MotionEvent.ACTION_DOWN) {
         // 1.这个函数内部将事件拦截功能的开关进行了重置
         resetTouchState();
      }
      // ...2.继续处理事件拦截和事件分发
  }
}

这确实是重置拦截机制的更好时机，既保证了其它子控件的触摸事件不会被之前的反拦截机制所影响，同时也维护了ViewGroup内部本身的自治性。

这也证明了 事件序列 中的起始事件 ACTION_DOWN 总是可以被父控件接收到并进行拦截处理，因此，开发者绝大多数情况下不能在 ViewGroup 的 onInterceptTouchEvent() 中，直接对ACTION_DOWN事件返回true，因为这将会导致父控件拦截了整个 事件序列 ，子控件连ACTION_DOWN都接受不到，反拦截机制彻底失效。

总结

事件拦截机制 是一个非常重要的基础知识点，而 事件序列 又是其中最核心的概念，无论是 事件分发 还是 事件拦截，搞懂了 事件序列 的意义，其它逻辑概念的理解都不再困难。

参考 & 额外的话

这一篇文章就能让我理解Android事件拦截机制吗？

当然不能，在撰写本文的过程中，笔者最终删除了若干更细节知识点的讲解，比如:

• 父控件拦截了事件后，其内部的mFirstTouchTarget发生了怎样的变化？（事件传递链表的更新操作）
• 事件的拦截机制常常用于解决开发中的哪些问题？(解决滑动冲突)

等等，这些细节同样十分重要，它们是填充 事件拦截机制 完整体系的血与肉，建议读者结合本文与下列相关资料，开启一次更细致的探究之旅。

• 1、Android源码
• 2、「Android开发艺术探索」

关于我

Hello，我是 却把清梅嗅，女儿奴，源码的眷者，观众途径序列1，杀人游戏信徒，大头菜投机者，端茶递水工程师。欢迎关注我的 博客 或者 GitHub。

如果您觉得文章对您有价值，欢迎 ❤️，或通过下方打赏功能，督促我写出更好的文章 :)

• 我的学习体系
• 关于知识付费
• 关于「反思」系列

反思｜Android 输入系统 & ANR机制的设计与实现

反思 系列博客是我的一种新学习方式的尝试，该系列起源和目录请参考 这里 。

概述

对于Android开发者而言，ANR是一个老生常谈的问题，站在面试者的角度，似乎说出 「不要在主线程做耗时操作」 就算合格了。

但是，ANR机制到底是什么，其背后的原理究竟如何，为什么要设计出这样的机制？这些问题时时刻刻会萦绕脑海，而想搞清楚这些，就不得不提到Android自身的 输入系统 （Input System）。

Android自身的 输入系统 又是什么？一言以蔽之，任何与Android设备的交互——我们称之为 输入事件，都需要通过 输入系统 进行管理和分发；这其中最靠近上层，并且最典型的一个小环节就是View的 事件分发 流程。

这样看来，输入系统 本身确实是一个非常庞大复杂的命题，并且，越靠近底层细节，越容易有一种 只见树木不见树林 之感，反复几次，直至迷失在细节代码的较真中，一次学习的努力尝试付诸东流。

因此，控制住原理分析的粒度，在宏观的角度，系统地了解输入系统本身的设计理念，并引申到实际开发中的ANR现象的原理和解决思路 ，是一个非常不错的理论与实践相结合的学习方式，这也正是笔者写作本文的初衷。

本文篇幅较长，思维导图如下：

一、自顶向下探索

谈到Android系统本身，首先，必须将 应用进程 和 系统进程 有一个清晰的认知，前者一般代表开发者依托Android平台本身创造开发的应用；后者则代表 Android系统自身创建的核心进程。

这里我们抛开 应用进程 ，先将视线转向 系统进程，因为 输入系统 本身是由后者初始化和管理调度的。

Android系统在启动的时候,会初始化zygote进程和由zygote进程fork出来的SystemServer进程；作为 系统进程 之一，SystemServer进程会提供一系列的系统服务，而接下来要讲到的InputManagerService也正是由 SystemServer 提供的。

在SystemServer的初始化过程中，InputManagerService(下称IMS)和WindowManagerService(下称WMS)被创建出来；其中WMS本身的创建依赖IMS对象的注入：

// SystemServer.java
private void startOtherServices() {
 // ...
 InputManagerService inputManager = new InputManagerService(context);
 // inputManager作为WindowManagerService的构造参数
 WindowManagerService wm = WindowManagerService.main(context,inputManager, ...);
}

在 输入系统 中，WMS非常重要，其负责管理IMS、Window与ActivityManager之间的通信，这里点到为止，后文再进行补充，我们先来看IMS。

顾名思义，IMS服务的作用就是负责输入模块在Java层级的初始化，并通过JNI调用，在Native层进行更下层输入子系统相关功能的创建和预处理。

在JNI的调用过程中，IMS创建了NativeInputManager实例，NativeInputManager则在初始化流程中又创建了EventHub和InputManager:

NativeInputManager::NativeInputManager(jobject contextObj, jobject serviceObj, const sp<Looper>& looper) : mLooper(looper), mInteractive(true) {
    // ...
    // 创建一个EventHub对象
    sp<EventHub> eventHub = new EventHub();
    // 创建一个InputManager对象
    mInputManager = new InputManager(eventHub, this, this);
}

此时我们已经处于Native层级。读者需要注意，对于整个Native层级而言，其向下负责与Linux的设备节点中获取输入，向上则与靠近用户的Java层级相通信，可以说是非常重要。而在该层级中，EventHub和InputManager又是最核心的两个角色。

这两个角色的职责又是什么呢？首先来说EventHub，它是底层 输入子系统 中的核心类，负责从物理输入设备中不断读取事件（Event)，然后交给InputManager,后者内部封装了InputReader和InputDispatcher，用来从EventHub中读取事件和分发事件：

InputManager::InputManager(...) {
    mDispatcher = new InputDispatcher(dispatcherPolicy);
    mReader = new InputReader(eventHub, readerPolicy, mDispatcher);
    initialize();
}

简单来看，EventHub建立了Linux与输入设备之间的通信，InputManager中的InputReader和InputDispatcher负责了输入事件的读取和分发，在 输入系统 中，两者的确非常重要。

这里借用网上的图对此进行一个简单的概括：

二、EventHub 与 epoll 机制

对于EventHub的具体实现，绝大多数App开发者也许并不需要去花太多时间深入——简单了解其职责，然后一笔带过似乎是笔划算的买卖。

但是在EventHub的实现细节中笔者发现，其对epoll机制的利用是一个非常经典的学习案例，因此，花时间稍微深入了解也绝对是一举两得。

上文说到，EventHub建立了Linux与输入设备之间的通信，其实这种描述是不准确的，那么，EventHub是为了解决什么问题而设计的呢，其具体又是如何实现的？

1、多输入设备与输入子系统

我们知道，Android设备可以同时连接多个输入设备，比如 屏幕 、 键盘 、 鼠标 等等，用户在任意设备上的输入都会产生一个中断，经由Linux内核的中断处理及设备驱动转换成一个Event，最终交给用户空间的应用程序进行处理。

Linux内核提供了一个便于将不同设备不同数据接口统一转换的抽象层，只要底层输入设备驱动程序按照这层抽象接口实现，应用就可以通过统一接口访问所有输入设备，这便是Linux内核的 输入子系统。

那么 输入子系统 如何是针对接收到的Event进行的处理呢？这就不得不提到EventHub了，它是底层Event处理的枢纽，其利用了epoll机制，不断接收到输入事件Event，然后将其向上层的InputReader传递。

2、什么是epoll机制

这是常见于面试Handler相关知识点时的一道进阶题，变种问法是：「既然Handler中的Looper中通过一个死循环不断轮询，为什么程序没有因为无限死循环导致崩溃或者ANR?」

读者应该知道，Handler简单的利用了epoll机制，做到了消息队列的阻塞和唤醒。关于epoll机制，这里有一篇非常经典的解释，不了解其设计理念的读者 有必要 了解一下：

知乎：epoll或者kqueue的原理是什么?

参考上文，这里我们对epoll机制进行一个简单的总结:

epoll可以理解为event poll，不同于忙轮询和无差别轮询，在 多个输入流 的情况下，epoll只会把哪个流发生了怎样的I/O事件通知我们。此时我们对这些流的操作都是有意义的。

EventHub中使用epoll的恰到好处——多个物理输入设备对应了多个不同的输入流，通过epoll机制，在EventHub初始化时，分别创建mEpollFd和mINotifyFd；前者用于监听设备节点是否有设备文件的增删，后者用于监听是否有可读事件，创建管道，让InputReader来读取事件：

三、事件的读取和分发

本章节将对InputReader和InputDispatcher进行系统性的介绍。

1、InputReader：读取事件

InputReader是什么？简单理解InputReader的作用，通过从EventHub获取事件后，将事件进行对应的处理，然后将事件进行封装并添加到InputDispatcher的队列中，最后唤醒InputDispatcher进行下一步的事件分发。

乍得一看，在 输入系统 的Native层中，InputReader似乎平凡无奇，但越是看似朴实无华的事物，在整个流程中往往占据绝对重要的作用。

首先，EventHub传过来的Event除了普通的 输入事件 外，还包含了设备本身的增、删、扫描 等事件，这些额外的事件处理并没有直接交给InputDispatcher去分发，而是在InputReader中进行了处理。

当某个时间发生——可能是用户 按键输入，或者某个 设备插入，亦或 设备属性被调整 ，epoll_wait()返回并将Event存入。

这之后，InputReader对输入事件进行了一次读取，因为不同设备对事件的处理逻辑又各自不同，因此InputReader内部持有一系列的Mapper对事件进行 匹配 ，如果不匹配则忽略事件，反之则将Event封装成一个新的NotifyArgs数据对象，准备存入队列中，即唤醒InputDispatcher进行分发。

巧妙的是，在唤醒InputDispatcher进行分发之前，InputReader在自己的线程中先执行了一个很特殊的 拦截操作 环节。

2、输入事件的拦截和转换

读者知道，在应用开发中，一些特殊的输入事件是无法通过普通的方式进行拦截的；比如音量键，Power键，电话键，以及一些特殊的组合键，这里我们通称为 系统按键。

这点无可厚非，虽然Android系统对于开发者足够的开放，但是一切都是有限制的，绝大多数的 用户按键 通常可以被应用拦截处理，但是 系统按键 绝对不行——这种限制往往能够给予用户设备安全最后的保障。

因此，在InputReader唤醒InputDispatcher进行事件分发之前，InputReader在自己的线程中进行了两轮拦截处理。

首先的第一轮拦截操作就是对 系统按键 级别的 输入事件 进行处理，对于手机而言，这个工作是在PhoneWindowManager中完成；举例来说，当用户按了Power（电源）键，Android设备本身会切唤醒或睡眠——即亮屏和息屏。

这也正是「在技术论坛中，通常对 系统按键 拦截处理的技术方案，基本都是需要修改PhoneWindowManager的源码」的原因。

接下来输入事件进入到第二轮的处理中，如果用户在Setting->Accessibility中选择打开某些功能，以 手势识别 为例，Android的AccessbilityManagerService（辅助功能服务) 可能会根据需要转换成新的Event，比如说两根手指头捏动的手势最终会变成ZoomEvent。

需要注意的是，这里的拦截处理并不会真正将事件 消费 掉，而是通过特殊的方式将事件进行标记（policyFlags），然后在InputDispatcher中处理。

至此，InputReader对 输入事件 完整的一轮处理到此结束，这之后，InputReader又进入了新一轮等待。

3、InputDispatcher：分发事件

当wake()函数将在Looper中睡眠等待的InputDispatcher唤醒时，InputDispatcher开始新一轮事件的分发。

准确来说，InputDispatcher被唤醒时，wake()函数实际是在InputManagerService的线程中执行的，即整个流程的线程切换顺序为InputReaderThread -> InputManagerServiceThread -> InputDispatcherThread。

InputDispatcher的线程负责将接收到的 输入事件 分发给 目标应用窗口，在这个过程中，InputDispatcher首先需要对上个环节中标记了需要拦截的 系统按键 相关事件进行拦截，被拦截的事件至此不再向下分发。

这之后，InputDispatcher进入了本文最关键的一个环节——调用 findFocusedWindowTargetLocked()获取当前的 焦点窗口 ，同时检测目标应用是否有ANR发生。

如果检测到目标窗口处于正常状态，即ANR并未发生时，InputDispatcher进入真正的分发程序，将事件对象进行新一轮的封装，通过SocketPair唤醒目标窗口所在进程的Looper线程，即我们应用进程中的主线程，后者会读取相应的键值并进行处理。

表面来看，整个分发流程似乎干净简洁且便于理解，但实际上InputDispatcher整个流程的逻辑十分复杂，试想一次事件分发要横跨3个线程的流程又怎会简单？

此外，InputDispatcher还负责了 ANR 的处理，这又导致整个流程的复杂度又上升了一个层级，这个流程我们在后文的ANR章节中进行更细致的分析，因此先按住不提。

接下来，我们来看看整个 输入事件 的分发流程中， 应用进程 是如何与 系统进程 建立相应的通信链接的。

4、通过Socket建立通信

关于 跨进程通信的建立 这一节，笔者最初打算作为一个大的章节来讲，但是对于整个 输入系统 而言，其似乎又只是一个 重要非必需 的知识点。最终，笔者将其放在一个小节中进行简单的描述，有兴趣的读者可以在文末的参考链接中查阅更详尽的资料。

我们知道，InputReader和InputDispatcher运行在system_server 系统进程 中，而用户操作的应用都运行在自己的 应用进程 中；这里就涉及到跨进程通信，那么 应用进程 是如何与 系统进程 建立通信的呢？

让我们回到文章最初WindowManagerService(WMS)和InputManagerService(IMS)初始化的流程中来，当IMS以及其他的系统服务初始化完成之后，应用程序开始启动。

如果一个应用程序有Activity（只有Activity能够接受用户输入），那么它要将自己的Window注册到WMS中。

在这里，Android使用了Socket而不是Binder来完成。WMS中通过OpenInputChannelPair生成了两个Socket的FD， 代表一个双向通道的两端：向一端写入数据，另外一端便可以读出；反之，如果一端没有写入数据，另外一端去读，则陷入阻塞等待。

最终InputDispatcher中建立了目标应用的Connection对象，代表与远端应用的窗口建立了链接；同样，应用进程中的ViewRootImpl创建了WindowInputEventReceiver用于接受InputDispatchor传过来的事件：

这里我们对该次 跨进程通信建立流程 有了初步的认知，对于Android系统而言，Binder是最广泛的跨进程通信的应用方式，但是Android系中跨进程通信就仅仅只用到了Binder吗？答案是否定的，至少在 输入系统 中，除了Binder之外，Socket同样起到了举足轻重的作用。

那么新的问题就来了，这里为什么选择Socket而不是选择Binder呢，关于这个问题的解释，笔者找到了一个很好的版本：

Socket可以实现异步的通知，且只需要两个线程参与（Pipe两端各一个），假设系统有N个应用程序，跟输入处理相关的线程数目是 N+1 (1是Input Dispatcher线程）。然而，如果用Binder实现的话，为了实现异步接收，每个应用程序需要两个线程，一个Binder线程，一个后台处理线程（不能在Binder线程里处理输入，因为这样太耗时，将会堵塞住发送端的调用线程）。在发送端，同样需要两个线程，一个发送线程，一个接收线程来接收应用的完成通知，所以，N个应用程序需要 2（N+1)个线程。相比之下，Socket还是高效多了。

现在，应用进程 能够收到由InputDispatcher处理完成并分发过来的 输入事件 了。至此，我们来到了最熟悉的应用层级事件分发流程。对于这之后 应用层级的事件分发，可以阅读下述笔者的另外两篇文章，本文不赘述。

• Android 事件分发机制的设计与实现
• Android 事件拦截机制的设计与实现

[译]使用MVI打造响应式APP(三):状态折叠器

原文：REACTIVE APPS WITH MODEL-VIEW-INTENT - PART3 - STATE REDUCER
作者：Hannes Dorfmann
译者：却把清梅嗅

在上一章节中,我们针对 如何使用单向流和 Model-View-Intent 模式构建一个简单的页面 进行了探讨；本章节，我们将在reducer的帮助下实现MVI模式中更加复杂的页面。

如果你还未阅读前两个章节，阅读本文之前您应该先去阅读它们，从而对如下两个问题的答案有初步的了解：

• 1.我们如何通过Presenter将View层和业务逻辑相关联？
• 2.数据流是如何保证单向性的？

如下图所示，现在我们构建这样一个复杂的页面：

如你所见，屏幕中显示的是按照类别进行归类的商品列表；App每次只会为每个分类展示3个条目，当用户点击了 加载更多 按钮时，将会通过网络请求去加载该分类下所有的条目。

此外，用户还可以执行 下拉刷新 的操作，并且一旦用户向下滚动到列表末尾，分页功能就会继续加载下一页的数据——当然，所有这些行为可以同时执行，并且每个行为都可能会收到失败（即没有互联网连接）。

让我们一步步来，首先，我们先对View层的接口进行实现：

public interface HomeView {

  /**
   * 加载第一页数据的intent
   *
   * @return 发射的数据是没有意义的，true或者false没有区别
   */
  public Observable<Boolean> loadFirstPageIntent();

  /**
   * 分页加载下一页的intent
   *
   * @return 发射的数据是没有意义的，true或者false没有区别
   */
  public Observable<Boolean> loadNextPageIntent();

  /**
   * 对下拉刷新的响应intent
   *
   * @return 发射的数据是没有意义的，true或者false没有区别
   */
  public Observable<Boolean> pullToRefreshIntent();

  /**
   * 根据当前分类加载所有条目的intent
   *
   * @return 指定分类，String代表分类的名字
   */
  public Observable<String> loadAllProductsFromCategoryIntent();

  /**
   * 对ViewState进行渲染
   */
  public void render(HomeViewState viewState);
}

View层具体的实现简单明了，本文将不进行展示（但你可以在Github上找到它）。

接下来让我们把目光转向Model，正如前文所提到的，Model应该反应了状态，现在我来介绍一下Model的具体实现：HomeViewState。

public final class HomeViewState {

  private final boolean loadingFirstPage; // RecyclerView加载状态的指示器
  private final Throwable firstPageError; // 如果非空，展示一个error
  private final List<FeedItem> data;   // 列表的数据
  private final boolean loadingNextPage; // RecyclerView分页加载状态的指示器
  private final Throwable nextPageError; // 如果非空，展示分页error的toast
  private final boolean loadingPullToRefresh; // 展示下拉刷新状态的指示器
  private final Throwable pullToRefreshError; // 非空意味着下拉刷新的error

   // ... 构造器 ...
   // ... getter方法  ...
}

请注意，FeedItem 仅仅是一个接口，每个条目都需要实现该接口，然后交给RecyclerView去展示。比如 Product 实现了 FeedItem；此外，列表中的类别标题 SectionHeader 也实现了 FeedItem；还有，作为UI中的元素之一，表示 “可以加载该类别更多” 的指示器同样也是 FeedItem，其内部还持有了一个小状态——该状态代表了当前是否 正在加载更多条目 。

public class AdditionalItemsLoadable implements FeedItem {
  private final int moreItemsAvailableCount;
  private final String categoryName;
  private final boolean loading; // true 代表item正处于加载状态
  private final Throwable loadingError; // 标志loading时捕获到了error

   // ... 构造器 ...
   // ... getter方法  ...

这之后便是压轴的业务逻辑组件 HomeFeedLoader ，它负责对 FeedItems 进行加载：

public class HomeFeedLoader {

  // 通常由 下拉刷新 动作触发
  public Observable<List<FeedItem>> loadNewestPage() { ... }

  // 加载第一页
  public Observable<List<FeedItem>> loadFirstPage() { ... }

  // 加载下一页
  public Observable<List<FeedItem>> loadNextPage() { ... }

  // 加载某个分类的其它产品
  public Observable<List<Product>> loadProductsOfCategory(String categoryName) { ... }
}

现在，让我们一步步将这些点在Presenter中进行连接。请注意，接下来Presenter中展示的部分代码，在真实的开发中，应该被转移到Interactor(交互器)中（这并非是为了更好的可读性）。首先，我们先开始对初始化数据进行加载：

class HomePresenter extends MviBasePresenter<HomeView, HomeViewState> {

  private final HomeFeedLoader feedLoader;

  @Override protected void bindIntents() {

    // 在真实的开发中，应该被转移到Interactor中
    Observable<HomeViewState> loadFirstPage = intent(HomeView::loadFirstPageIntent)
        .flatMap(ignored -> feedLoader.loadFirstPage()
            .map(items -> new HomeViewState(items, false, null) )
            .startWith(new HomeViewState(emptyList, true, null) )
            .onErrorReturn(error -> new HomeViewState(emptyList, false, error))

    subscribeViewState(loadFirstPage, HomeView::render);
  }
}

到目前为止感觉良好，和上一章节我们实现的Search界面相比，没有什么太大的不同。

现在我们尝试添加对 下拉刷新 的支持：、

class HomePresenter extends MviBasePresenter<HomeView, HomeViewState> {

  private final HomeFeedLoader feedLoader;

  @Override protected void bindIntents() {

    // 在真实的开发中，应该被转移到Interactor中
    Observable<HomeViewState> loadFirstPage = ... ;

    Observable<HomeViewState> pullToRefresh = intent(HomeView::pullToRefreshIntent)
        .flatMap(ignored -> feedLoader.loadNewestPage()
            .map( items -> new HomeViewState(...))
            .startWith(new HomeViewState(...))
            .onErrorReturn(error -> new HomeViewState(...)));

    Observable<HomeViewState> allIntents = Observable.merge(loadFirstPage, pullToRefresh);

    subscribeViewState(allIntents, HomeView::render);
  }
}

稍微等一下：feedLoader.loadNewestPage() 仅仅返回了新的条目数据，但是之前我们已经加载了的条目怎么办？

“传统”的MVP模式中，我们可以调用类似view.addNewItems(newItems)的方法，但是在 第一篇文章 中，我们已经探讨了为什么这不是一个好主意（状态问题）。

我们当前面临的问题是，下拉刷新依赖了之前的状态，因为我们想要将下拉刷新返回的条目和之前已经加载的条目进行 合并。

女士们，先生们，现在，让我们热情地欢迎状态折叠器（State Reducer）的到来！

State Reducer是函数式编程中的一个概念，它 将前一个状态作为输入，并根据前一个状态计算得出一个新的状态，就像这样：

public State reduce( State previous, Foo foo ){
  State newState;
  // ... 根据前一个状态计算得出一个新的状态 ...
  return newState;
}

因此上述问题的解决方案是，我们定义一个Foo组件，通过其类似reduce()的函数，结合之前的状态计算出一个新的状态。

这个名为Foo的组件通常意味着我们希望对之前状态所进行的改变，在我们的案例中，我们希望将 最初通过loadFirstPageIntent计算得到的HomeViewState 和 下拉刷新得到的结果 进行reduce。

你猜怎么着，RxJava有一个名为 scan() 的操作符，让我们对我们的代码进行略微的重构，我们需要引入另外一个表示 部分改变 的类—— 上面我们将其称之为Foo，它将用于计算新的状态。

class HomePresenter extends MviBasePresenter<HomeView, HomeViewState> {

  private final HomeFeedLoader feedLoader;

  @Override protected void bindIntents() {

    Observable<PartialState> loadFirstPage = intent(HomeView::loadFirstPageIntent)
        .flatMap(ignored -> feedLoader.loadFirstPage()
            .map(items -> new PartialState.FirstPageData(items) )
            .startWith(new PartialState.FirstPageLoading(true) )
            .onErrorReturn(error -> new PartialState.FirstPageError(error))

    Observable<PartialState> pullToRefresh = intent(HomeView::pullToRefreshIntent)
        .flatMap(ignored -> feedLoader.loadNewestPage()
            .map( items -> new PartialState.PullToRefreshData(items)
            .startWith(new PartialState.PullToRefreshLoading(true)))
            .onErrorReturn(error -> new PartialState.PullToRefreshError(error)));

    Observable<PartialState> allIntents = Observable.merge(loadFirstPage, pullToRefresh);
    // 展示第一页数据加载中...
    HomeViewState initialState = ... ;
    Observable<HomeViewState> stateObservable = allIntents.scan(initialState, this::viewStateReducer)

    subscribeViewState(stateObservable, HomeView::render);
  }

  private HomeViewState viewStateReducer(HomeViewState previousState, PartialState changes){
     ...
   }
 }

我们在这里做了什么？相比较直接返回Observable<HomeViewState>，现在每个Intent返回的是Observable<PartialState>。这之后我们通过merge()操作符将其全部合并为一个可观察的流中，并最终应用到了reducer的函数中（即Observable.scan()）。

这意味着，无论何时用户发起了一个intent,这个intent将会生产一个PartialState的实例，然后被reduced得到了HomeViewState,最终，被View层进行展示（HomeView.render(HomeViewState)）。

唯一遗漏的部分应该就是state reducer的函数本身了，如上文中的定义一样，HomeViewState类本身并未发生了改变，但是我们通过Builder模式添加了一个Builder，这样我们就可以非常便捷地创建一个新的HomeViewState实例。

现在让我们开始实现state reducer的函数：

private HomeViewState viewStateReducer(HomeViewState previousState, PartialState changes){
    if (changes instanceof PartialState.FirstPageLoading)
        return previousState.toBuilder() // 根据当前状态复制一个内部同样状态的对象
        .firstPageLoading(true) // 展示progressBar
        .firstPageError(null) // 不展示error
        .build()

    if (changes instanceof PartialState.FirstPageError)
     return previousState.builder()
         .firstPageLoading(false) // 隐藏progressBar
         .firstPageError(((PartialState.FirstPageError) changes).getError()) // 展示error
         .build();

     if (changes instanceof PartialState.FirstPageLoaded)
       return previousState.builder()
           .firstPageLoading(false)
           .firstPageError(null)
           .data(((PartialState.FirstPageLoaded) changes).getData())
           .build();

     if (changes instanceof PartialState.PullToRefreshLoading)
      return previousState.builder()
            .pullToRefreshLoading(true) // 展示下拉刷新的UI指示器
            .nextPageError(null)
            .build();

    if (changes instanceof PartialState.PullToRefreshError)
      return previousState.builder()
          .pullToRefreshLoading(false) // 隐藏下拉刷新的UI指示器
          .pullToRefreshError(((PartialState.PullToRefreshError) changes).getError())
          .build();

    if (changes instanceof PartialState.PullToRefreshData) {
      List<FeedItem> data = new ArrayList<>();
      data.addAll(((PullToRefreshData) changes).getData()); // 将新的数据插入到当前列表的顶部
      data.addAll(previousState.getData());
      return previousState.builder()
        .pullToRefreshLoading(false)
        .pullToRefreshError(null)
        .data(data)
        .build();
    }


   throw new IllegalStateException("Don't know how to reduce the partial state " + changes);
}

我知道，这些代码看起来并不优雅，但这不是本文的重点——为什么博主会在他的文章中展示如此 “丑陋” 的代码？

因为我希望能够阐述一个观点，我认为 读者并不应该为源码中错综复杂的逻辑买单 ，比如，我们的购物车App中，也不需要读者对某些设计模式有额外的知识储备。

因此，我认为博客文章中最好避免出现设计模式，这的确会展示出更好的代码，但其本身就意味着 更高的阅读理解成本。

回顾本文，其重点是对State Reducer进行配置，通过上述的代码，大家都能够更快更准确地去了解它是什么。但你会在实际开发中这样编写代码吗？当然不会，我会去使用设计模式或者其它的解决方案，比如使用 public HomeViewState computeNewState(previousState) 之类的方法将PartialState定义为接口。

好吧，我想你已经了解了State Reducer是如何工作的，让我们实现剩下来的功能：分页以及能够加载某个指定分类更多的Item：

class HomePresenter extends MviBasePresenter<HomeView, HomeViewState> {

  private final HomeFeedLoader feedLoader;

  @Override protected void bindIntents() {

    Observable<PartialState> loadFirstPage = ... ;
    Observable<PartialState> pullToRefresh = ... ;

    Observable<PartialState> nextPage =
      intent(HomeView::loadNextPageIntent)
          .flatMap(ignored -> feedLoader.loadNextPage()
              .map(items -> new PartialState.NextPageLoaded(items))
              .startWith(new PartialState.NextPageLoading())
              .onErrorReturn(PartialState.NexPageLoadingError::new));

      Observable<PartialState> loadMoreFromCategory =
          intent(HomeView::loadAllProductsFromCategoryIntent)
              .flatMap(categoryName -> feedLoader.loadProductsOfCategory(categoryName)
                  .map( products -> new PartialState.ProductsOfCategoryLoaded(categoryName, products))
                  .startWith(new PartialState.ProductsOfCategoryLoading(categoryName))
                  .onErrorReturn(error -> new PartialState.ProductsOfCategoryError(categoryName, error)));


    Observable<PartialState> allIntents = Observable.merge(loadFirstPage, pullToRefresh, nextPage, loadMoreFromCategory);
    // 展示第一页正在加载
    HomeViewState initialState = ... ;
    Observable<HomeViewState> stateObservable = allIntents.scan(initialState, this::viewStateReducer)

    subscribeViewState(stateObservable, HomeView::render);
  }

  private HomeViewState viewStateReducer(HomeViewState previousState, PartialState changes){
    // ... 第一页的部分状态处理和下拉刷新 ...

      if (changes instanceof PartialState.NextPageLoading) {
       return previousState.builder().nextPageLoading(true).nextPageError(null).build();
     }

     if (changes instanceof PartialState.NexPageLoadingError)
       return previousState.builder()
           .nextPageLoading(false)
           .nextPageError(((PartialState.NexPageLoadingError) changes).getError())
           .build();


     if (changes instanceof PartialState.NextPageLoaded) {
       List<FeedItem> data = new ArrayList<>();
       data.addAll(previousState.getData());
        // 将新的数据添加到list的尾部
       data.addAll(((PartialState.NextPageLoaded) changes).getData());

       return previousState.builder().nextPageLoading(false).nextPageError(null).data(data).build();
     }

     if (changes instanceof PartialState.ProductsOfCategoryLoading) {
         int indexLoadMoreItem = findAdditionalItems(categoryName, previousState.getData());

         AdditionalItemsLoadable ail = (AdditionalItemsLoadable) previousState.getData().get(indexLoadMoreItem);

         AdditionalItemsLoadable itemsThatIndicatesError = ail.builder() // 创建所有item的副本
         .loading(true).error(null).build();

         List<FeedItem> data = new ArrayList<>();
         data.addAll(previousState.getData());
         data.set(indexLoadMoreItem, itemsThatIndicatesError); // 这将会展示一个loading的指示器

         return previousState.builder().data(data).build();
      }

     if (changes instanceof PartialState.ProductsOfCategoryLoadingError) {
       int indexLoadMoreItem = findAdditionalItems(categoryName, previousState.getData());

       AdditionalItemsLoadable ail = (AdditionalItemsLoadable) previousState.getData().get(indexLoadMoreItem);

       AdditionalItemsLoadable itemsThatIndicatesError = ail.builder().loading(false).error( ((ProductsOfCategoryLoadingError)changes).getError()).build();

       List<FeedItem> data = new ArrayList<>();
       data.addAll(previousState.getData());
       data.set(indexLoadMoreItem, itemsThatIndicatesError); // 这将会展示一个error和重试的button
       return previousState.builder().data(data).build();
     }

     if (changes instanceof PartialState.ProductsOfCategoryLoaded) {
       String categoryName = (ProductsOfCategoryLoaded) changes.getCategoryName();
       int indexLoadMoreItem = findAdditionalItems(categoryName, previousState.getData());
       int indexOfSectionHeader = findSectionHeader(categoryName, previousState.getData());

       List<FeedItem> data = new ArrayList<>();
       data.addAll(previousState.getData());
       removeItems(data, indexOfSectionHeader, indexLoadMoreItem); // 移除指定分类下的所有item

       // 添加指定分类下的所有item (包括之前已经被移除的)
       data.addAll(indexOfSectionHeader + 1,((ProductsOfCategoryLoaded) changes).getData());

       return previousState.builder().data(data).build();
     }

     throw new IllegalStateException("Don't know how to reduce the partial state " + changes);
  }
}

实现分页加载和下拉刷新十分相似，异同之处仅仅在于前者是把加载到的数据添加在列表末尾，而下拉刷新则是把数据展示在界面顶部。

更有趣的是我们如何针对某个类别去加载更多条目：为了展示某个类别的加载指示器和错误/重试的按钮，我们只需在所有的FeedItems列表中找到对应的AdditionalItemsLoadable对象，然后我们将其改变为展示加载指示器或者错误/重试的按钮。

如果我们已成功加载某个类别的所有条目，我们将搜索SectionHeader和AdditionalItemsLoadable，并用新加载的列表替换这里的所有条目，仅此而已。

结语

本文的目的是向您展示 状态折叠器（State Reducer） 如何帮助我们通过 简洁且易读 的代码构建复杂的页面。现在回过头来思考，“传统”的MVP或者MVVM针对这些功能，在不使用State Reducer的前提下是如何实现这些功能的。

显然，能够使用State Reducer的关键是我们有一个反映状态的Model类，这也印证了该系列的第一篇文章中所阐述的，为什么理解 Model 是那么的重要。

此外，只有当我们确定状态（或准确的Model）来自单一的数据源时，才能使用State Reducer，因此单向数据流同样非常重要。

我希望我们花费在 阅读 并 理解 前两篇博客的时间是有意义的，现在，所有的点都成功的连在了一起，是时候欢呼了。

如果还没有，不用担心，对此我也花了相当长的时间才完全理解——还有很多次练习、错误和重试。

在第二篇博客中，针对搜索界面，我们并未使用State Reducer。这是因为如果我们以某种方式依赖于先前的状态，State Reducer是有意义的。而在“搜索界面”中，我们不依赖于先前的状态。

虽然在最后，但是我还是想重申，也许你还没有注意到，那就是我们的data都是不可变的——我们总是创建HomeViewState新的实例，而不是在已有的对象上调用其setter方法，这也使得多线程不再是问题。

用户可以在加载下一页的同时开始下拉刷新并加载某个类别的更多条目，因为State Reducer总是能够产生正确的状态，却不依赖于http响应的任何特定顺序。另外，我们用纯函数编写了代码，没有任何副作用。这使我们的代码非常具有可测试性、可重现性、易于推演和高度可并行化（即多线程）。

当然，State Reducer并非是MVI发明的，您可以在多种编程语言的许多三方库，框架和系统中找到其概念。它完全符合Model-View-Intent的理念，具有单向的数据流和表示状态的Model。

在下一个部分中，我们将聚焦于如何通过MVI 构建 可复用 和 响应式 的UI组件，敬请关注。

系列目录

《使用MVI打造响应式APP》原文

• Part 1: Model
  
• Part 2: View and Intent
• Part 3: State Reducer
• Part 4: Independent UI Components
  
• Part 5: Debugging with ease
  
• Part 6: Restoring State
  
• Part 7: Timing (SingleLiveEvent problem)
  
• Part 8: In-App Navigation
  

《使用MVI打造响应式APP》译文

• [译]使用MVI打造响应式APP(一):Model到底是什么
• [译]使用MVI打造响应式APP[二]:View层和Intent层
• [译]使用MVI打造响应式APP[三]:状态折叠器
• [译]使用MVI打造响应式APP[四]:独立性UI组件
• [译]使用MVI打造响应式APP[五]:轻而易举地Debug
• [译]使用MVI打造响应式APP[六]:恢复状态
• [译]使用MVI打造响应式APP[七]:掌握时机(SingleLiveEvent问题)
• [译]使用MVI打造响应式APP[八]:导航

《使用MVI打造响应式APP》实战

• 实战：使用MVI打造响应式&函数式的Github客户端

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费

反思|Android 列表分页组件Paging的设计与实现：架构设计与原理解析

本文是Android Jetpack Paging系列的第二篇文章；强烈建议 读者将本系列作为学习Paging 阅读优先级最高的文章，如果读者对Paging还没有系统性的认识，请参考：

• 反思|Android 列表分页组件Paging的设计与实现：系统概述

前言

Paging是一个非常优秀的分页组件，与其它热门的分页相关库不同的是，Paging更偏向注重服务于 业务 而非 UI 。——我们都知道业务类型的开源库的质量非常依赖代码 整体的架构设计（比如Retofit和OkHttp）；那么，如何说服自己或者同事去尝试使用Paging？显然源码中蕴含的优秀**更具有说服力。

反过来说，若从Google工程师们设计、研发和维护的源码中有所借鉴，即使不在项目中真正使用它，自己依然能受益匪浅。

本文章节如下：

架构设计与原理解析

1、通过建造者模式进行依赖注入

创建流程毫无疑问是架构设计中最重要的环节。

作为组件的门板，向外暴露的API对于开发者越简单友善方便调用越好，同时，作为API调用者的我们也希望框架越灵活，可配置选项越多越好。

这听起来似乎有点违反常理—— 如何才能保证既保证 简单干净的接口设计 易于开发者上手，同时又有 足够多的可配置项 保证框架的灵活呢？

Paging的API设计中使用了经典的 建造者（Builder）模式，并通过依赖注入将依赖一层层向下传递，最终依次构建了各个层级的对象实例。

对于开发者而言，只需要配置自己关心的参数，而不关心（甚至可以是不知道）的参数配置，全交给Builder类使用默认参数：

// 你可以这样复杂地配置
val pagedListLiveData =
    LivePagedListBuilder(
            dataSourceFactory,
            PagedList.Config.Builder()
                    .setPageSize(PAGE_SIZE)                         // 分页加载的数量
                    .setInitialLoadSizeHint(20)                     // 初始化加载的数量
                    .setPrefetchDistance(10)                        // 预加载距离
                    .setEnablePlaceholders(ENABLE_PLACEHOLDERS)     // 是否启用占位符
                    .build()
    ).build()

// 也可以这样简单地配置
val pagedListLiveData =
    LivePagedListBuilder(dataSourceFactory, PAGE_SIZE).build()

需要注意的是，分页相关功能配置对象的构建 和 可观察者对象的构建 是否是两个不同的职责？显然是有必要的，因为：

LiveData<PagedList> = DataSource + PagedList.Config（即 分页数据的可观察者 = 数据源 + 分页配置）

因此，这里Paging的配置使用到了2个Builder类，即使是决定使用 建造者模式 ，设计者也需要对Builder类的定义有一个清晰的认知，这里也是设计过程中 单一职责原则 的优秀体现。

最终，Builder中的所有配置都通过依赖注入的方式对PagedList进行了实例化：

// PagedList.Builder.build()
public PagedList<Value> build() {
    return PagedList.create(
            mDataSource,
            mNotifyExecutor,
            mFetchExecutor,
            mBoundaryCallback,
            mConfig,
            mInitialKey);
}

// PagedList.create()
static <K, T> PagedList<T> create(@NonNull DataSource<K, T> dataSource,
            @NonNull Executor notifyExecutor,
            @NonNull Executor fetchExecutor,
            @Nullable BoundaryCallback<T> boundaryCallback,
            @NonNull Config config,
            @Nullable K key) {
    // 这里我们仅以ContiguousPagedList为例
    // 可以看到，所有PagedList都是将构造函数的依赖注入进行的实例化
    return new ContiguousPagedList<>(contigDataSource,
          notifyExecutor,
          fetchExecutor,
          boundaryCallback,
          config,
          key,
          lastLoad);
}

依赖注入 是一个非常简单而又朴实的编码技巧，Paging的设计中，几乎没有用到单例模式，也几乎没有太多的静态成员——所有对象中除了自身的状态，其它所有通过依赖注入的配置项都是 final (不可变)的:

// PagedList.java
public abstract class PagedList<T> {
  final Executor mMainThreadExecutor;
  final Executor mBackgroundThreadExecutor;
  final BoundaryCallback<T> mBoundaryCallback;
  final Config mConfig;
  final PagedStorage<T> mStorage;
}

// ItemKeyedDataSource.LoadInitialParams.java
public static class LoadInitialParams<Key> {
  public final Key requestedInitialKey;
  public final int requestedLoadSize;
  public final boolean placeholdersEnabled;
}

上文说到 几乎没有用到单例模式，实际上线程切换的设计有些许例外，但其本身依然可以通过Builder进行依赖注入以覆盖默认的线程获取逻辑。

通过 依赖注入 保证了对象的实例所需依赖有迹可循，类与类之间的依赖关系非常清晰，而实例化的对象内部 成员的不可变 也极大保证了PagedList分页数据的线程安全。

2、构建懒加载的LiveData

对于被观察者而言，只有当真正被订阅的时候，其数据的更新才有意义。换句话说，当开发者构建出一个LiveData<PagedList>时候，这时立即通过后台线程开始异步请求分页数据是没有意义的。

反过来理解，若没有订阅就请求数据，当真正订阅的时候，DataSource中的数据已经过时了，这时还需要重新请求拉取最新数据，这样之前的一系列行为就没有意义了。

真正的请求应该放在LiveData.observe()的时候，即被订阅时才去执行，笔者这里更偏向于称其为“懒加载”——如果读者对RxJava比较熟悉的话，会发现这和Observable.defer()操作符概念比较相似：

那么，如何构建“懒加载”的LiveData<PagedList>呢?Google的设计者使用了ComputableLiveData类对LiveData的数据发射行为进行了包装：

// @hide
public abstract class ComputableLiveData<T> {}

这是一个隐藏的类，开发者一般不能直接使用它，但它被应用的地方可不少，Room组件生成的源码中也经常可以看到它的身影。

用一句话描述ComputableLiveData的定义，笔者觉得 LiveData的数据源 比较适合，感兴趣的读者可以仔细研究一下它的源码，笔者有机会会为它单独开一篇文章，这里不继续展开。

总之，通过ComputableLiveData类，Paging实现了订阅时才执行异步任务的功能，更大程度上减少了做无用功的情况。

3、为分页数据赋予生命周期

分页数据PagedList理应也有属于自己的生命周期。

正常的生命周期内，PagedList不断从DataSource中尝试加载分页数据，并展示出来；但数据源中的数据总有过期失效的时候，这意味着PagedList生命周期走到了尽头。

Paging需要响应式地创建一个新的DataSource数据快照以及新的PagedList，然后交给PagedListAdapter更新在UI上。

为此，PagedList类中增加了对应的一个mDetached字段：

public abstract class PagedList<T> extends AbstractList<T> {
  //...
  private final AtomicBoolean mDetached = new AtomicBoolean(false);

  public boolean isDetached() {
      return mDetached.get();
  }

  public void detach() {
    mDetached.set(true);
  }
}

这个AtomicBoolean类型的字段是有意义的：我们知道PagedList对分页数据的加载是异步的，因此尝试加载下一页数据时，若此时mDetached.get()为true，意味着此时的分页数据已经失效，因此异步的分页请求任务不再需要被执行：

class ContiguousPagedList<K, V> extends PagedList<V> {

  //...
  public void onPagePlaceholderInserted(final int pageIndex) {
         mBackgroundThreadExecutor.execute(new Runnable() {
             @Override
             public void run() {
                 // 不再异步加载分页数据
                 if (isDetached()) {
                     return;
                 }

                 // 若数据源失效，则将mDetached.set(true)
                 if (mDataSource.isInvalid()) {
                    detach();
                 } else {
                 // ... 加载下页数据
                 }
             }
         });
     }
}

通过上述代码片段读者也可以看到，PagedList的生命周期是否失效，则依赖DataSource的isInvalid()函数，这个函数表示当前的DataSource数据源是否失效：

public abstract class DataSource<Key, Value> {
  private AtomicBoolean mInvalid = new AtomicBoolean(false);
  private CopyOnWriteArrayList<InvalidatedCallback> mOnInvalidatedCallbacks =
          new CopyOnWriteArrayList<>();

  // 通知数据源失效        
  public void invalidate() {
      if (mInvalid.compareAndSet(false, true)) {
          for (InvalidatedCallback callback : mOnInvalidatedCallbacks) {
              // 数据源失效的回调函数，通知上层创建新的PagedList
              callback.onInvalidated();
          }
      }
  }

  // 数据源是否失效
  public boolean isInvalid() {
      return mInvalid.get();
  }
}

当数据源DataSource失效时，则会通过回调函数，通知上文我们提到的ComputableLiveData<T>创建新的PagedList，并通知给LiveData的观察者更新在UI上。

因此，PagedList作为分页数据，DataSource作为数据源，ComputableLiveData<T>作为PagedList的创建和分发者三者形成了一个闭环：

4、提供Room的响应式支持

我们知道Paging原生提供了对Room组件的响应式支持，当数据库数据发生了更新，Paging能够响应到并自动构建新的PagedList，然后更新到UI上。

这似乎是一个神奇的操作，但原理却十分简单，上一小节我们知道，DataSource调用了invalidate()函数时，意味着数据源失效，DataSource会通过回调函数重新构建新的PagedList。

Room组件也是根据这个特性额外封装了一个新的DataSource：

public abstract class LimitOffsetDataSource<T> extends PositionalDataSource<T> {

  protected LimitOffsetDataSource(...) {
      // 1.定义一个"命令数据源失效"的回调函数
      mObserver = new InvalidationTracker.Observer(tables) {
          @Override
          public void onInvalidated(@NonNull Set<String> tables) {
              invalidate();
          }
      };
      // 2.为数据库的失效跟踪器（InvalidationTracker）配置观察者
      db.getInvalidationTracker().addWeakObserver(mObserver);
  }
}

这之后，每当数据库中数据失效，都会自动执行DataSource.invalidate()函数。

现在读者回顾最初学习Paging的时候，Room中开发者定义的Dao类，返回的DataSource.Factory到底是怎样的一个对象？

@Dao
interface RedditPostDao {
    @Query("SELECT * FROM posts WHERE subreddit = :subreddit ORDER BY indexInResponse ASC")
    fun postsBySubreddit(subreddit : String) : DataSource.Factory<Int, RedditPost>
}

答案不言而喻，正是LimitOffsetDataSource的工厂类：

@Override
public DataSource.Factory<Integer, RedditPost> postsBySubreddit(final String subreddit) {
  return new DataSource.Factory<Integer, RedditPost>() {
   // 返回能够响应数据库数据失效的 LimitOffsetDataSource
   @Override
   public LimitOffsetDataSource<RedditPost> create() {
     return new LimitOffsetDataSource<RedditPost>(__db, _statement, false , "posts") {
        // ....
     }
}

原理上讲，这些代码平淡无奇，但设计者通过注解的一层封装，大幅简化了开发者的代码量。对于开发者而言，只需要配置一个接口，而无需去了解内部的代码实现细节。

中场：更多的困惑

上一篇文章中对DataSource进行了简单的介绍，很多朋友反应DataSource这一部分的源码过于晦涩，对于DataSource的选择也是懵懵懂懂。

复杂问题的解决依赖于问题的切割细分，本文将其细分成以下2个小问题，并进行一一探讨：

• 1、为什么设计出这么多的DataSource和其子类，它们的使用场景各是什么？
• 2、为什么设计出这么多的PagedList和其子类？

5、数据源的连续性与分页加载策略

为什么设计出这么多的DataSource和其子类，它们的使用场景各是什么？

Paging分页组件的设计中，DataSource是一个非常重要的模块。顾名思义，DataSource<Key, Value>中的Key对应数据加载的条件，Value对应数据集的实际类型， 针对不同场景，Paging的设计者提供了几种不同类型的DataSource实现类:

关于这些DataSource的介绍，请参考上一篇文章的这一小节，本文不再赘述。

第一次阅读这一部分源码时，笔者最困惑的是，ContiguousDataSource和PositionalDataSource的区别到底是什么呢？

翻阅过源码的读者也许曾经注意到，DataSource有这样一个抽象函数：

public abstract class DataSource<Key, Value> {
  // 数据源是否是连续的
  abstract boolean isContiguous();
}

class ContiguousDataSource<Key, Value> extends DataSource<Key, Value> {
  // ContiguousDataSource 是连续的
  boolean isContiguous() { return true; }
}

class PositionalDataSource<T> extends DataSource<Integer, T> {
  // PositionalDataSource 是非连续的
  boolean isContiguous() { return false; }
}

那么，数据源的连续性 到底是什么概念？

对于一般的网络分页加载请求而言，下一页的数据总是需要依赖上一页的加载，这种时候，我们通常称之为 数据源是连续的 —— 这似乎毫无疑问，这也是ItemKeyedDataSource和PageKeyedDataSource被广泛使用的原因。

但有趣的是，在 以本地缓存作为分页数据源 的业务模型下，这种 分页数据源应该是连续的 常识性的认知被打破了。

每个手机都有通讯录，因此本文以通讯录APP为例，对于通讯录而言，所有数据取自于本地持久层，而考虑到手机内也许会有成千上万的通讯录数据，APP本身列表数据也应该进行分页加载。

这种情况下，分页数据源是连续的吗？

读者仔细思考可以得知，这时分页数据源 一定不能是连续的 。诚然，对于滑动操作而言，数据的连续分页请求没有问题，但是当用户从通讯录页面的侧边点击Z字母，尝试快速跳转Z开头的用户时，分页数据请求的连续性被打破了：

这便是PositionalDataSource的使用场景：通过特定的位置加载数据，这里Key是Integer类型的位置信息，每一条分页数据并不依赖上一条分页数据，而是依赖数据所处数据源本身的位置（Position）。

分页数据的连续性 是一个十分重要的概念，理解了这个概念，读者也就能理解DataSource各个子类的意义了：

无论是PositionalDataSource、ItemKeyedDataSource还是PageKeyedDataSource，这些类都是不同的 分页加载策略。开发者只需要根据不同业务的场景（比如 数据的连续性），选择不同的 分页加载策略 即可。

6、分页数据模型与分页数据副本

为什么设计出这么多的PagedList和其子类？

和DataSource相似，PagedList同样拥有一个isContiguous()接口：

public abstract class PagedList<T> extends AbstractList<T> {
  abstract boolean isContiguous();
}

class ContiguousPagedList<K, V> extends PagedList<V> {
  // ContiguousPagedList 内部持有 ContiguousDataSource
  final ContiguousDataSource<K, V> mDataSource;

  boolean isContiguous() { return true; }
}

class TiledPagedList<T> extends PagedList<T> {
  // TiledPagedList 内部持有 PositionalDataSource
  final PositionalDataSource<T> mDataSource;

  boolean isContiguous() { return false; }
}

读者应该理解，PagedList内部持有一个DataSource，而 分页数据加载 的行为本质上是从DataSource中异步获取数据—— 在分页数据请求的过程中，不同的DataSource也会有不同的参数需求，从而导致PagedList内部的行为也不尽相同；因此PagedList向下导出了ContiguousPagedList和TiledPagedList类，用于不同业务情况的分页请求处理。

那么SnapshotPagedList又是一个什么类呢？

PagedList额外有一个snapshot()接口，以返回当前分页数据的快照：

public abstract class PagedList<T> extends AbstractList<T> {
  public List<T> snapshot() {
      return new SnapshotPagedList<>(this);
  }
}

这个snapshot()函数非常重要，其用于保存分页数据的前一个状态，并且用于AsyncPagedListDiffer进行数据集的差异性计算，新的PagedList到来时（通过PagedListAdapter.submitList()），并未直接进行数据的覆盖和差异性计算，而是先对之前PagedList中的数据集进行拷贝。

篇幅原因不详细展示，有兴趣的读者可以自行阅读PagedListAdapter.submitList()相关源码。

接下来简单了解下SnapshotPagedList内部的实现：

class SnapshotPagedList<T> extends PagedList<T> {
  SnapshotPagedList(@NonNull PagedList<T> pagedList) {
    // 1.这里我们看到，其它对象都没有改变堆内地址的引用
    // 除了 pagedList.mStorage.snapshot()，最终执行 -> 2
      super(pagedList.mStorage.snapshot(),
              pagedList.mMainThreadExecutor,
              pagedList.mBackgroundThreadExecutor,
              null,
              pagedList.mConfig);
      mDataSource = pagedList.getDataSource();
      mContiguous = pagedList.isContiguous();
      mLastLoad = pagedList.mLastLoad;
      mLastKey = pagedList.getLastKey();
  }
}

final class PagedStorage<T> extends AbstractList<T> {
  PagedStorage(PagedStorage<T> other) {
      // 2.对当前分页数据进行了一次拷贝
      mPages = new ArrayList<>(other.mPages);
  }
}

此外，mSnapshot还用于状态的保存，当差异性计算未执行完毕时，若此时开发者调用getCurrentList()函数，则会尝试将mSnapshot——即之前数据集的副本进行返回，有兴趣的读者可以研究一下。

7、线程切换与Paging设计中的"Bug"

Google的工程师们设计Paging的初衷就希望能够让开发者 无感知地进行线程切换 ，因此大部分线程切换的代码都封装在内部：

public class ArchTaskExecutor extends TaskExecutor {
  // 主线程的Executor
  private static final Executor sMainThreadExecutor = new Executor() {
      @Override
      public void execute(Runnable command) {
          getInstance().postToMainThread(command);
      }
  };

  // IO线程的Executor
  private static final Executor sIOThreadExecutor = new Executor() {
      @Override
      public void execute(Runnable command) {
          getInstance().executeOnDiskIO(command);
      }
  };
}

有兴趣的读者可以研究ArchTaskExecutor内部的源码，其内部sMainThreadExecutor原理依然是通过Looper.getMainLooper()创建对应的Handler并向主线程发送消息，本文不赘述。

源码的设计者希望，使用Paging的开发者能够在执行数据的分页加载任务时，内部切换到IO线程，而分页数据加载成功后，则内部切换回到主线程更新UI。

从设计上讲，这是一个非常优秀的设计，但是开发者真正使用时，却很难注意到DataSource中对数据加载的回调方法，本身就是执行在IO线程的：

public abstract class PositionalDataSource<T> extends DataSource<Integer, T>{
  // 通过注解提醒开发者回调在子线程
  @WorkerThread
  public abstract void loadInitial(...);

  @WorkerThread
  public abstract void loadRange(...);
}

回调本身在子线程执行，意味着，开发者对分页数据的加载最好不要使用异步方法，否则很可能出问题。

对于OkHttp的使用者而言，开发者应该使用execute()同步方法：

override fun loadInitial(..., callback: LoadInitialCallback<RedditPost>) {
  // 使用同步方法
  val response = request.execute()
  callback.onResult(...)
}

对于RxJava而言，则应该使用blocking相关的方法进行阻塞操作。

如果说PositionalDataSource还有@WorkerThread提醒，那么另外的ItemKeyedDataSource和PageKeyedDataSource干脆就没有@WorkerThread注解：

public abstract class ItemKeyedDataSource<Key, Value> extends ContiguousDataSource<Key, Value> {
  public abstract void loadInitial(...);

  public abstract void loadAfter(...);
}

// PageKeyedDataSource也没有`WorkerThread`注解，不赘述

因此如果没有注意到这些细节，开发者很可能误入歧途，从而导致未知的一些问题，对此，开发者可以尝试参考Google这个示例代码。

奇怪的是，即使是Google官方的代码示例中，对于loadInitial和loadAfter两个函数，也只有loadInitial中使用了同步方法进行请求，而loadAfter中依然是使用enqueue()进行异步请求。尽管注释中明确声明了这点，但笔者还是无法理解这种行为，因为这的确有可能令一些开发者误入歧途。

总之，Paging的设计中，其初衷将线程切换的实现细节进行隐藏是好的，但是结果的确没有达到很好的效果，相反还有可能导致错误的理解和使用（笔者踩坑了）。

也许线程切换不交给内部的默认参数去实现（尤其是不要交给Builder模式去配置，这太容易被忽视了），而是强制要求交给开发者去指定更好？

欢迎有想法的朋友在本文下方留言，**的交流会更容易让人进步。

总结

本文对Paging的原理实现进行了系统性的讲解，那么，Paging的架构设计上，到底有哪些优点值得我们学习？

首先，依赖注入。Paging内部所有对象的依赖，包括配置参数、内部回调、线程切换，绝大多数都是通过依赖注入进行的，简单 且 朴实 ，类与类之间的依赖关系皆有迹可循。

其次，类的抽象和将不同业务的下沉，DataSource和PagedList分工明确，并向上抽象为一个抽象类，并将不同业务情况下的分页逻辑下沉到各自的子类中去。

最后，明确对象的边界：设计分页数据的生命周期，当数据源无效时，避免执行无效的异步分页任务；使用 懒加载的LiveData ，保证未订阅时不执行分页逻辑。

参考 & 更多

如果对Paging感兴趣，欢迎阅读笔者更多相关的文章，并与我一起讨论：

• 反思|Android 列表分页组件Paging的设计与实现：系统概述

• Android官方架构组件Paging：分页库的设计美学

• Android官方架构组件Paging-Ex：为分页列表添加Header和Footer

• Android官方架构组件Paging-Ex：列表状态的响应式管理

关于我

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

[译] 编写AndroidStudio插件(二):持久化数据

原文：Write an Android Studio Plugin Part 2: Persisting data
作者：Marcos Holgado
译者：却把清梅嗅
《编写AndroidStudio插件》系列是 IntelliJ IDEA 官方推荐的学习IDE插件开发的博客专栏，希望对有需要的读者有所帮助。

在本系列的第一部分中，我们了解了如何为Android Studio创建一个基本的插件，并编写了第一个Action。本文我们将了解如何在插件中对数据进行持久化。

请记住，您可以在GitHub上找到本系列的所有代码，还可以在对应的分支上查看每篇文章的相关代码，本文的代码在Part2分支中。

https://github.com/marcosholgado/plugin-medium

我们要做什么？

我们今天的目标是在插件中对数据进行持久化。在此过程中，我们将学习什么是component以及如何使用component来管理插件的生命周期。接下来我们将开始使用它，以保证Android Studio启动并且安装了新版本的插件时显示通知。您将来可用此功能向用户显示您插件更新了哪些内容。

什么是 Component ？

在编写任何代码之前，我们需要了解什么是Component。 Component是插件集成的基本概念，Component让我们能够控制插件的生命周期并保持其状态，以便将其自动保存和加载。

一共有三种不同类型的Component：

• Application 级别: 在IDE（Android Studio）启动时创建并初始化的Component;
• Project 级别: 为每个项目实例创建的Component;
• Module 级别: 为每个项目中的模块创建的Compoenent.

第一步：新建一个 Component

首先我们要确定所需Component的类型，在本文中，我们想在Android Studio启动时做一些事情，因此，通过查看不同类型的Component，我们可以清楚地知道需要一个 Application级别的Component。

JetBrains官方文档这样描述：我们可以实现ApplicationComponent接口，这是可选的，但本文我们会这样做。ApplicationComponent接口将为我们提供之前提到的生命周期方法，便于我们在IDE启动时用于执行某些操作。这些方法来自ApplicationComponent的扩展类BaseComponent。

public interface BaseComponent extends NamedComponent {
  /**
   * Component should perform initialization and communication with other components in this method.
   * This is called after {@link com.intellij.openapi.components.PersistentStateComponent#loadState(Object)}.
   */
  default void initComponent() {
  }

  /**
   * @see com.intellij.openapi.Disposable
   */
  default void disposeComponent() {
  }
}

现在让我们对Component进行编码，第一次迭代将非常简单，我们通过继承ApplicationComponent并重写initComponent来检查是否有新版本。

class MyComponent: ApplicationComponent {

    override fun initComponent() {
        super.initComponent()
        if (isANewVersion()) { }
    }

    private fun isANewVersion(): Boolean = true

}

第二步：实现 isANewVersion()

那么有意思的来了。我们将从声明两个新字段开始：localVersion和version。第一个将存储我们已安装的最新版本，而第二个将是我们插件的实际安装版本。

我想要比较它们，以检查版本号localVersion是否在version的后面，若如此我们就能知道用户是否刚刚安装了新版本的插件，以及是否向用户发送通知。我们还必须将localVersion更新为与version相同的值，以便下次用户启动Android Studio时不再收到欢迎信息。

首先，用户未安装我们的插件，因此我们将localVersion的值设置为0.0，因为我们的第一个版本是1.0-SNAPSHOT。您可以在build.gradle文件中更改插件的版本，但如果未更改，则应为：

version '1.0-SNAPSHOT'

为了实现isANewVersion，我们将做一些简单的事情。如果你愿意，可以适当进行修改，但是这里只是针对版本号进行简单的比较，因此我没有对边界条件相关逻辑进行全方位覆盖。

首先，我摆脱了实际上要在版本上维护的-SNAPSHOT部分。之后，我使用.作为分隔符对每个版本号进行了分割。因此我们得到一个包含所有主数字和副数字的List<String>，以便我们可以比较它们并返回true或false。这并非最佳算法，但足以满足我们的需求。该算法的假设非常简单，两个版本号必须具有相同的长度，并且必须遵循相同的命名约定majorV.minorV。

private fun isANewVersion(): Boolean {
    val s1 = localVersion.split("-")[0].split(".")
    val s2 = version.split("-")[0].split(".")

    if (s1.size != s2.size) return false
    var i = 0

    do {
        if (s1[i] < s2[i]) return true
        i++
    } while (i < s1.size && i < s2.size)

    return false
}

第三步：整合起来

现在是时候将isANewVersion方法以及两个新字段移到Component中了。您可以使用PluginManager获得插件的版本以及插件的ID，您还可以在plugin.xml文件中找到（和更改）插件的ID。我还建议此时将插件名称更改为更有意义的名称，例如My awesome plugin。

<idea-plugin>
    <id>myplugin.myplugin</id>
    <name>My awesome plugin</name>
    ...

该Component的整个实现非常简单:我们从PluginManager获取版本，检查是否发生了版本更新，如果有，就同步更新本地版本号，以便下次启动Android Studio时不会再触发整个过程。最后，我们向用户显示一个简单的通知，整合完毕后，看起来像这样。

class MyComponent: ApplicationComponent {

    private var localVersion: String = "0.0"
    private lateinit var version: String

    override fun initComponent() {
        super.initComponent()

        version = PluginManager.getPlugin(
            PluginId.getId("myplugin.myplugin")
        )!!.version

        if (isANewVersion()) {
            updateLocalVersion()
            val noti = NotificationGroup("myplugin",
                                         NotificationDisplayType.BALLOON,
                                         true)

            noti.createNotification("Plugin updated",
                                    "Welcome to the new version",
                                   NotificationType.INFORMATION,
                                   null)
                .notify(null)
        }
    }

    private fun isANewVersion(): Boolean {
        val s1 = localVersion.split("-")[0].split(".")
        val s2 = version.split("-")[0].split(".")

        if (s1.size != s2.size) return false
        var i = 0

        do {
            val l1 = s1[i]
            val l2 = s2[i]
            if (l1 < l2) return true
            i++
        } while (i < s1.size && i < s2.size)

        return false
    }

    private fun updateLocalVersion() {
        localVersion = version
    }

}

第四步：持久化 Component 的状态

现在，我们可以尝试测试我们的插件，由于两个原因，它无法正常工作。

首先是因为我们仍然必须注册Component，其次是因为我们还没有真正保留Component的状态。每次Android Studio初始化时，localVersion的值仍然是0.0。

那么，针对如何保存Component状态的问题，我们该怎么做呢？为此，我们必须实现PersistentStateComponent。这意味着我们必须重写两个新方法，即getState和loadState。我们还需要了解PersistentStateComponent的工作方式，
它将公共字段，带注释的私有字段和bean属性存储为XML格式。要从序列化中删除公共字段，可以使用@Transient注释该字段。

在我们的例子中，我将使用@Attribute注释localVersion，以便在存储它的同时将其保持私有状态，将组件本身返回到getState并使用XmlSerializerUtil加载状态，我们还必须使用@State注释组件，并指定xml的位置。

@State(
        name = "MyConfiguration",
        storages = [Storage(value = "myConfiguration.xml")])
class MyComponent: ApplicationComponent,
        PersistentStateComponent<MyComponent> {

    @Attribute
    private var localVersion: String = "0.0"
    private lateinit var version: String

    override fun initComponent() {
        super.initComponent()

        version = PluginManager.getPlugin(
                PluginId.getId("myplugin.myplugin")
        )!!.version

        if (isANewVersion()) {
            updateLocalVersion()
            val noti = NotificationGroup("myplugin",
                                         NotificationDisplayType.BALLOON,
                                         true)
            noti.createNotification("Plugin updated",
                                    "Welcome to the new version",
                                    NotificationType.INFORMATION,
                                    null)
                .notify(null)
        }
    }

    override fun getState(): MyComponent? = this

    override fun loadState(state: MyComponent) = XmlSerializerUtil.copyBean(state, this)

    private fun isANewVersion(): Boolean {
        val s1 = localVersion.split("-")[0].split(".")
        val s2 = version.split("-")[0].split(".")

        if (s1.size != s2.size) return false
        var i = 0

        do {
            if (s1[i] < s2[i]) return true
            i++
        } while (i < s1.size && i < s2.size)

        return false
    }

    private fun updateLocalVersion() {
        localVersion = version
    }

}

像往常一样，您可以按需定制，例如定义存储位置或自定义xml格式，更多信息请参考这里。

第五步：注册 Component

最后一步是在plugin.xml文件中注册Component。为此，我们只需要在文件的application-component部分内创建一个新Component，然后指定我们刚刚创建的Component类即可。

<application-components>
    <component>
        <implementation-class>
            components.MyComponent
        </implementation-class>
    </component>
</application-components>

大功告成！现在，您可以运行buildPlugin命令，使用Android Studio中生成的jar文件从磁盘安装插件，下次打开Android Studio时，您会看到此通知。之后，仅当您提高插件版本时，通知也会再次出现。

第2部分到此为止，在第3部分中，我们将学习如何为插件创建设置页面，当然在此之前我们还将了解如何为插件创建UI。

如果您有任何疑问，请访问Twitter或发表评论。

《编写AndroidStudio插件》译文系列

• 译: 编写AndroidStudio插件(一):创建一个基本插件
• 译: 编写AndroidStudio插件(二):持久化数据
• 译: 编写AndroidStudio插件(三): 更多配置
• 译: 编写AndroidStudio插件(四):整合Jira
• 译: 编写AndroidStudio插件(五):本地化和通知

关于译者

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

如果您觉得文章还差了那么点东西，也请通过 关注 督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

运用递归解决二叉树相关问题

在之前的章节中，我们已经介绍了如何解决树的遍历问题。我们也已经尝试过使用递归解决树的为 前序遍历 、 中序遍历 和 后序遍历 问题。

事实上，递归 是解决树相关问题的最有效和最常用的方法之一。本节中，我们将会介绍两种典型的递归方法。

解决方案

本小节内容节选自 LeetCode：运用递归解决树的问题 .

递归是解决树的相关问题最有效和最常用的方法之一。

我们知道，树可以以递归的方式定义为一个节点（根节点），它包括一个值和一个指向其他节点指针的列表。 递归是树的特性之一。 因此，许多树问题可以通过递归的方式来解决。 对于每个递归层级，我们只能关注单个节点内的问题，并通过递归调用函数来解决其子节点问题。

通常，我们可以通过 自顶向下 或 自底向上 的递归来解决树问题。

“自顶向下” 的解决方案

自顶向下 意味着在每个递归层级，我们将首先访问节点来计算一些值，并在递归调用函数时将这些值传递到子节点。 所以 自顶向下 的解决方案可以被认为是一种 前序遍历。 具体来说，递归函数 top_down(root, params) 的原理是这样的：

• 1、在null值的情况下返回指定的值；
• 2、如果有必要，更新answer;
• 3、left_ans = top_down(root.left, left_params)；
• 4、right_ans = top_down(root.right, right_params)；
• 5、如果有必要返回answer。

“自底向上” 的解决方案

自底向上 是另一种递归方法。 在每个递归层次上，我们首先对所有子节点递归地调用函数，然后根据返回值和根节点本身的值得到答案。 这个过程可以看作是 后序遍历 的一种。 通常， 自底向上 的递归函数 bottom_up(root) 为如下所示：

• 1、在null值的情况下返回指定的值；
• 2、left_ans = top_down(root.left, left_params)；
• 3、right_ans = top_down(root.right, right_params)；
• 4、返回answer。

例题

1、二叉树的最大深度

题目描述

解题思路及实现

1、自顶向下

class Solution {
  private int answer = 0;

  public int maxDepth(TreeNode root) {
      max_depth(root, 0);
      return answer;
  }

  private void max_depth(TreeNode root, int depth) {
      if (root == null) return;

      if (root.left == null && root.right == null) {
          answer = Math.max(depth, answer);
          return;
      }

      max_depth(root.left, depth + 1);
      max_depth(root.right, depth + 1);
  }
}

2、自底向上

class Solution {

  public int maxDepth(TreeNode root) {
      return max_depth2(root);
  }

  private int max_depth2(TreeNode root) {
      if (root == null)
          return 0;

      int leftDepth = max_depth2(root.left) + 1;
      int rightDepth = max_depth2(root.right) + 1;
      return Math.max(leftDepth, rightDepth);
  }
}

2、对称二叉树

题目描述

解题思路及实现

这道题笔者的思路是迭代，后来发现非常困难，看了题解才发现，将同一个树作为2次参数分别放入递归函数进行递归，确实是一个很棒的思路。

class Solution {

    public boolean isSymmetric(TreeNode root) {
        return isMirror(root, root);
    }

    private boolean isMirror(TreeNode t1, TreeNode t2) {
        if (t1 == null && t2 == null) return true;
        if (t1 == null || t2 == null) return false;

        return t1.val == t2.val && isMirror(t1.left, t2.right) && isMirror(t1.right, t2.left);
    }
}

3、路径总和

题目描述

解题思路及实现

比较简单，标准的dfs进行递归：

class Solution {

  public boolean hasPathSum(TreeNode root, int sum) {
      return dfs(root, 0, sum);
  }

  private boolean dfs(TreeNode root, int currentSum, int target) {
      if (root == null) {
          return false;
      }
      int sum = currentSum + root.val;

      if (root.left != null || root.right != null) {
          return dfs(root.left, sum, target) || dfs(root.right, sum, target);
      } else {
          return sum == target;
      }
  }
}

参考 & 感谢

文章绝大部分内容节选自LeetCode，概述：

• https://leetcode-cn.com/explore/learn/card/data-structure-binary-tree/3/solve-problems-recursively/11/

例题：

• https://leetcode-cn.com/problems/maximum-depth-of-binary-tree/
• https://leetcode-cn.com/problems/symmetric-tree/
• https://leetcode-cn.com/problems/path-sum/

关于我

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

哈希映射用法及算法例题

本文为博主算法学习过程中的学习笔记，主要内容来源于其他平台或书籍，出处请参考下方 参考&感谢 一节。

用法

哈希映射 是用于存储 (key, value) 键值对的一种实现。

使用哈希映射的第一个场景是，我们 需要更多的信息，而不仅仅是键。然后通过哈希映射 建立密钥与信息之间的映射关系。

另一个常见的场景是 按键聚合所有信息。我们也可以使用哈希映射来实现这一目标。

例题

1、两数之和

题目描述

给定一个整数数组 nums 和一个目标值 target，请你在该数组中找出和为目标值的那 两个 整数，并返回他们的数组下标。

你可以假设每种输入只会对应一个答案。但是，你不能重复利用这个数组中同样的元素。

示例:

给定 nums = [2, 7, 11, 15], target = 9

因为 nums[0] + nums[1] = 2 + 7 = 9
所以返回 [0, 1]

解题思路及实现

HashMap入门的经典题。

简单的方式是使用双层循环进行暴力破解，这种算法时间复杂度为O(N^2)。

而使用HashMap则可以将问题在一层循环中进行解决，时间复杂度仅O(N)：

class Solution {
    public int[] twoSum(int[] nums, int target) {
        HashMap<Integer, Integer> map = new HashMap<>();
        int[] result = new int[2];
        for (int i = 0; i < nums.length; i++) {
            int value = nums[i];
            int find = target - value;
            if (map.containsKey(find) && map.get(find) != i) {
                result[0] = i;
                result[1] = map.get(find);
                break;
            }
            map.put(nums[i], i);
        }
        return result;
    }
}

2、同构字符串

题目描述

给定两个字符串 s 和 t，判断它们是否是同构的。

如果 s 中的字符可以被替换得到 t ，那么这两个字符串是同构的。

所有出现的字符都必须用另一个字符替换，同时保留字符的顺序。两个字符不能映射到同一个字符上，但字符可以映射自己本身。

你可以假设 s 和 t 具有相同的长度。

示例:

输入: s = "egg", t = "add"
输出: true
输入: s = "foo", t = "bar"
输出: false

解题思路及实现

通过2个HashMap存储各自字符对应最初的索引，然后进行比较，当字符对应的最初索引不同时，说明2个字符串不是同构的：

class Solution {
    public boolean isIsomorphic(String s, String t) {
        char[] char1 = s.toCharArray();
        char[] char2 = t.toCharArray();
        HashMap<Character, Integer> map1 = new HashMap<>();
        HashMap<Character, Integer> map2 = new HashMap<>();
        for (int i = 0; i < char1.length; i++) {
            char c1 = char1[i];
            char c2 = char2[i];
            if (!map1.containsKey(c1))
                map1.put(c1, i);
            if (!map2.containsKey(c2))
                map2.put(c2, i);

            if (map1.get(c1) != map2.get(c2))
                return false;
        }
        return true;
    }
}

3、两个列表的最小索引总和

题目描述

https://leetcode-cn.com/problems/minimum-index-sum-of-two-lists/

解题思路及实现

这道题的难点是发现映射关系，即 最爱餐厅 -> 索引值 的映射关系。

通过遍历将该映射关系存储到HashMap中后，再次通过一次遍历找出索引值和最小的餐厅，因为索引值最小的情况可能不止一个，因此用一个List进行维护，最终将答案遍历输出：

class Solution {
    public String[] findRestaurant(String[] list1, String[] list2) {
        HashMap<String, Integer> map = new HashMap<>();
        List<Integer> posList = new ArrayList<>();
        int minPosNum = Integer.MAX_VALUE;

        for (int i = 0; i < list1.length; i++) {
            map.put(list1[i], i);
        }
        for (int i = 0; i < list2.length; i++) {
            String favorite = list2[i];
            Integer position = map.get(favorite);
            if (position != null) {
                int posNum = i + position;
                if (minPosNum > posNum) {
                    minPosNum = posNum;
                    posList.clear();
                    posList.add(i);
                } else if (minPosNum == posNum) {
                    posList.add(i);
                }
            }
        }
        String[] result = new String[posList.size()];
        for (int i = 0; i < posList.size(); i++)
            result[i] = list2[posList.get(i)];
        return result;
    }
}

4、字符串中的第一个唯一字符

题目描述

给定一个字符串，找到它的第一个不重复的字符，并返回它的索引。如果不存在，则返回 -1。

示例：

s = "leetcode"
返回 0.
s = "loveleetcode"
返回 2.

您可以假定该字符串只包含小写字母。

解题思路及实现

比较简单，通过2次遍历，第一次遍历将每个字符对应出现的次数进行存储，第二次遍历每个字符的出现次数，当出现次数为1，返回该字符的索引即可。

class Solution {
    public int firstUniqChar(String s) {
        char[] arr = s.toCharArray();
        HashMap<Character, Integer> map = new HashMap<>();
        // 遍历将所有字符的频率输出到Map中
        for (int i = 0; i < arr.length; i++) {
            char c = arr[i];
            if (map.containsKey(c)) {
                map.put(c, map.get(c) + 1);
            } else {
                map.put(c, 1);
            }
        }
        for (int i = 0; i < arr.length; i++) {
            char c = arr[i];
            if (map.get(c) == 1)
                return i;
        }
        return -1;
    }
}

5、两个数组的交集 II

题目描述

给定两个数组，编写一个函数来计算它们的交集。

输入: nums1 = [1,2,2,1], nums2 = [2,2]
输出: [2,2]
输入: nums1 = [4,9,5], nums2 = [9,4,9,8,4]
输出: [4,9]

输出结果中每个元素出现的次数，应与元素在两个数组中出现的次数一致。
我们可以不考虑输出结果的顺序。

解题思路及实现

仍然是通过2次遍历，第一次遍历将nums1[]每个数字对应出现的次数进行存储，第二次遍历nums2[]，然后和之前的结果进行匹配，最终返回结果。

class Solution {
    public int[] intersect(int[] nums1, int[] nums2) {
        HashMap<Integer, Integer> map = new HashMap<>();

        // 遍历数组将所有元素和其数量存入map中
        for (int i = 0; i < nums1.length; i++) {
            int key = nums1[i];
            if (map.containsKey(key)) {
                map.put(key, map.get(key) + 1);
            } else {
                map.put(key, 1);
            }
        }

        int[] result = new int[nums2.length];
        int pos = 0;
        for (int i = 0; i < nums2.length; i++) {
            int key = nums2[i];
            if (map.containsKey(key) && map.get(key) >= 1) {
                result[pos] = key;
                pos++;
                map.put(key, map.get(key) - 1);
            }
        }

        return Arrays.copyOf(result, pos);
    }
}

6、存在重复元素 II

题目描述

给定一个整数数组和一个整数 k，判断数组中是否存在两个不同的索引 i 和 j，使得 nums [i] = nums [j]，并且 i 和 j 的差的绝对值最大为 k。

输入: nums = [1,2,3,1], k = 3
输出: true
输入: nums = [1,0,1,1], k = 1
输出: true
输入: nums = [1,2,3,1,2,3], k = 2
输出: false

解题思路及实现

题目理解了就好做了，关键是数组内相同的数字最小距离是否不大于k，做一次遍历，每次都将数字作为key，其索引作为value进行存储。

遍历结束前，只要有一个满足要求就可以返回true，否则最终返回false即可。

class Solution {
    public boolean containsNearbyDuplicate(int[] nums, int k) {
        HashMap<Integer, Integer> map = new HashMap<>();
        for (int i = 0; i < nums.length; i++) {
            int key = nums[i];
            if (map.containsKey(key)) {
                int oldPos = map.get(key);
                if (i - oldPos <= k) {
                    return true;
                } else {
                    map.put(key, i);
                }
            } else {
                map.put(key, i);
            }
        }
        return false;
    }
}

参考 & 感谢

文章绝大部分内容节选自LeetCode，概述：

• https://leetcode-cn.com/explore/learn/card/hash-table/205/practical-application-hash-map/809/

例题：

• https://leetcode-cn.com/problems/two-sum/
• https://leetcode-cn.com/problems/isomorphic-strings/
• https://leetcode-cn.com/problems/minimum-index-sum-of-two-lists/
• https://leetcode-cn.com/problems/first-unique-character-in-a-string/
• https://leetcode-cn.com/problems/intersection-of-two-arrays-ii/
• https://leetcode-cn.com/problems/contains-duplicate-ii/

关于我

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

ThreadLocal原理分析

接下来笔者的文章方向偏向于 Android & Java 面试相关知识点系统性的总结，欢迎关注。

ThreadLocal类是java.lang包下的一个类，用于线程内部的数据存储，通过它可以在指定的线程中存储数据，本文针对该类进行原理分析。

通过思维导图对其进行简单的总结：

一.ThreadLocal源码分析

ThreadLocal类最重要的几个方法如下：

• get():T 获取当前线程下存储的变量副本
• set(T):void 存储该线程下的某个变量副本
• remove():void 移除该线程下的某个变量副本

1.get()方法分析

ThreadLocal类比较简单，其最重要的就是get()和set()方法，顾名思义，起作用就是取值和设置值：

// 获取当前线程中的变量副本
public T get() {
    // 获取当前线程
    Thread t = Thread.currentThread();
    // 获取线程中的ThreadLocalMap对象
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            // 获取变量副本并返回
            T result = (T)e.value;
            return result;
        }
    }
    // 若没有该变量副本，返回setInitialValue()
    return setInitialValue();
}

这里先将ThreadLocalMap暂时理解为一个Map结构的容器，内部存储着该线程作用域下的的所有变量副本，我们从ThreadLocal类中取值的时候，实际上是从ThreadLocalMap中取值。

如果Map中没有该变量的副本，会从setInitialValue()中取值：

private T setInitialValue() {
   T value = initialValue();
   Thread t = Thread.currentThread();
   ThreadLocalMap map = getMap(t);
   if (map != null)
       map.set(this, value);
   else
       createMap(t, value);
   return value;
}

可以看到，setInitialValue()中也非常的简单，依然是从当前线程中获取到ThreadLocalMap，略微不同的是，setInitialValue()会对变量进行初始化，存入ThreadLocalMap中并返回。

这个初始化的方法的执行，需要开发者自己重写initialValue()方法，否则返回值依然为null。

public class ThreadLocal<T> {
    // ...
    protected T initialValue() {
       return null;
    }
}    

2.set()方法分析

和setInitialValue()方法类似，set()方法也非常简单：

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        // map不为空，直接将ThreadLocal对象作为key
        // 变量本身的值为value，存入map
        map.set(this, value);
    else
        // 否则，创建ThreadLocalMap
        createMap(t, value);
}

可以看到，这个方法的作用就是将变量副本作为value存入Map，需要注意的是，key并非是我们下意识认为的Thread对象，而是ThreadLocal本身（Thread和Value本身是一对一的，我们更容易将其映射为key-value的关系）。

3.remove()方法分析

public void remove() {
   ThreadLocalMap m = getMap(Thread.currentThread());
   if (m != null)
       m.remove(this);
}

对于变量副本的移除，也是通过map进行处理的，和set()和get()相同，Entry的键值对中，ThreadLocal本身作为key，对变量副本进行检索。

4.小结

可以看出，ThreadLocal本身内部的逻辑都是围绕着ThreadLocalMap在运作，其本身更像是一个空壳，仅作为API供开发者调用，内部逻辑都委托给了ThreadLocalMap。

接下来我们来探究一下ThreadLocalMap和Thread以及ThreadLocal之间的关系。

二、ThreadLocalMap分析

ThreadLocalMap内部代码和算法相对复杂，个人亦是一知半解，因此就不逐行代码进行分析，仅系统性进行概述。

首先来看一下ThreadLocalMap的定义：

public class ThreadLocal<T> {

    // ThreadLocalMap是ThreadLocal的内部类
    static class ThreadLocalMap {

      // Entry类，内部key对应的是ThreadLocal的弱引用
      static class Entry extends WeakReference<ThreadLocal<?>> {
          // 变量的副本，强引用
          Object value;

          Entry(ThreadLocal<?> k, Object v) {
              super(k);
              value = v;
          }
      }
    }
}

ThreadLocal中的嵌套内部类ThreadLocalMap本质上是一个map，依然是key-value的形式，其中有一个内部类Entry，其中key可以看做是ThreadLocal实例的弱引用。

和最初的设想不同的是，ThreadLocalMap中key并非是线程的实例Thread，而是ThreadLocal，那么ThreadLocalMap是如何保证同一个Thread中，ThreadLocal的指定变量唯一呢？

// 1.ThreadLocal的set()方法
public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    // ...
}

// 2.getMap()实际上是从Thread中获取threadLocals成员
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

public class Thread implements Runnable {
    // 3.每个Thread实例都持有一个ThreadLocalMap的属性
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

Thread本身持有ThreadLocal.ThreadLocalMap的属性，每个线程在向ThreadLocal里setValue的时候，其实都是向自己的ThreadLocalMap成员中加入数据；get()同理。

三、内存泄漏的风险？

在上一小节中，我们看到ThreadLocalMap中的Entry中，其ThreadLocal作为key，是作为弱引用进行存储的。

当ThreadLocal不再被作为强引用持有时，会被GC回收，这时ThreadLocalMap对应的ThreadLocal就变成了null。而根据文档所叙述的，当key == null时，这时就可以默认该键不再被引用，该Entry就可以被直接清除，该清除行为会在Entry本身的set()/get()/remove()中被调用，这样就能 一定情况下避免内存泄漏。

这时就有一个问题出现了，作为key的ThreadLocal变成了null，那么作为value的变量可是强引用呀，这不就导致内存泄漏了吗？

其实一般情况下也不会，因为即使再不济，线程在执行结束时，自然也会消除其对value的引用，使得Value能够被GC回收。

当然，在某种情况下（比如使用了 线程池），线程再次被使用，Value这时依然可以被获取到，自然也就发生了内存泄漏，因此此时，我们还是需要通过手动将value的值设置为null（即调用ThreadLocal.remove()方法）以规避内存泄漏的风险。

参考&感谢

• 《Android开发艺术探索》
• 深入理解ThreadLocal的"内存溢出"
• 关于ThreadLocal内存泄露的备忘
• ThreadLocal源码分析

关于我

Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的博客或者Github。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费

[译] 编写AndroidStudio插件(一):创建一个基本插件

原文：Write an Android Studio Plugin Part 1: Creating a basic plugin
作者：Marcos Holgado
译者：却把清梅嗅

早在10月的时候，我就在Droidcon UK 2018上针对如何在Android Studio上创建自己的插件，以及如何使所有相关操作自动化进行了讨论。因为当时我并没有很多时间对其进行详细介绍，所以这个系列诞生了。

我们要干什么？

本文我们将编写一个非常基本的插件，这次内容也许并不多，但重要的是，我们将学习插件以及创建插件所需的知识。我们还将创建一个新的Action，该Action将显示一个带有消息的弹出框。

这只是一个非常长的系列文章的第一部分，我将深入研究并为我们的插件扩展更多功能。 您将看到的所有代码都在下方的GitHub仓库中：

marcosholgado/plugin-medium

随着进度的提升，虽然master会一直保持最新的代码，但我还将对每篇文章保留单独的分支。想要如此做，您可以随时返回查看Part1分支。

第一步：安装 IntelliJ IDEA CE

要创建我们的插件，我们将使用IntelliJ IDEA社区版。其主要原因是因为社区版是免费的，且非常容易使用，我们还可以利用gradle-intellij-plugin让这个过程变得更加轻松。

我将使用并非IntelliJ IDEA CE最新稳定版本的IntelliJ IDEA CE 2018.1.6。原因是因为Android Studio 3.2.1基于此IntelliJ版本，我不也想使用任何可能与Android Studio不兼容的新功能。

您可以从此处下载IntelliJ IDEA CE 2018.1.6:

https://www.jetbrains.com/idea/download/previous.html

译者注：上述链接会跳转最新的 IDEA Preview 版本，读者可根据自己喜好进行下载。

第二步：创建一个新的插件项目

和往常一样，创建一个新的项目。

选择Gradle和IntelliJ Platform Plugin，我们唯一要做的，就是确定我们将使用哪种语言。本文我将选择Kotlin（Java）。

这之后，我们需要定义三个属性。

• GroupId — 新项目的groupId，如果您计划在本地部署项目，则可忽略此字段；
• ArtifactId - 新项目的名称；
• Version - 新项目的版本，默认情况下，此字段是自动指定的。

因为我不打算发布此插件，所以只将myplugin用作GroupId和ArtifactId，读者可按需自行定制。

在下一个弹窗，我将不做任何更改，仅保留默认选项。如果您想了解更多有关此步骤的信息，请访问这里。

最后一步就是给我们的插件起个名字。

恭喜你！您刚刚创建了一个新插件，不仅适用于Android Studio，而且还适用于基于IntelliJ的任何其他IDE——尽管您的插件还没有做其它任何事情。

第三步：Gradle 和 plugin.xml

现在，我们已经创建了项目，我们将快速浏览两个文件：plugin.xml和build.gradle。

我们从plugin.xml开始。该文件包含一些插件相关的元数据，以及我们必须注册插件不同元素的位置。在必要的时候，我们将更深入地研究此文件中的某些内容。

另一个文件是build.gradle，我们已经熟悉它了，所以我不解释它的作用。这是您将获得的默认build.gradle文件（版本不同，内容会略有不同）:

plugins {
    id 'org.jetbrains.intellij' version '0.3.12'
    id 'org.jetbrains.kotlin.jvm' version '1.3.10'
}

group 'myplugin'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    compile "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
}

compileKotlin {
    kotlinOptions.jvmTarget = "1.8"
}
compileTestKotlin {
    kotlinOptions.jvmTarget = "1.8"
}
intellij {
    version '2018.2.2'
}
patchPluginXml {
    changeNotes """
      Add change notes here.<br>
      <em>most HTML tags may be used</em>"""
}

一切似曾相识，因为我们习惯了Android项目。当我们开始添加更多依赖项时，我们将折回该文件，依此类推，但目前我只关注两件事。

首先，您可以看到我们的 依赖项 使用了compile而不是implementation/api，主要原因是gradle-intellij-plugin尚不支持implementation/api。

译者注：最新版本的 IDEA 插件已支持。

不过，如果您需要kapt进行任何类型的注解处理，则可以使用kapt（说的就是你，Dagger）。与任何Android项目中一样，您可以使用所需的任何库，但使用时务必小心，因为这不是Android项目。

其次，我们有一个新的部分称为intellij。 在这里，我们将在需要时添加更多属性，如插件依赖性等。现在，我们唯一拥有的属性是version，它指定了应该用作依赖性的IDEA的发行版本。

在继续之前，我将向intellij部分添加另一个属性。 我们现在拥有的插件只能在IntelliJ IDEA CE上调试。 如果我们想立即调试插件的行为，一个新的IntelliJ实例将被启动，我们将不得不在那里进行调试/测试。显然我们想在Android Studio上测试我们的插件，以便告诉gradle-intellij-plugin我们要使用Android Studio，我们必须添加一个新属性。

最终该部分声明如下：

intellij {
    version '2018.1.6'
    alternativeIdePath '/Applications/Android Studio.app'
}

通过使用AlternativeIdePath并指向本地安装的Android Studio，我们告诉gradle-intellij-plugin每当运行插件或对其进行调试时都使用Android Studio，而不是使用默认的IntelliJ IDE。

如果您迫不及待要其他文章来查看可使用的其他属性，请访问这里以获取更多信息。

第四步：编写第一个Action

我们可以在插件中使用不同的元素，我们将在以后的文章中看到所有这些元素，但现在我们将重点介绍最常用的：actions。

当您单击工具栏或菜单项时，基本上就是一个动作，就这么简单，下列图片中您看到的所有内容都是Actions展示的：

通过Actions，我们可以将自己的项目应用到Android Studio的菜单和工具栏上，这些Action被组织成Group，这些Group可以包含其他Group，依此类推。

要创建一个新的Action，我们必须让这个类继承AnAction并重写actionPerformed方法。

class MyAction: AnAction() {

    override fun actionPerformed(e: AnActionEvent) {
        val noti = NotificationGroup("myplugin", NotificationDisplayType.BALLOON, true)
        noti.createNotification("My Title",
                                "My Message",
                                NotificationType.INFORMATION,
                                null
                               ).notify(e.project)
    }
}

在这里，我们创建了一个简单的Action，它将显示一个带有标题和消息的弹窗。我们要做的最后一件事是将此Action添加到我们的plugin.xml文件中。

<actions>
    <group id="MyPlugin.TopMenu"
           text="_MyPlugin"
           description="MyPlugin Toolbar Menu">
        <add-to-group group-id="MainMenu" anchor="last"/>
        <action id="MyAction"
                class="actions.MyAction"
                text="_MyAction"
                description="MyAction"/>
    </group>
</actions>

我们的Action必须属于一个Group，因此，首先，我创建了一个ID为MyPlugin.TopMenu的新Group。 我还将该Group添加到MainMenu Group，它是您可以在任何IntelliJ IDE上看到的主要工具栏。我将其位置锚定为最后一个，这样我们的Group将处于该Group的最后位置。 最后，我将Action添加到MyPlugin.TopMenu Group中，以便我们可以从那里访问它。

如果您想知道我如何知道MainMenu ID的存在，只需命令+单击MainMenu ID，它将带您进入一个名为PlatformActions.xml的文件，该文件包含绝大多数Action（类似于VcsActions.xml） 和IDE中的Group。

我们可以对Action和Group执行许多不同的操作，例如添加分隔符或复用它们。我将在以后的文章中对其进行探讨，但现在您可以在这里查看它们。

第五步：运行它！

就这样，我们刚刚编写了一个非常简单的插件。现在我们可以使用run按钮运行它，也可以对其进行调试。这将创建一个新的Android Studio实例，它将安装我们的插件。另一个选项是运行buildPlugin gradle任务，该任务将生成一个.jar文件，您可以将其作为插件安装在Android Studio或任何其他IntelliJ IDE上。

安装插件并运行Android Studio后，您现在可以在主工具栏上看到包含MyAction的新MyPlugin group。

在单击MyAction之后，将显示一个新的弹窗，其包含您定义的标题和消息。请记住在log日志窗口上启用 Show balloons，否则，您将不会看到弹窗，而是一个日志事件。

第一部分就是这样。在第二部分，我们将研究如何使用组件存储数据并保存插件的状态。同时，如果您有任何疑问，请访问twitter或发表评论。

如果您想观看我在Droidcon UK上发表的演讲，请点击这里。

《编写AndroidStudio插件》译文系列

• 译: 编写AndroidStudio插件(一):创建一个基本插件
• 译: 编写AndroidStudio插件(二):持久化数据
• 译: 编写AndroidStudio插件(三): 更多配置
• 译: 编写AndroidStudio插件(四):整合Jira
• 译: 编写AndroidStudio插件(五):本地化和通知

关于译者

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

如果您觉得文章还差了那么点东西，也请通过 关注 督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

哈希表原理及简单设计

本文为博主算法学习过程中的学习笔记，主要内容来源于其他平台或书籍，出处请参考下方 参考&感谢 一节。

介绍

哈希表 是一种使用哈希函数组织数据，以支持快速插入和搜索的数据结构。

有两种不同类型的哈希表：哈希集合 和 哈希映射。

• 哈希集合是 集合 数据结构的实现之一，用于存储 非重复值。
• 哈希映射是 映射 数据结构的实现之一，用于存储(key, value)键值对。

通过选择合适的哈希函数，哈希表可以在插入和搜索方面实现出色的性能。

原理及设计关键

哈希表的关键**是使用哈希函数 将键映射到存储桶。更确切地说，

• 1、当我们插入一个新的键时，哈希函数将决定该键应该分配到哪个桶中，并将该键存储在相应的桶中；
• 2、当我们想要搜索一个键时，哈希表将使用相同的哈希函数来查找对应的桶，并只在特定的桶中进行搜索。

1、哈希函数

哈希函数是哈希表中最重要的组件，该哈希表用于将键映射到特定的桶。

散列函数将取决于 键值的范围 和 桶的数量。

哈希函数的设计是一个开放的问题。其**是尽可能将键分配到桶中，理想情况下，完美的哈希函数将是键和桶之间的一对一映射。然而，在大多数情况下，哈希函数并不完美，它需要在桶的数量和桶的容量之间进行权衡。

2、解决冲突

理想情况下，如果我们的哈希函数是完美的一对一映射，我们将不需要处理冲突。不幸的是，在大多数情况下，冲突几乎是不可避免的。

冲突解决算法应该解决以下几个问题：

1、如何组织在同一个桶中的值？
2、如果为同一个桶分配了太多的值，该怎么办？
3、如何在特定的桶中搜索目标值？

根据我们的哈希函数，这些问题与 桶的容量 和可能映射到 同一个桶的键的数目 有关。

让我们假设存储最大键数的桶有 N 个键。

通常，如果 N 是常数且很小，我们可以简单地使用一个数组将键存储在同一个桶中。如果 N 是可变的或很大，我们可能需要使用 高度平衡的二叉树 来代替。

设计哈希集合

不使用任何内建的哈希表库设计一个哈希集合。

在本文中，我们使用单独链接法，来看看它是如何工作的。

• 1、从本质上讲，HashSet的存储空间相当于连续内存数组，这个数组中的每个元素相当于一个桶。
• 2、给定一个值，我们首先通过哈希函数生成对应的散列值来定位桶的位置。
• 3、一旦找到桶的位置，则在该桶上做相对应的操作，如add，remove，contains。

对于桶的设计，我们有几种选择，可以使用数组来存储桶的所有值。然而数组的一个缺点是需要O(N)的时间复杂度进行插入和删除，而不是O(1)。

因为任何的更新操作，我们首先是需要扫描整个桶为了避免重复。选择链表来存储桶的所有值是更好的选择，插入和删除具有常数的时间复杂度。

public class MyHashSet {

    private int keyRange;
    private Bucket[] buckets;

    /**
     * Initialize your data structure here.
     */
    public MyHashSet() {
        this.keyRange = 793;
        this.buckets = new Bucket[this.keyRange];

        for (int i = 0; i < keyRange; i++) {
            buckets[i] = new Bucket();
        }
    }

    protected int _hash(int key) {
        return key % this.keyRange;
    }

    public void add(int key) {
        int index = this._hash(key);
        buckets[index].insert(key);
    }

    public void remove(int key) {
        int index = this._hash(key);
        buckets[index].delete(key);
    }

    public boolean contains(int key) {
        int index = this._hash(key);
        return buckets[index].contain(key);
    }

    class Bucket {

        private LinkedList<Integer> container;

        Bucket() {
            this.container = new LinkedList<>();
        }

        void insert(Integer key) {
            int index = container.indexOf(key);

            if (index == -1)
                container.addFirst(key);
        }

        void delete(Integer key) {
            container.remove(key);
        }

        boolean contain(Integer key) {
            return container.indexOf(key) != -1;
        }
    }
}

设计哈希映射

不使用任何内建的哈希表库设计一个哈希映射。

class MyHashMap {

    private int keyRange;
    private Node[] nodes;

    public MyHashMap() {
        this.keyRange = 793;
        this.nodes = new Node[this.keyRange];
    }

    protected int _hash(int key) {
        return key % this.keyRange;
    }

    public void put(int key, int value) {
        int index = this._hash(key);
        Node curr = nodes[index];

        if (curr == null) {
            Node node = new Node(key, value);
            nodes[index] = node;
            return;
        }

        while (curr != null) {
            if (curr.key == key) {
                curr.value = value;
                return;
            }
            if (curr.next == null) {
                Node node = new Node(key, value);
                node.prev = curr;
                node.next = curr.next;  // curr.next = null
                curr.next = node;
                return;
            } else {
                curr = curr.next;
            }
        }
    }

    public int get(int key) {
        int index = this._hash(key);
        Node curr = nodes[index];

        while (curr != null) {
            if (curr.key == key) {
                return curr.value;
            } else {
                curr = curr.next;
            }
        }
        return -1;
    }

    public void remove(int key) {
        int index = this._hash(key);
        Node curr = nodes[index];

        if (curr != null && curr.key == key) {
            Node next = curr.next;
            if (next != null)
                next.prev = null;
            nodes[index] = next;
            return;
        }

        while (curr != null) {
            if (curr.key == key) {
                Node prev = curr.prev;
                Node next = curr.next;

                if (prev != null)
                    prev.next = next;
                if (next != null)
                    next.prev = prev;
                return;
            } else {
                curr = curr.next;
            }
        }
    }

    class Node {

        Integer key;
        Integer value;

        Node next;
        Node prev;

        Node(Integer key, Integer value) {
            this.key = key;
            this.value = value;
        }
    }
}

参考 & 感谢

文章绝大部分内容节选自LeetCode，概述：

• https://leetcode-cn.com/explore/learn/card/hash-table/203/design-a-hash-table/797/

例题：

• https://leetcode-cn.com/problems/design-hashset/
• https://leetcode-cn.com/problems/design-hashmap/

关于我

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列

Flutter与Android混合编码配置笔记

学习Flutter一小段时间，对纯Flutter项目有了一些基本的了解，但更趋近实际开发的应该是将Flutter模块作为一个依赖库添加到原生的Android项目中。

本文笔者将尝试分享个人针对Flutter与Android混编时的配置步骤，以及踩坑过程。

一、初始化Flutter-Module

参考 官方文档 ，首先需要确认Flutter-Module依赖库文件夹的位置，简单来说，这里有两种方式：

• 1.创建在项目的根目录下（内部）；
• 2.创建和项目文件夹的同一层级（外部），这也是官方推荐的方式。

其实这些方式没什么区别，但是个人更倾向于第二种，我们在项目文件夹的目录层级下对Flutter-Module文件夹进行 创建 并 初始化：

$ flutter create -t module module_flutter

成功后，Flutter-Module和Android项目本身应该是这样的（红框内的两个项目）：

二、配置Android项目

接下来我们需要将这个项目和刚刚创建的module-flutter进行依赖，我们先打开Android原生项目，并为项目根目录下的settings.gradle文件中添加如下配置：

setBinding(new Binding([gradle: this]))
evaluate(new File(
        settingsDir.parentFile,
        'module_flutter/.android/include_flutter.groovy'
))

如果module-flutter模块是创建在项目内部，那么需要稍微改一改：

setBinding(new Binding([gradle: this]))
evaluate(new File(
        settingsDir.path,
        'module_flutter/.android/include_flutter.groovy'
))

然后，我们需要打开app的build.gradle文件，添加对flutter的依赖：

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'androidx.appcompat:appcompat:1.0.0'
    implementation 'androidx.annotation:annotation:1.0.0'

    ......

    implementation project(':flutter')
}

这样，对于简单的Android原生项目而言，Flutter已经配置成功了。

三、AndroidX的迁移

由于笔者的项目迁移了AndroidX, 但是低版本的Flutter命令生成的module默认依赖的是support包, 因此我们需要将默认support的依赖手动迁移到AndroidX。

截止笔者发文前，FlutterV1.7已经提供了对AndroidX的支持，当创建 Flutter 项目的时候，你可以通过添加 --androidx 来确保生成的项目文件支持AndroidX，详情参考这里。

手动迁移的方式有两种：

• 1.通过Android Studio 自动迁移 过去。

首先通过Android Studio打开flutter-module，这时候是不能直接迁移AndroidX的，需要通过flutter - Open Android module in AS 方式新打开一个窗口。