Android

Android 相关知识、常用工具的原理解析等

Android View 体系

好玩系列：优雅的处理ButterKnife和KAE被废弃

最近反思了一下近期的工作，忽然就出现了一个想法，将平时干的好玩的事情，整理成一个系列，和大家分享一下，想来想去也没想好这个系列叫啥，索性就叫好玩系列得了。

文中涉及的代码均在 此处 可以找到

前言

如果你的项目中使用了ButterKnife或者Kotlin-Android-Extention（KAE）插件，近半年你一定关注过如下信息：

Attention: This tool is now deprecated. Please switch to view binding. Existing versions will continue to work, obviously, but only critical bug fixes for integration with AGP will be considered. Feature development and general bug fixes have stopped. -- ButterKnife

Resource IDs will be non-final in Android Gradle Plugin version 5.0, avoid using them in switch case statements Inspection info:Avoid the usage of resource IDs where constant expressions are required. A future version of the Android Gradle Plugin will generate R classes with non-constant IDs in order to improve the performance of incremental compilation.

Issue id: NonConstantResourceId -- lint

The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

是的，这两个在Android中使用面很广的内容被标记为废弃了。

对于ButterKnife，被废弃的原因是：从AGP-5.0版本开始，R类生成的值不再是常量

对于KAE，问题如下：

• 类型安全：res下的任何id都可以被访问，有可能因访问了非当前Layout下的id而出错，难以利用lint等静态代码校验
• 空安全：运行时可能出现NPE
• 兼容性：只能在kotlin中使用，java不友好
• 局限性：不能跨module使用

按照官方或者社区的推荐，替代方案还是回归到findViewById or ViewBinding or DataBinding.

未来可能替代XML描述布局文件的技术：Compose还没有真正到来，而且一时半会也不可能把原先的内容全部迁移到Compose实现，所以我们还是要老老实实回归到上面的三个方案。

有些同学知识面广一点，立马想到了psi，通过分析代码文件的psi树，实现代码转换，直接搞一个插件来处理ButterKnife的迁移问题。

当然，这篇文章并不准备去讲psi，虽然这是一个挺好玩的东西。下次有时间会专门写一个好玩的psi

思考1：为什么要废弃ButterKnife

因为AGP生成的R类资源值不再是常量，无论是library还是application，那么要继续再思考一个问题：library的R类资源也不是常量，原先ButterKnife是怎么处理的？ 我们知道，Butterknife有运行时反射用法，也有编译期使用apt预生成代码的用法。bk提供了gradle插件，用于copy原始R类内容,生成R2类，R2复刻了R的内容，但均为常量。因为注解中的内容，是需要在编译期确定，它被要求为常量，并且在编译时被优化。但我们知道，通过字节码技术，可以修改很多东西，无论是一个常量的值，还是索性连类都给换了。 一旦这个值被修改，注解中的信息便为谬误。但因为R2的存在，我们可以通过常量值反向获取到常量的名字，从而去使用R类。

思考2：是不是Butterknife所有的代码都没有意义了？

显然不是，因为findviewbyid还没用被革命性改变，bk中所有的核心代码还是有用的 如果你使用的apt方式，那么就有意思了，对于一个特定的target，bk生成的绑定代码完全是没有“废弃”风险的，我们完全可以拷贝其中的逻技，或者直接对生成类实行“拿来主义” 最终，我们只需要扔掉bk的gradle插件，注解和apt处理器，岁月静好。 如果你使用的是运行时反射方案，我不排斥运行时反射，虽然他会多耗一些时间，如果你不介意耗费更多的时间，完全可以改造bk的注解和逻辑，虽然它很好玩，但这并不是一个值得推荐的做法。

思考3：kae又是怎么帮助我们找到view的

没错，还是通过findviewbyid，它被废弃并不是犯了什么大错，只是不在适应潮流，且有各种各样的小毛病。 我们以Fragment为例子，看一下编译器为我们植入的代码：

public android.view.View _$_findCachedViewById(int var1) {
    if (this._$_findViewCache == null) {
       this._$_findViewCache = new HashMap();
    }

    android.view.View var2 = (android.view.View)this._$_findViewCache.get(var1);
    if (var2 == null) {
       android.view.View var10000 = this.getView();
       if (var10000 == null) {
          return null;
       }

       var2 = var10000.findViewById(var1);
       this._$_findViewCache.put(var1, var2);
    }

    return var2;
 }

 public void _$_clearFindViewByIdCache() {
    if (this._$_findViewCache != null) {
       this._$_findViewCache.clear();
    }

 }

以及：

// $FF: synthetic method
public void onDestroyView() {
  super.onDestroyView();
  this._$_clearFindViewByIdCache();
}

//源码
vMallAccountTitleBar.setTitle("我的钱包")

//反编译结果
((BarStyle4)this._$_findCachedViewById(id.vMallAccountTitleBar))
	.setTitle((CharSequence)"我的钱包");

可以很轻易的发现，具有多种场景下潜在的npe风险。本质上还是在使用findViewByID机制

思考4：是否可以最小程度重构实现从bk切换到databinding或者viewbinding

首先还是要粗略提一下databinding和viewbinding。记忆中databinding技术先于viewbinding，是Google提供的声明式UI解决方案，这里必须要岔开一句：什么是声明式UI？

这里我用SQL举个例子类比， select * from t where 't.id' = 1， 这就是声明式，声明一个符合规则的定则，让对应的系统执行，得到目标结果。相应的，对立面就是命令式，命令式需要准确的指出每一步操作的具体指令，以完成一个特定的算法。

肤浅的总结，声明式是底层实现了一类行为的抽象，其核心的算法或者控制段均被封装，只需要控制输入，即可得到输出。而命令式则完全需要自行实现。

理解了这一点，我们就会意识到，databinding本身不应该对外暴露这些view，只是这么干的话，项目迁移成本就会变大，所以还是选择了开放，这也就有了后来的viewbinding。

言归正传，原先用bk，我们需要一个根view作为起始点，以实现视图绑定，基本是找到Activity#setContentView(Int id)后activity的decorview，或者是viewholder#getRoot()，或者是开发者inflate得到的一个view等等。

不难判断，如果彻底的修改代码，从基类出发应该是没什么方案。只能进行一件枯燥乏味的事情

思考5：如果是kotlin语言下，利用属性代理是否可以简化代码修改

延伸：属性委托指的是一个类的某个属性值不是在类中直接进行定义，而是将其托付给一个代理类，从而实现对该类的属性统一管理。 属性委托语法格式：

val/var <属性名>: <类型> by <表达式>

实践1：属性代理替代BK的注解

先定一个小目标,我们会将注解形式变成类似以下代码的形式：

val tvHello1 by bindView<TextView>(R.id.dialog)

val tvHello by bindView<TextView>(viewProvider, R.id.hello, lifecycle) {
    bindClick { changeText() }
}

val tvHellos by bindViews<TextView>(
    viewProvider,
    arrayListOf(R.id.hello1, R.id.hello2),
    lifecycle
) {
    this.forEach {
        it.bindClick { tv ->
            Toast.makeText(tv.context, it.text.toString(), Toast.LENGTH_SHORT).show()
        }
    }
}

那么我们需要先定义一个属性代理类，并实现操作符，以bindView为例，

我们先缓一缓，定义一个基类，接受属性持有者的生命周期，以实现其生命周期走到特定节点时释放依赖。

abstract class LifeCycledBindingDelegate<F,T>(lifecycle: Lifecycle): ReadOnlyProperty<F,T> {

    protected var property: T? = null

    init {
        lifecycle.onDestroyOnce { destroy() }
    }

    protected open fun destroy() {
        property = null
    }
}

internal class OnDestroyObserver(var lifecycle: Lifecycle?, val destroyed: () -> Unit) :
    LifecycleEventObserver {
    override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
        val lifecycleState = source.lifecycle.currentState
        if (lifecycleState == Lifecycle.State.DESTROYED) {
            destroyed()
            lifecycle?.apply {
                removeObserver(this@OnDestroyObserver)
                lifecycle = null
            }
        }
    }
}

fun Lifecycle.onDestroyOnce(destroyed: () -> Unit) {
    addObserver(OnDestroyObserver(this, destroyed))
}

这时候我们来处理findViewById的核心部分

class BindView<T:View>(
    private val targetClazz: Class<T>,
    private val rootViewProvider: ViewProvider,
    @IdRes val resId: Int,
    lifecycle: Lifecycle,
    private var onBind: (T.() -> Unit)?
):LifeCycledBindingDelegate<Any,T>(lifecycle) {


    override fun getValue(thisRef: Any, property: KProperty<*>): T {
        return this.property ?: let {

            val rootView = rootViewProvider.provide()
            val v = rootView.findViewById<T>(resId)
                ?: throw IllegalStateException(
                    "could not findViewById by id $resId," +
                            " given name: ${rootView.context.resources.getResourceEntryName(resId)}"
                )
            return v.apply {
                this@BindView.property = this
                onBind?.invoke(this)
                onBind = null
            }
        }
    }
}

我们需要几样东西以支持：

View#<T extends View> T findViewById(@IdRes int id)

对应了目标类，根View提供者，目标view的id，属性持有者的生命周期和初次属性初始化后的附加逻辑

至于BindViews，我们如法炮制即可。

这时候会发现，这样使用太累了，对于Activity、Fragment、ViewHolder等常见的类而言，虽然他们提供根视图等内容的方式有所差别，但这种行为基本是可以抽象的。

以ComponentActivity为例，我们只需要定义扩展函数：

inline fun <reified T : View> ComponentActivity.bindView(@LayoutRes resId: Int) =
    BindView<T>(
        targetClazz = T::class.java,
        rootViewProvider = object : ViewProvider {
            override fun provide(): View {
                return this@bindView.window.decorView
            }
        },
        resId = resId,
        lifecycle = this.lifecycle,
        onBind = null
    )

就可以比较方便的使用，剩下来的Fragment、ViewHolder之类的东西，讲起来太啰嗦了，都是如法炮制。

再定义一个大而全的：

inline fun <reified T : View> Any.bindView(
    rootViewProvider: ViewProvider,
    @LayoutRes resId: Int,
    lifecycle: Lifecycle,
    noinline onBind: (T.() -> Unit)?
) =
    BindView<T>(
        targetClazz = T::class.java,
        rootViewProvider = rootViewProvider,
        resId = resId,
        lifecycle = lifecycle,
        onBind = onBind
    )

实际项目中想怎么用完全看实际就行了。

思考6：让DataBinding和ViewBinding拥有同样的特性是否有价值

当然是有价值的，一个大项目中，尤其是进行了模块化拆分，不同模块使用不同的技术是很正常的，DataBinding和ViewBinding并存的情况一定会发生，虽然我并没有真正遇到过同时使用的，并且并不清楚同时使用会不会有bug

实践2：支持DataBinding和ViewBinding

因为笔者项目中没有使用ViewBinding，我们就粗暴的只实现DataBinding了，其实都是获取Binding类实例而已，机制是一致的，ViewBinding可以如法炮制

得益于我们上面定义的基类，我们可以直接干一个处理DataBinding的子类了

class BindDataBinding<T : ViewDataBinding>(
    private val targetClazz: Class<T>,
    private val inflaterProvider: LayoutInflaterProvider,
    @LayoutRes val resId: Int,
    lifecycle: Lifecycle,
    private var onBind: (T.() -> Unit)?
) : LifeCycledBindingDelegate<Any, T>(lifecycle) {

    override fun getValue(thisRef: Any, property: KProperty<*>): T {

        return this.property ?: let {

            val layoutInflater = inflaterProvider.provide()
            val bind = DataBindingUtil.bind<T>(layoutInflater.inflate(resId, null))
                ?: throw IllegalStateException(
                    "could not create binding ${targetClazz.name} by id $resId," +
                            " given name: ${layoutInflater.context.resources.getResourceEntryName(resId)}"
                )
            return bind.apply {
                this@BindDataBinding.property = this
                onBind?.invoke(this)
                onBind = null
            }
        }

    }
}

依葫芦画瓢，我们直接搞定inflate方式获取Binding。

仔细一想，这还不够，本来我们将布局改为DataBinding模板，有多种方案设置视图，使用属性代理，有一个目的是：让设置视图和得到Binding实例之间减少限制。

再干一个：

class FindDataBinding<T : ViewDataBinding>(
    private val targetClazz: Class<T>,
    private val viewProvider: ViewProvider,
    lifecycle: Lifecycle,
    private var onBind: (T.() -> Unit)?
) : LifeCycledBindingDelegate<Any, T>(lifecycle) {

    override fun getValue(thisRef: Any, property: KProperty<*>): T {

        return this.property ?: let {
            val view = viewProvider.provide()
            val bind = DataBindingUtil.bind<T>(view)
                ?: throw IllegalStateException(
                    "could not find binding ${targetClazz.name}"
                )
            return bind.apply {
                this@FindDataBinding.property = this
                onBind?.invoke(this)
                onBind = null
            }
        }
    }
}

我们又可以通过bind的方式，从一个View发现其binding了。寻找binding和设置视图的先后，就可以灵活选择了。

加上一些扩展方法后，我们就可以开心的使用了：

class MainActivity2 : AppCompatActivity() ,ViewProvider{
    val binding by dataBinding<ActivityMainBinding>(this)

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

        binding.hello.text = "fragment"
        binding.hello.bindClick {

        }
    }

    override fun provide(): View {
        return window.decorView.findViewById(R.id.ll_root)
    }
}

总结

正如开篇提到的，好玩系列其出发点一定是好玩，它很可能是对一个问题展开的一次脑暴和尝试，不一定是一个真正成熟的特定问题通用解法。

这一篇，我们从Butterknife的废弃和KAE的废弃开始思考，回顾了两者的实现原理和被废弃的原因，再到寻找迁移方案，并进行了实践。抛开还未涉及到的PSI，基本可以画上一个阶段性句号了。

再次贴上代码链接： UIBinding，如果本文中的内容对你有一丝丝的帮助，希望可以得到点赞支持。

补充：2021-1-25 再补充一段内容重点。

• 对于Java编写的业务，不牵涉kae，只涉及bk，个人建议拷贝其生成类核心逻辑，再删除相关注解点。
• 对于kotlin编写的业务，bk内容可以和Java一样处理，kae相关内容考虑使用属性代理方式，增加全局变量。
• 这一波重构，并不适合在基类做手脚。
• 对于还没有迁移到databinding或者viewbinding的内容，配合属性代理迁移到databinding或者viewbinding也不麻烦。

三思系列：View体系认知(一)，内容是如何正确被展现出来的--视觉呈现概览

前言

这是View体系认知子系列的第一篇，这一篇会探知Android中，是通过怎么的设计 让视图正确呈现在屏幕上的。

关于三思系列

关于View系列 极力建议读者了解一下 为什么撰写这个系列

考虑到博客不适合做大量的代码展现，我会以 WorkShop 的形式展现这些代码。链接

我们知道，在GUI编程中，必然存在一套试图体系内容，Android中也有一套，抛开掉底层内容，和Compose中的内容， 我们这一篇，一同探究下 Framework中，View体系 如何做视觉呈现。

补充：2021-02-22

感谢读者 鲁班贼六的建议，补充内容导图

这篇文章篇幅较长，在 View 的 measure 机制上花费了不少篇幅。本文尝试先抛开 Android已有知识体系，模拟 从现实情况思考，以建立认知体系的情况。

所以文章的内容编排和导图有一定出入。

注:本文中不涉及：

• Canvas绘制基础
• 屏幕渲染底层机制

我们会先思考，如何描述一个任意的界面，引出 View 继承体系，和 View-Tree 视图树。

再逆推一波：当界面被描述后，需要正确显示存在以下三步：

• 将 正确内容 绘制在 正确位置
  • 本文中，Widget的内容绘制略
• 依据布局规则，确定布局位置。 注：显示大小 也可以算作 布局规则 的范畴
• 测量显示大小

我们会先从现实情况出发，思考并设计一种可行的 测量规则 ，并不断完善它，重点在于：

• 理解 这种设计是如何 演化 得来的
• 明白 测量本身就和 布局规则 有关，布局规则 会影响到测量过程

如果读者对 某些内容 已经打下 坚实的基础，建议 选择性泛读。

如何描述一个任意的界面

假如我们现在对Android的内容一无所知，如何描述 一个 任意的界面。

• 无论我们要达成什么效果，必然存在一个虚拟窗体，和物理屏幕相对应
• 系统层面抽象的绘制呈现过程，一定需要通过 这个 虚拟窗体，而我们描述的界面内容，会被放在窗体中
• 按照 面向对象思想 和 单一职责原则，描述 这个窗体 的类，假定被称为 Window，一定和描述视图的类 不是同一个。假定视图类被称为 View
• Window可以获知内部View的信息

在此基础上，

方案1：构建一个上帝类，它全知全能，能够 记录 和 表达 任意的"文字"、"图片"、"区块"等信息。

方案2：构建一个简单类 View，它有方式知道自己多大，并抽象了视图内容绘制，可以在内部放置子 View，并有方式确定如何放置；

显然，方案1不可取。我们细化方案2.

此时，我们做出了一个假设：View拥有3个能力

• 测算自身大小
• 可以放置子View；并知道其所在位置，即拥有 布局能力
• 准确的知道如何绘制自身所代表的内容

在此基础上，我们就可以将 任意界面 拆分结构，这个结构可以用 树 来表达。

目前我们约定：

• 每个 View 只能有 一个 双亲
• 作为双亲的 View，仅用来描述 布局信息
• 实际 可视 、 可交互 的 View， 描述其代表的内容信息

于是 描述任意界面 的问题，就可以用 描述一棵树 来解决。

注：目前这个约定还很粗糙，但是不影响我们进行问题认知

树的存储方法有3种：

• 双亲表示法
• 孩子表示法
• 孩子兄弟表示法

以及基于以上方法的改进版本

为了更加方便地向上和向下检索，我们使用 双亲孩子表示法 这一改进版本。

细化方案2，ViewGroup和Widget，各司其职

按照我们上面对树的约定

我们按职责细分：

• 一部分View 专注于对子View的布局能力，而不再表达 "文字"、"图片"等内容信息，我们将其抽象为子类 ViewGroup。因为没有具体表达 如何放置子View的 规则，所以它是抽象类。

• 将 非包含子View 的，表达"文字"、"图片"等特定信息的View，归纳为Widget。

小结：在上面的阶段性成果中，我们已经细化了方案，用树的形式，描述了界面的结构和内容。 存在一个预设的ViewGroup，作为树的根节点。

下面我们先给出一些伪代码。

open class View {
    var parent: View? = null

    //绘制能力
    protected open fun onDraw(canvas: Canvas) {

    }

    //布局能力
    protected open fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {

    }

    //测量能力
    protected open fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {

    }
}

abstract class ViewGroup : View() {
    protected val children = arrayListOf<View>()

    abstract override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int)

    fun addView(view: View) {
        if (view.parent != null) {
            throw IllegalArgumentException("view has a parent")
        }
        children.add(view)
        view.parent = this
    }

}

测量大小

接下来我们设计测量大小的能力，

假定有一个显示文字的View，他可以测算自身的大小，但这有3种可能：

• 恰好装下文字内容
• 被指定了大小，但和第一种大小不一致，这又分两个情况：
  • 人为指定的明确值
  • 被限定的区域，比如无法超过屏幕大小

此时仔细思考一下，对于一个 View-tree 而言,测量每一个节点大小的意义是什么？

准确的完成布局 并 完成自身的绘制

但是有很重要的一点： 屏幕的大小，屏幕的大小是 固定的 、 明确的，这意味着，界面能够单次展示的最大 区域已经固定。

同理，对于一个有 Parent 的 View，原则上来说，它的展示区域也被限定在 Parent的区域中。

但是仔细一想，这并 不合理 啊，有一种革命式的交互： 滑动 ，可以用有限的窗口，展示无限的内容。

所以，我们先记住 一个情况：

不同类型的ViewGroup，对应着不同的布局特性，他们对待 子View 的态度也是不同的，可以表现为

• 子View 可以 要求 比自身大 的展示大小，最终满不满足以及如何满足是之后的事情。
• 子View 可以 要求 比自身大 的展示大小，但是要了也不给。

这时我们可以总结一个结论，展示和绘制一个内容时，有两组大小需要被考虑：

• 内容本身的大小
• 用于展示的区域大小

同样的，当一个 View 或者 ViewGroup，称之为A 被置于 ViewGroup B 中时。

A的大小就是内容本身的大小，B的大小就是用于展示的区域大小，递归思考之后，整个View-Tree都是这样。

显然，测量工作从树的 根节点开始，按照经验，可以使用 深度优先 完成整个测量工作。

我们希望得到的，是每个 View 所对应的 展示区域大小。按照刚才举的例子分析实际情况，我们可以用三种方式来指定View的展示大小：

• 一个明确值
• 相对值：刚好能够放下它的内容 -- wrap_content
• 相对值：撑满 Parent 的空间 -- match_parent

并在测量时，得到准确的结果。

我们再思考这几个取值场景：

对于Child而言，

• 设置了 展示大小为 明确值，毋庸置疑，测量时一定可以得到这个明确值
• 设置了 展示大小为 match_parent, 因为测量是从 Parent 到 Child， 所以，对于Child 而言,只要Parent的测量工作已经完成， 即 Parent 已经测算出自己的 精确大小， 那么Child使用 match_parent 是可以得到明确值的。但如果Parent没有完成测算，我们先不思考这个问题
• 设置了 wrap_content，显然，要先测算出 其内容 的大小，才能得到 显示区域 的 明确值

注 上面这一段内容，非常重要，值得仔细思考。另：上述的内容中，我们先忽略掉 可能存在 的 内边距。

刚才我们还有一些没有考虑的内容：

Parent 没有完成测算，Child 设置了 match_parent

那么，至少我们可以确定 Parent 不可能 指定了 显示大小 的 明确值，至于其他的情况，需要用数学归纳法 讨论嵌套，我们换个角度思考。

根节点 的ViewGroup，我们可以得到 显示大小 的 明确值，按照刚才的讨论，其子View，使用 match_parent 或者 明确值 时，结合Parent 信息，可以得到 明确值；

只有当其为 wrap_content 时，需要继续测量其内容，再根据内容的大小，确定自身显示大小。

可以确定，当树中的一个节点为wrap_content 时，将该节点作为根节点，取出子树，当该子树的 所有分支 都能够找到满足 条件R 的节点时， 该根节点能够确定自身需要的显示大小。

条件R为：该View

• 指定 显示大小为 match_parent 或者 明确值
• 或者其 布局要求 能够让 parent 大小撑满至一个 明确值

上面这一段内容有点长，适当消化一下

此时，我们可以做出一点约定：

Parent 多承担一点责任，结合自身情况，和Child情况，先确定一下，Child是否可以得到明确的显示大小，

• 如果不可以，就将自身信息传递给Child，让它向下继续处理
• 如果可以，那么 Parent 可以得出Child的显示大小, 注意 不同类型的Parent，应该有不同的计算方式。 这在前面提到过

确定测量规则

经过上面的思考，我们可以拟定测量规则了。

1. 测量必然从一个明确自身展示大小 的 ViewGroup 开始
2. 对于一个子View -- A，当其 Parent -- P 判断出 A
   • 可以得到 明确的 显示大小时，将 该信息： 可准确得到结果 + 结果值 传递给 子View A； 注意，结果值是 Parent 按照自身规则计算的，和子View要求的可能不一致
   • 否则，将 P 的 自身大小 和 你还需要继续测量以得到结果 的信息传递给 子View A。
3. 对于一个Parent，如果它是 wrap_content，则需要在子View 的显示大小都确定时，再计算自身大小。
4. 只要View-Tree中还 存在 未确定 自身 显示大小 的节点。就需要从根节点开始，继续遍历处理测量。

让表达更加准确一些，可准确得到结果 用 EXACTLY 代替。 你还需要继续测量以得到结果 用 AT_MOST 代替。

不言自明，AT_MOST 意味着会给定一个最大值。意味着：家族中的直系长辈 已经帮它 限定了人身自由。

方便准确表达，将他们称为 测量模式，简称 mode ：

• EXACTLY：Parent 已经为 Child 决定了显示大小，按照规则，Child 应当使用 Parent 给定的值
• AT_MOST：Parent 已经为 Child 决定了最大显示大小，按照规则，Child 自行决定使用 最大不超过该值 的显示大小

方便表达, 将 显示大小 简称为 size

显示和屏幕像素数量有关，显然，该数量是自然数范畴。size 在绝大多数情况下，可以用 Int值 准确表达，极少数情况下，大到越界，但极不合理。

若使用对象封装 mode 和 size，会出现大量的对象创建，这一点都不优雅，可以将 Int 分为 高位区域 和 低位区域 分别表达 mode 和 size 这也是Android中采用的设计

考虑到 测量模式 中，还可能存在 Parent 不约束 Child 的情况。

我们使用一个 32位Int 的 高2位 标识 mode，低30位 标识 size

进一步优化以减少遍历

规则的第4点中，是通过 迭代 的方式，完成整个树中所有节点的测量，按照实际分析，我们可以用 递归 来简化。

我们约定, 对于一个 设置了 wrap_content 的尾端节点，如果它没有实质的内容物，我们也认为它 已经测量出了 需要的展示大小

那么在一次递归中，我们就可以完成整个树的测量。

在 递 的过程中，仅有设置为 wrap_content 的 Parent角色 无法完成准确测量，而 尾端节点 必然完成了自身的测量。

开始 归 的过程，我们可以确定，每 归 到一个 Parent，

• 已经完成测量的继续 归，
• 没有完成测量的，它的 Children 都完成了测量，则按照 wrap_content 的定义，它必然可以完成测量，然后继续 归

最终整棵树完成测量。

完善规则，再添加一种mode

前面我们提到了 滑动 这一交互形式，可以利用 有限的 展示空间，显示 无限的 内容。

即，我们会遇到一些场景，Child 并不会收到 Parent 的制约。更加准确的说，是 内容 不受到 呈现主体 在显示空间上的制约。

而这个场景，超越了 EXACTLY 和 AT_MOST 两种测量模式的功能，我们还需要一种配套的测量模式：

UNSPECIFIED，即 Parent 不约束 Child，Child按照自身情况，自行测算。

注：对于 UNSPECIFIED ，不要 强行结合场景，尤其是 不要 利用 warp_content或者 match_parent的概念去理解。他们虽然有一些关联， 但并不是一个范畴的内容，也不可以相互推导。

因此，我单独将其拎了出来。

编码以验证

参考Android中FrameLayout的布局规则，它对于Child要求的大小为： 子View 可以 要求 比自身大 的展示大小，但是超过自身显示范围的不予显示。 所以，不 按照自身情况 调整 子View的 size

先给View添加一些必要的内容：

open class View {

    companion object {
        const val layout_width = "layout_width"
        const val layout_height = "layout_height"
        var debug = true
    }

    var tag: Any? = null

    var parent: View? = null

    val layoutParams: MutableMap<String, Int> = mutableMapOf()

    var measuredWidth: Int = WRAP_CONTENT

    var measuredHeight: Int = WRAP_CONTENT

    val heightMeasuredSize: Int
        get() = android.view.View.MeasureSpec.getSize(measuredHeight)

    val widthMeasuredSize: Int
        get() = android.view.View.MeasureSpec.getSize(measuredWidth)

    val heightMeasureMode: Int
        get() = android.view.View.MeasureSpec.getMode(measuredHeight)

    val widthMeasureMode: Int
        get() = android.view.View.MeasureSpec.getMode(measuredWidth)


    private var measured: Boolean = false

    fun isMeasured() = measured

    //绘制能力
    protected open fun onDraw(canvas: Canvas) {

    }

    //布局能力
    protected open fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {

    }

    fun measure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
        if (!measured) {
            onMeasure(widthMeasureSpec, heightMeasureSpec)
        }
    }

    //测量能力
    protected open fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
        setMeasuredDimensionRaw(widthMeasureSpec, heightMeasureSpec)
        debugMeasureInfo()
    }

    protected fun debugMeasureInfo() {
        if (debug) {
            Log.d(
                "view-debug",
                "$tag has measured: $measured, w mode:${getMode(widthMeasureMode)}, w size: $widthMeasuredSize " +
                        "h mode:${getMode(heightMeasureMode)}, h size: $heightMeasuredSize "
            )
        }
    }

    protected fun setMeasuredDimension(measuredWidth: Int, measuredHeight: Int) {
        setMeasuredDimensionRaw(measuredWidth, measuredHeight)
    }

    private fun setMeasuredDimensionRaw(measuredWidth: Int, measuredHeight: Int) {
        this.measuredWidth = measuredWidth
        this.measuredHeight = measuredHeight
        measured = true
        if (debug) {
            Log.d(
                "view-debug",
                "$tag mark has measured: $measured"
            )
        }
    }
}

添加一个FrameLayout：

class FrameLayout : ViewGroup() {
    override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {
    }

    override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
        //handle horizon
        val widthMode = View.MeasureSpec.getMode(widthMeasureSpec)
        var widthSize = View.MeasureSpec.getSize(widthMeasureSpec)

        var wMeasured = false
        var hMeasured = false
        when (widthMode) {
            View.MeasureSpec.EXACTLY -> {
                // widthSize 即为Parent 为此决定的准确值，直接采用
                wMeasured = true
            }
            View.MeasureSpec.AT_MOST -> {
                // 需要再次测量，但可以保存该信息了
                measuredWidth = widthMeasureSpec
            }
            else -> {
                throw IllegalStateException("暂不支持测量模式：$widthMode")
            }
        }

        //同理处理 vertical方向

        val heightMode = View.MeasureSpec.getMode(heightMeasureSpec)
        var heightSize = View.MeasureSpec.getSize(heightMeasureSpec)

        when (heightMode) {
            View.MeasureSpec.EXACTLY -> {
                hMeasured = true
            }
            View.MeasureSpec.AT_MOST -> {
                measuredHeight = heightMeasureSpec
            }
            else -> {
                throw IllegalStateException("暂不支持测量模式：$widthMode")
            }
        }

        if (hMeasured && wMeasured) {
            setMeasuredDimension(widthMeasureSpec, heightMeasureSpec)
        }

        children.forEach {
            val childWidthMeasureSpec = makeMeasureSpec(widthMode, widthSize, it.layoutWidth)
            val childHeightMeasureSpec = makeMeasureSpec(heightMode, heightSize, it.layoutHeight)
            it.measure(childWidthMeasureSpec, childHeightMeasureSpec)
        }


        if (!hMeasured || !wMeasured) {
            var w = 0
            var h = 0
            children.forEach {
                if (!wMeasured)
                    w = maxOf(w, it.widthMeasuredSize)

                if (!hMeasured)
                    h = maxOf(h, it.heightMeasuredSize)
            }

            if (wMeasured)
                w = widthSize

            if (hMeasured)
                h = heightSize

            setMeasuredDimension(
                View.MeasureSpec.makeMeasureSpec(w, widthMode),
                View.MeasureSpec.makeMeasureSpec(h, heightMode),
            )
        }
        if (!allChildHasMeasured())
            throw IllegalStateException("child 未全部完成测量")

        debugMeasureInfo()
    }

    private fun makeMeasureSpec(mode: Int, size: Int, childSize: Int): Int {
        // 参考Android中FrameLayout的布局规则，它对于Child要求的大小为：
        // 子View 可以 要求 比自身大 的展示大小，但是超过自身显示范围的不予显示。
        // 所以，不 按照自身情况 调整 子View的 size
        val childMode = when (childSize) {
            WRAP_CONTENT -> View.MeasureSpec.AT_MOST
            else -> View.MeasureSpec.EXACTLY

        }

        val childSize2 = when (childSize) {
            WRAP_CONTENT -> size
            MATCH_PARENT -> size
            else -> childSize
        }
        return View.MeasureSpec.makeMeasureSpec(childSize2, childMode)
    }

    private fun allChildHasMeasured(): Boolean {
        val i = children.iterator()
        while (i.hasNext()) {
            if (!i.next().isMeasured())
                return false
        }

        return true
    }

}

以上代码 结合前面的规则 理解下即可

目前还没有到LayoutParam的阶段，我们将 必要的布局信息 声明在 map 中存储。

我们适当添加添加一些助手类，以建立View-tree

enum class Mode(val v: Int) {

    /**
     * Measure specification mode: The parent has not imposed any constraint
     * on the child. It can be whatever size it wants.
     */
    UNSPECIFIED(0 shl 30),

    /**
     * Measure specification mode: The parent has determined an exact size
     * for the child. The child is going to be given those bounds regardless
     * of how big it wants to be.
     */
    EXACTLY(1 shl 30),

    /**
     * Measure specification mode: The child can be as large as it wants up
     * to the specified size.
     */
    AT_MOST(2 shl 30)
}

class A {
    companion object {
        fun getMode(v: Int): Mode {
            Mode.values().forEach {
                if (it.v == v)
                    return it
            }
            throw IllegalStateException()
        }
    }
}

以上代码不言自明

typealias Decor<T> = (v: T) -> Unit

val MATCH_PARENT: Int = android.view.ViewGroup.LayoutParams.MATCH_PARENT
val WRAP_CONTENT = android.view.ViewGroup.LayoutParams.WRAP_CONTENT

var View.layoutWidth: Int
    get() {
        return layoutParams[View.layout_width] ?: WRAP_CONTENT
    }
    set(value) {
        layoutParams[View.layout_width] = value
    }

var View.layoutHeight: Int
    get() {
        return layoutParams[View.layout_height] ?: WRAP_CONTENT
    }
    set(value) {
        layoutParams[View.layout_height] = value
    }


fun root(): ViewGroup = FrameLayout().apply {
    this.layoutWidth = 1080
    this.layoutHeight = 1920
}

inline fun ViewGroup?.frameLayout(decor: Decor<FrameLayout>): ViewGroup {
    val child = FrameLayout()
    child.let(decor)
    return this?.apply { addView(child) } ?: child
}

inline fun ViewGroup.view(decor: Decor<View>): ViewGroup {
    val child = View()
    child.let(decor)
    return this.apply { addView(child) }
}

用以实现树结构描述的助手，不言自明

偷个懒，不设计单元测试了，构建一个结构：

class ViewTest {

    @Test
    fun testMeasure() {

        val tree = root().frameLayout { v1 ->

            v1.tag = "v1"
            v1.layoutWidth = MATCH_PARENT
            v1.layoutHeight = WRAP_CONTENT

            v1.frameLayout { frameLayout ->
                frameLayout.tag = "v2"
                frameLayout.layoutWidth = MATCH_PARENT
                frameLayout.layoutHeight = WRAP_CONTENT

                frameLayout.view {
                    it.tag = "v3"
                    it.layoutWidth = 200
                    it.layoutHeight = 300
                }

                frameLayout.frameLayout {
                    it.tag = "v4"
                    it.layoutWidth = WRAP_CONTENT
                    it.layoutHeight = WRAP_CONTENT
                }
            }
        }

        tree.tag = "root"


        tree.measure(
            View.MeasureSpec.makeMeasureSpec(1080, View.MeasureSpec.EXACTLY),
            View.MeasureSpec.makeMeasureSpec(1920, View.MeasureSpec.EXACTLY)
        )
        assert(tree is FrameLayout)
        assertEquals(true, (tree as FrameLayout).allChildHasMeasured())
    }
}

直接看一下日志输出的信息：

I/TestRunner: started: testMeasure(osp.leobert.blog.code.ViewTest)
D/view-debug: root mark has measured: true
D/view-debug: v3 mark has measured: true
D/view-debug: v3 has measured: true, w mode:EXACTLY, w size: 200 h mode:EXACTLY, h size: 300 
D/view-debug: v4 mark has measured: true
D/view-debug: v4 has measured: true, w mode:AT_MOST, w size: 0 h mode:AT_MOST, h size: 0 
D/view-debug: v2 mark has measured: true
D/view-debug: v2 has measured: true, w mode:EXACTLY, w size: 1080 h mode:AT_MOST, h size: 300 
D/view-debug: v1 mark has measured: true
D/view-debug: v1 has measured: true, w mode:EXACTLY, w size: 1080 h mode:AT_MOST, h size: 300 
D/view-debug: root has measured: true, w mode:EXACTLY, w size: 1080 h mode:EXACTLY, h size: 1920 
I/TestRunner: finished: testMeasure(osp.leobert.blog.code.ViewTest)

考虑到 一组 Parent 和 Child 有9种组合，我们全部验证一下。限于篇幅就不放代码和结果了

小结：上面通过很长一段篇幅，让我们在 抛开Android的知识 的前提下：

1. 思考了如何设计一套系统，用以描述任意的界面

根据经验确定了使用 视图树 的方式，进行界面的描述，并意识到，应用 不同的类 来封装不同的功能，相互配合，完成界面描述工作。

2. 思考了描述尺寸的 两种方式 、三种取值类型，并延伸出 测量 视图树 每个节点的 显示大小 问题。

从现实角度出发，得出一种测量方式，并进行了优化，得出结论：

• 测量过程从 Parent 到 Child。Parent 结合自身情况和 Child的情况，为 Child 决定测量的模式 即 mode， 以及 EXACTLY 模式下的精准值 和 AT_MOST 模式下的 最大值 参考值

  • 从 Parent 到 Child 表现为：测量的入口为 measure()，其中封装了调用自身onMeasure() 的逻辑, 具体ViewGroup 类覆写 onMeasure() 并调用 Child的 measure() 方法,传递测量过程
  • 显示大小的 测量 和 布局规则 有关

• 通过一次递归即可测量出视图树每个节点的显示大小

至此，我们对这套测量机制已经有了足够的认知，但是请注意，它还没有被完善。

确定布局位置

在前面，我们思考了一套可行的测量方案，其中我们提到：一个情况

并且，提出了条件R, 我们在其中提到了一个概念： 布局规则

结合我们的经验，不同的GUI中，都会有布局规则体系。为了解决可能出现的布局需求，均抽象了不同的布局类，以实现不同的规则。

前面我们也提到了，不同的规则下，ViewGroup 对 子View 的测量是不同的。

这很合理，测量的目的 是为了 正确布局，不同的布局规则，具有特定的测量规则。

使用 LayoutParams 描述布局规则和信息

在前面，我们参考Android 建立了 FrameLayout 类，实现了 帧布局 的规则， 当然，这一种规则还不足以处理各种界面布局需求，还有更多的ViewGroup子类 等着我们实现。

换个说法：当 一个View 被 添加到 一个ViewGroup 中时，需要按照该ViewGroup的布局规则，阐述自身的布局信息. 必要信息不可缺省

显然，

• 按照面向对象思想，布局规则簇 应该被封装为类，称之为 LayoutParams。
• 按照单一职责原则，不同的布局规则，对应不同的ViewGroup子类，也对应不同的 LayoutParams类，显然这是一一对应的
• 按照依赖倒置原则，View 的 layoutParam 依赖于 抽象，而不是某个规则的具体类；
• 按照里氏代换原则，LayoutParams的继承关系，和ViewGroup的继承关系应当是对应的；

按照经验，我们会写出如下代码，一个 必须指定宽高规则 的 ViewGroup.LayoutParams 基类。

而视图 可以 存在 内、外边距，这可以被认为是 基本规则。

继续为FrameLayout 加上 重力 规则。

我们很快写出如下代码：

abstract class ViewGroup : View() {
    open class LayoutParams(var width: Int, var height: Int) {

    }

    open class MarginLayoutParams(width: Int, height: Int) : LayoutParams(width, height) {
        var leftMargin = 0

        var topMargin = 0

        var rightMargin = 0

        var bottomMargin = 0
    }
}

class FrameLayout : ViewGroup() {
    class LayoutParams(width: Int, height: Int) : ViewGroup.MarginLayoutParams(width, height) {
        val UNSPECIFIED_GRAVITY = -1

        var gravity = UNSPECIFIED_GRAVITY
    }

    override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {
    }

    override fun checkLayoutParams(layoutParams: ViewGroup.LayoutParams): Boolean {
        return layoutParams is LayoutParams
    }

    override fun generateDefaultLayoutParams(): ViewGroup.LayoutParams {
        return LayoutParams(MATCH_PARENT, MATCH_PARENT)
    }
}

并对原先的Demo工程进行重构， 限于篇幅，略去相关代码

注：按照里氏代换原则，我们定义的 LayoutParams 体系在使用中时，可能会遇到 输入不符合期望 的问题。此时我们需要了解一下： 契约式设计：

使用契约式设计，类中的方法需要声明前置条件和后置条件。前置条件为真，则方法才能被执行。而在方法调用完成之前，方法本身将确保后置条件也成立。

于是，在ViewGroup 体系中，设计了：

• checkLayoutParams(layoutParams: ViewGroup.LayoutParams): Boolean
• generateDefaultLayoutParams(): ViewGroup.LayoutParams

我们可以采用两种契约：

• 输入的LayoutParams 必须满足约束，否则抛出异常
• 输入的LayoutParams 需要满足约束，否则使用默认规则

获得布局规则信息、按照ViewGroup 的布局规则进行布局

至此，我们已经理解了：

• 使用视图树描述一个任意视图
• 用不同的 ViewGroup 子类描述不同的布局，他们具有特定的布局规则；用不同的 Widget 展现不同的内容
• 一种 测量视图树各个节点 的 显示大小 的测量方式
• 不同的规则，决定了显示大小测算的细节有所不同
• 使用LayoutParams 描述布局规则信息

在此基础上，我们需要接受设定：

存在一个机制，可以正确地解析 视图树各个节点 中申明的 布局规则信息，这些信息，会存储在正确的 LayoutParams 对象中，被对应的节点所持有，以待使用。

这个机制，我们先忽略。

按照刚才获得的经验，布局和测量的过程类似，

我们定义 layout() 和 onLayout() 方法

open class View {
    open fun layout(l: Int, t: Int, r: Int, b: Int) {
        //todo
    }

    //布局能力
    protected open fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {

    }
}

对于参数，约定为：

• l Left position, relative to parent
• t Top position, relative to parent
• r Right position, relative to parent
• b Bottom position, relative to parent

在完成了 大小测试 和 布局规则解析 的前提下，这些相对值的计算并不复杂。

我们约定，实际的布局逻辑，在onLayout中完成，而layout方法，用于实现 前置条件，onLayout调用 和 状态维护

对于 ViewGroup 而言，需要遍历Children，为每个 Child，使用其显示大小信息&布局规则信息，确定其布局位置，即 l,t,r,b 四个参数值。 调用 Child 的 layout() 方法。

对于 Widget 而言，则是需要决定Content的展示区域，因为 Content 不再是 View，不再需要继续向下调用 layout 方法。

至此，所有的准备工作均已完成，接下来，就是绘制工作。

最后一步，绘制在正确位置

在此之前，我们已经得到了视图树每个节点的正确位置，此时，只需要将内容绘制在对应位置，即可通过屏幕呈现在用户眼前。

按照之前的经验，我们定义：

• draw(canvas:Canvas) 方法，封装整个绘制流程
• onDraw(canvas:Canvas) 方法，实现内容的绘制
• 如果在ViewGroup中覆写onDraw(canvas:Canvas) 同时 实现 自身内容的绘制，例如背景 ，和 分发 Child 的绘制，这并不符合开闭原则 故而添加 dispatchDraw(canvas: Canvas) 用以实现 分发 Child 的绘制

其实到此为止，我们已经对 正确展示内容 有了比较完善的认知，绘制的内容，理解不复杂，但内容很庞杂，本篇就不再展开了。

展望

本身还计划再写如下内容的：

• 和Framework中的实现思路进行对比
• 编码验证布局规则 等

限于篇幅，这些内容被择掉了。不过我会将一些 编码验证的内容以 WorkShop 的形式展现。

下一篇，会对 View体系的 交互 功能进行探索。点关注不迷路。

注：关于WorkShop的内容，原定计划是配合博客中的知识体系，独立建立一套 简单的，可视交互 系统。用以验证和帮助理解 Android-View 体系的知识。

希望今年的业务时间还能比较充裕。

三思系列：为什么要自定义View

前言

或许你掌握了 measure的细节 ，layout机制 ，事件传递机制 ，canvas各种API ，但是，你们想过这个问题吗？

这一篇，不仅仅是对一个面试必会题的解析，更是透过这个问题的思考，寻找 最佳实践 ，拓展思维角度 ， 少走弯路

三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，关于三思系列

关于View系列 View系列旨在通过 对现实问题 的思考，建立完善的 View体系认知，极力建议读者了解一下 我为什么撰写、分享这个系列

先给出思考这个问题的 脑图 ，文章内容会按照思考过程展开

思考这类问题，为什么要这样干 是最基本，作为三思系列的成员，本篇还将对以下内容点进行展开论述：

• 怎么干 -- How to do
• 是否一定要这样干 -- 适用场景
• 如果不这样干，还可以怎么干 -- Best Practice
• 各种干法的 注意事项

从View体系出现的目的说起

作为 GUI Graphical User Interface，图形用户接口 类型的程序 framework，View体系是其 必不可少 的一部分。参与了两件重要的事情：

• 描述、呈现 界面
• 参与 人机交互

笼统的讲，当 现有 的 View体系内的 控件簇 无法满足合理需求时，可以在遵从 framework 内在 的 规则 、机制 ，进行扩展，以满足需求。

从这个角度看，扩展可以有两个方面：

• 扩展 显示 功能
• 扩展 交互 功能

扩展显示功能

我们知道，这又分为3种：

• 通过一组控件，共同完成特定的功能，
• 扩展布局规则
• 扩展内容显示

最简单的，一组控件完成特定功能

举个例子： 输入框 右侧加一个 模态的图片，输入框有内容时显示，无内容时隐藏。图片显示一个❌，点击时清除输入框的内容

经过简单的封装，我们可以很快的完成这样的功能。

Android的UI描述并不那么方便，为了方便，往往会定义一个ViewGroup的子类，来描述这个 控件组。 但是 组合优于继承，这样的做法让人有点 膈应，不能算作是最佳实践。-- 这一点对应了脑图中的 扩展类簇1

相比于这样干，我更建议使用 Facade模式 进行逻辑封装，采用xml方式 声明这个控件组，或者封装 命令式构建函数构建这个控件组。

继承ViewGroup，扩展布局规则

Android中ViewGroup来封装布局规则，并提供了一套Layout。

当这些布局规则 无法满足 我们的需求时，我们可以通过 自定义ViewGroup 的方式来实现 自定义布局规则。

当然，Android发展到如今，已经 很难 找到一个相对抽象的布局规则，却没有被官方支持。

若确有必要，扩展布局规则时需要处理：

• 封装规则描述，并实现 契约式编程设计
  • 定义LayoutParams，封装规则的细节点描述
  • 覆写 checkLayoutParams 以实现规则校验，契约式编程设计
  • 覆写 generateLayoutParams(AttributeSet attrs) 以实现 从xml属性生成LayoutParams
  • 覆写 generateLayoutParams(ViewGroup.LayoutParams p) 以实现 当规则不满足契约时，生成一个满足契约的LayoutParams，注意：可以从原LayoutParams中 采纳一些内容。
  • 覆写 generateDefaultLayoutParams 以实现生成符合契约的 默认布局规则，如果返回null，在addView(View) 时，会引起运行时异常
• 在 onMeasure 方法中处理测量的逻辑，以实现 确定自身大小 和 触发子View测量
  • 接受 Parent 给到自身的 尺寸测量信息，如果测量模式是 EXACTLY，即可直接确定自身对应维度的尺寸；如果是 AT_MOST 或者 UNSPECIFIED， 则需要先测量子View，再确定自身。
  • 按照布局特性，自身的 尺寸测量信息，和子View的布局规则属性值，确定 子View 的 尺寸测量信息，调用 子View 的 measure 方法触发测量
• 在 onLayout 方法中，处理布局，使用子View的 尺寸测量值 和 LayoutParams规则值，计算子View 的布局位置，并调用 子View 的 layout 方法触发子View布局
• 如果有特定需求，可以在 onDraw 中进行绘制，例如绘制分隔线

继承View，扩展内容显示能力

一般来说，少数情况下，继承View 或者 特定的Widget 是为了扩展 布局尺寸上的特性，这基本是从 measure机制 上入手。除此之外，一些场景下， 可以通过 继承View 实现 自定义内容绘制。

例如，显示图表的View。

这种场景下，一般需要处理：

• 尺寸测量流程中，Content的尺寸测量，并在 onMeasure 中实现：测量模式为 AT_MOST 或 UNSPECIFIED 时，利用Content的大小确定显示尺寸。
• 绘制流程中，onDraw 中实现内容的绘制

注意: 如果并不牵涉到 交互，这并不是唯一方案，自定义Drawable的方案，也是很棒的方案。

借用 PhotoView 举个例子，如果交互局限为：双指缩放，拖拽，单击，双击。

那么通过 OnTouchListener + GestureDetector + 自定义Drawable， 对于绝大多数场景，都可以胜任。

扩展交互功能

在这个方向上，主要还是和 事件处理 体系有关。在 View体系 中，存在三个方法 和这个过程直接相关：

• dispatchTouchEvent
• onInterceptTouchEvent
• onTouchEvent

对于 onInterceptTouchEvent，非ViewGroup 的 View子类 是不参与的，因为这部分View，已经是事件处理的末端。

话分两头。

对于ViewGroup

扩展的目的一般有二：

• 在恰当的场景下，拦截事件并自身处理，处理逻辑在 onTouch 中实现
• 处理可能存在的 事件处理冲突，当然，按照Android的规则，利用 requestDisallowInterceptTouchEvent 可以要求 直系的 所有 Parent 不拦截事件。 但难免有意外，可以通过 onInterceptTouchEvent 来决定是否自身拦截处理事件，或者更加复杂的场景。

对于View而言

扩展的目的在于 定义事件的含义

举个例子，继承View实现一个字母表导航控件，点击、滑动 被定义为切换到 对应的字母 进行导航

我们需要在 onTouchEvent 中进行处理。

在前面，我们提到了 PhotoView 的例子，如果：事件 的含义 足够抽象，例如，对View 进行了：

• 单击
• 双击
• 拖拽
• 缩放

而不是 点击了View的特定区域，滑动至View的特定位置 等。 我们可以利用 Android屏幕事件处理机制 中的 OnTouchListener 来获取事件信息， 并进行处理。在这种做法中，利用 GestureDetector 可以大大降低这一过程的难度。

总结

这一篇中，我们比较 随性 的思考了 为什么要自定义View 的问题，并展开了：

• 为什么需要这么干
• 具体做法
• 是否有其他方案，并简单交代了 哪种方案更适合

这篇文章比较短，但是这部分内容的背后，还是值得继续深究、挖掘的

三思系列："声明式UI"和"命令式UI"，你的理解可能是错的

三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，关于三思系列

前言

最近，Jetpack Compose 发布了 Beta 版本，可以说是千呼万唤始出来。

在一个 现象级事物 出现时，关于它的讨论会很热。我注意到，最近有一大批关于Compose的文章涌现了出来，并且有很多的讨论，这很棒。

但是，值得一提的是，我发现很多人对于 声明式UI 、 命令式UI 的认知，可能出现了一点偏差。

当然，我也 不是 像 马丁老爷子 或者 Jack Wharton 那样的 专家，对于这个问题，只能是同大家 一道探索。

声明式 和 命令式 含义探索

按照经验，中文往往比英文具有 更强的表达力 ，这也意味着：中文的 凝练度更高，也更容易产生理解误差，我们结合英文一起看

• 声明式 declarative

a declarative sentence has the form of a statement.

statement: 4条释义，看第一条

• something you say or write, especially publicly or officially, to let people know your intentions or opinions, or to record facts
• 其他三条略

• 命令式 imperative

technical, an imperative verb is one that expresses an order, such as ‘stand up’

如果从 语境 上来看，声明 是面向一个环境、一个群体表达某些规则，而 命令 所面向的，是一个明确的对象群，在指使他们做一些事情。

举个可能不太恰当的例子：

• 我军优待俘虏，缴枪投降不杀，这是对敌军的声明

• 营长命令各战斗单位，打扫战场，一连收缴武器弹药，二连负责收押俘虏。这是命令式

我发现，讨论 声明式 和 命令式 时，需要先界定好 讨论范围。这一点非常重要，一旦超越了范围，讨论就会出现错误。

放在计算机领域中讨论这两者时，需要先界定好 层。

我们知道，程序设计中，以及在计算机设计中，都是 分层 的。下层 的内容交给 上层 使用时，需要使用到 接口，

这个接口，不仅仅是我们编程中的API的概念

甚至，接口的表现形式是一种 语言。

接口被定义时，其表意即已固定，当其表意：

• 越倾向于 现实表达 时，呈现为 声明式
• 越倾向于 执行过程 时，呈现为 命令式

UI

User Interface 的简称，直译为用户界面

UI系统需要处理两个范畴的事情：

• 内容呈现、反馈
• 用户交互

另外，还需要程序 构建 出UI。

我们需要从这 三个角度 来看。

构建UI时的 命令式 和 声明式

我们在Android原有的知识领域中看这个问题。

我们知道，这部分内容设计时是遵守 OOP 的，存在一整套 View 类簇。而界面由具体的功能类组建出 视图树。

我们需要讨论的，就是 视图树 的 构建。我们知道：

ViewGroup 存在一系列 addView 方法，通过它们，最终实现 树结构

这套 接口 ，倾向于 执行过程，直接使用这套接口去构建，就是 命令式 的构建。

而在此基础上，封装了 LayoutInflater，将 xml语法 表达的 结构树 转换为 视图树， 此时我们使用的 接口 ，其表现形式是 xml语言。

按照特定的规则，我们 直接描述 了 期望的结果，这更倾向于 现实表达，这样的构建方式，就是 声明式

View 存在一系列的 布局属性，一些直接持有，一些被LayoutParams封装而间接持有。

在 视图树 的节点构建过程中，还需要处理 布局属性。

按照刚才的讨论，我们很容易得出：

• 直接使用 View的API 或者 LayoutParams的API，或者直接对属性赋值，可以断言是 命令式 范畴。
• 而在布局文件中，声明对应的属性值，可以断言是 声明式 范畴

小结：本段内容，我们讨论了构建UI的两种做法。并讨论了其所属的范畴。

Android体系最基础的内容中，内容呈现&交互

在最基础的内容中，讨论 内容呈现 和 交互 部分使用的API，是 命令式 的，还是 声明式 的，这 非常的无聊。

内容呈现时的 命令式 与 声明式

在 View 提供的 接口 中，例如：

• TextView#setText(Charsequence cs)
• ImageView#setImageDrawable(Drawable d)

等，更加偏向于 执行过程 。

但是注意，此时 执行过程 和 现实表达 的界限已经有点模糊了 。我们不必 牵强附会。

读一下这两句话：

• 我们通过调用相应API设置了需要显示的内容
• 我们在布局文件中指明了视图显示时需要呈现的内容

交互时的 命令式 与 声明式

我们知道，Android View 体系中，封装了一系列 Listener，通过 接口回调，让程序可以 监听 到用户发出的 交互指令。

除此之外，在 最基础内容 中，仅有简陋的 click 属性可以声明点击事件的 消费函数

此时，我们 放大着眼点 。我们处理视觉呈现和交互时，面向的两个重要对象

          信息展示
   | ================ |
   |     内容呈现     \|/
|=====|           |=====|   
| 实体 |           | UI  |
|=====|           |=====|
  /|\      交互       |
   | ================ | 
          状态变更
            

这两者之间存在两条线：

• 代表信息 的 实体 -> UI, 这是 内容呈现 ，实质是：在UI上做 信息展示
• UI -> 代表信息 的 实体 ，这是 交互 ，实质是：在信息实体上做 状态变更，即变更信息

我们在实现这两条线时：

• 如果直接利用 了倾向于 现实表达 的高阶框架封装，那这个框架就是 声明式的框架；
• 如果仅使用 低阶的 view层api ，自行实现了逻辑，那就是 命令式 的编程，毕竟也没用啥框架；

评价一套 UI工具体系 是否是 声明式 的，要从这三个方面看，如果在三个方面均进行了封装，提供的 接口 都偏向于 现实表达，那是成熟完善的 声明式UI 框架。

看几个例子：

• 直接使用 View体系的接口 构建UI、处理显示和交互，这是 命令式编程
• 使用 LayoutInflater 工具和 xml表达的布局文件。绝大多数情况下，还需要通过映射关系，找到View对象；并进一步 根据业务逻辑 ，操作 View对象 实现内容呈现和交互逻辑。 这是 声明式构建，命令式编程 处理显示和交互。这套工具并不是完善的 声明式UI开发工具
• 使用 LayoutInflater 工具 + DataBinding工具包 和 xml表达的布局文件。DataBingding + LayoutInflater是一套完善的 声明式UI框架
• Compose，完善的 声明式UI框架

思考：为什么当初XML布局方式受到官方推荐

很大一方面是Java语言特性的原因，最开始，都是使用Java语言编写业务逻辑，而基于Java，很难直接定义DSL

注：Java语言很难直接定义DSL 这一点我并没有做严格的调研考证，如果有谬误，请指出。

而基于Groovy等语言开发符合 DSL 的 声明式UI框架，必然要引入Groovy，这在当时也和 主流 格格不入，虽然Google很喜欢创新。

所以，官方提出了 布局 和 业务 分开，这样也有很多好处：

• 业务逻辑的 模块内聚性 和 复用度 可提升
• 开发者可以提升专注度
• xml树 和 view树 之间 关系明了，借助成熟内容，快速开发出 预览工具

思考：为什么XML布局方式走在被淘汰的路上

因为使用XML布局的方式存在 先天弱点 ，它和 业务逻辑 天生生活在两个世界。

这意味着，必然存在一个 加载器 或者 转换器，在 运行时 或者 编译时，将 xml语法 所描述的 声明式布局 转换到 业务逻辑 所在的世界。

所以，并不是 DataBinding 这一 声明式UI框架 不够优秀，而是 xml 和 业务逻辑代码 之间天生的屏障不够 人道主义。

而推行 kotlin first 也有一段时间了，基于kotlin，开发 DSL 工具包非常的方便。

延伸：响应式UI框架

这也是 Modern Development 中非常热门的一个词，响应式 是对特点的一种描述，方法论是：事件驱动，Event-Driven，发布订阅者模式。

这个概念，和前面提到的 声明式UI框架 和 命令式UI编程 没有必然的联系，它所表达的是： 代表信息的实体 和 UI 之间的互操作是符合 响应式 特征的。

但可以想象，要实现响应式，其接口变现特征，天然倾向于 现实表达；如果是倾向于 操作过程，可以断言其抽象程度非常低。

扣题：勘误

再看到这些说法，我们可以判断出它们存在 谬误：

• 基于xml无法实现声明式UI
• xml被淘汰是因为无法实现声明式UI
• 基于xml布局方式都是命令式
• 声明式一定会取代命令式，你看xml都要被淘汰了
• 用代码写的就是命令式UI

等。

再多聊两句，一套曾经热门的技术，一定有其热门的原因和背景，它走向消亡，往往是其 面向的问题 和 场景 ，在事物发展过程中，越来越少见。

声明式 和 命令式 各有优劣。按照规律，高阶封装更 人道主义 ，解决高复杂度问题时，也容易实现 降维打击。 但这也意味着机器付出的代价更高一点。

总之，脱离了环境背景讨论谁胜谁负，往往是耍流氓。

总结

这一篇，我们用比较 随性 的文字，对 声明式UI 进行了一次脑暴，进而讨论其概念的实质。我相信，经过这次脑暴，对这一套概念体系的理解会更加 深刻 、 准确 。相应的，学习新内容时也会 更加轻松、事半功倍

进一步延伸, 在学习Compose，思考Compose的优劣时，势必会上升到 OOP 和 FP 两大编程范式的讨论。这一篇不再展开。

点赞关注收藏，从此不迷路。

Drawable

• 三思系列：重新认识Drawable
• 好玩系列：拥有它，XML文件少一半--更方便的处理View背景
• 迟来的续集--Drawable+Animator，将优雅进行到底
• 好玩系列：让ImageSpan动起来

三思系列：重新认识Drawable

前言

关于三思系列

前一段时间看到宏洋公众号推送了一篇关于splash页面动效的文章，具体为：将一个英文单词拆分为多个字母，散落在屏幕中，然后按照一定的路径回归，最终展示一段流光效果，完成splash页面。

当时文章中提到的做法是自定义View的实现。当时脑海中灵光一闪，感觉还是用Drawable来干这个事情更加合适。

记忆中，我曾经整理过一篇Drawable基础内容的文章，可惜丢失了，在开始干这件事情之前，我们把这一块内容再完整的梳理一遍。

这篇文章会比较长，先给出导图

Drawable的设计意图

A Drawable is a general abstraction for "something that can be drawn." Most often you will deal with Drawable as the type of resource retrieved for drawing things to the screen; the Drawable class provides a generic API for dealing with an underlying visual resource that may take a variety of forms. Unlike a View, a Drawable does not have any facility to receive events or otherwise interact with the user.

这是SDK文档中的内容，大致含义呢：drawable是对于"可以被绘制的内容"的抽象。 多数情况下，我们将获取的资源作为Drawable绘制在屏幕上， Drawable类提供了一个通用API，用于处理可能采用多种类型的底层可视资源。 不像View，Drawable没有任何接收事件或以其他方式与用户交互的功能。

为了简化绘制，Drawable中为使用者提供了一定的机制操作绘制：

• The {@link #setBounds} method must be called to tell the > Drawable where it is drawn and how large it should be. All Drawables > should respect the requested size, often simply by scaling their > imagery. A client can find the preferred size for some Drawables with > the {@link #getIntrinsicHeight} and {@link #getIntrinsicWidth} methods.

• The {@link #getPadding} method can return from some Drawables > information about how to frame content that is placed inside of them. > For example, a Drawable that is intended to be the frame for a button > widget would need to return padding that correctly places the label > inside of itself.

• The {@link #setState} method allows the client to tell the Drawable > in which state it is to be drawn, such as "focused", "selected", etc. > Some drawables may modify their imagery based on the selected state.

• The {@link #setLevel} method allows the client to supply a single > continuous controller that can modify the Drawable is displayed, such as > a battery level or progress level. Some drawables may modify their > imagery based on the current level.

• A Drawable can perform animations by calling back to its client > through the {@link Callback} interface. All clients should support this > interface (via {@link #setCallback}) so that animations will work. A > simple way to do this is through the system facilities such as > {@link android.view.View#setBackground(Drawable)} and > {@link android.widget.ImageView}.

继续简要翻译一下重要内容

• setBounds 方法必须被调用，它告知了Drawable应该被绘制的位置和大小
• getPadding 方法可以获知一些Drawable绘制时的内边距信息
• setState 方法允许使用者告知Drawable应当在哪些状态时绘制，例如获取了焦点，被选中等
• setLevel 方法允许调用者提供一个连续的控制器，可以修改显示的可绘制内容， 例如电池电量或进度。一些Drawable可能会根据当前的level改变其图像
• Drawable可以展现动画，通过设置Callback接口回调给他的使用者，所有的使用者，需要通过 setCallback方法提供回调函数支持以让动画工作。一个简便方式是通过一些系统设施例如：View#setBackground 和 ImageView

注：Drawable展现动画部分，这里翻译的比较晦涩，具体细节见：Drawable Api概览

小结：Android SDK中抽象了Drawable体系，不同于View体系，它仅负责描述可绘制的内容，不可进行用户交互，其子类将描述各类可绘制内容的特性。

SDK中的Drawable子类概览

注：经过多次思考，我最终把这一段的草稿删除了，这部分体系实在是太大，浅写无异于copy官方文档，深挖就会影响文章关注的重点。 如果对系统中提供的Drawable子类感兴趣的，建议深入源码看一下。

Drawable Api概览

在开头的设计意图探索中，我们已经阅读了几个关键API：setBound，getPadding，setState，setLevel，setCallback的信息

还有getBound，copyBound等获取边界信息的API，RippleDrawable和一些自定义的Drawable还覆写了getDirtyBounds，用以获取它可能涉及到的范围边界

横向的方向相关：setLayoutDirection，getLayoutDirection，onLayoutDirectionChanged

透明度相关：setAlpha，getAlpha

着色和颜色filter相关：setColorFilter，getColorFilter，clearColorFilter， setTint，setTintList，setTintMode，setTintBlendMode

尺寸测量：getIntrinsicWidth，getIntrinsicHeight，getMinimumWidth，getMinimumHeight 当作为背景使用时，getMinimumXXX用于告知View建议使用的最小宽高。getIntrinsicXXX是获取一个Drawable的内在的、固有的宽高，这个值和设备屏幕密度是有关系的。

自我独立：mutate，和缓存机制有关，调用得到一个新的Drawable，这样自己的状态就不会影响到其他使用处。

重绘相关：setCallback(@Nullable Callback cb)，getCallback()，invalidateSelf()， scheduleSelf(@NonNull Runnable what, long when)，unscheduleSelf(@NonNull Runnable what)

上面我们提到这一组API会详细说一下。以AnimationDrawable为例，这是一个动画Drawable，

class AnimationDrawable {
    private void setFrame(int frame, boolean unschedule, boolean animate) {
        if (frame >= mAnimationState.getChildCount()) {
            return;
        }
        mAnimating = animate;
        mCurFrame = frame;
        selectDrawable(frame);
        if (unschedule || animate) {
            unscheduleSelf(this);
        }
        if (animate) {
            // Unscheduling may have clobbered these values; restore them
            mCurFrame = frame;
            mRunning = true;
            scheduleSelf(this, SystemClock.uptimeMillis() + mAnimationState.mDurations[frame]);
        }
    }
}

设置某一帧之后，如果是使用动画，则会调用scheduleSelf，时间戳是下一帧应该出现的时间戳。

class Drawable {
    public void scheduleSelf(@NonNull Runnable what, long when) {
        final Callback callback = getCallback();
        if (callback != null) {
            callback.scheduleDrawable(this, what, when);
        }
    }
}

如果存在Callback，则调用Callback#scheduleDrawable。

以View的代码为例

class View {
    public void scheduleDrawable(@NonNull Drawable who, @NonNull Runnable what, long when) {
        if (verifyDrawable(who) && what != null) {
            final long delay = when - SystemClock.uptimeMillis();
            if (mAttachInfo != null) {
                mAttachInfo.mViewRootImpl.mChoreographer.postCallbackDelayed(
                        Choreographer.CALLBACK_ANIMATION, what, who,
                        Choreographer.subtractFrameDelay(delay));
            } else {
                // Postpone the runnable until we know
                // on which thread it needs to run.
                getRunQueue().postDelayed(what, delay);
            }
        }
    }
}

很简单，验证合法性之后定时执行Runnable，Runnable的内容：

class AnimationDrawable {
    public void run() {
        nextFrame(false);
    }

    private void nextFrame(boolean unschedule) {
        int nextFrame = mCurFrame + 1;
        final int numFrames = mAnimationState.getChildCount();
        final boolean isLastFrame = mAnimationState.mOneShot && nextFrame >= (numFrames - 1);

        // Loop if necessary. One-shot animations should never hit this case.
        if (!mAnimationState.mOneShot && nextFrame >= numFrames) {
            nextFrame = 0;
        }

        setFrame(nextFrame, unschedule, !isLastFrame);
    }
}

显示下一帧，逻辑非常清晰，不再进行解析。

小结: 这一段我们对Drawable的API进行了简单的梳理，略去了大量关于创建的API以及和开发不太紧密的API，完成了一次概览。 更完善的认知需要再仔细研读源码内容，限于篇幅不再展开。

DrawableInflater

顾名思义，这是一个Drawable加载器，和LayoutInflater类似，从一种满足特定语法的语法式中解析出实例对象，显然，在Android中它用来处理xml语法的drawable资源文件。

看一下文档：

/**
 * Instantiates a drawable XML file into its corresponding
 * {@link android.graphics.drawable.Drawable} objects.
 * <p>
 * For performance reasons, inflation relies heavily on pre-processing of
 * XML files that is done at build time. Therefore, it is not currently possible
 * to use this inflater with an XmlPullParser over a plain XML file at runtime;
 * it only works with an XmlPullParser returned from a compiled resource (R.
 * <em>something</em> file.)
 *
 * @hide Pending API finalization.
 */

需要注意，从性能角度上，这种创建严重依赖于构建时的预处理，因此，目前不可能利用它和 XmlPullParser 一起 在运行时解析一个xml文件 并创建对象实例 只适用于那些已经在资源编译阶段返回的XmlPullParser

我们知道，一个受检的xml document，会被解析为语法树，得到树中的标签节点和属性信息。

我们阅读DrawableInflater的代码，有两段关于创建Drawable具体实例的内容，这是根据tag创建实例的代码

class DrawableInflater {
    private Drawable inflateFromTag(@NonNull String name) {
        switch (name) {
            case "selector":
                return new StateListDrawable();
            case "animated-selector":
                return new AnimatedStateListDrawable();
            case "level-list":
                return new LevelListDrawable();
            case "layer-list":
                return new LayerDrawable();
            case "transition":
                return new TransitionDrawable();
            case "ripple":
                return new RippleDrawable();
            case "adaptive-icon":
                return new AdaptiveIconDrawable();
            case "color":
                return new ColorDrawable();
            case "shape":
                return new GradientDrawable();
            case "vector":
                return new VectorDrawable();
            case "animated-vector":
                return new AnimatedVectorDrawable();
            case "scale":
                return new ScaleDrawable();
            case "clip":
                return new ClipDrawable();
            case "rotate":
                return new RotateDrawable();
            case "animated-rotate":
                return new AnimatedRotateDrawable();
            case "animation-list":
                return new AnimationDrawable();
            case "inset":
                return new InsetDrawable();
            case "bitmap":
                return new BitmapDrawable();
            case "nine-patch":
                return new NinePatchDrawable();
            case "animated-image":
                return new AnimatedImageDrawable();
            default:
                return null;
        }
    }
}

如果您已经在第二小节自行对Drawable的子类进行了概览，应该对这些内容不陌生了。

以Android项目模板为例，工程会创建一个启动图标：

<vector xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:aapt="http://schemas.android.com/aapt"
        android:width="108dp"
        android:height="108dp"
        android:viewportWidth="108"
        android:viewportHeight="108">
    <path
        android:pathData="M31,63.928c0,0 6.4,-11 12.1,-13.1c7.2,-2.6 26,-1.4 26,-1.4l38.1,38.1L107,108.928l-32,-1L31,63.928z">
        <aapt:attr name="android:fillColor">
            <gradient
                android:endX="85.84757"
                android:endY="92.4963"
                android:startX="42.9492"
                android:startY="49.59793"
                android:type="linear">
                <item
                    android:color="#44000000"
                    android:offset="0.0"/>
                <item
                    android:color="#00000000"
                    android:offset="1.0"/>
            </gradient>
        </aapt:attr>
    </path>
    <path
        android:fillColor="#FFFFFF"
        android:fillType="nonZero"
        android:pathData="M65.3,45.828l3.8,-6.6c0.2,-0.4 0.1,-0.9 -0.3,-1.1c-0.4,-0.2 -0.9,-0.1 -1.1,0.3l-3.9,6.7c-6.3,-2.8 -13.4,-2.8 -19.7,0l-3.9,-6.7c-0.2,-0.4 -0.7,-0.5 -1.1,-0.3C38.8,38.328 38.7,38.828 38.9,39.228l3.8,6.6C36.2,49.428 31.7,56.028 31,63.928h46C76.3,56.028 71.8,49.428 65.3,45.828zM43.4,57.328c-0.8,0 -1.5,-0.5 -1.8,-1.2c-0.3,-0.7 -0.1,-1.5 0.4,-2.1c0.5,-0.5 1.4,-0.7 2.1,-0.4c0.7,0.3 1.2,1 1.2,1.8C45.3,56.528 44.5,57.328 43.4,57.328L43.4,57.328zM64.6,57.328c-0.8,0 -1.5,-0.5 -1.8,-1.2s-0.1,-1.5 0.4,-2.1c0.5,-0.5 1.4,-0.7 2.1,-0.4c0.7,0.3 1.2,1 1.2,1.8C66.5,56.528 65.6,57.328 64.6,57.328L64.6,57.328z"
        android:strokeWidth="1"
        android:strokeColor="#00000000"/>
</vector>

其实就是机器人头的图标，它会被加载为VectorDrawable

我们反推一下，调用者为：

class DrawableInflater {
    @NonNull
    public Drawable inflateFromXml(@NonNull String name, @NonNull XmlPullParser parser,
                                   @NonNull AttributeSet attrs, @Nullable Theme theme)
            throws XmlPullParserException, IOException {
        return inflateFromXmlForDensity(name, parser, attrs, 0, theme);
    }


    @NonNull
    Drawable inflateFromXmlForDensity(@NonNull String name, @NonNull XmlPullParser parser,
                                      @NonNull AttributeSet attrs, int density, @Nullable Theme theme)
            throws XmlPullParserException, IOException {
        // Inner classes must be referenced as Outer$Inner, but XML tag names
        // can't contain $, so the <drawable> tag allows developers to specify
        // the class in an attribute. We'll still run it through inflateFromTag
        // to stay consistent with how LayoutInflater works.
        if (name.equals("drawable")) {
            name = attrs.getAttributeValue(null, "class");
            if (name == null) {
                throw new InflateException("<drawable> tag must specify class attribute");
            }
        }

        //注意这里 --1
        Drawable drawable = inflateFromTag(name);
        if (drawable == null) {
            //注意这里 --2
            drawable = inflateFromClass(name);
        }
        drawable.setSrcDensityOverride(density);
        //注意这里 --3
        drawable.inflate(mRes, parser, attrs, theme);
        return drawable;
    }
}

上面标记了3处注意点， 第一处即为内置的顶层drawable创建

第二处我们稍后再看

第三处将parser，属性和主题交给生成的Drawable继续解析。不同的Drawable子类按照自身特性实现自己的解析需求。

以LevelListDrawable为例，我们知道它内部还可以添加Drawable作为不同的level，这是通过递归调用解析创建实现的， 最终追溯源码至Drawable

public class LevelListDrawable {
    private void inflateChildElements(Resources r, XmlPullParser parser, AttributeSet attrs,
                                      Theme theme) throws XmlPullParserException, IOException {
        //略
        while ((type = parser.next()) != XmlPullParser.END_DOCUMENT
                && ((depth = parser.getDepth()) >= innerDepth
                || type != XmlPullParser.END_TAG)) {
            //略

            Drawable dr;
            if (drawableRes != 0) {
                dr = r.getDrawable(drawableRes, theme);
            } else {
                //略
                //注意此处
                dr = Drawable.createFromXmlInner(r, parser, attrs, theme);
            }
            mLevelListState.addLevel(low, high, dr);
        }
        onLevelChange(getLevel());
    }
}


public class Drawable {

    public static Drawable createFromXmlInner(@NonNull Resources r, @NonNull XmlPullParser parser,
                                              @NonNull AttributeSet attrs, @Nullable Theme theme)
            throws XmlPullParserException, IOException {
        return createFromXmlInnerForDensity(r, parser, attrs, 0, theme);
    }

    @NonNull
    static Drawable createFromXmlInnerForDensity(@NonNull Resources r,
                                                 @NonNull XmlPullParser parser, @NonNull AttributeSet attrs, int density,
                                                 @Nullable Theme theme) throws XmlPullParserException, IOException {
        return r.getDrawableInflater().inflateFromXmlForDensity(parser.getName(), parser, attrs,
                density, theme);
    }
}

我们再看第二处，当特定的tag未被匹配时，会使用反射方式尝试创建Drawable：

class DrawableInflater {
    @NonNull
    private Drawable inflateFromClass(@NonNull String className) {
        try {
            Constructor<? extends Drawable> constructor;
            synchronized (CONSTRUCTOR_MAP) {
                constructor = CONSTRUCTOR_MAP.get(className);
                if (constructor == null) {
                    final Class<? extends Drawable> clazz =
                            mClassLoader.loadClass(className).asSubclass(Drawable.class);
                    constructor = clazz.getConstructor();
                    CONSTRUCTOR_MAP.put(className, constructor);
                }
            }
            return constructor.newInstance();
        }
        //略
        catch (XXX e) {
        }
    }
}

Custom drawables

All versions of Android allow the Drawable class to be extended and used at run time in place of framework-provided drawable classes. Starting in API 24, custom drawables classes may also be used in XML. Note: Custom drawable classes are only accessible from within your application package. Other applications will not be able to load them.

文档中有这样一段话，自定义的Drawable一直是可行的，但仅Api>=24时才能够用XML定义这样的资源。虽然没有仔细追溯版本源码，但应该和此处有关。

小结：我们简单阅读了DrawableInflater的源码，了解了Android如何从xml资源得到Drawable对象。需要注意的是，我们没有阅读Resource#getDrawable 的相关源码，这一块内容也很有意思，建议读者有时间自行阅读下。

自定义一个Drawable

终于来到这个环节了，为了更好的进行这个环节，我们新建一个WorkShop项目，我会按照文章中每一个小目标提出的一个小目标建立提交。 DrawableWorkShop

version 1 一个能绘制的自定义Drawable

这里我们尽可能的简单，目标就是绘制一个字母，先定义类：

class LetterDrawable : Drawable() {
    val tag = "LetterDrawable"

    var letter: Char = 'A'

    val paint = Paint().apply {
        textSize = 60f
        color = Color.CYAN
    }

    override fun draw(canvas: Canvas) {
        Log.d(tag, "on draw")
        canvas.drawText(letter.toString(), 60f, 60f, paint)
    }

    override fun setAlpha(alpha: Int) {
        //ignore
    }

    override fun setColorFilter(colorFilter: ColorFilter?) {
        //ignore
    }

    override fun getOpacity(): Int {
        return PixelFormat.TRANSLUCENT
    }
}

字号字色，绘制字母的位置和内容都直接写死，

定义资源：

<?xml version="1.0" encoding="utf-8"?>
<osp.leobert.android.drawableworkshop.drawable.LetterDrawable
    xmlns:android="http://schemas.android.com/apk/res/android"
>

</osp.leobert.android.drawableworkshop.drawable.LetterDrawable>

直接使用：得到结果：

version 2 支持颜色和字号等可配

我们将单个字符改为String，添加color和textSize成员变量，并将改动设置到paint

添加属性定义：

<resources xmlns:tools="http://schemas.android.com/tools">

    <declare-styleable name="letter_drawable">
        <attr name="android:text" format="string|reference"/>
        <attr name="color" format="color|reference"/>
        <attr name="android:textSize" format="dimension|reference"/>

    </declare-styleable>

</resources>

这样我们就可以进行资源配置和解析

按照我们之前阅读的代码，我们需要覆写inflate以实现属性解析

class LetterDrawable {
    override fun inflate(
        r: Resources,
        parser: XmlPullParser,
        attrs: AttributeSet,
        theme: Resources.Theme?
    ) {
        super.inflate(r, parser, attrs, theme)
        val a: TypedArray = obtainAttributes(r, theme, attrs, R.styleable.letter_drawable)
        letter = a.getString(R.styleable.letter_drawable_android_text) ?: "A"

        textSize = a.getDimension(R.styleable.letter_drawable_android_textSize, 60f)
        color = a.getColor(R.styleable.letter_drawable_color, Color.CYAN)

        a.recycle()

        paint.color = color
        paint.textSize = textSize
    }

    private class Size(val type: Int) : ReadWriteProperty<LetterDrawable, Float?> {
        private var prop: Float? = null
        override fun getValue(thisRef: LetterDrawable, property: KProperty<*>): Float? {
            return prop ?: thisRef.run {
                val rect = Rect()
                this.paint.getTextBounds(this.letter, 0, this.letter.length, rect)
                val s = when (type) {
                    0 -> rect.width()
                    else -> rect.height()
                }.toFloat()
                prop = s
                prop
            }
        }

        override fun setValue(thisRef: LetterDrawable, property: KProperty<*>, value: Float?) {
            prop = value
        }

    }

    private var width by Size(0)
    private var height by Size(1)

    override fun draw(canvas: Canvas) {
        Log.d(tag, "on draw,$letter , $height")
        canvas.drawText(letter, 0f, height ?: 60f, paint)
    }
}

并且我们利用属性代理来封装计算宽高的细节（只是利用了小技巧，可以减少不必要的重复测量）

修改我们资源：

<?xml version="1.0" encoding="utf-8"?>
<osp.leobert.android.drawableworkshop.drawable.LetterDrawable
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:textSize="40sp"
    app:color="#ff3c06"
    android:text="@string/letters">


</osp.leobert.android.drawableworkshop.drawable.LetterDrawable>

运行后我们得到这样的结果：

version 3: 正确处理宽高

我们发现Drawable的位置是有问题的，对于TextView，并没有在文字之上（drawableTop）， 对于ImageView，并没有居中（默认 ScaleType.FIT_CENTER）。

class LetterDrawable {
    var letter: String = "A"
        set(value) {
            field = value
            width = null
            height = null
            invalidateSelf()
        }

    var color: Int = Color.CYAN
        set(value) {
            field = value
            paint.color = value
            invalidateSelf()
        }

    var textSize: Float = 60f
        set(value) {
            field = value
            width = null
            height = null
            paint.textSize = value
            invalidateSelf()
        }

    override fun getIntrinsicHeight(): Int {
        return height?.toInt() ?: -1
    }

    override fun getIntrinsicWidth(): Int {
        return width?.toInt() ?: -1
    }
}

并且当颜色、文字、字号变更时触发重新计算和重绘

看一下结果：

注：更多和Canvas和Paint的内容忽略，Padding和文字边距等细节忽略

小结：这一小节到此基本可以结束了，我们用了三步实现了一个简单自定义Drawable， 并且在比较常见的场景下进行了效果演示。读者可以在此基础上在对于padding等属性进行尝试， 以及尝试绘制自己感兴趣的内容。

自定义一个动画Drawable

这一次，我们尝试让字从分散，开始聚拢，最终排列成一行。因为它的draw规则更加特殊，我们新建一个Drawable进行演示。

还是在原来的项目上，version 直接递增

version 4: 先让一个字母动起来

目标：让字母从一个随机的初始位置，匀速运动到终点位置。约定最终将文字绘制在中心

我们建立一个新的类AnimLetterDrawable，迁移LetterDrawable中的主要逻辑，并实现Runnable接口，以实现schedule 时的主要逻辑； 实现Animatable2接口并完成动画相关逻辑

class AnimLetterDrawable : Drawable(), Animatable2, Runnable {
    private var frameIndex = 0

    private val totalFrames = 30 * 3 //3 second, 30frames per second
    
    private val animationCallbacks: MutableSet<Animatable2.AnimationCallback> = linkedSetOf()

    private var mAnimating: Boolean = false

    private fun setFrame(frame: Int, unschedule: Boolean, animate: Boolean) {
        if (frame >= totalFrames) {
            return
        }
        mAnimating = animate
        frameIndex = frame

        if (unschedule || animate) {
            unscheduleSelf(this)
        }
        if (animate) {
            // Unscheduling may have clobbered these values; restore them
            frameIndex = frame

            scheduleSelf(this, SystemClock.uptimeMillis() + durationPerFrame)
        }
        invalidateSelf()
    }

    private fun nextFrame(unschedule: Boolean) {
        var nextFrame: Int = frameIndex + 1
        val isLastFrame = nextFrame + 1 == totalFrames
        if (nextFrame + 1 > totalFrames) {
            nextFrame = totalFrames - 1
        }

        setFrame(nextFrame, unschedule, !isLastFrame)
    }

    private val durationPerFrame = 3000 / totalFrames

    override fun start() {
        Log.d(tag, "start called")
        mAnimating = true

        if (!isRunning) {
            // Start from 0th frame.
            setFrame(
                frame = 0, unschedule = false, animate = false
            )
        } else {
            setFrame(
                frame = 0, unschedule = false, animate = true
            )
        }
    }

    override fun stop() {
        mAnimating = false

        if (isRunning) {
            frameIndex = 0
            //un-schedule it at first
            unscheduleSelf(this)

            setFrame(0, unschedule = true, animate = false)
        }
    }

    override fun isRunning(): Boolean {
        return mAnimating
    }

    override fun registerAnimationCallback(callback: Animatable2.AnimationCallback) {
        animationCallbacks.add(callback)
    }

    override fun unregisterAnimationCallback(callback: Animatable2.AnimationCallback): Boolean {
        return animationCallbacks.remove(callback)
    }

    override fun clearAnimationCallbacks() {
        animationCallbacks.clear()
    }

    override fun run() {
        Log.d(tag, "callback by schedule")
        if (isRunning) {
            nextFrame(false)
        } else {
            //safe call
            setFrame(0, unschedule = true, animate = false)
        }
    }
}

这一段代码虽然有点长，但是逻辑很简单，阅读文章过程中，可以忽略这部分代码的细节。

显然，我们还需要实现：正确绘制每一帧

在约定的目标中，每个字母从一个 随机的初始位置，匀速运动 到 终点位置。那么，对于任意一个字母，只需要确定 四个参数，即可确定其 位置

• 总帧数
• 当前帧数
• 字母起始位置
• 字母结束位置

延伸：上面的例子中，我们约定了轨迹是直线，延伸开来，其实我们只需要一个 location = f(time) 的函数和time值即可确定其位置。

一般情况下，我们需要关心轨迹方程，和加速度公式。有加速度公式，我们按照时间积分得到速度-时间函数，再按照时间积分，得到 移动距离-时间函数， 在有轨迹方程和起始点的情况下，就可以找到任意时间的位置，得到 location = f(time) 函数

当然，因为我们的场景足够简单，起始点和终点确定的线段即为路径，运动为匀速，当前时间 通过 当前帧,每帧时间确定，达到总动画时长（最后一帧）时 达到终点

• x = startX + (endX - startX) * time / totalTime
• y = startY + (endY - startY) * time / totalTime

附上计算相关的源码： 运动过程中我是适当处理了文字的透明度

class AnimLetterDrawable : Drawable(), Animatable2, Runnable {
    private val originalLetterLocations = SparseArray<PointF>()

    private val finalLetterLocations = SparseArray<PointF>()

    override fun draw(canvas: Canvas) {
        Log.d(tag, "on draw,$letters , $height,$frameIndex")

        val progress = if (totalFrames > 1) {
            frameIndex.toFloat() / (totalFrames - 1).toFloat()
        } else {
            1f
        }

        paint.alpha = min(255, (255 * progress).toInt() + 100)

        for (i in letters.indices) {
            val endPoint: PointF = finalLetterLocations.get(i)
            val startPoint: PointF = originalLetterLocations.get(i)
            val x: Float = startPoint.x + (endPoint.x - startPoint.x) * progress
            val y: Float = startPoint.y + (endPoint.y - startPoint.y) * progress
            canvas.drawText(letters[i].toString(), x, y, paint)
        }

    }

    override fun onBoundsChange(bounds: Rect) {
        super.onBoundsChange(bounds)
        Log.d(tag, "onBoundsChange, $bounds")

        height = bounds.height().toFloat()
        width = bounds.width().toFloat()

        calcLetterStartEndLocations()

        invalidateSelf()
    }

    private fun calcLetterStartEndLocations() {
        originalLetterLocations.clear()
        finalLetterLocations.clear()

        val height = this.height ?: throw IllegalStateException("height cannot be null")
        val width = this.width ?: throw IllegalStateException("width cannot be null")

        val centerY: Float = height / 2f + paint.textSize / 2

        val totalLength = paint.measureText(letters)
        val startX = (width - totalLength) / 2

        var currentStartX = startX

        for (i in letters.indices) {
            val str: String = letters[i].toString()
            val currentLength: Float = paint.measureText(str)


            originalLetterLocations.put(
                i, PointF(
                    Math.random().toFloat() * width, Math.random()
                        .toFloat() * height
                )
            )

            finalLetterLocations.put(i, PointF(currentStartX, centerY))
            // TODO: 2021/2/1 consider padding for letters inner
            currentStartX += currentLength

        }
    }
}

最终我们看一下效果： 大约从第四秒开始点击了start，中间点击了stop，随后又点击了start

注：gif丢失了一定的连贯性，可以看一下录制的视频 链接 因为起始位置是随机的，所以每次的效果都会有差别

version 5 让所有的字母都动起来

其实细心的读者应该发现了，上面Version 4的代码已经可以让每个字母都动起来了。 先来试一下效果，把Drawable资源的text改成Leobert，看一下效果:

录制视频：链接

可能有些读者这时候已经在思考，继续添加各种配置支持项，改变初始点的随机位置算法，计算过程中更加细致的考虑字号、文字留白等等等等细节了。

打住，我们的目标是重新梳理Drawable中的知识，而不是实现一个特定的Drawable。到这里，我们已经实现了一个自定义的动画Drawable。

最终总结和反思

这篇文章中，我们梳理了Drawable的设计意图，自行梳理了Drawable子类概览，梳理了Drawable的API概览，练习了自定义Drawable。

我们再思考几个问题：

自定义View和自定义Drawable的区别是什么

前者是对于视图的自定义，后者是对于绘制的自定义。两者有一定的关联性，因为视图也是需要通过视觉呈现给用户的，有很大一部和绘制相关；

但自定义View不仅仅可以自定义绘制，还可以自定义交互，这一点是自定义Drawable不具备的。如果我们仅仅是期望对绘制进行自定义，选择自定义Drawable即可；

相比于自定义View，自定义Drawable在应用内的适用性更广，它具体描述了一种绘制，所以，只要存在绘制机制的地方，理论上就可以使用它。

各种"花里胡哨"的效果都可以这样干吗

可以但不是所有的都建议。一些简单的场景，例如一种点击特效、一种Progress效果 是建议这样处理的。

一些复杂的场景，例如启动图、固定的酷炫的转场等，是不建议这样处理的。不是说不建议用自定义Drawable处理，而是不建议 再用代码去直接描述Draw的内容。

对于复杂内容，可以对其内容进行抽象和分类，一般来说，我们可以从：

• 静态、动态
• 矢量描述、非矢量描述

两个维度区分一个要绘制的内容；

对于静态的，或者矢量描述的内容，已经有相关的类进行抽象描述。而对于动态的非矢量描述的绘制内容， 它们往往复杂，而且很具体，用纯代码进行描述太糟糕了。应当建立抽象体系并结合中间物来描述它们。

以大名鼎鼎的Lottie为例，设计使用AE创作动画文件，并导出成lottie的动画文件：

• 不可矢量描述的、唯一命名的图
• json格式封装的所有帧信息

那么只需要描述：

• 解析文件
• 加载帧信息
• 展示帧，即绘制帧
• 按照动画时间和帧信息schedule

即可。内容设计这种事情，就交给UI和UX了

从技术梳理和博客的角度看，这篇文章的内容已经结束了，从商业投产的角度看，这篇文章的内容远没有结束

好玩系列：拥有它，XML文件少一半--更方便的处理View背景

前言

关于好玩系列

这是一项已经被我们项目实验性投产将近一年的方案，虽然还处于实验性阶段，但稳定性和实用性都不错。

DaVinCi 仓库链接

问题背景：Android 中普遍使用XML来定义资源，对于视图的背景样式而言，需要定义大量的 GradientDrawable、StateListDrawable 资源等。当项目体量很大时。这些资源就会出现难管理的问题。

诚然，从最佳实践角度出发，对项目中的资源进行合理地命名以满足查询索引规则，按照设计风格定义对应的Style，视图定义时利用Style约束其样式。这才是 优秀的做法。但是，事与愿违，按照国内的从业者现状看，大多数处理大型项目的团队都没有做好这一点的必要条件。

在展开实践之前，我们不妨反思下为何会如此，不外乎：

• 缺乏或者频繁变动顶层设计语言，这个词可能并不太准确
• 以往的页面已经在线上运行了，设计新的页面簇改变了设计风格时，没有安排原有内容的统一修改并给到时间。
• 以上两条导致全栈Style混乱
• 当Style超过3种风格时，开发团队一般选择毁灭吧，我累了，谁动全栈风格跟谁急。

OK，既然都选择了毁灭吧,那为什么不选择一种更加舒适的方式来处理常见的背景问题。

挑选目标--最常用的Drawable资源

经过一番草率的筛选，我们很快锁定了目标：selector、shape

举个例子，窥一斑而见全豹：

这还只是一小部分，相信各位的项目中也会有这样的痛点吧。

且不谈 命名规则 是否合情合理，这是一种很反人类的设定，就像你忘记了密码，申请重置，按照一系列的密码规则， 终于设定了一个 让你惴惴不安 担心 再次忘记 的密码后，提交提示：不能和原密码一致。

对Drawable体系有一定了解的话，我们知道 selector、shape 分别对应：

• StateListDrawable
• GradientDrawable

如果对Drawable体系还不太清楚的话，可以简要阅读一下我之前的一篇博客：三思系列：重新认识Drawable

换一种定义资源、解析资源的方式

布局文件中使用这些Drawable资源时，在View被创建后，会解析配置的属性，而Drawable相关的资源，会被DrawableInflater加载并运用。

这一点就不展开了。毫无疑问，如果要替换掉基于xml的资源定义方式，我们只能采用一个新的方式。但是，我们并没有打算 抛弃使用xml文件定义布局资源

且不卖关子，当时搜索枯肠，要满足：

• 丢弃单独文件定义
• 方便，不需要查手册

两个要素，只想到两个关键词： DSL，OO，没错，领域特定语言 和 面向对象。

严格来说，这两者基本是互斥的。

但是很抱歉，这里必须要先打住，要先讲点别的，然后再回到这个话题。

注，后面很大一段篇幅，会用于：

• 解释抛弃自定义View和属性的方案
• 使用Builder简化Drawable构造过程
• DSL简介
• 用DSL解决这个问题

个人认为 使用自定义文法 和 解释器处理文法解析 是一件挺好玩的事情，值得玩一玩， 但限于我的水平，这段内容读起来可能很晦涩，如果不是非常感兴趣，可以直接跳过到：到底是DSL还是OO

抛弃了自定义View和属性的方式

在开始时，我考虑过这种方案。但是使用 自定义的 LayoutInflater 或者 hook 系统LayoutInflater 都是可能影响到某些 黑科技的

就算不考虑干扰到其他黑科技，也需要严格的处理各种属性组合，并提供完善的查询手册，这很 不人道主义，

而基于十几个属性组合场景自定义lint规则，这 很烦 ，一点都 不好玩

所以这个方案直接被否决

工欲善其事必先利其器，Drawable对象构建工具 -- Drawable Builder

因为 StateListDrawable 和 GradientDrawable 的内部细节都是比较多的，这句话等价于：构建这两者的实例对象比较复杂。

这很符合Builder模式的使用场景，我们先设计一个Builder来处理这两者的构建，并在构建过程中检验信息

这是一件比较枯燥的事情，代码略。详见DaVinCiCore.kt

在我们完善的考虑了 各种state下： 形状，渐变的角度、方式，填充，描边，尺寸，指定的drawable等之后，我们可以 "很方便" 的创建Drawable啦！

一套适应场景的DSL -- 定义规则

在内容展开之前，我们再回顾一下DSL的基础。

DSL即 Domain Specified Language 、领域专用语言。

Wikipedia中关于这个词条的描述：

A specialized computer language designed for a specific task.

为了解决 某类 特定问题 而设计的一种 特殊 的计算机语言

而马丁老爷子关于它的描述，看起来就很高深了，但我更喜欢这一个描述：

A computer programming language of limited expressiveness focused on a particular domain.

一种 抑制表达能力 以 专注于 特定领域 的计算机语言。

这种抑制，让它专注于特定的领域，而抛弃了其他的领域，以达到更加高效、准确的目的。

我们知道，xml协议的扩展性非常强，而这种扩展性，让它的解析变得非常的繁琐，继而带来了效率问题。Android中，为了 兼顾 xml的 扩展性 和 使用的 效率问题， 定制了各类Inflater以处理特定的问题。

显然，我们这次不打算在巨人的肩膀上更进一步，而是要在特定问题上，剑走偏锋。

按照我们积累的知识，要构建一个 GradientDrawable，可能用到：

• 形状 shape
• 纯色填充色 solidColor
• 圆角相关：
  • cornersRadius
  • cornersBottomLeftRadius
  • cornersBottomRightRadius
  • cornersTopLeftRadius
  • cornersTopRightRadius
• 填充渐变：
  • 渐变方向角 gradientAngle
  • 渐变中点x gradientCenterX
  • 渐变中点y gradientCenterY
  • 渐变起始颜色 gradientStartColor
  • 渐变中点颜色 gradientCenterColor
  • 渐变终点颜色 gradientEndColor
• 渐变形式 gradient
• 形式为 RADIAL_GRADIENT时的 gradientRadius
• useLevel
• padding
• sizeWidth
• sizeHeight
• 描边宽度 strokeWidth
• 描边颜色 strokeColor
• 虚线段宽度 strokeDashWidth
• 虚线段间距 strokeDashGap

当然，我们还需要考虑到 不同的状态，和一些 细节 ，这里先不展开

此时我们有两个选择方向，让我们的DSL类似于：

shape:[
    gradient:[type:linear;startColor:#ff3c08;endColor:#353538 ];
    st:[Oval];
    corners:[40 dp];
    stroke:[width:4 dp;color:rc / colorAccent ]
]

ps，因为目标固定为设置background，所以语法式中忽略这种描述

或者类似于sql的insert语句。

不过后者的 字段 太多，实在不适合阅读，而且SQL的 表达能力 相对于我们要处理的问题，还是过强了一点。

ok，我们再仔细设计一下规则。

终结符：

• [ ],当前域的子句均置于其中，例：

域:[子域1:[值]]

shape:[st:[Oval]]

• ;,当前域有多个子域时，子域之间用 ; 分隔

非终结符：

• shape: 代表创建一个GradientDrawable
• st: 代表shape类型，枚举值为
  • Rectangle
  • Oval
  • Line
  • Ring
• corners: 圆角相关设置，值置于[]中，一个值代表4个角，4个值代表 左上、右上、右下、左下 四个值对应设置
• solid: 纯色填充，[]内为色值，色值表达见后
• gradient:渐变色，子命令置于 [] 中
  • type：渐变类型，枚举为：
    • linear
    • radial
    • sweep
  • startColor: 起始色
  • centerColor: 中间色
  • endColor: 结束色
  • centerX: 中点x
  • centerY: 中点y
  • angle: 渐变角度
• stroke: 描边，子命令置于 [] 中
  • width: 描边宽度
  • color: 描边颜色
  • dashWidth: 虚线宽
  • dashGap: 虚线间距
• size: 尺寸
  • width:
  • height:
• padding: 内边距
  • left
  • top
  • right
  • bottom

特殊规则：

• 尺寸描述：纯数字代表px，数值+dp 代表dp值，w代表 wrap_content，m 代表 match_parent
• 颜色表达："#ffffff"等色值字符串，代表ARGB值的 int 值，"rc/资源名" 表达资源引用， 以及用"@idName"来获取目标View的tag，tag值需为颜色字符串或者ARGB色

为了适当减少类的数量，我们约定：

• 不拥有子域的域弱化为属性，以属性名:属性值的方式表达，而不再需要 [] 符号
• 当某个域的属性只存在一个或者已经被约定时，可以忽略其属性名，直接使用属性值

注:重新整理时，我发现最开始编码的 ShapeType 和 Corners 没有重新按照上述约定修正， 这是一处遗忘修改的bug，准确的讲，是将子域弱化为属性时，期望略去终结符而带来的文法规则缺陷，读者不要深究。

出现这个bug的根本原因是：我当时想减少小类数量，并 一定程度上降低解析复杂度，将非终结符识别标记 和终结符 [ 组合在了一起，替代原先的非终结符识别标记使用。

注2：主体是 GradientDrawable ，为什么用 Shape去对应？因为国内普遍存在的文章中，绝大多数都已经将 Gradient 对应为"颜色的梯度渐变"，而将这一资源文件定义为 "形状"、带"填充"和"描边"的形状。而Android的资源定义语法中， 也是类似的。大家也都习惯了，索性尊重习惯。

解释器 -- 处理表达式解析

在GOF的设计模式中，解释器模式 ( Interpreter Pattern ) 提供了 评估 语言的 语法 或 表达式 的方式，它属于 行为型模式。

需要注意，其实在这个问题的实际场景中，一条语句，子句出现的频率可能并不会太高，但解释器模式 依旧是场景适用 的。

我们再回顾一下解释器模式的 优缺点：

优点：

• 可扩展性比较好，灵活。
• 易于实现简单文法。

缺点：

• 对于复杂的文法比较难维护
• 可能引起类膨胀
• 采用递归调用方法，层级过深，可能出现效率问题

定义上下文

其中 core:DaVinCiCore 是上面提到的构建者，未遵循习惯命名法。 view:View 是要操作的View。

源码枯燥，略

抽象表达式

sealed class DaVinCiExpression(var daVinCi: DaVinCi? = null) {

    // 节点名称
    protected var tokenName: String? = null

    // 文本内容
    protected var text: String? = null

    //实际属性是否需要从text解析，手动创建并给了专有属性的，设为false，就不会被覆盖了
    protected var parseFromText = true

    abstract fun injectThenParse(daVinCi: DaVinCi?)

    /*
     * 执行方法
     */
    abstract fun interpret()

    open fun startTag(): String = ""

    companion object {
        @JvmStatic
        fun shape(): Shape = Shape(true)

        const val sLogTag = "DaVinCi"

        const val END = "]"

        const val NEXT = "];"

        const val sResourceColor = "rc/"
    }
}

终结符处理

只需要处理兄弟域的关系即可，例如，我们知道 solid 和 stroke 就是兄弟域，

 protected class ListExpression(daVinCi: DaVinCi? = null, private val manual: Boolean = false) :
    DaVinCiExpression(daVinCi) {
    private val list: ArrayList<DaVinCiExpression> = ArrayList()

    fun append(exp: DaVinCiExpression) {
        list.add(exp)
    }

    override fun injectThenParse(daVinCi: DaVinCi?) {
        this.daVinCi = daVinCi
        if (manual) {
            list.forEach { it.injectThenParse(daVinCi) }
            return
        }

        // 在ListExpression解析表达式中,循环解释语句中的每一个单词,直到终结符表达式或者异常情况退出
        daVinCi?.let {
            var i = 0
            while (i < 100) { // true,语法错误时有点可怕，先上限100
                if (it.currentToken == null) { // 获取当前节点如果为 null 则表示缺少]表达式
                    println("Error: The Expression Missing ']'! ")
                    break
                } else if (it.equalsWithCommand(END)) {
                    it.next()
                    // 解析正常结束
                    break
                } else if (it.equalsWithCommand(NEXT)) {
                    //进入同级别下一个解析
                    it.next()
                } else { // 建立Command 表达式
                    try {
                        val expressions: DaVinCiExpression = CommandExpression(it)
                        list.add(expressions)
                    } catch (e: Exception) {
                        if (DaVinCi.enableDebugLog) Log.e(sLogTag, "语法解析有误", e)
                        break
                    }
                }
                i++
            }
            if (i == 100) {
                if (DaVinCi.enableDebugLog) Log.e(sLogTag, "语法解析有误，进入死循环，强制跳出")
            }
        }
    }

    override fun interpret() { // 循环list列表中每一个表达式 解释执行
        list.forEach { it.interpret() }
    }

    override fun toString(): String {
        val b = StringBuilder()

        val iMax: Int = list.size - 1
        if (iMax == -1) return ""
        var i = 0
        while (true) {
            b.append(list[i].toString())
            if (i == iMax) return b.toString()
            b.append("; ")
            i++
        }
    }
}

非终结符的规则处理

open class CommandExpression(daVinCi: DaVinCi? = null, val manual: Boolean = false) :
    DaVinCiExpression(daVinCi) {
    private var expressions: DaVinCiExpression? = null

    init {
        //因为是嵌套层，且作为父类了，避免递归
        if (this::class == CommandExpression::class)
            onParse(daVinCi)
    }

    override fun injectThenParse(daVinCi: DaVinCi?) {
        onParse(daVinCi)
    }

    protected fun toPx(str: String, context: Context): Int? {
        //略
    }

    protected fun parseColor(text: String?): Int? {
        //略
    }

    protected fun parseInt(text: String?, default: Int?): Int? {
        //略
    }

    protected fun parseFloat(text: String?, default: Float?): Float? {
        //略
    }

    protected fun getTag(context: Context?, resName: String): String? {
        //略
    }

    protected fun getColor(context: Context?, resName: String?): Int? {
        //略
    }

    @Throws(Exception::class)
    private fun onParse(daVinCi: DaVinCi?) {
        this.daVinCi = daVinCi
        if (manual) return
        daVinCi?.let {
            expressions = when (it.currentToken) {
                Corners.tag -> Corners(it)
                Solid.tag -> Solid(it)
                ShapeType.tag -> ShapeType(it)
                Stroke.tag -> Stroke(it)
                Size.tag -> Size(it)
                Padding.tag -> Padding(it)
                Gradient.tag -> Gradient(it)
                else -> throw Exception("cannot parse ${it.currentToken}")
            }
        }
    }

    protected fun asPrimitiveParse(start: String, daVinCi: DaVinCi?) {
        this.daVinCi = daVinCi
        daVinCi?.let {
            tokenName = it.currentToken
            it.next()
            if (start == tokenName) {
                this.text = it.currentToken
                it.next()
            } else {
                it.next()
            }
        }
    }

    override fun interpret() {
        expressions?.interpret()
    }

    override fun toString(): String {
        return "$expressions"
    }
}

以solid为例：

class Solid(daVinCi: DaVinCi? = null, manual: Boolean = false) :
    CommandExpression(daVinCi, manual) {
    @ColorInt
    internal var colorInt: Int? = null //这是解析出来的，不要乱赋值

    companion object {
        const val tag = "solid:["
    }

    init {
        injectThenParse(daVinCi)
    }

    override fun injectThenParse(daVinCi: DaVinCi?) {
        this.daVinCi = daVinCi

        if (manual) {
            if (parseFromText)
                colorInt = parseColor(text)
            return
        }
        colorInt = null
        asPrimitiveParse(tag, daVinCi)
        colorInt = parseColor(text)

    }

    override fun interpret() {
        if (tag == tokenName || manual) {
            daVinCi?.let {
                colorInt?.let { color ->
                    it.core.setSolidColor(color)
                }
            }
        }
    }

    override fun toString(): String {
        return "$tag ${if (parseFromText) text else colorInt?.run { text }} $END"
    }
}

同理，我们处理完：

• Corners
• ShapeType
• Stroke
• Size
• Padding
• Gradient

即可。

最重要的Shape

至此，我们只需要再解析 shape:[] 即可完成工作。

很简单，只要我们识别出来，其子域的描述子句均可被提取出来，利用 ; 分割子句，那么我们只需要用 ListExpression 即可储存子句。

代码略

注，至此，我们完成了文法的定义和解析处理，注意，目前所有的主体都是 GradientDrawable，他的文法已经足够复杂了，

StateListDrawable 所对应的各种状态 我们不在文法中进行扩展了，否则单条语句的长度会非常可怕。

到底是DSL还是OO

前面我们谈到了这个问题，要满足

• 丢弃单独文件定义
• 方便，不需要查手册

两个要素，只想到两个关键词： DSL，OO，即 领域特定语言 和 面向对象。

当时我们切到了其他话题，并顺带着已经把 DSL方案 的核心实现了。

我们注意到，如果使用DSL，直接使用 字符串形式 的 表达语句，这 很不人道主义。

我们不太可能像web技术那样，再走一条 css 方式的道路

那么，我们目前做的都是鸡肋吗？

这个问题，笔者我目前也无法回答，因为我站得高度还不够高。

但是，这不影响我们继续探究：如何使用OO思想，让构建变得更加简单

在文法符号的相关类基础上，面向对象

在前面的工作中，我们定义了一堆 终结符 和 非终结符 对应的类，而其语法树结构，是通过直接反解 一段 文法表达式字符串 得到的。

反过来想，我们直接面向对象操作，也可以直接构建出期望的语法树。

只要有正确的语法树，执行后一样可以得到期望的结果。

想通这一点，编码就很容易了，这里我们略去相关源码。

注：至此，究竟是 面向对象 构建语法树处理问题，还是使用 文法表达式字符串 构建语法树，已经不再重要。 其本质都是构建语法树以描述Drawable的构建规则，只不过是在两个世界中的不同表达形式

最后一步，巧借东风，借助DataBinding，直接在xml中使用

我们知道，利用DataBinding，可以直接在xml中实现声明使用

再结合 BindingAdapter 机制，我们就可以实现 声明背景 的目标。

@BindingAdapter(
    "daVinCi_bg", "daVinCi_bg_pressed", "daVinCi_bg_unpressed",
    "daVinCi_bg_checkable", "daVinCi_bg_uncheckable", "daVinCi_bg_checked", "daVinCi_bg_unchecked",
    requireAll = false
)
fun View.daVinCi(
    normal: DaVinCiExpression? = null,
    pressed: DaVinCiExpression? = null, unpressed: DaVinCiExpression? = null,
    checkable: DaVinCiExpression? = null, uncheckable: DaVinCiExpression? = null,
    checked: DaVinCiExpression? = null, unchecked: DaVinCiExpression? = null
) {
    val daVinCi = DaVinCi(null, this)
    //用于多次构建
    val daVinCiLoop = DaVinCi(null, this)

    normal?.let {
        daVinCi.apply {
            currentToken = normal.startTag()
        }
        if (DaVinCi.enableDebugLog) Log.d(sLogTag, "${this.logTag()} daVinCi normal:$normal")

        normal.injectThenParse(daVinCi)
        normal.interpret()
    }

    pressed?.let {
        simplify(daVinCiLoop, it, "pressed", this)
        daVinCi.core.setPressedDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }

    unpressed?.let {
        simplify(daVinCiLoop, it, "unpressed", this)
        daVinCi.core.setUnPressedDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }

    checkable?.let {
        simplify(daVinCiLoop, it, "checkable", this)
        daVinCi.core.setCheckableDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }

    uncheckable?.let {
        simplify(daVinCiLoop, it, "uncheckable", this)
        daVinCi.core.setUnCheckableDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }

    checked?.let {
        simplify(daVinCiLoop, it, "checked", this)
        daVinCi.core.setCheckedDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }

    unchecked?.let {
        simplify(daVinCiLoop, it, "unchecked", this)
        daVinCi.core.setUnCheckedDrawable(daVinCiLoop.core.build())
        daVinCiLoop.core.clear()
    }


    //下面的略
    //    private var enabledDrawable: Drawable? = null
    //    private var unEnabledDrawable: Drawable? = null
    //    private var selectedDrawable: Drawable? = null
    //    private var focusedDrawable: Drawable? = null
    //    private var focusedHovered: Drawable? = null
    //    private var focusedActivated: Drawable? = null
    //    private var unSelectedDrawable: Drawable? = null
    //    private var unFocusedDrawable: Drawable? = null
    //    private var unFocusedHovered: Drawable? = null
    //    private var unFocusedActivated: Drawable? = null

    ViewCompat.setBackground(this, daVinCi.core.build())
}

示例：

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <data>

        <variable
            name="a"
            type="String" />

        <import type="osp.leobert.android.davinci.DaVinCiExpression" />

    </data>

    <androidx.core.widget.NestedScrollView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        tools:context=".MainActivity">

        <LinearLayout
            daVinCi_bg="@{DaVinCiExpression.shape().solid(`#eaeaea`)}"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical"
            android:padding="10dp">

            <TextView
                android:id="@+id/test"
                daVinCi_bg="@{DaVinCiExpression.shape().corner(60).solid(`@i2`).stroke(`4dp`,`@i2`)}"
                android:layout_width="match_parent"
                android:layout_height="100dp"
                android:layout_marginTop="10dp"
                android:background="@drawable/test"
                android:gravity="center"
                android:text="@string/app_name">

                <tag
                    android:id="@id/i1"
                    android:value="@color/colorPrimaryDark" />

                <tag
                    android:id="@id/i2"
                    android:value="@color/colorAccent" />
            </TextView>

            <Button
                daVinCi_bg_pressed="@{DaVinCiExpression.shape().corner(`10dp,15dp,20dp,30dp`).stroke(`4dp`,`@i2`).gradient(`#26262a`,`#ff0699`,0)}"
                daVinCi_bg_unpressed="@{DaVinCiExpression.shape().corner(60).solid(`@i1`).stroke(`4dp`,`@i2`)}"
                android:layout_width="match_parent"
                android:layout_height="100dp"
                android:gravity="center"
                android:text="Hello World!">

                <tag
                    android:id="@id/i1"
                    android:value="@color/colorPrimaryDark" />

                <tag
                    android:id="@id/i2"
                    android:value="@color/colorAccent" />
            </Button>

            <TextView
                android:id="@+id/test2"
                daVinCi_bg="@{DaVinCiExpression.shape().corner(`10dp,15dp,20dp,30dp`).stroke(`4dp`,`@i2`).gradient(`#26262a`,`#ff0699`,0)}"
                android:layout_width="match_parent"
                android:layout_height="100dp"
                android:layout_marginTop="10dp"
                android:background="@drawable/test"
                android:gravity="center"
                android:text="@string/app_name">

                <tag
                    android:id="@id/i1"
                    android:value="@color/colorPrimaryDark" />

                <tag
                    android:id="@id/i2"
                    android:value="@color/colorAccent" />
            </TextView>

            <CheckBox
                daVinCi_bg="@{DaVinCiExpression.shape().corner(60).solid(`@i2`).stroke(`4dp`,`@i2`)}"
                daVinCi_bg_pressed="@{DaVinCiExpression.shape().corner(`10dp,15dp,20dp,30dp`).stroke(`4dp`,`@i2`).gradient(`#26262a`,`#ff0699`,0)}"
                android:layout_width="match_parent"
                android:layout_height="100dp"
                android:layout_marginTop="10dp"
                android:background="@drawable/test"
                android:gravity="center"
                android:text="错误示范：daVinCi_bg只能单独使用，一旦有其他的，就需要使用相应的成对的">

                <tag
                    android:id="@id/i1"
                    android:value="@color/colorPrimaryDark" />

                <tag
                    android:id="@id/i2"
                    android:value="@color/colorAccent" />
            </CheckBox>

            <CheckBox
                daVinCi_bg_checked="@{DaVinCiExpression.shape().corner(60).solid(`@i2`).stroke(`4dp`,`@i2`)}"
                daVinCi_bg_unchecked="@{DaVinCiExpression.shape().corner(`10dp,15dp,20dp,30dp`).stroke(`4dp`,`@i2`).gradient(`#26262a`,`#ff0699`,0)}"
                android:layout_width="match_parent"
                android:layout_height="100dp"
                android:layout_marginTop="10dp"
                android:background="@drawable/test"
                android:gravity="center"
                android:text="check状态">

                <tag
                    android:id="@id/log_tag"
                    android:value="测试log tag" />

                <tag
                    android:id="@id/i1"
                    android:value="@color/colorPrimaryDark" />

                <tag
                    android:id="@id/i2"
                    android:value="@color/colorAccent" />

                <tag
                    android:id="@id/i3"
                    android:value="@string/app_name" />
            </CheckBox>

        </LinearLayout>

    </androidx.core.widget.NestedScrollView>

</layout>

粗糙的Demo效果，见笑了： 感谢读者鲁班贼六同学提醒我补充效果图

甚至可以玩杂耍，直接使用字符串形式的DSL内容：

binding.test2.setOnClickListener {
    it.daVinCi("shape:[ gradient:[ type:linear;startColor:#ff3c08;endColor:#353538 ];" +
            " st:[ Oval ]; corners:[ 40dp ]; stroke:[ width:4dp;color:rc/colorAccent ] ]")
}

注意，这个方式不推荐使用，很不利于维护，就是 杂耍，可以直接更新背景：

总结和展望

这一篇，我们从一个问题：

xml定义的资源文件难以管理、维护

开始，尝试性的提出了一种 替代xml 定义背景资源文件的方式。并进行了知识展开和拓展。 最终实现了期望目标。

但是，使用 xml文件 或者其他形式的文件来定义资源，是有它的道理的，虽然，这种方式的弊端已经被长久诟病， 并且在新兴技术中，资源和代码的存在位置已经开始交融。

我们知道，Compose这一革命性技术，新事物想要完全替代旧事物，不是一朝一夕的事情，旧事物不会突然消失。

本文中的方案，我将其视为一次 好玩 ，跟时髦 的尝试。并且我个人认为，这一方案还是有存在价值的。

而在此基础上，还可以继续开展 style定义和使用，ColorStateList 文法表达式。

今天是除夕，祝大家除夕快乐。

迟来的续集--Drawable+Animator，将优雅进行到底

前言

2021年初，读过一篇关于splash页面动效的推送文章，作者讲解了如何实现一个闪屏页效果：

将一个英文单词拆分为多个字母，散落在屏幕中，然后按照一定的路径回归，最终展示一段流光效果。

通过自定义View的方式予以实现。

当时我脑中闪过一个念头：他的实现很棒，但如果不需要点触、手势交互，使用Drawable实现更好。并由此编写了一篇文章：三思系列：重新认识Drawable , 并在不久之后通过 三思系列：为什么要自定义View 一文阐释了对于 "自定义View适用场景" 的个人拙见。

简单通过思维导图回顾 三思系列：重新认识Drawable 一文的内容：

阅读原文大约需要10-15分钟

文中，我们最终以该方案实现了 "自定义一个动画Drawable" ： unscheduleSelf() / scheduleSelf() 机制 停止回调/设置定时回调 + invalidateSelf() 机制进行刷新绘制； 方案的本质是 在预设时间点绘制关键帧 。仔细观察后不难发现问题：效果并不顺滑 。效果如下：

视频：链接

彼时，文章的主旨为重新认识Drawable，并未对此展开讨论并进一步优化。 本篇文章作为迟来的续集，将会 对问题展开讨论、探索优化方案、追究原理、并进一步拓宽思路。按照此方式展开将迎来久违的三思系列。

关于三思系列

思危：问题本质

上文已经提到，我们通过 unscheduleSelf() / scheduleSelf() 机制 停止回调/设置定时回调，重新绘制关键帧。那么 scheduleSelf() 的本质又是什么？

阅读代码可知，源码中通过接口回调的设计，将功能的实现剥离：

class Drawable {
    public void scheduleSelf(@NonNull Runnable what, long when) {
        final Callback callback = getCallback();
        if (callback != null) {
            callback.scheduleDrawable(this, what, when);
        }
    }

    public final void setCallback(@Nullable Callback cb) {
        mCallback = cb != null ? new WeakReference<>(cb) : null;
    }

    @Nullable
    public Callback getCallback() {
        return mCallback != null ? mCallback.get() : null;
    }

    public interface Callback {
        void invalidateDrawable(@NonNull Drawable who);

        void scheduleDrawable(@NonNull Drawable who, @NonNull Runnable what, long when);

        void unscheduleDrawable(@NonNull Drawable who, @NonNull Runnable what);
    }
}

继续寻找 Callback 实现类：重点关注 scheduleDrawable 即可

public class View implements Drawable.Callback {
    public void invalidateDrawable(@NonNull Drawable drawable) {
        if (verifyDrawable(drawable)) {
            final Rect dirty = drawable.getDirtyBounds();
            final int scrollX = mScrollX;
            final int scrollY = mScrollY;

            invalidate(dirty.left + scrollX, dirty.top + scrollY,
                    dirty.right + scrollX, dirty.bottom + scrollY);
            rebuildOutline();
        }
    }

    //看这里
    public void scheduleDrawable(@NonNull Drawable who, @NonNull Runnable what, long when) {
        if (verifyDrawable(who) && what != null) {
            final long delay = when - SystemClock.uptimeMillis();
            if (mAttachInfo != null) {
                mAttachInfo.mViewRootImpl.mChoreographer.postCallbackDelayed(
                        Choreographer.CALLBACK_ANIMATION, what, who,
                        Choreographer.subtractFrameDelay(delay));
            } else {
                // Postpone the runnable until we know
                // on which thread it needs to run.
                getRunQueue().postDelayed(what, delay);
            }
        }
    }

    public void unscheduleDrawable(@NonNull Drawable who, @NonNull Runnable what) {
        if (verifyDrawable(who) && what != null) {
            if (mAttachInfo != null) {
                mAttachInfo.mViewRootImpl.mChoreographer.removeCallbacks(
                        Choreographer.CALLBACK_ANIMATION, what, who);
            }
            getRunQueue().removeCallbacks(what);
        }
    }

    public void unscheduleDrawable(Drawable who) {
        if (mAttachInfo != null && who != null) {
            mAttachInfo.mViewRootImpl.mChoreographer.removeCallbacks(
                    Choreographer.CALLBACK_ANIMATION, null, who);
        }
    }

}

简单解释程序逻辑如下：如果 "该Drawable作用于自身" 且 "Runnable非空"，计算回调的delay，如果View已经添加到Window，则交给Choreographer，否则丢入缓存队列。

而缓存队列的内容将在View添加到Window时交给 Choreographer

public class View {
    void dispatchAttachedToWindow(AttachInfo info, int visibility) {
        //ignore

        // Transfer all pending runnables.
        if (mRunQueue != null) {
            mRunQueue.executeActions(info.mHandler);
            mRunQueue = null;
        }

        //ignore
    }
}

读者诸君，如果您熟悉Android的 屏幕刷新机制 和 消息机制 ，一定不会对 Choreographer 感到陌生

Choreographer 直译为编舞者，暗含了 "编制视图变化效果" 的隐喻，其本质依旧是利用 VSync+Handler消息机制。delay Callback的设计存在毫秒级的误差。

作者按：本篇不再展开讨论Android的消息机制，以下仅给出 基于消息机制的界面绘制设计 关键部分流程图：

结合前面的代码分析，scheduleDrawable 的流程可以参考此图理解。

作者按，虽然仍有差异，但机制一致，可参考理解

验证

Talk is cheap, show you the code

在 View 中有一段代码和 scheduleDrawable 高度相似：

class View {
    public void postOnAnimationDelayed(Runnable action, long delayMillis) {
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            attachInfo.mViewRootImpl.mChoreographer.postCallbackDelayed(
                    Choreographer.CALLBACK_ANIMATION, action, null, delayMillis);
        } else {
            // Postpone the runnable until we know
            // on which thread it needs to run.
            getRunQueue().postDelayed(action, delayMillis);
        }
    }
}

注意：scheduleDrawable 基于执行的目标时间 when，和当前系统时钟计算了delay，又额外调整了delay时间, Choreographer.subtractFrameDelay(delay)，_ 它是隐藏API_

public final class Choreographer {
    private static final long DEFAULT_FRAME_DELAY = 10;
    // The number of milliseconds between animation frames.
    private static volatile long sFrameDelay = DEFAULT_FRAME_DELAY;

    public static long subtractFrameDelay(long delayMillis) {
        final long frameDelay = sFrameDelay;
        return delayMillis <= frameDelay ? 0 : delayMillis - frameDelay;
    }
}

设计一个简单的验证代码：

class Demo {
    //...

    fun test() {
        val btn = findViewById<Button>(R.id.btn)
        var index = 0
        var s = System.currentTimeMillis()

        val action: Runnable = object : Runnable {
            override fun run() {
                Log.e("lmsg", "$index, offset time ${System.currentTimeMillis() - s - index * 30}")
                index++
                if (index < 100) {
                    btn.postOnAnimationDelayed(
                        this,
                        30L - 10L /*hide api:android.view.Choreographer#subtractFrameDelay*/
                    )
                } else {
                    Log.e("lmsg", "finish, total time ${System.currentTimeMillis() - s}")

                }
            }
        }

        btn.setOnClickListener {
            index = 0
            s = System.currentTimeMillis()
            it.postOnAnimationDelayed(action, 0L)
        }
    }
}

参考一下结果：注意执行结果不会幂等，但整体表现为超出预期时长

思退：使用Animator改进

Android 在 Android 3.0，API11 中提供了更强大的动画 Animator，借助其中的 ValueAnimator，可以很方便的 编排 动画。

即便尚未分析原理，只要使用过属性动画，也知道它具有非常丝滑的效果

以上还都是推测，接下来进行实测。

实现

刨去一致部分，我们需要完成以下两点：

• 创建 ValueAnimator 实例，并按照动画需求设置 时长、插值器、UpdateListener 等
• 若没有额外需要，可将 Animatable2 弱化为 Animatable，仅保留动画控制API，通过 ValueAnimator 实例委托实现API业务逻辑。

核心代码如下： 完整代码可从github获取：DrawableWorkShop

class AnimLetterDrawable2 : Drawable(), Animatable {
    // 相似部分略去

    private val totalFrames = 30 * 3 //3 second, 30frames per second

    private val valueAnimator = ValueAnimator.ofInt(totalFrames).apply {
        duration = 3000L

        this.interpolator = LinearInterpolator()

        addUpdateListener {
            setFrame(it.animatedValue as Int)
        }
    }

    private var frameIndex = 0


    private fun setFrame(frame: Int) {
        if (frame >= totalFrames) {
            return
        }
        frameIndex = frame
        invalidateSelf()
    }

    override fun start() {
        Log.d(tag, "start called")
        valueAnimator.start()
    }

    override fun stop() {
        valueAnimator.cancel()
        setFrame(0)
    }

    override fun isRunning(): Boolean {
        return valueAnimator.isRunning
    }

}

效果和关键代码对比

gif的效果太差，可以在 github项目仓库 中获取 webm视频

关键代码差异：

在原方案中，我们计算了下一帧的播放时间点，借助 scheduleSelf -> View#scheduleDrawable 进行了刷新

class AnimLetterDrawable {
    private fun setFrame(frame: Int, unschedule: Boolean, animate: Boolean) {
        if (frame >= totalFrames) {
            return
        }
        mAnimating = animate
        frameIndex = frame

        if (unschedule || animate) {
            unscheduleSelf(this)
        }
        if (animate) {
            // Unscheduling may have clobbered these values; restore them
            frameIndex = frame

            scheduleSelf(this, SystemClock.uptimeMillis() + durationPerFrame)
        }
        invalidateSelf()
    }
}

而新方案中，我们借助ValueAnimator的更新回调函数直接刷新，显示预定帧

class AnimLetterDrawable2 {
    private val valueAnimator = ValueAnimator.ofInt(totalFrames).apply {
        duration = 3000L

        this.interpolator = LinearInterpolator()

        addUpdateListener {
            setFrame(it.animatedValue as Int)
        }
    }

    private fun setFrame(frame: Int) {
        if (frame >= totalFrames) {
            return
        }
        frameIndex = frame
        invalidateSelf()
    }
}

Animator的原理

此时，再来思索一番，为何 Animator 的实现效果明显丝滑呢？

思危：是否和scheduleDrawable相比使用了不一样的底层机制？

源码跟进

单纯阅读文章内的代码会很枯燥，建议读者诸君对文中列出的源码进行泛读，抓住思路后再精读一遍源码。

以下将有6个关键点，可厘清其原理

• 1，start方法 -- 找到动画被驱动的核心
• 2， AnimationHandler#addAnimationFrameCallback(AnimationFrameCallback)
• 3，mAnimationCallbacks 何时移除元素
• 4，AnimationHandler#doAnimationFrame 方法的逻辑
• 5，向前看，何人调用FrameCallback -- 驱动动画的底层逻辑
• 6，向后看，ValueAnimator#doAnimationFrame -- 丝滑的原因

1，start方法

class ValueAnimator {

    public void start() {
        start(false);
    }

    private void start(boolean playBackwards) {
        if (Looper.myLooper() == null) {
            throw new AndroidRuntimeException("Animators may only be run on Looper threads");
        }
        //略去一部分
        addAnimationCallback(0); //这里是核心

        if (mStartDelay == 0 || mSeekFraction >= 0 || mReversing) {
            startAnimation();
            if (mSeekFraction == -1) {
                setCurrentPlayTime(0);
            } else {
                setCurrentFraction(mSeekFraction);
            }
        }
    }

    private void addAnimationCallback(long delay) {
        //startWithoutPulsing 才会return
        if (!mSelfPulse) {
            return;
        }
        getAnimationHandler().addAnimationFrameCallback(this, delay); //这里是核心
    }
}

简单阅读，可以排除掉 startAnimation setCurrentPlayTime setCurrentFraction，他们均不是动画回调的核心，只是在进行必要地初始化和FLAG状态维护。

真正的核心是：getAnimationHandler().addAnimationFrameCallback(this, delay);

注意：AnimationHandler 存在线程单例设计:

//使用方：
class ValueAnimator {
    public AnimationHandler getAnimationHandler() {
        return mAnimationHandler != null ? mAnimationHandler : AnimationHandler.getInstance();
    }
}

//ThreadLocal线程单例设计
class AnimationHandler {
    public final static ThreadLocal<AnimationHandler> sAnimatorHandler = new ThreadLocal<>();
    private boolean mListDirty = false;

    public static AnimationHandler getInstance() {
        if (sAnimatorHandler.get() == null) {
            sAnimatorHandler.set(new AnimationHandler());
        }
        return sAnimatorHandler.get();
    }
}

2, AnimationHandler#addAnimationFrameCallback(AnimationFrameCallback)

方法逻辑中，有两处需要关注：

• 如果无 AnimationFrameCallback 回调实例 ， 说明没有在运行中的动画 ，则挂载 Choreographer.FrameCallback mFrameCallback ， 为更新动画（_ 调用动画的AnimationFrameCallback回调接口_）做准备。
• 在动画的 AnimationFrameCallback 回调实例未被注册的情况下，注册该回调实例

看完这一段源码，读者诸君一定会对以下两点产生兴趣，我们在下文展开：

• doAnimationFrame 方法的逻辑
• mAnimationCallbacks 何时移除元素

先看源码：

public class AnimationHandler {
    private final Choreographer.FrameCallback mFrameCallback = new Choreographer.FrameCallback() {
        @Override
        public void doFrame(long frameTimeNanos) {
            doAnimationFrame(getProvider().getFrameTime());

            //这不就破案了，只要还有动画的 AnimationFrameCallback，就挂载 mFrameCallback

            if (mAnimationCallbacks.size() > 0) {
                getProvider().postFrameCallback(this);
            }
        }
    };

    private AnimationFrameCallbackProvider getProvider() {
        if (mProvider == null) {
            mProvider = new MyFrameCallbackProvider();
        }
        return mProvider;
    }

    public void addAnimationFrameCallback(final AnimationFrameCallback callback, long delay) {
        if (mAnimationCallbacks.size() == 0) {
            getProvider().postFrameCallback(mFrameCallback);
        }
        if (!mAnimationCallbacks.contains(callback)) {
            mAnimationCallbacks.add(callback);
        }

        //注意，delay为0，阅读时可以忽略这段逻辑
        if (delay > 0) {
            mDelayedCallbackStartTime.put(callback, (SystemClock.uptimeMillis() + delay));
        }
    }
}

3，mAnimationCallbacks 何时移除元素

AnimationHandler中 "清理" mAnimationCallbacks 的设计 : 先设置null，再择机集中清理null，维护链表结构。可以避免循环过程中移除元素带来的潜在bug、以及避免频繁调整链表空间带来的损耗

关键代码为：android.animation.AnimationHandler#removeCallback，它有两处调用点，看完下面这一段源码后再行分析。

class AnimationHandler {
    public void removeCallback(AnimationFrameCallback callback) {
        mCommitCallbacks.remove(callback);
        mDelayedCallbackStartTime.remove(callback);
        int id = mAnimationCallbacks.indexOf(callback);
        if (id >= 0) {
            mAnimationCallbacks.set(id, null);
            mListDirty = true;
        }
    }

    private void cleanUpList() {
        if (mListDirty) {
            for (int i = mAnimationCallbacks.size() - 1; i >= 0; i--) {
                if (mAnimationCallbacks.get(i) == null) {
                    mAnimationCallbacks.remove(i);
                }
            }
            mListDirty = false;
        }
    }
}

removeCallback 存在一个直接调用，进而可找到两个间接调用点：

• endAnimation 停止动画时, 主动停止以及计算出动画已结束
• doAnimationFrame 中发现动画已经被暂停

再看一下源码：

class ValueAnimator {
    private void removeAnimationCallback() {
        if (!mSelfPulse) {
            return;
        }
        //直接调用-1
        getAnimationHandler().removeCallback(this);
    }

    private void endAnimation() {
        if (mAnimationEndRequested) {
            return;
        }
        //间接调用-1
        removeAnimationCallback();
        //略去
    }

    public final boolean doAnimationFrame(long frameTime) {
        if (mStartTime < 0) {
            // First frame. If there is start delay, start delay count down will happen *after* this
            // frame.
            mStartTime = mReversing
                    ? frameTime
                    : frameTime + (long) (mStartDelay * resolveDurationScale());
        }

        // Handle pause/resume
        if (mPaused) {
            mPauseTime = frameTime;
            //间接调用-2
            removeAnimationCallback();
            return false;
        }
        //略
    }
}

4，AnimationHandler#doAnimationFrame 方法的逻辑

一共有三个业务目的：

• 筛选，调用回调
• 处理 CommitCallback 情况
• 清理 mAnimationCallbacks 详见3

class AnimationHandler {
    private void doAnimationFrame(long frameTime) {
        long currentTime = SystemClock.uptimeMillis();
        final int size = mAnimationCallbacks.size();
        for (int i = 0; i < size; i++) {
            final AnimationFrameCallback callback = mAnimationCallbacks.get(i);

            // `为何会有null？` 请看3 `mAnimationCallbacks` 何时移除元素
            if (callback == null) {
                continue;
            }

            //如果是延迟执行的callback，在未到预定时间时为false
            if (isCallbackDue(callback, currentTime)) {

                // 回调，实际逻辑：android.animation.ValueAnimator#doAnimationFrame
                callback.doAnimationFrame(frameTime);

                // 此处值得再写一篇文章
                if (mCommitCallbacks.contains(callback)) {
                    getProvider().postCommitCallback(new Runnable() {
                        @Override
                        public void run() {
                            commitAnimationFrame(callback, getProvider().getFrameTime());
                        }
                    });
                }
            }
        }
        cleanUpList();
    }

    private void commitAnimationFrame(AnimationFrameCallback callback, long frameTime) {
        if (!mDelayedCallbackStartTime.containsKey(callback) &&
                mCommitCallbacks.contains(callback)) {
            callback.commitAnimationFrame(frameTime);
            mCommitCallbacks.remove(callback);
        }
    }
}

作者按：值得一提的是，AnimationHandler中定义了所谓的 OneShotCommitCallback ，均添加到 mCommitCallbacks中。

ValueAnimator 中曾利用它调整动画起始帧回调

SDK 24 、25 中明确存在，从26直至32均未发现使用。注意，我此次翻阅源码时较为粗略，仍需详查 android.animation.ValueAnimator#addOneShotCommitCallback 方可定论，如有谬误还请读者指出，避免误导。

5，向前看，何人调用FrameCallback

跟进 getProvider().postFrameCallback(mFrameCallback); 发现是暗度陈仓

class AnimationHandler {
    private AnimationFrameCallbackProvider getProvider() {
        if (mProvider == null) {
            mProvider = new MyFrameCallbackProvider();
        }
        return mProvider;
    }

    private class MyFrameCallbackProvider implements AnimationFrameCallbackProvider {

        final Choreographer mChoreographer = Choreographer.getInstance();

        @Override
        public void postFrameCallback(Choreographer.FrameCallback callback) {
            mChoreographer.postFrameCallback(callback);
        }

        @Override
        public void postCommitCallback(Runnable runnable) {
            mChoreographer.postCallback(Choreographer.CALLBACK_COMMIT, runnable, null);
        }

        @Override
        public long getFrameTime() {
            return mChoreographer.getFrameTime();
        }

        @Override
        public long getFrameDelay() {
            return Choreographer.getFrameDelay();
        }

        @Override
        public void setFrameDelay(long delay) {
            Choreographer.setFrameDelay(delay);
        }
    }
}

又见 Choreographer ，这回应该不陌生了，跟进代码：

class Choreographer {
    public void postFrameCallback(FrameCallback callback) {
        postFrameCallbackDelayed(callback, 0);
    }

    public void postFrameCallbackDelayed(FrameCallback callback, long delayMillis) {
        if (callback == null) {
            throw new IllegalArgumentException("callback must not be null");
        }

        postCallbackDelayedInternal(CALLBACK_ANIMATION,
                callback, FRAME_CALLBACK_TOKEN, delayMillis);
    }
}

值得注意的是：此次使用的是：CALLBACK_ANIMATION

Choreographer 中将Callback一共 分为5类

• CALLBACK_INPUT = 0;
• CALLBACK_ANIMATION = 1;
• CALLBACK_INSETS_ANIMATION = 2;
• CALLBACK_TRAVERSAL = 3;
• CALLBACK_COMMIT = 4;

回调时的顺序也是如此。

读者诸君可还记得前文给出的 基于消息机制处理UI绘制 的关键流程图？其中多次出现关键字样：TRAVERSAL，对应此处的 CALLBACK_TRAVERSAL，它负责界面布局和绘制相关的业务。

而在上文 View#scheduleDrawable 的分析中，发现它使用的类型为：Choreographer.CALLBACK_ANIMATION，和 Animator 是一致的！

至此，我们悬着的心可以放下，Animator 和 View#scheduleDrawable 相比，使用了同样的底层机制

但是我们的疑问尚未得到答案，再顺着整个流程向后看。

6，向后看，ValueAnimator#doAnimationFrame

作者按，以API25之后的源码解析，以下源码为API30，注意24之前、24&25，均存在差异，主要体现为首帧的开始。省略部分不重要的源码细节

不难发现，重点部分为：animateBasedOnTime(currentTime)

class ValueAnimator {
    public final boolean doAnimationFrame(long frameTime) {
        if (mStartTime < 0) {
            // First frame. If there is start delay, start delay count down will happen *after* this
            // frame.
            mStartTime = mReversing
                    ? frameTime
                    : frameTime + (long) (mStartDelay * resolveDurationScale());
        }

        // Handle pause/resume
        //省略 暂停、恢复的处理

        if (!mRunning) {
            //省略，判断是否可以开始播放首帧
        }

        if (mLastFrameTime < 0) {
            //省略，处理动画是否seek的情况
        }
        mLastFrameTime = frameTime;

        // The frame time might be before the start time during the first frame of
        // an animation.  The "current time" must always be on or after the start
        // time to avoid animating frames at negative time intervals.  In practice, this
        // is very rare and only happens when seeking backwards.
        final long currentTime = Math.max(frameTime, mStartTime);

        //此处为重点
        boolean finished = animateBasedOnTime(currentTime);

        //完毕的处理
        if (finished) {
            endAnimation();
        }
        return finished;
    }
}

继续抓住重点：animateBasedOnTime(currentTime)

class ValueAnimator {
    boolean animateBasedOnTime(long currentTime) {
        boolean done = false;
        if (mRunning) {
            //确定lastFraction、fraction
            final long scaledDuration = getScaledDuration();
            
            //差别在这里 
            final float fraction = scaledDuration > 0 ?
                    (float) (currentTime - mStartTime) / scaledDuration : 1f;
            final float lastFraction = mOverallFraction;

            //确定轮播迭代标记
            final boolean newIteration = (int) fraction > (int) lastFraction;
            final boolean lastIterationFinished = (fraction >= mRepeatCount + 1) &&
                    (mRepeatCount != INFINITE);

            // 确定 done
            if (scaledDuration == 0) {
                // 0 duration animator, ignore the repeat count and skip to the end
                done = true;
            } else if (newIteration && !lastIterationFinished) {
                // Time to repeat
                if (mListeners != null) {
                    int numListeners = mListeners.size();
                    for (int i = 0; i < numListeners; ++i) {
                        mListeners.get(i).onAnimationRepeat(this);
                    }
                }
            } else if (lastIterationFinished) {
                done = true;
            }

            //确定fraction 重点1
            mOverallFraction = clampFraction(fraction);
            float currentIterationFraction = getCurrentIterationFraction(
                    mOverallFraction, mReversing);

            //重点2
            animateValue(currentIterationFraction);
        }
        return done;
    }
}

此处有两处重点：

• 确定 currentIterationFraction
• animateValue 执行动画帧

看重点1：泛读即可，主要理解fraction的设计

class ValueAnimator {
    private float clampFraction(float fraction) {
        if (fraction < 0) {
            fraction = 0;
        } else if (mRepeatCount != INFINITE) {
            fraction = Math.min(fraction, mRepeatCount + 1);
        }
        return fraction;
    }

    //重点1 整数部分代表iteration，小数部分代表当前iteration的fraction
    private float getCurrentIterationFraction(float fraction, boolean inReverse) {
        fraction = clampFraction(fraction);
        int iteration = getCurrentIteration(fraction);
        float currentFraction = fraction - iteration;
        return shouldPlayBackward(iteration, inReverse)
                ? 1f - currentFraction
                : currentFraction;
    }

    //依据是fraction和iteration的设计：
    //    Calculates current iteration based on the overall fraction. 
    //    The overall fraction will be in the range of [0, mRepeatCount + 1]. 
    //    Both current iteration and fraction in the current iteration can be derived from it.
    private int getCurrentIteration(float fraction) {
        fraction = clampFraction(fraction);
        // If the overall fraction is a positive integer, we consider the current iteration to be
        // complete. In other words, the fraction for the current iteration would be 1, and the
        // current iteration would be overall fraction - 1.
        double iteration = Math.floor(fraction);
        if (fraction == iteration && fraction > 0) {
            iteration--;
        }
        return (int) iteration;
    }

    //和动画正向、反向播放有关，可先忽略
    private boolean shouldPlayBackward(int iteration, boolean inReverse) {
        if (iteration > 0 && mRepeatMode == REVERSE &&
                (iteration < (mRepeatCount + 1) || mRepeatCount == INFINITE)) {
            // if we were seeked to some other iteration in a reversing animator,
            // figure out the correct direction to start playing based on the iteration
            if (inReverse) {
                return (iteration % 2) == 0;
            } else {
                return (iteration % 2) != 0;
            }
        } else {
            return inReverse;
        }
    }
}

看重点2：

class ValueAnimator {
    void animateValue(float fraction) {
        //插值器重新计算fraction -- 优雅的设计
        fraction = mInterpolator.getInterpolation(fraction);
        mCurrentFraction = fraction;
        int numValues = mValues.length;
        
        //PropertyValuesHolder 计算value -- 又是一个优雅的设计
        for (int i = 0; i < numValues; ++i) {
            mValues[i].calculateValue(fraction);
        }
        
        //回调，onAnimationUpdate 常用到 getAnimatedValue，和 calculateValue 对应
        if (mUpdateListeners != null) {
            int numListeners = mUpdateListeners.size();
            for (int i = 0; i < numListeners; ++i) {
                mUpdateListeners.get(i).onAnimationUpdate(this);
            }
        }
    }
}

阶段性小结

源码内容着实很多，经过刚才的源码重点拆解，也已梳理出大致流程。

回归到我们阅读源码前的问题：

Animator 是否和scheduleDrawable相比使用了不一样的底层机制？

否, 均使用了 Choreographer [ˌkɔːriˈɑːɡrəfər],记住它的读写 + Vsync + Android 消息机制 ，且回调类型一致，均为 CALLBACK_ANIMATION

为何更加丝滑？

动画内部调用频次 ≥ 原方案，回调时依据时间计算帧号的算法更加准确合理

ValueAnimator#animateBasedOnTime 中，使用了准确、合理的计算方式 ：final float fraction = scaledDuration > 0 ? (float) (currentTime - mStartTime) / scaledDuration : 1f;

而先前文章中的代码，并没有依据当前实际时间调整帧。

思变：打开思路

至此，动画的核心奥秘已经揭开，似乎一切已尽在不言中，轮子也均已完备，也并不需要再额外实现一套插值器、估值器逻辑。

既然如此，我们不再对第一篇中的例子进行以下改进："依据时间调整帧"，"提升回调频率"。

作者按：如果下次计划写插值器、估值器的文章，可能以逐步完善造轮子的方式进行内容展开

那么本篇的核心内容，除了面试或者给同事科普外，还能带来什么呢？

整体回顾一下，并打开思路：

1. 我们从一个实例出发进行完善，并收获一个经验：可以通过 Drawable+Animator，将动画内容推广到任意View做显示，如果没有必要，可以少做一些自定义View的事情。
2. 分析了Drawable更新内容的底层实现，是否可以将这种动画效果推广到更多地方呢？例如 TextView的DrawableStart、ImageSpan，是否都能正确显示动效呢？，如果不能要怎么做？
3. 我们分析动画被驱动的过程中，遇到一个宝藏 Choreographer，是否可以拿来干点有趣的事情？例如：FPS监测
4. 将ValueAnimator的核心机制复刻，在别的平台搞点好玩的东西😂
5. 在视觉呈现内容 与 时间 的函数关系确定时，使用 ValueAnimator 作为核心驱动，将问题变为一个纯数学问题，例如 点迹动效绘制，全景图锚点A到锚点B之间的渐变
6. 融合以上内容，自定义一套数据协议，解析后，所见皆可动起来

闲话一二

文中出现的源码，除去AOSP部分，均收录于仓库中：DrawableWorkShop

最近还处于瓶颈之中，我花了大约半年的时间，让自己 "慢" 下来，却还没有做到真正松弛下来，礼记中言："张而不弛，文武弗能也；弛而不张，文武弗为也；一张一弛，文武之道也。"

有两个方面的瓶颈，让我颇为难受：

• "输出质量的高期望" 与 "输入、知识体系存货达不到更高层次" 之间的矛盾带来的内容瓶颈
• "不同读者需要的知识深度不同" 与 "博客内容提纲不能照顾到各个深度" 之间的矛盾带来的编写瓶颈

我还需要调整好节奏、捋一捋下一个五年，再进行知识重整合，才能先驰后张，输出更有意义的内容，这能解决第一个瓶颈问题。但第二个瓶颈问题，确实没找到办法。

好玩系列：让ImageSpan动起来

前言

前不久，我写过一篇文章：迟来的续集--Drawable+Animator，将优雅进行到底 , 并在其中留下一个思考题：" 用 动画Drawable 是否可以让 ImageSpan 直接动起来"

相信大家也进行了尝试，并且不出意外地出现了意外！即便使用可以动起来的Drawable构建ImageSpan，也没有让他动起来！

今天我们将在一个愉快的氛围下，让ImageSpan动起来，并进行一些更深层次的探索，不出意外，这将是Drawable相关文章的终结篇。

另外，有几篇相关文章可以作为扩展阅读：

• 三思系列：重新认识Drawable
• 三思系列：为什么要自定义View

是否用得上

"学而时习之，不亦说乎" -- 《论语-学而》

Span是Android中实现富文本的一种方式，读者诸君请注意，是一种方式而不是唯一方式！ 除却Span机制，依旧有其他形式展现富文本。

但不可否认：Span是非常轻量的一种方式，虽然这种 脱离展示容器的轻量 使得它的设计并不简单， 导致了简单使用它时很方便，重度使用它时 难以如指臂使 ，并会遭遇性能瓶颈。

以Juejin为例，只要我持续创作读者感兴趣的内容，我相信终有一天会解锁Lv10级作者，那么：

"在APP上给我颁发一个会闪烁的徽章，并追加在昵称后，以显示身份"，包括不限于：我的主页、文章作者栏、评论区、文章中 @我 的地方

这个功能似乎很合情合理😆。

用ImageSpan方案实现这一需求也很合理，并且这一解析、展示方案可以多处复用，并不需要四处精心维护布局。虽然juejin并未这样做😂

简单盘算后，今天的知识一定有使用的前景，稳赚不亏！

制造一个翻车现场

还是借助先前的项目：DrawableWorkShop ，先制作一个翻车现场。

在上一篇文章中，我们已经完成了动画Drawable，正好利用它生成ImageSpan。我们再增加DrawableStart 用作对比。

关键代码如下：

val tvSpan = findViewById<TextView>(R.id.tv_span)

val drawable = createADrawable()
val imgSpan = ImageSpan(drawable)

val ss = SpannableString("ImageSpan *")
ss.setSpan(imgSpan, 10, 11, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE)
tvSpan.text = ss

val drawableStart = createADrawable()
tvSpan.setCompoundDrawables(drawableStart, null, null, null)

tvSpan.setOnClickListener {
    drawable.start()
    drawableStart.start()
}

fun createADrawable(): AnimLetterDrawable2 {
    val drawable = AnimLetterDrawable2()
    drawable.textSize = 20f
    drawable.letters = "span"
    drawable.setBounds(0, 0, 100, 100)
    return drawable
}

点击TextView开启动画，好，果然翻车了！ImageSpan并未动起来，而DrawableStart动起来了。

温故而知新 -- 原因分析

在前两篇相关文章中，我们已经窥探到动画的原理：

按照特定的时间序列绘制对应帧，利用视觉暂留形成动画效果

无论是控件的属性动画、还是Drawable动画，其本质均为此。在前两篇文章中，我们分别用了两种方式驱动Drawable形成动画效果，稍作复习：

• 基于 Drawable#scheduleSelf API，向宿主View Post 一个延迟执行的 Runnable 业务逻辑为重新绘制。在Handler消息机制的驱动下, Choreographer 实现了动画基本原理
• 基于 ValueAnimator，按照时序执行回调，业务逻辑为重新绘制。依旧是借助Handler消息机制的驱动, Choreographer 实现动画基本原理。

此时，可以做出大胆的假设：问题本质是没有正确重新绘制。

在前文中，我们已经知道，Drawable重新绘制的核心是 invalidateSelf()：

class Drawable {
    public void invalidateSelf() {
        final Callback callback = getCallback();
        if (callback != null) {
            callback.invalidateDrawable(this);
        }
    }
}

而该API借助了 Drawable.Callback 委托实现。

Debug之后可以发现，配合ImageSpan使用时，Drawable并未持有Callback实例 。

对比参考TextView设置DrawableStart的相关核心代码，忽略掉无关细节，其中调用了 Drawable#setCallback(this) ：

class TextView {
    private void setRelativeDrawablesIfNeeded(Drawable start, Drawable end) {
        boolean hasRelativeDrawables = (start != null) || (end != null);
        if (hasRelativeDrawables) {
            //ignore 
            if (start != null) {
                //ignore

                //重点
                start.setCallback(this);

                //ignore
            } else {
                dr.mDrawableSizeStart = dr.mDrawableHeightStart = 0;
            }
            if (end != null) {
                //ignore
                end.setCallback(this);

                //ignore
            } else {
                dr.mDrawableSizeEnd = dr.mDrawableHeightEnd = 0;
            }
            //ignore
        }
    }
}

至此，推测得到验证。

直面问题 -- 以最简单的代码让ImageSpan动起来

才思敏捷的读者可能已经想到，给ImageSpan内部的Drawable设置Callback不就可以了吗？就像这样：

 tvSpan.setOnClickListener {
    //设置Callback
    drawable.callback = it

    drawable.start()
    //屏蔽掉DrawableStart的干扰
    // drawableStart.start()
}

当你自信满满的尝试了一下，哎呀，又TM翻车了！！！

翻车原因

让我们再复习一下：

public class View {
    public void invalidateDrawable(@NonNull Drawable drawable) {
        //看这里的校验
        if (verifyDrawable(drawable)) {
            final Rect dirty = drawable.getDirtyBounds();
            final int scrollX = mScrollX;
            final int scrollY = mScrollY;

            //这里是刷新
            invalidate(dirty.left + scrollX, dirty.top + scrollY,
                    dirty.right + scrollX, dirty.bottom + scrollY);
            rebuildOutline();
        }
    }

    protected boolean verifyDrawable(@NonNull Drawable who) {
        // Avoid verifying the scroll bar drawable so that we don't end up in
        // an invalidation loop. This effectively prevents the scroll bar
        // drawable from triggering invalidations and scheduling runnables.
        return who == mBackground || (mForegroundInfo != null && mForegroundInfo.mDrawable == who)
                || (mDefaultFocusHighlight == who);
    }
}

很显然，ImageSpan内包含的Drawable和TextView之间并无直接关联！

注意,TextView的判断逻辑存在重载，仅背景、聚焦效果、DrawableStart、DrawableTop、DrawableEnd、DrawableBottom 是有关联的：

class TextView {
    protected boolean verifyDrawable(@NonNull Drawable who) {
        final boolean verified = super.verifyDrawable(who);
        if (!verified && mDrawables != null) {
            for (Drawable dr : mDrawables.mShowing) {
                if (who == dr) {
                    return true;
                }
            }
        }
        return verified;
    }
}

暗度陈仓，绕过校验

才思敏捷的读者朋友一定想到了："既然是校验出的问题，那我绕过校验不就好了"，很快掏出了代码V2：

tvSpan.setOnClickListener {
//            drawable.callback = it //这种方式无效，Drawable和TextView之间无关联
    drawable.callback = object : Drawable.Callback {
        override fun invalidateDrawable(who: Drawable) {
            //直接刷，绕过校验
            it.invalidate()
        }

        override fun scheduleDrawable(who: Drawable, what: Runnable, `when`: Long) {
            it.scheduleDrawable(who, what, `when`)
        }

        override fun unscheduleDrawable(who: Drawable, what: Runnable) {
            it.unscheduleDrawable(who, what)
        }

    }
    drawable.start()
//            drawableStart.start()
}

果然，它动起来了！

作者按：让ImageSpan动起来的核心知识，到此已经结束，但知识的探索还未结束，下面将打开Span世界的大门

优雅，永恒的追求

我一直追求编程中的一种优雅：

• 复杂度按必要程度分层展开，避免 没有必要的详细导致难以理解的复杂
• 井然有序，当代码不得不做出改变时，不因代码间没必要的耦合，加大变化难度

而我们目前面对的问题，恰恰就是一个好机会，可以顺势研究源码，汲取知识，在此基础上，封装代码，更优雅地解决问题；并且在研究的过程中，可以摸索到其它知识模块。

这恰好可以通往第三境 对于 人生追求三境 ，我会在下一个杂篇和读者们交流一下心得

直接使用会带来的问题

1.虽然有效，但耦合过重，业务代码中不得不暴露过多无关代码

我们已经使ImageSpan动起来了，那我多搞几个动态徽章没有问题吧。

将核心代码复刻，很快就得到了以下代码

val tvSpan2 = findViewById<TextView>(R.id.tv_span2)
val infoBuilder = SpannableStringBuilder().append("Leobert")

val madels = arrayListOf<String>("Lv.10", "持续创造", "笔耕不追", "夜以继日")
val drawables: List<AnimLetterDrawable2> = madels.map { madel ->
    appendMadel(infoBuilder, madel).let { drawable ->
        drawable.callback = object : Drawable.Callback {
            override fun invalidateDrawable(who: Drawable) {
                tvSpan2.invalidate()
            }
            //ignore
        }
        drawable
    }
}

tvSpan2.text = infoBuilder
tvSpan2.setOnClickListener {
    drawables.forEach {
        it.start()
    }
}

fun appendMadel(builder: SpannableStringBuilder, madel: String): AnimLetterDrawable2 {
    val drawable = AnimLetterDrawable2()
    //ignore

    val imgSpan = ImageSpan(drawable)
    val ss = SpannableString(" *")
    ss.setSpan(imgSpan, 1, 2, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE)
    builder.append(ss)

    //ignore，追加了一处ClickSpan，可以直观观测点击触发

    return drawable
}

您已经发现，为了让功能有效，我们不得不小心的设置回调，一旦有所疏漏，就会带来Bug。

务必注意，仅用于显示时，我们尚可以说服自己不负责任地忽略 "不移除回调" 带来的负面影响，诸如无效刷新、内存泄露。

而在编辑时（如EditText中使用，并删除图片）、以及RecycleView中TextView复用（推广到可替换呈现内容的情况） 则不得不移除回调。否则轻则造成性能损耗和内存泄露，重则立现 UI bug。

可以想象，这样的代码太过于丑陋，过多的无关代码暴露在业务实现中。

2.影响复用

Callback的唯一性导致ImageSpan不能被有效复用，还需要进行一定的改造。

虽然在理论上已经推断出这种做法会影响Drawable复用（以及Span的复用、进一步推广到Spannable的复用），仍旧以代码验证一下推论：

val tvSpan3 = findViewById<TextView>(R.id.tv_span3)
// 沿用上文中构建的Spannable，它已经通过Callback和tvSpan2高度耦合，
// 我们希望这样的代码就可以完成目标，但显然目前无法完成
tvSpan3.text = infoBuilder
tvSpan3.setOnClickListener {
    drawables.forEach {
        it.start()
    }
}
tvSpan3.movementMethod = LinkMovementMethod.getInstance()

读者诸君可使用WorkShop自行尝试，不出意外的翻车了吧。

1.解决Callback对复用的限制

显然，我们无法修改SDK的内容，但可以使用组合模式。

先定义一个回调接口，依赖抽象以解耦。

interface OnRefreshListener {
    /**
     * will be called when a inner drawable of the span want to invalidate.
     *
     * @return true if the listener want to be called in future.
     * false otherwise
     */
    fun onRefresh(): Boolean
}

定义组合，仍旧以接口定义，以提升灵活度：

interface OnRefreshListeners : OnRefreshListener {
    fun addRefreshListener(callback: OnRefreshListener)
    fun removeRefreshListener(callback: OnRefreshListener)
}

我们可以顺其自然的定义一个组合Callback实现如下：

class DrawableCallbackComposer : OnRefreshListeners, Drawable.Callback {
    private val mRefreshListeners: MutableCollection<OnRefreshListener> = mutableListOf()

    override fun addRefreshListener(callback: OnRefreshListener) {
        mRefreshListeners.add(callback)
    }

    override fun removeRefreshListener(callback: OnRefreshListener) {
        mRefreshListeners.remove(callback)
    }

    override fun onRefresh(): Boolean {
        val stillActivatedAfterRefresh = mRefreshListeners.filter {
            it.onRefresh()
        }
        mRefreshListeners.clear()
        mRefreshListeners.addAll(stillActivatedAfterRefresh)
        return true
    }

    override fun unscheduleDrawable(who: Drawable, what: Runnable) {
    }

    override fun invalidateDrawable(who: Drawable) {
        onRefresh()
    }

    override fun scheduleDrawable(who: Drawable, what: Runnable, `when`: Long) {
    }
}

接下来就可以使用 DrawableCallbackComposer 来扩展复用度，但显然，我们并不愿意到处裸露 DrawableCallbackComposer 的操作，继续考虑封装和隐藏。

2.李代桃僵，利用代理

如果我们拥有一个代理层，它帮助 Drawable 处理 DrawableCallbackComposer 的 子节点 OnRefreshListener 注册与解注册，并且最终表现为一个 Drawable，那么 裸露的控制代码 将替换为简单的 依赖注入中的实例提供

基于接口的灵活性，我们可以顺其自然的定义如下 DrawableProxy 类。

它能够直接代理原Drawable关于绘制的全部内容，又追加了 使用 DrawableCallbackComposer 和 回调注册解注册的必要控制逻辑

class DrawableProxy
@JvmOverloads constructor(
    proxy: Drawable? = null,
    private val drawableCallbackComposer: DrawableCallbackComposer = DrawableCallbackComposer()
) : Drawable(),
    ResizeDrawable,
    Drawable.Callback by drawableCallbackComposer,
    OnRefreshListeners by drawableCallbackComposer {

    private var proxySafety: Drawable = proxy?.also { it.callback = drawableCallbackComposer } ?: this
        set(drawable) {
            field.callback = null
            drawable.callback = drawableCallbackComposer
            field = drawable
            needResize = true
            invalidateDrawable(this)
        }

    fun setProxy(drawable: Drawable) {
        this.proxySafety = drawable
    }

    fun clearProxy() {
        this.proxySafety = this
    }

    override var needResize: Boolean = false

    /*以下是代理实现，无需过度关心*/

    override fun getIntrinsicWidth(): Int {
        return proxySafety.intrinsicWidth
    }

    override fun getIntrinsicHeight(): Int {
        return proxySafety.intrinsicHeight
    }

    override fun draw(canvas: Canvas) {
        proxySafety.draw(canvas)
    }

    override fun setAlpha(alpha: Int) {
        proxySafety.alpha = alpha
    }

    override fun setColorFilter(cf: ColorFilter?) {
        proxySafety.colorFilter = cf
    }

    override fun getOpacity(): Int {
        return proxySafety.opacity
    }

    override fun onBoundsChange(bounds: Rect) {
        super.onBoundsChange(bounds)
        needResize = false
    }

    override fun setBounds(bounds: Rect) {
        super.setBounds(bounds)
        proxySafety.bounds = bounds
    }

    override fun setBounds(left: Int, top: Int, right: Int, bottom: Int) {
        super.setBounds(left, top, right, bottom)
        proxySafety.setBounds(left, top, right, bottom)
    }

}

至此，我们将使用DrawableProxy 替代原先的 AnimDrawable,用以构建Span实例。

接下来可以将注意力转移到："实现、添加 OnRefreshListener"，通过调用宿主TextView的刷新，显示动画帧。

继续使用SpanWatcher解放双手

行至此处，您一定不甘心再在业务代码中裸露此类控制代码：

drawable?.addRefreshListener(object : OnRefreshListener {
    override fun onRefresh(): Boolean {
        //ignore 诸如生命周期断定 。。。
        view.invalidate()
        return true
    }
})

哪怕您将它封装成一个静态API以供业务代码中调用，也难以达到您对 追求"优雅" 的要求底线了。

而SDK中已经确定了这位天选打工人 SpanWatcher，看一下它的定义：

/**
 * When an object of this type is attached to a Spannable,
 * its methods will be called to notify it that other 
 * markup objects have been added, changed, or removed.
 * */

翻译如下：

当 SpanWatcher 类型的实例被添加到 Spannable 之后，一旦发生 （Span）标记被 添加、改变、移除时， 实例相应的 API方法 会被调用，起到通知效果。

藉此，我们可以顺其自然地简化处理回调的注册与解注册

读者诸君，此时还请再想一想，它能完美的解决问题吗？

class AnimImageSpanWatcher(view: View) : SpanWatcher, OnRefreshListener {
    private var mLastRefreshStamp: Long = 0
    private val mViewWeakReference: WeakReference<View> = WeakReference(view)

    override fun onSpanAdded(text: Spannable, what: Any, start: Int, end: Int) {
        if (what is RefreshSpan) {
            val drawable = what.getInvalidateDrawable()
            drawable?.addRefreshListener(this)
        }
    }

    override fun onSpanRemoved(text: Spannable, what: Any, start: Int, end: Int) {
        if (what is RefreshSpan) {
            val drawable = what.getInvalidateDrawable()
            drawable?.removeRefreshListener(this)
        }
    }

    override fun onSpanChanged(text: Spannable, what: Any, ostart: Int, oend: Int, nstart: Int, nend: Int) {

    }

    override fun onRefresh(): Boolean {
        val view = mViewWeakReference.get() ?: return false

        //ignore 生命周期有效性判断

        val currentTime = System.currentTimeMillis()
        //加一层过滤，避免刷新过于频繁
        if (currentTime - mLastRefreshStamp > REFRESH_INTERVAL) {
            mLastRefreshStamp = currentTime
            view.invalidate()
        }
        return true
    }

    companion object {
        private const val REFRESH_INTERVAL = 60
    }
}

作者按：感谢 长安皈故里 的提醒，我遗漏了部分代码。

interface RefreshSpan {
    fun getInvalidateDrawable(): OnRefreshListeners?
}

行至此处，还剩下关键的一步：借助TextView自身的机制，让这些类正常工作！

使用 Spannable.Factory 梦幻联动

不清楚读者诸君是否 精心研读 过 TextView 的源码，当然，本篇并不打算展开分析，TextView 中有一个API：

class TextView {
    /**
     * Sets the Factory used to create new Spannable
     */
    public final void setSpannableFactory(Spannable.Factory factory) {
        mSpannableFactory = factory;
        setText(mText);
    }
}

通过API实现，您可以发现，它会重新调用 setText API，并利用该 Factory 创建用于显示的 Spannable

Spannable.Factory：

/**
 * Factory used by TextView to create new Spannables.
 * You can subclass it to provide something other than SpannableString.
 */
public static class Factory {
    //ignore

    /**
     * Returns a new SpannableString from the specified CharSequence.
     * You can override this to provide a different kind of Spannable.
     */
    public Spannable newSpannable(CharSequence source) {
        return new SpannableString(source);
    }
}

值得注意：

设计Spannable的拷贝时，理所当然存在一些Span不希望被拷贝，于是设计有该机制，实现 NoCopySpan 的标记（span）不会被拷贝

于是，可实现类似如下工厂类，完成最后的联动。

class CustomSpannableFactory(private val mNoCopySpans: List<NoCopySpan>) : Spannable.Factory() {

    override fun newSpannable(source: CharSequence): Spannable {
        val spannableStringBuilder = SpannableStringBuilder()
        mNoCopySpans.forEach {
            spannableStringBuilder.setSpan(
                it, 0, 0,
                Spanned.SPAN_INCLUSIVE_INCLUSIVE or Spanned.SPAN_PRIORITY
            )
        }
        spannableStringBuilder.append(source)
        return spannableStringBuilder
    }
}

最终，以伪代码实现展现调用细节如下：

val tvSpan = findViewById<TextView>(R.id.tv_span)

//第一部分
//如上文，创建一个动画Drawable
val drawable = createADrawable()
//基于代理，利用它简化Drawable.Callback的处理
val proxyDrawable = DrawableProxy(drawable)
//您可以认为这就是一个实现了RefreshSpan的ImageSpan，
//内部做了等高处理等，这些和文章主题无关，简要代码附于下文
val imgSpan = AnimIsohypseImageSpan(proxyDrawable)

//第二部分
//构建一个演示用的Spannable
val ss = SpannableString("ImageSpan *")
ss.setSpan(imgSpan, 10, 11, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE)
tvSpan.text = ss

//第三部分
//使用Watcher简化回调设置
val watchers = ArrayList<NoCopySpan>()
watchers.add(AnimImageSpanWatcher(tvSpan))
//使用自定义Factory实现联动
tvSpan.setSpannableFactory(CustomSpannableFactory(watchers))

//演示手动触发动画
tvSpan.setOnClickListener {
    drawable.start()
}

作者按：感谢 长安皈故里 的提醒，我遗漏了部分代码。

另外还有一部分代码，仅用于参考，读者诸君需要结合自身项目实际情况进行类簇的扩展

//DrawableProxy中用到
interface ResizeDrawable {
    var needResize: Boolean
}

interface IntegratedSpan

//等高
open class IsohypseImageSpan : ImageSpan, IntegratedSpan {
    //构造器和等高计算、绘制等略

    open fun getResizedDrawable(): Drawable {
        val d = drawable
        if (drawableHeight == 0) {
            return d
        }
        if (!resized) {
            resized = true
            d.bounds = Rect(
                0, 0,
                (1f * drawableHeight.toFloat() * d.intrinsicWidth.toFloat() / d.intrinsicHeight).toInt(),
                drawableHeight
            )
        }
        return d
    }
}

//配合自定义的SpanWatcher
open class AnimIsohypseImageSpan : IsohypseImageSpan, RefreshSpan {
    //构造器略

    override fun getInvalidateDrawable(): OnRefreshListeners? {
        val d = getResizedDrawable()
        return if (d is OnRefreshListeners) {
            d
        } else {
            null
        }
    }
}

//用于有重计算高度的需求
class ResizeIsoheightImageSpan : AnimIsohypseImageSpan, RefreshSpan {
    //构造器略

    override fun getResizedDrawable(): Drawable {
        val d = drawable
        if (drawableHeight == 0) {
            return d
        }
        if (d is ResizeDrawable && (d.needResize || !resized)) {
            resizeSpan(d)
        } else if (!resized) {
            resizeSpan(d)
        }
        return d
    }

    private fun resizeSpan(d: Drawable) {
        resized = true
        d.bounds = Rect(0, 0,
                (1f * drawableHeight * d.intrinsicWidth / d.intrinsicHeight).toInt(),
                drawableHeight)
    }
}

实际上，在工程中应用时：

• 第一部分我们会使用工厂类+依赖注入工具，在业务层屏蔽掉细节
• 第二部分略，如何构建Spannable并在业务层屏蔽该细节与本文无关
• 第三部分也可以屏蔽掉一些细节

可以想象的到，业务层变得纯粹了，而组件的 Ability 层（这是笔者自行杜撰的命名，用于描述自定义的控件、及其拓展功能的类）也会非常干净，均可以做到依赖抽象，按需使用，简化耦合。

敲响警钟

一般来说，文章写到这，基本是结束的节奏，可能您也憋了好长一口气才看到这里，想着可以缓一口气了。

然而有个坏消息不得不告诉您：其实问题并没有完全解决！

回顾一下前文，有这样一段：

务必注意，仅用于显示时，我们尚可以说服自己不负责任地忽略 "不移除回调" 带来的负面影响，诸如无效刷新、内存泄露。

而在编辑时（如EditText中使用，并删除图片）、以及RecycleView中TextView复用（推广到可替换呈现内容的情况） 则不得不移除回调。否则轻则造成性能损耗和内存泄露，重则立现 UI bug。

我们已经解决了一部分问题：

• 简化注册回调，让Spannable可以被多个View有效复用，展现出动画。并且在工程性问题上做的不错。
• 移除Span时，对回调进行解注册。可回看 AnimImageSpanWatcher 代码
• 使用者认为自身不再需要被回调更新时，解除回调。可回看 OnRefreshListener 代码，注意，该情况完全交给业务管控。
• 弱引用，不妨碍使用者及宿主Activity被回收
• 等

但有一个重要的问题：RecycleView中TextView复用（推广到可替换呈现内容的情况）没有考虑。

作者按：注意，EditText在编辑时的特性、选中特性、Span机制本身的特性问题，没有在本篇中展开。这不代表它们不存在！

持续思考&非常重要的结语

作者按：本篇的篇幅已经很长了，所以还请没有看过瘾的读者们见谅，考虑到大多数读者的阅读感受，我们需要在此结束了

但尚遗留3个问题需要持续思考：

1. RecycleView中，控件复用了，问题该如何解决？

当然，我们可以简化问题模型，用 RecycleView中TextView复用 来表现太重了，我们可以简化为：

一个TextView展现 Spannable-A，随后展现 Spannable-B，

2. 使用EditText编辑时，是否会有新的问题，例如：删除时先选中的需求，删除完之后，又应当如何解决
3. 以上做法已经是最优了吗？还能不能继续优化

因为我认为以上代码尚存在优化空间，并且推测您的项目中已经使用了Span机制的扩展以实现某些需求；

而我尚不打算花费大量的时间编写用于兼容用途的功能类。所以我并未将这部分代码传入仓库，避免您直接当做库项目使用，导致原功能模块不可用。

如果您很迫切的需要将其移植到项目中，文中的代码已经涵盖所有重点，但请务必自行测试相关功能模块，做好兼容工作。

Android 消息机制

三思系列：Android的消息机制，一文吃透

三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，关于三思系列

这次，真的可以一文吃透：

• Java层消息队列的设计
• Java层Looper分发
• Native层消息队列和Java层消息队列的关系
• Native层Looper分发
• 消息
• epoll

前言

作为Android中 至关重要 的机制之一，十多年来，分析它的文章不断，大量的内容已经被挖掘过了。所以：

• 已经对这一机制比较 熟稔 的读者，在这篇文章中，看不到 新东西 了。
• 还不太熟悉消息机制的读者，可以在文章的基础上，继续挖一挖。

但是，经过简单的检索和分析，大部分 的文章是围绕：

• Handler，Looper，MQ的关系
• 上层的Handler，Looper、MQ 源码分析

展开的。单纯的从这些角度学习的话，并不能 完全理解 消息机制。

这篇文章本质还是 一次脑暴 ，一来 避免脑暴跑偏 ，二来帮助读者 捋清内容脉络 。先放出脑图：

脑暴：OS解决进程间通信问题

程序世界中，存在着大量的 通信 场景。搜索我们的知识，解决 进程间通信 问题有以下几种方式：

这段内容可以泛读，了解就行，不影响往下阅读

• 管道

  • 普通管道pipe：一种 半双工 的通信方式，数据只能 单向流动 ，而且只能在具有 亲缘关系 的进程间使用。
  • 命令流管道s_pipe: 全双工，可以同时双向传输
  • 命名管道FIFO：半双工 的通信方式，允许 在 无亲缘关系 的进程间通信。

• 消息队列 MessageQueue：

消息的链表，存放在内核 中 并由 消息队列标识符 标识。 消息队列克服了 信号传递信息少、管道 只能承载 无格式字节流 以及 缓冲区大小受限 等缺点。

• 共享存储 SharedMemory：

映射一段 能被其他进程所访问 的内存，这段共享内存由 一个进程创建，但 多个进程都可以访问。 共享内存是 最快的 IPC 方式，它是针对 其他 进程间通信方式 运行效率低 而专门设计的。 往往与其他通信机制一同使用，如 信号量 配合使用，来实现进程间的同步和通信。

• 信号量 Semaphore：

是一个 计数器 ，可以用来控制多个进程对共享资源的访问。它常作为一种 锁机制，防止某进程正在访问共享资源时， 其他进程也访问该资源，实现 资源的进程独占。因此，主要作为 进程间 以及 同一进程内线程间 的同步手段。

• 套接字Socket：

与其他通信机制不同的是，它可以 通过网络 ，在 不同机器之间 进行进程通信。

• 信号 signal：

用于通知接收进程 某事件已发生。机制比较复杂。

我们可以想象，Android之间也有大量的 进程间通信场景，OS必须采用 至少一种 机制，以实现进程间通信。

仔细研究下去，我们发现，Android OS用了不止一种方式。而且，Android 还基于 OpenBinder 开发了 Binder 用于 用户空间 内的进程间通信。

关于 为什么不直接使用Linux中现有的进程间通信方式 ，可以看看这篇知乎问答

这篇文章 也简单探讨了 "内核空间内的消息队列"

这里我们留一个问题以后探究：

Android 有没有使用 Linux内核中的MessageQueue机制 干事情

基于消息队列的消息机制设计有很多优势，Android 在很多通信场景内，采用了这一设计思路。

消息机制的三要素

不管在哪，我们谈到消息机制，都会有这三个要素：

• 消息队列
• 消息循环（分发）
• 消息处理

消息队列 ，是 消息对象 的队列，基本规则是 FIFO。

消息循环（分发）， 基本是通用的机制，利用 死循环 不断的取出消息队列头部的消息，派发执行

消息处理，这里不得不提到 消息 有两种形式：

• Enrichment 自身信息完备
• Query-Back 自身信息不完备，需要回查

这两者的取舍，主要看系统中 生成消息的开销 和 回查信息的开销 两者的博弈。

在信息完备后，接收者即可处理消息。

Android Framework中的消息队列

Android 的Framework中的消息队列有两个：

• Java层 frameworks/base/core/java/android/os/MessageQueue.java
• Native层 frameworks/base/core/jni/android_os_MessageQueue.cpp

Java层的MQ并不是 List 或者 Queue 之类的 Jdk内的数据结构实现。

Native层的源码我下载了一份 Android 10 的 源码 ，并不长，大家可以完整的读一读。

并不难理解：用户空间 会接收到来自 内核空间 的 消息 ， 从 下图 我们可知，这部分消息先被 Native层 获知，所以：

• 通过 Native层 建立消息队列，它拥有消息队列的各种基本能力
• 利用JNI 打通 Java层 和 Native层 的 Runtime屏障，在Java层 映射 出消息队列
• 应用建立在Java层之上，在Java层中实现消息的 分发 和 处理

PS：在Android 2.3那个时代，消息队列的实现是在Java层的，至于10年前为何改成了 native实现， 推测和CPU空转有关，笔者没有继续探究下去，如果有读者了解，希望可以留言帮我解惑。

PS:还有一张经典的 系统启动架构图 没有找到，这张图更加直观

代码解析

我们简单的 阅读、分析 下Native中的MQ源码

Native层消息队列的创建：

static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
    NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
    if (!nativeMessageQueue) {
        jniThrowRuntimeException(env, "Unable to allocate native queue");
        return 0;
    }

    nativeMessageQueue->incStrong(env);
    return reinterpret_cast<jlong>(nativeMessageQueue);
}

很简单，创建一个Native层的消息队列，如果创建失败，抛异常信息,返回0，否则将指针转换为Java的long型值返回。当然，会被Java层的MQ所持有。

NativeMessageQueue 类的构造函数

NativeMessageQueue::NativeMessageQueue() :
        mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {
    mLooper = Looper::getForThread();
    if (mLooper == NULL) {
        mLooper = new Looper(false);
        Looper::setForThread(mLooper);
    }
}

这里的Looper是native层Looper，通过静态方法 Looper::getForThread() 获取对象实例，如果未获取到，则创建实例，并通过静态方法设置。

看一下Java层MQ中会使用到的native方法

class MessageQueue {
    private long mPtr; // used by native code

    private native static long nativeInit();

    private native static void nativeDestroy(long ptr);

    private native void nativePollOnce(long ptr, int timeoutMillis); /*non-static for callbacks*/

    private native static void nativeWake(long ptr);

    private native static boolean nativeIsPolling(long ptr);

    private native static void nativeSetFileDescriptorEvents(long ptr, int fd, int events);
}

对应签名：

static const JNINativeMethod gMessageQueueMethods[] = {
    /* name, signature, funcPtr */
    { "nativeInit", "()J", (void*)android_os_MessageQueue_nativeInit },
    { "nativeDestroy", "(J)V", (void*)android_os_MessageQueue_nativeDestroy },
    { "nativePollOnce", "(JI)V", (void*)android_os_MessageQueue_nativePollOnce },
    { "nativeWake", "(J)V", (void*)android_os_MessageQueue_nativeWake },
    { "nativeIsPolling", "(J)Z", (void*)android_os_MessageQueue_nativeIsPolling },
    { "nativeSetFileDescriptorEvents", "(JII)V",
            (void*)android_os_MessageQueue_nativeSetFileDescriptorEvents },
};

mPtr 是Native层MQ的内存地址在Java层的映射。

Java层判断MQ是否还在工作：

private boolean isPollingLocked() {
    // If the loop is quitting then it must not be idling.
    // We can assume mPtr != 0 when mQuitting is false.
    return !mQuitting && nativeIsPolling(mPtr);
}

static jboolean android_os_MessageQueue_nativeIsPolling(JNIEnv* env, jclass clazz, jlong ptr) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    return nativeMessageQueue->getLooper()->isPolling();
}

/**
 * Returns whether this looper's thread is currently polling for more work to do.
 * This is a good signal that the loop is still alive rather than being stuck
 * handling a callback.  Note that this method is intrinsically racy, since the
 * state of the loop can change before you get the result back.
 */
bool isPolling() const;

唤醒 Native层MQ：

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jlong ptr) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->wake();
}

void NativeMessageQueue::wake() {
    mLooper->wake();
}

Native层Poll：

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
        jlong ptr, jint timeoutMillis) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
    mPollEnv = env;
    mPollObj = pollObj;
    mLooper->pollOnce(timeoutMillis);
    mPollObj = NULL;
    mPollEnv = NULL;

    if (mExceptionObj) {
        env->Throw(mExceptionObj);
        env->DeleteLocalRef(mExceptionObj);
        mExceptionObj = NULL;
    }
}

这里比较重要，我们先大概看下 Native层的Looper是 如何分发消息 的

//Looper.h

int pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData);
inline int pollOnce(int timeoutMillis) {
    return pollOnce(timeoutMillis, NULL, NULL, NULL);
}

//实现

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        while (mResponseIndex < mResponses.size()) {
            const Response& response = mResponses.itemAt(mResponseIndex++);
            int ident = response.request.ident;
            if (ident >= 0) {
                int fd = response.request.fd;
                int events = response.events;
                void* data = response.request.data;
#if DEBUG_POLL_AND_WAKE
                ALOGD("%p ~ pollOnce - returning signalled identifier %d: "
                        "fd=%d, events=0x%x, data=%p",
                        this, ident, fd, events, data);
#endif
                if (outFd != NULL) *outFd = fd;
                if (outEvents != NULL) *outEvents = events;
                if (outData != NULL) *outData = data;
                return ident;
            }
        }

        if (result != 0) {
#if DEBUG_POLL_AND_WAKE
            ALOGD("%p ~ pollOnce - returning result %d", this, result);
#endif
            if (outFd != NULL) *outFd = 0;
            if (outEvents != NULL) *outEvents = 0;
            if (outData != NULL) *outData = NULL;
            return result;
        }

        result = pollInner(timeoutMillis);
    }
}

先处理Native层滞留的Response，然后调用pollInner。这里的细节比较复杂，稍后我们在 Native Looper解析 中进行脑暴。

先于此处细节分析，我们知道，调用一个方法，这是阻塞的 ，用大白话描述即在方法返回前，调用者在 等待。

Java层调动 native void nativePollOnce(long ptr, int timeoutMillis); 过程中是阻塞的。

此时我们再阅读下Java层MQ的消息获取：代码比较长，直接在代码中进行要点注释。

在看之前，我们先单纯从 TDD的角度 思考下，有哪些 主要场景 ：当然，这些场景不一定都合乎Android现有的设计

• 消息队列是否在工作中
  • 工作中，期望返回消息
  • 不工作，期望返回null
• 工作中的消息队列 当前 是否有消息
  • 不存在消息，阻塞 or 返回null？-- 如果返回null，则在外部需要需要 保持空转 或者 唤醒机制，以支持正常运作。从封装角度出发，应当 保持空转，自己解决问题
  • 存在消息
    • 特殊的 内部功能性消息，期望MQ内部自行处理
    • 已经到处理时间的消息， 返回消息
    • 未到处理时间，如果都是排过序的，期望 空转保持阻塞 or 返回静默并设置唤醒？ 按照前面的讨论，是期望 保持空转

class MessageQueue {
    Message next() {
        // Return here if the message loop has already quit and been disposed.
        // This can happen if the application tries to restart a looper after quit
        // which is not supported.
        // 1. 如果 native消息队列指针映射已经为0，即虚引用，说明消息队列已经退出，没有消息了。
        // 则返回 null
        final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }

        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        int nextPollTimeoutMillis = 0;
        
        // 2. 死循环，当为获取到需要 `分发处理` 的消息时，保持空转
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }

            // 3. 调用native层方法，poll message，注意，消息还存在于native层
            nativePollOnce(ptr, nextPollTimeoutMillis);

            synchronized (this) {
                // Try to retrieve the next message.  Return if found.
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
                
                //4. 如果发现 barrier ，即同步屏障，则寻找队列中的下一个可能存在的异步消息
                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
                
                if (msg != null) {
                    // 5. 发现了消息，
                    // 如果是还没有到约定时间的消息，则设置一个 `下次唤醒` 的最大时间差
                    // 否则 `维护单链表信息` 并返回消息
                    
                    if (now < msg.when) {
                        // Next message is not ready.  Set a timeout to wake up when it is ready.
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // 寻找到了 `到处理时间` 的消息。 `维护单链表信息` 并返回消息
                        // Got a message.
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    nextPollTimeoutMillis = -1;
                }

                // 处理 是否需要 停止消息队列                
                // Process the quit message now that all pending messages have been handled.
                if (mQuitting) {
                    dispose();
                    return null;
                }

                // 维护 接下来需要处理的 IDLEHandler 信息，
                // 如果没有 IDLEHandler，则直接进入下一轮消息获取环节
                // 否则处理 IDLEHandler
                // If first time idle, then get the number of idlers to run.
                // Idle handles only run if the queue is empty or if the first message
                // in the queue (possibly a barrier) is due to be handled in the future.
                if (pendingIdleHandlerCount < 0
                        && (mMessages == null || now < mMessages.when)) {
                    pendingIdleHandlerCount = mIdleHandlers.size();
                }
                if (pendingIdleHandlerCount <= 0) {
                    // No idle handlers to run.  Loop and wait some more.
                    mBlocked = true;
                    continue;
                }

                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // 处理 IDLEHandler
            // Run the idle handlers.
            // We only ever reach this code block during the first iteration.
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler

                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            // Reset the idle handler count to 0 so we do not run them again.
            pendingIdleHandlerCount = 0;

            // While calling an idle handler, a new message could have been delivered
            // so go back and look again for a pending message without waiting.
            nextPollTimeoutMillis = 0;
        }
    }
}

Java层压入消息

这就比较简单了，当消息本身合法，且消息队列还在工作中时。 依旧从 TDD角度 出发：

• 如果消息队列没有头，期望直接作为头
• 如果有头
  • 消息处理时间 先于 头消息 或者是需要立即处理的消息，则作为新的头
  • 否则按照 处理时间 插入到合适位置

 boolean enqueueMessage(Message msg, long when) {
        if (msg.target == null) {
            throw new IllegalArgumentException("Message must have a target.");
        }

        synchronized (this) {
            if (msg.isInUse()) {
                throw new IllegalStateException(msg + " This message is already in use.");
            }

            if (mQuitting) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }

            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                // Inserted within the middle of the queue.  Usually we don't have to wake
                // up the event queue unless there is a barrier at the head of the queue
                // and the message is the earliest asynchronous message in the queue.
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            }

            // We can assume mPtr != 0 because mQuitting is false.
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

同步屏障 barrier后面单独脑暴， 其他部分就先不看了

Java层消息分发

这一节开始，我们脑暴消息分发，前面我们已经看过了 MessageQueue ，消息分发就是 不停地 从 MessageQueue 中取出消息，并指派给处理者。 完成这一工作的，是Looper。

在前面，我们已经知道了，Native层也有Looper，但是不难理解：

• 消息队列需要 桥梁 连通 Java层和Native层
• Looper只需要 在自己这一端，处理自己的消息队列分发即可

所以，我们看Java层的消息分发时，看Java层的Looper即可。

关注三个主要方法：

• 出门上班
• 工作
• 下班回家

出门上班 prepare

class Looper {

    public static void prepare() {
        prepare(true);
    }

    private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }
}

这里有两个注意点：

• 已经出了门，除非再进门，否则没法再出门了。同样，一个线程有一个Looper就够了，只要它还活着，就没必要再建一个。
• 责任到人，一个Looper服务于一个Thread，这需要 注册 ，代表着 某个Thread 已经由自己服务了。利用了ThreadLocal，因为多线程访问集合，总需要考虑 竞争，这很不人道主义，干脆分家，每个Thread操作自己的内容互不干扰，也就没有了竞争，于是封装了 ThreadLocal

上班 loop

注意工作性质是 分发，并不需要自己处理

• 没有 注册 自然就找不到负责这份工作的人。
• 已经在工作了就不要催，催了会导致工作出错，顺序出现问题。
• 工作就是不断的取出 老板-- MQ 的 指令 -- Message，并交给 相关负责人 -- Handler 去处理，并记录信息
• 007，不眠不休，当MQ再也不发出消息了，没活干了，大家都散了吧，下班回家

class Looper {
    public static void loop() {
        final Looper me = myLooper();
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        if (me.mInLoop) {
            Slog.w(TAG, "Loop again would have the queued messages be executed"
                    + " before this one completed.");
        }

        me.mInLoop = true;
        final MessageQueue queue = me.mQueue;

        // Make sure the identity of this thread is that of the local process,
        // and keep track of what that identity token actually is.
        Binder.clearCallingIdentity();
        final long ident = Binder.clearCallingIdentity();

        // Allow overriding a threshold with a system prop. e.g.
        // adb shell 'setprop log.looper.1000.main.slow 1 && stop && start'
        final int thresholdOverride =
                SystemProperties.getInt("log.looper."
                        + Process.myUid() + "."
                        + Thread.currentThread().getName()
                        + ".slow", 0);

        boolean slowDeliveryDetected = false;

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            // This must be in a local variable, in case a UI event sets the logger
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }
            // Make sure the observer won't change while processing a transaction.
            final Observer observer = sObserver;

            final long traceTag = me.mTraceTag;
            long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
            long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs;
            if (thresholdOverride > 0) {
                slowDispatchThresholdMs = thresholdOverride;
                slowDeliveryThresholdMs = thresholdOverride;
            }
            final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0);
            final boolean logSlowDispatch = (slowDispatchThresholdMs > 0);

            final boolean needStartTime = logSlowDelivery || logSlowDispatch;
            final boolean needEndTime = logSlowDispatch;

            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }

            final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
            final long dispatchEnd;
            Object token = null;
            if (observer != null) {
                token = observer.messageDispatchStarting();
            }
            long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
            try {
                //注意这里
                msg.target.dispatchMessage(msg);
                if (observer != null) {
                    observer.messageDispatched(token, msg);
                }
                dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
            } catch (Exception exception) {
                if (observer != null) {
                    observer.dispatchingThrewException(token, msg, exception);
                }
                throw exception;
            } finally {
                ThreadLocalWorkSource.restore(origWorkSource);
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }
            if (logSlowDelivery) {
                if (slowDeliveryDetected) {
                    if ((dispatchStart - msg.when) <= 10) {
                        Slog.w(TAG, "Drained");
                        slowDeliveryDetected = false;
                    }
                } else {
                    if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
                            msg)) {
                        // Once we write a slow delivery log, suppress until the queue drains.
                        slowDeliveryDetected = true;
                    }
                }
            }
            if (logSlowDispatch) {
                showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
            }

            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

            // Make sure that during the course of dispatching the
            // identity of the thread wasn't corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"
                        + Long.toHexString(ident) + " to 0x"
                        + Long.toHexString(newIdent) + " while dispatching to "
                        + msg.target.getClass().getName() + " "
                        + msg.callback + " what=" + msg.what);
            }

            msg.recycleUnchecked();
        }
    }
}

下班 quit/quitSafely

这是比较粗暴的行为，MQ离开了Looper就没法正常工作了，即下班即意味着辞职

class Looper {
    public void quit() {
        mQueue.quit(false);
    }
    
    public void quitSafely() {
        mQueue.quit(true);
    }
}

消息处理 Handler

这里就比较清晰了。API基本分为以下几类：

面向使用者：

• 创建Message，通过Message的 享元模式
• 发送消息，注意postRunnable也是一个消息
• 移除消息，
• 退出等

面向消息处理：

class Handler {
    /**
     * Subclasses must implement this to receive messages.
     */
    public void handleMessage(@NonNull Message msg) {
    }

    /**
     * Handle system messages here.
     * Looper分发时调用的API
     */
    public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
}

如果有 Handler callback，则交给callback处理，否则自己处理，如果没覆写 handleMessage ，消息相当于被 drop 了。

消息发送部分可以结合下图梳理：

阶段性小结,至此，我们已经对 Framework层的消息机制 有一个完整的了解了。 前面我们梳理了：

• Native层 和 Java层均有消息队列，并且通过JNI和指针映射，存在对应关系
• Native层 和 Java层MQ 消息获取时的大致过程
• Java层 Looper 如何工作
• Java层 Handler 大致概览

根据前面梳理的内容，可以总结：从 Java Runtime 看：

• 消息队列机制服务于 线程级别，即一个线程有一个工作中的消息队列即可，当然，也可以没有。 即，一个Thread 至多有 一个工作中的Looper。
• Looper 和 Java层MQ 一一对应
• Handler 是MQ的入口，也是 消息 的处理者
• 消息-- Message 应用了 享元模式，自身信息足够，满足 自洽，创建消息的开销性对较大，所以利用享元模式对消息对象进行复用。

下面我们再继续探究细节，解决前面语焉不详处留下的疑惑：

• 消息的类型和本质
• Native层Looper 的pollInner

消息的类型和本质

message中的几个重要成员变量：

class Message {
   
    public int what;
    
    public int arg1;
    
    public int arg2;
    
    public Object obj;

    public Messenger replyTo;

    /*package*/ int flags;
    
    public long when;

    /*package*/ Bundle data;

    /*package*/ Handler target;

    /*package*/ Runnable callback;

}

其中 target是 目标，如果没有目标，那就是一个特殊的消息： 同步屏障 即 barrier；

what 是消息标识 arg1 和 arg2 是开销较小的 数据，如果 不足以表达信息 则可以放入 Bundle data 中。

replyTo 和 obj 是跨进程传递消息时使用的，暂且不看。

flags 是 message 的状态标识，例如 是否在使用中，是否是同步消息

上面提到的同步屏障，即 barrier，其作用是拦截后面的 同步消息 不被获取，在前面阅读Java层MQ的next方法时读到过。

我们还记得，next方法中，使用死循环，尝试读出一个满足处理条件的消息，如果取不到，因为死循环的存在，调用者（Looper）会被一直阻塞。

此时可以印证一个结论，消息按照 功能分类 可以分为 三种：

• 普通消息
• 同步屏障消息
• 异步消息

其中同步消息是一种内部机制。设置屏障之后需要在合适时间取消屏障，否则会导致 普通消息永远无法被处理，而取消时，需要用到设置屏障时返回的token。

Native层Looper

相信大家都对 Native层 的Looper产生兴趣了，想看看它在Native层都干些什么。

对完整源码感兴趣的可以看 这里 ，下面我们节选部分进行阅读。

前面提到了Looper的pollOnce，处理完搁置的Response之后，会调用pollInner获取消息

int Looper::pollInner(int timeoutMillis) {
#if DEBUG_POLL_AND_WAKE
    ALOGD("%p ~ pollOnce - waiting: timeoutMillis=%d", this, timeoutMillis);
#endif

    // Adjust the timeout based on when the next message is due.
    if (timeoutMillis != 0 && mNextMessageUptime != LLONG_MAX) {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        int messageTimeoutMillis = toMillisecondTimeoutDelay(now, mNextMessageUptime);
        if (messageTimeoutMillis >= 0
                && (timeoutMillis < 0 || messageTimeoutMillis < timeoutMillis)) {
            timeoutMillis = messageTimeoutMillis;
        }
#if DEBUG_POLL_AND_WAKE
        ALOGD("%p ~ pollOnce - next message in %lldns, adjusted timeout: timeoutMillis=%d",
                this, mNextMessageUptime - now, timeoutMillis);
#endif
    }

    // Poll.
    int result = ALOOPER_POLL_WAKE;
    mResponses.clear();
    mResponseIndex = 0;

    struct epoll_event eventItems[EPOLL_MAX_EVENTS];
    
    //注意 1
    int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);

    // Acquire lock.
    mLock.lock();

// 注意 2
    // Check for poll error.
    if (eventCount < 0) {
        if (errno == EINTR) {
            goto Done;
        }
        ALOGW("Poll failed with an unexpected error, errno=%d", errno);
        result = ALOOPER_POLL_ERROR;
        goto Done;
    }

// 注意 3
    // Check for poll timeout.
    if (eventCount == 0) {
#if DEBUG_POLL_AND_WAKE
        ALOGD("%p ~ pollOnce - timeout", this);
#endif
        result = ALOOPER_POLL_TIMEOUT;
        goto Done;
    }

//注意 4
    // Handle all events.
#if DEBUG_POLL_AND_WAKE
    ALOGD("%p ~ pollOnce - handling events from %d fds", this, eventCount);
#endif

    for (int i = 0; i < eventCount; i++) {
        int fd = eventItems[i].data.fd;
        uint32_t epollEvents = eventItems[i].events;
        if (fd == mWakeReadPipeFd) {
            if (epollEvents & EPOLLIN) {
                awoken();
            } else {
                ALOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
            }
        } else {
            ssize_t requestIndex = mRequests.indexOfKey(fd);
            if (requestIndex >= 0) {
                int events = 0;
                if (epollEvents & EPOLLIN) events |= ALOOPER_EVENT_INPUT;
                if (epollEvents & EPOLLOUT) events |= ALOOPER_EVENT_OUTPUT;
                if (epollEvents & EPOLLERR) events |= ALOOPER_EVENT_ERROR;
                if (epollEvents & EPOLLHUP) events |= ALOOPER_EVENT_HANGUP;
                pushResponse(events, mRequests.valueAt(requestIndex));
            } else {
                ALOGW("Ignoring unexpected epoll events 0x%x on fd %d that is "
                        "no longer registered.", epollEvents, fd);
            }
        }
    }
Done: ;

// 注意 5
    // Invoke pending message callbacks.
    mNextMessageUptime = LLONG_MAX;
    while (mMessageEnvelopes.size() != 0) {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
        if (messageEnvelope.uptime <= now) {
            // Remove the envelope from the list.
            // We keep a strong reference to the handler until the call to handleMessage
            // finishes.  Then we drop it so that the handler can be deleted *before*
            // we reacquire our lock.
            { // obtain handler
                sp<MessageHandler> handler = messageEnvelope.handler;
                Message message = messageEnvelope.message;
                mMessageEnvelopes.removeAt(0);
                mSendingMessage = true;
                mLock.unlock();

#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
                ALOGD("%p ~ pollOnce - sending message: handler=%p, what=%d",
                        this, handler.get(), message.what);
#endif
                handler->handleMessage(message);
            } // release handler

            mLock.lock();
            mSendingMessage = false;
            result = ALOOPER_POLL_CALLBACK;
        } else {
            // The last message left at the head of the queue determines the next wakeup time.
            mNextMessageUptime = messageEnvelope.uptime;
            break;
        }
    }

    // Release lock.
    mLock.unlock();

//注意 6
    // Invoke all response callbacks.
    for (size_t i = 0; i < mResponses.size(); i++) {
        Response& response = mResponses.editItemAt(i);
        if (response.request.ident == ALOOPER_POLL_CALLBACK) {
            int fd = response.request.fd;
            int events = response.events;
            void* data = response.request.data;
#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
            ALOGD("%p ~ pollOnce - invoking fd event callback %p: fd=%d, events=0x%x, data=%p",
                    this, response.request.callback.get(), fd, events, data);
#endif
            int callbackResult = response.request.callback->handleEvent(fd, events, data);
            if (callbackResult == 0) {
                removeFd(fd);
            }
            // Clear the callback reference in the response structure promptly because we
            // will not clear the response vector itself until the next poll.
            response.request.callback.clear();
            result = ALOOPER_POLL_CALLBACK;
        }
    }
    return result;
}

上面标记了注意点

• 1 epoll机制，等待 mEpollFd 产生事件, 这个等待具有超时时间。
• 2，3，4 是等待的三种结果，goto 语句可以直接跳转到 标记 处
• 2 检测poll 是否出错，如果有，跳转到 Done
• 3 检测pool 是否超时，如果有，跳转到 Done
• 4 处理epoll后所有的事件
• 5 处理 pending 消息的回调
• 6 处理 所有 Response的回调

并且我们可以发现返回的结果有以下几种：

• ALOOPER_POLL_CALLBACK

有 pending message 或者 request.ident 值为 ALOOPER_POLL_CALLBACK 的 Response被处理了。 如果没有：

• ALOOPER_POLL_WAKE 正常唤醒
• ALOOPER_POLL_ERROR epoll错误
• ALOOPER_POLL_TIMEOUT epoll超时

查找了一下枚举值:

ALOOPER_POLL_WAKE = -1,
ALOOPER_POLL_CALLBACK = -2,
ALOOPER_POLL_TIMEOUT = -3,
ALOOPER_POLL_ERROR = -4

阶段性小结, 我们对 消息 和 Native层的pollInner 进行了一次脑暴，引出了epoll机制。

其实Native层的 Looper分发还有不少值得脑暴的点，但我们先缓缓，已经迫不及待的要对 epoll机制进行脑暴了。

##脑暴：Linux中的I/O模型

这部分内容，推荐一篇文章：使用 libevent 和 libev 提高网络应用性能——I/O模型演进变化史 作者 hguisu

PS:本段中，存在部分图片直接引用自该文，我偷了个懒，没有去找原版内容并标记出处

阻塞I/O模型图：在调用recv()函数时，发生在内核中等待数据和复制数据的过程

实现非常的 简单，但是存在一个问题，阻塞导致线程无法执行其他任何计算，如果是在网络编程背景下，需要使用多线程提高处理并发的能力。

注意，不要用 Android中的 点击屏幕等硬件被触发事件 去对应这里的 网络并发，这是两码事。

如果采用了 多进程 或者 多线程 实现 并发应答，模型如下：

到这里，我们看的都是 I/O 阻塞 模型。

脑暴，阻塞为调用方法后一直在等待返回值，线程内执行的内容就像 卡顿 在这里。

如果要消除这种卡顿，那就不能调用方法等待I/O结果，而是要 立即返回 ！

举个例子：

• 去西装店定制西装，确定好款式和尺寸后，你坐在店里一直等着，等到做好了拿给你，这就是阻塞型的，这能等死你；
• 去西装店定制西装，确定好款式和尺寸后，店员告诉你别干等着，好多天呢，等你有空了来看看，这就是非阻塞型的。

改变为非阻塞模型后，应答模型如下：

不难理解，这种方式需要顾客去 轮询 。对客户不友好，但是对店家可是一点损失都没有，还让等候区没那么挤了。

有些西装店进行了改革，对客户更加友好了:

去西装店定制西装，确定好款式和尺寸后，留下联系方式，等西服做好了联系客户，让他来取。

这就变成了 select or poll 模型：

注意：进行改革的西装店需要增加一个员工，图中标识的用户线程，他的工作是：

• 在前台记录客户订单和联系方式
• 拿记录着 订单 的小本子去找制作间，不断检查 订单是否完工，完工的就可以提走并联系客户了。

而且，他去看订单完工时，无法在前台记录客户信息，这意味他 阻塞 了，其他工作只能先搁置着。

这个做法，对于制作间而言，和 非阻塞模型 并没有多大区别。还增加了一个店员，但是，用 一个店员 就解决了之前 很多店员 都会跑去 制作间 帮客户问"订单好了没有？" 的问题。

值得一提的是，为了提高服务质量，这个员工每次去制作间询问一个订单时，都需要记录一些信息：

• 订单完成度询问时，是否被应答；
• 应答有没有说谎；等

有些店对每种不同的考核项均准备了记录册，这和 select模型类似

有些店只用一本记录册，但是册子上可以利用表格记录各种考核项，这和 poll 模型类似

select 模型 和 poll 模型的近似度比较高。

没多久，老板就发现了，这个店员的工作效率有点低下，他每次都要拿着一本订单簿，去把订单都问一遍，倒不是员工不勤快，是这个模式有点问题。

于是老板又进行了改革：

• 在 前台 和 制作间 之间加一个送信管道。
• 制作间有进度需要汇报了，就送一份信到前台，信上写着订单号。
• 前台员工直接去问对应的订单。

这就变成了 epoll模型解决了 select/poll 模型的遍历效率问题。

这样改革后，前台员工就不再需要按着订单簿从上到下挨个问了。提高了效率，前台员工只要无事发生，就可以优雅的划水了。

我们看一下NativeLooper的构造函数：

Looper::Looper(bool allowNonCallbacks) :
        mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
        mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
    int wakeFds[2];
    int result = pipe(wakeFds);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not create wake pipe.  errno=%d", errno);

    mWakeReadPipeFd = wakeFds[0];
    mWakeWritePipeFd = wakeFds[1];

    result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake read pipe non-blocking.  errno=%d",
            errno);

    result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake write pipe non-blocking.  errno=%d",
            errno);

    // Allocate the epoll instance and register the wake pipe.
    mEpollFd = epoll_create(EPOLL_SIZE_HINT);
    LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance.  errno=%d", errno);

    struct epoll_event eventItem;
    memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
    eventItem.events = EPOLLIN;
    eventItem.data.fd = mWakeReadPipeFd;
    result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not add wake read pipe to epoll instance.  errno=%d",
            errno);
}

总结

相信看到这里，大家已经自己悟透了各种问题。按照惯例，还是要总结下，因为 这篇是脑暴，所以 思绪 是比较 跳跃 的，内容前后关系不太明显。

我们结合一个问题来点明内容前后关系。

Java层 Looper和MQ 会什么使用了死循环但是 不会"阻塞"UI线程 / 没造成ANR / 依旧可以响应点击事件

• Android是基于 事件驱动 的，并建立了 完善的 消息机制
• Java层的消息机制只是一个局部，其负责的就是面向消息队列，处理 消息队列管理，消息分发，消息处理
• Looper的死循环保障了 消息队列 的 消息分发 一直处于有效运行中，不循环就停止了分发。
• MessageQueue的 死循环 保障了 Looper可以获取有效的消息，保障了Looper 只要有消息，就一直运行，发现有效消息，就跳出了死循环。
• 而且Java层MessageQueue在 next() 方法中的死循环中，通过JNI调用了 Native层MQ的 pollOnce，驱动了Native层去处理Native层消息
• 值得一提的是，UI线程处理的事情也都是基于消息的，无论是更新UI还是响应点击事件等。

所以，正是Looper 进行loop()之后的死循环，保障了UI线程的各项工作正常执行。

再说的ANR，这是Android 确认主线程 消息机制 正常 且 健康 运转的一种检测机制。

因为主线程Looper需要利用 消息机制 驱动UI渲染和交互事件处理， 如果某个消息的执行，或者其衍生出的业务，在主线程占用了大量的时间，导致主线程长期阻塞，会影响用户体验。

所以ANR检测采用了一种 埋定时炸弹 的机制，必须依靠Looper的高效运转来消除之前装的定时炸弹。而这种定时炸弹比较有意思，被发现了才会炸。

在说到 响应点击事件，类似的事件总是从硬件出发的，在到内核，再进程间通信到用户空间，这些事件以消息的形式存在于Native层，经过处理后，表现出：

ViewRootImpl收到了InputManager的输入，并进行了事件处理

这里我们借用一张图总结整个消息机制流程：

图片来自 《Android7.0 MessageQueue详解》 作者 Gaugamela

PS:这篇文章写得很长，内容长，耗时也长，大约花费了10天的时间，其中还有不少内容写得未能尽兴。例如： "Java层在哪些情况下利用JNI调取Native层的唤醒，为什么这么干？"等等。

但是考虑到篇幅，决定不再往下挖了。

Android中遇到的兼容性工作

好玩系列：让项目中的相册支持Heif格式图片

前言

目前市面上的成熟的APP，其用户体系中均存在 设置头像 的功能，考虑到尺寸规范问题，一般会加入 图片裁剪 功能； 考虑到页面UI统一度问题，甚至会在应用内实现 相册功能。据此推断：各位的项目中，会遇到 Heif格式图片 需要兼容的需求。

笔者目前参与的商业项目，也被市场要求对Heif图片进行适配。这篇文章，记录了我在这件事情上 折腾 的过程。

好玩系列是我进行 新事物实践 、 尝试创造 的记录，了解更多

背景

HEIF格式的全名为 High Efficiency Image File Format（高效率图档格式），是由动态图像专家组（MPEG）在2013年推出的新格式，了解更多

了解Heif整个项目

测试文件

笔者注：印象中，iOS系统大约在16年就全面支持这一类型的文件了，而Android大约是三年前，在Android P推出的时候，宣布原生支持Heif文件

随着市场上的Android机器已经大面积过渡到 Android Q，从这一点看，确实到了该适配的阶段了。

目标，至少实现Android P及其以上的适配，尝试向更低版本适配

ISO Base Media File Format

HEIF格式是基于 ISO Base Media File Format格式衍生出来的图像封装格式，所以它的文件格式同样符合ISO Base Media File Format (ISO/IEC 14496-12)中的定义（ ISOBMFF）。

文件中所有的数据都存储在称为Box的数据块结构中，每个文件由若干个Box组成，每个Box有自己的类型和长度。在一个Box中还可以包含子Box，最终由一系列的Box组成完整的文件内容，结构如下图所示，图中每个方块即代表一个Box。

我们常见的MP4文件同样是ISOBMFF结构，所以HEIF文件结构和MP4文件结构基本一致，只是用到的Box类型有区别。

HEIF文件如果是单幅的静态图片的话，使用item的形式保存数据，所有item单独解码；如果保存的为图片序列的话，使用track的方式保存。

作者：金山视频云 链接：https://www.jianshu.com/p/b016d10a087d 来源：简书 著作权归作者所有

通过ContentResolver查询Heif格式文件

系统通过ContentProvider向其他应用暴露图片等内容信息。目前 尚未查询相关文档 ，未确定 Android相册向其他应用提供了Heif文件查询支持

通过查询我们得到Heif文件的 主要的 扩展名为 heic 、 heif.

ContentResolver contentResolver = context.getContentResolver();
String sort = MediaStore.Images.Media.DATE_MODIFIED + " desc ";
String selection = MediaStore.Images.Media.MIME_TYPE + "=?";
String[] selectionArgs = new String[]{"image/heic"};

String[] projection = {MediaStore.Images.Media._ID, MediaStore.Images.ImageColumns.BUCKET_DISPLAY_NAME,
        MediaStore.Images.ImageColumns.DATE_MODIFIED};

Cursor cursor = contentResolver.query(
        MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
        projection,
        selection,
        selectionArgs,
        sort
);

我们在测试文件中只找到了 heic, 就先只测一种。

我们发现，系统支持的情况下，是可以查询到数据的。PS，导入数据到手机后，最好重启下

解码与图片显示

我们忽略掉Android版本相应的适配问题，假定已经得到了相应文件的 Uri, 项目中Glide-4.12.0版本已经处理了适配。

我们去探索一下，是自行添加的解码器，还是依赖于系统API

ExifInterfaceImageHeaderParser 提及内容

/**
 * Uses {@link ExifInterface} to parse orientation data.
 *
 * <p>ExifInterface supports the HEIF format on OMR1+. Glide's {@link DefaultImageHeaderParser}
 * doesn't currently support HEIF. In the future we should reconcile these two classes, but for now
 * this is a simple way to ensure that HEIF files are oriented correctly on platforms where they're
 * supported.
 */

文档中提到，系统版本 O_MR1+ 中已经支持了 HEIF，但是目前的 DefaultImageHeaderParser 还不支持，未来会综合考虑这两个类（系统Exif相关类和DefaultImageHeaderParser），但目前，这是一个简单的方式，确保HEIF在受支持的平台上被正确处理图片方向。

Glide 类中提及的内容

// Right now we're only using this parser for HEIF images, which are only supported on OMR1+.
// If we need this for other file types, we should consider removing this restriction.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O_MR1) {
  registry.register(new ExifInterfaceImageHeaderParser());
}

目前仅用于解析HEIF文件的头信息。

我们知道，Glide加载是先获取流，解析头信息，利用对应的解码器处理。而加载此类性质的图片时，是先解码为Bitmap，在进行 装饰 , 而Bitmap的解码是利用了系统API，见BitmapFactory.

所以，如果项目中使用了Glide（似乎高于4.10.0即具有功能，没有仔细查阅），而手机也支持了HEIF，那么应用就可以支持Heif显示了。

Glide官方对于 自定义解码器 还是持保守态度的。但是我们要试一下，尝试在Glide中接入Heif解码器。

至此，我们已经完成了基本目标：

• 借用平台自身兼容性（当然也可以自己根据版本适配查询语句），利用 ContentResolver 获取 Heif格式的图片
• 借助Glide已有的实现，直接在支持的平台版本上解码、构建Bitmap、构建相应Drawable、呈现。

Glide官方提供了支持，是一件值得庆幸的事情。

因为项目中仅使用了Glide，笔者没有继续对Fresco展开调研。而Fresco作为一款优秀的图片加载框架，并且有庞大的社区支持，盲目推测其亦实现了内部支持。

接下来展开向更低版本适配的尝试。当然，这 仅限于 解码、呈现环节，并不考虑 ContentProvider， ContentResolver 在低版本上对于Heif格式文件的适配。

尝试向Glide接入Heif解码器

将官方测试数据集导入 支持Heif 的小米、华为部分机型后，我发现部分图片未被系统支持，提示文件损毁或者不受支持。

另外，冲着好玩，我值得折腾一下。

必须申明：下面的实践只是从好玩角度出发的，并未考虑 健壮性和全场景覆盖。

我计划将Heif文件放入Assets资源，按照我们对Glide的了解，其解码路径起始点是：android.content.res.AssetManager$AssetInputStream

@GlideModule
class CustomGlideModule : AppGlideModule() {
    override fun registerComponents(context: Context, glide: Glide, registry: Registry) {
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O_MR1) {
            registry.register(object : ImageHeaderParser {
                override fun getType(`is`: InputStream): ImageHeaderParser.ImageType {
                    return ImageHeaderParser.ImageType.UNKNOWN
                }

                override fun getType(byteBuffer: ByteBuffer): ImageHeaderParser.ImageType {
                    return ImageHeaderParser.ImageType.UNKNOWN
                }

                override fun getOrientation(`is`: InputStream, byteArrayPool: ArrayPool): Int {
                    return ImageHeaderParser.UNKNOWN_ORIENTATION
                }

                override fun getOrientation(byteBuffer: ByteBuffer, byteArrayPool: ArrayPool): Int {
                    return ImageHeaderParser.UNKNOWN_ORIENTATION
                }

            })
        }

        registry.prepend(
                Registry.BUCKET_BITMAP,
                InputStream::class.java, Bitmap::class.java, CustomBitmapDecoder(context, glide.bitmapPool)
        )
    }

}

这样，我们会得到这样一条解码路径：

DecodePath{ 
	dataClass=class android.content.res.AssetManager$AssetInputStream, 
	decoders=[
		osp.leobert.android.heifdemo.CustomBitmapDecoder@5c4ee9e,
		com.bumptech.glide.load.resource.bitmap.StreamBitmapDecoder@1c1ed7f
	],
	transcoder=com.bumptech.glide.load.resource.transcode.BitmapDrawableTranscoder@529014c
}

接下来我们需要考虑解码器的接入。

Nokia的SDK

Nokia的Heif库：链接

草率了，经过一番源码研读，发现只有读写过程封装，相当于只有 最基础 的协议封包、拆包，想要真正在Android上使用，还有很多事情要处理。

看下Android P

我们知道，Android P原生支持了Heif，查一下资料，其底层支持如下：

一番思考后，发现 成本过大。

再附上 Glide 适用的Decoder：

class CustomBitmapDecoder(val context: Context, val bitmapPool: BitmapPool) : ResourceDecoder<InputStream, Bitmap> {
    override fun handles(source: InputStream, options: Options): Boolean {
        return true
    }

    @Throws(IOException::class)
    fun toByteArray(input: InputStream): ByteArray? {
        val output = ByteArrayOutputStream()
        copy(input, output)
        return output.toByteArray()
    }

    @Throws(IOException::class)
    fun copy(input: InputStream, output: OutputStream): Int {
        val count = copyLarge(input, output)
        return if (count > 2147483647L) {
            -1
        } else count.toInt()
    }

    @Throws(IOException::class)
    fun copyLarge(input: InputStream, output: OutputStream): Long {
        val buffer = ByteArray(4096)
        var count = 0L
        var n = 0
        while (-1 != input.read(buffer).also { n = it }) {
            output.write(buffer, 0, n)
            count += n.toLong()
        }
        return count
    }

    override fun decode(source: InputStream, width: Int, height: Int, options: Options): Resource<Bitmap>? {

        val heif = HEIF()
        try {
            val byteArray = toByteArray(source)
            // Load the file
            heif.load(ByteArrayInputStream(byteArray))

            // Get the primary image
            val primaryImage = heif.primaryImage

            // Check the type, assuming that it's a HEVC image
            if (primaryImage is HEVCImageItem) {
//                val decoderConfig = primaryImage.decoderConfig.config

                val imageData = primaryImage.itemDataAsArray
                // Feed the data to a decoder

                // FIXME: 2021/3/23 find a decoder to generate Bitmap when not upon Android P
                return BitmapResource.obtain(
                        BitmapFactory.decodeByteArray(imageData, 0, imageData.size),
                        bitmapPool
                )
            }
        } // All exceptions thrown by the HEIF library are of the same type
        // Check the error code to see what happened
        catch (e: Exception) {
            e.printStackTrace()
        } finally {
            heif.release()
        }
        return null
    }
}

如果找到了一个解码器，在Android P以下支持解码或转码，封装为Bitmap，就 可以在低版本上适配 了。当然还需要完成：适配所有可能的解码路径，头信息处理 工作。

这次尝试， 以失败告终。

居然翻车了，

遐想

力大砖飞？集成ImageMagick之类的库，直接实现图片转码，成本有点过大了，先不折腾。

本次实践，我们实现了基本目标，高级目标因为初步调研不充分以失败告终，但是也增长了知识。

Glide

Glide 源码和设计解析

三思系列：Glide 4.X全方位认知 -- 模块职责概览 | Glide（一）

最近在解决一些问题时，进行了一下检索，发现 绝大多数文章 是 基于3.X。Glide从进入4.X也有两三年了，在3.X的基础上，发生了很多变化。 所幸我对 4.X 的源码还比较熟，且Glide的设计也很精彩，索性写一写 对4.X的剖析。

当然，对于多数读者而言，因为有一定的基础知识，这些剖析文章并不是满地金砖了，可以泛读查漏。

三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，了解更多

本文主旨

Glide是一个 庞大 的项目，这一篇旨在对Glide项目4.X版本进行 全方位的认知

具体为：了解Glide处理哪些问题，哪些模块与之相对应

对早年间 Square公司开源的 Picasso 比较熟悉的读者而言，不难理解：Picasso 是一个 小而雅 的框架，聚焦于图片加载的以下4点主要问题：

• 异步过程管理与调度
• 资源与显示容器多对多关系
• 多级缓存
• 图片转换支持ScaleType

而后起之秀 Glide 已经是一个 博大且细致 的图片异步加载框架。

在Glide 1.X 时期，两者的关注点基本一致，随着官方支持Glide的发展，它的关注点也越来越多，包括但不限于：

• 资源的封装
• 资源获取方式与过程
• 缓存
• decode、encode 的过程
• Target的抽象，注：媒体资源获取的最终目标，例如存为文件、加载到ImageView中等
• 图片转换
• 资源与Target多对多关系
• 生命周期感知与控制

仔细思考这些点之后，我们不难发现，Glide已经着眼于解决这样一个问题：

构建一个系统，对指定的标识媒体资源的实体，其封装形式可以自行扩展，执行资源的获取，并应用内存、磁盘进行缓存，封装图片的解码过程，按指定要求进行 裁切、缩放等图片转换，最终将结果运用到指定的目标。并对整个过程按照Android平台特性进行生命周期管理。

而这个过程中的绝大多数 节点 或者称之为 切面，均可进行 外部扩展

这一点我们可以从项目介绍中得到印证：看重点单词即可

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

Glide supports fetching, decoding, and displaying video stills, images, and animated GIFs. Glide includes a flexible API that allows developers to plug in to almost any network stack. By default Glide uses a custom HttpUrlConnection based stack, but also includes utility libraries plug in to Google's Volley project or Square's OkHttp library instead.

Glide's primary focus is on making scrolling any kind of a list of images as smooth and fast as possible, but Glide is also effective for almost any case where you need to fetch, resize, and display a remote image.

模块职责划分，从Glide的构建过程窥一斑

不难理解：一个庞大的系统需要在符合 SRP 的基础上进行职责划分，这样一来，类就会变得很多，构建过程会变得复杂，利用Builder模式可以很好的解决这一问题。

class GlideBuilder {
    public Glide build(@NonNull Context context) {
        if (sourceExecutor == null) {
            sourceExecutor = GlideExecutor.newSourceExecutor();
        }

        if (diskCacheExecutor == null) {
            diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();
        }

        if (animationExecutor == null) {
            animationExecutor = GlideExecutor.newAnimationExecutor();
        }

        if (memorySizeCalculator == null) {
            memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();
        }

        if (connectivityMonitorFactory == null) {
            connectivityMonitorFactory = new DefaultConnectivityMonitorFactory();
        }

        if (bitmapPool == null) {
            int size = memorySizeCalculator.getBitmapPoolSize();
            if (size > 0) {
                bitmapPool = new LruBitmapPool(size);
            } else {
                bitmapPool = new BitmapPoolAdapter();
            }
        }

        if (arrayPool == null) {
            arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());
        }

        if (memoryCache == null) {
            memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
        }

        if (diskCacheFactory == null) {
            diskCacheFactory = new InternalCacheDiskCacheFactory(context);
        }

        if (engine == null) {
            engine = new Engine(
                    memoryCache,
                    diskCacheFactory,
                    diskCacheExecutor,
                    sourceExecutor,
                    GlideExecutor.newUnlimitedSourceExecutor(),
                    GlideExecutor.newAnimationExecutor(),
                    isActiveResourceRetentionAllowed);
        }

        RequestManagerRetriever requestManagerRetriever =
                new RequestManagerRetriever(requestManagerFactory);

        return new Glide(
                context,
                engine,
                memoryCache,
                bitmapPool,
                arrayPool,
                requestManagerRetriever,
                connectivityMonitorFactory,
                logLevel,
                defaultRequestOptions.lock(),
                defaultTransitionOptions);
    }
}

从这里我们可以收集到一下有效信息

• 缓存与池
  • MemorySizeCalculator
  • LruBitmapPool
  • BitmapPoolAdapter
  • LruArrayPool
  • LruResourceCache
  • InternalCacheDiskCacheFactory
• 资源获取
  • RequestManagerRetriever
  • DefaultConnectivityMonitorFactory
• 核心流程管理
  • Engine
• 线程池
  • GlideExecutor

再看到构造函数：代码挺长，略去了部分内容

class Glide {
    Glide(
            @NonNull Context context,
            @NonNull Engine engine,
            @NonNull MemoryCache memoryCache,
            @NonNull BitmapPool bitmapPool,
            @NonNull ArrayPool arrayPool,
            @NonNull RequestManagerRetriever requestManagerRetriever,
            @NonNull ConnectivityMonitorFactory connectivityMonitorFactory,
            int logLevel,
            @NonNull RequestOptions defaultRequestOptions,
            @NonNull Map<Class<?>, TransitionOptions<?, ?>> defaultTransitionOptions) {

        this.engine = engine;
        this.bitmapPool = bitmapPool;
        this.arrayPool = arrayPool;
        this.memoryCache = memoryCache;
        this.requestManagerRetriever = requestManagerRetriever;
        this.connectivityMonitorFactory = connectivityMonitorFactory;

        DecodeFormat decodeFormat = defaultRequestOptions.getOptions().get(Downsampler.DECODE_FORMAT);
        bitmapPreFiller = new BitmapPreFiller(memoryCache, bitmapPool, decodeFormat);

        final Resources resources = context.getResources();

        registry = new Registry();
        registry.register(new DefaultImageHeaderParser());

        Downsampler downsampler = new Downsampler(registry.getImageHeaderParsers(),
                resources.getDisplayMetrics(), bitmapPool, arrayPool);
        ByteBufferGifDecoder byteBufferGifDecoder =
                new ByteBufferGifDecoder(context, registry.getImageHeaderParsers(), bitmapPool, arrayPool);
        ResourceDecoder<ParcelFileDescriptor, Bitmap> parcelFileDescriptorVideoDecoder =
                VideoDecoder.parcel(bitmapPool);
        ByteBufferBitmapDecoder byteBufferBitmapDecoder = new ByteBufferBitmapDecoder(downsampler);
        StreamBitmapDecoder streamBitmapDecoder = new StreamBitmapDecoder(downsampler, arrayPool);
        ResourceDrawableDecoder resourceDrawableDecoder =
                new ResourceDrawableDecoder(context);
        ResourceLoader.StreamFactory resourceLoaderStreamFactory =
                new ResourceLoader.StreamFactory(resources);
        ResourceLoader.UriFactory resourceLoaderUriFactory =
                new ResourceLoader.UriFactory(resources);
        ResourceLoader.FileDescriptorFactory resourceLoaderFileDescriptorFactory =
                new ResourceLoader.FileDescriptorFactory(resources);
        ResourceLoader.AssetFileDescriptorFactory resourceLoaderAssetFileDescriptorFactory =
                new ResourceLoader.AssetFileDescriptorFactory(resources);
        BitmapEncoder bitmapEncoder = new BitmapEncoder(arrayPool);

        BitmapBytesTranscoder bitmapBytesTranscoder = new BitmapBytesTranscoder();
        GifDrawableBytesTranscoder gifDrawableBytesTranscoder = new GifDrawableBytesTranscoder();

        ContentResolver contentResolver = context.getContentResolver();

        registry
                .append(ByteBuffer.class, new ByteBufferEncoder())
                /*略去一段内容，太长了*/
                .register(GifDrawable.class, byte[].class, gifDrawableBytesTranscoder);

        ImageViewTargetFactory imageViewTargetFactory = new ImageViewTargetFactory();
        glideContext =
                new GlideContext(
                        context,
                        arrayPool,
                        registry,
                        imageViewTargetFactory,
                        defaultRequestOptions,
                        defaultTransitionOptions,
                        engine,
                        logLevel);
    }
}

这一段可以分为即可部分：

• builder 的 field 对应取值赋值
• 构建非开放的 BitmapPreFiller 实例
• 构建 Registry 实例 registry
• 构建 DefaultImageHeaderParser 、 ResourceLoader 、Decoder 、 ResourceTranscoder 并将之注册到 registry
• 构建 GlideContext 实例 glideContext

按照经验推断，Registry 是一个策略注册表，服务于 策略模式。

不难理解：Glide的工作环境非常复杂，例如获取资源，其资源存在位置可能在网络中的某个位置、 可能在应用的Assets中，也可能在其他位置，对于某一个目标，根据场景不同，存在不同的实现策略

继续按照经验推断，注册会分为不同的策略组，对应不同的目标,这一点我们稍后再看。

再按照我们常见的使用习惯，追踪一下初始化过程：泛读即可

class Glide {
    public static Glide get(@NonNull Context context) {
        if (glide == null) {
            synchronized (Glide.class) {
                if (glide == null) {
                    checkAndInitializeGlide(context);
                }
            }
        }

        return glide;
    }

    private static void checkAndInitializeGlide(@NonNull Context context) {
        //...
        initializeGlide(context);
        //...
    }

    //重载略去
    public static RequestManager with(@NonNull Activity activity) {
        return getRetriever(activity).get(activity);
    }

    @NonNull
    private static RequestManagerRetriever getRetriever(@Nullable Context context) {
        // Context could be null for other reasons (ie the user passes in null), but in practice it will
        // only occur due to errors with the Fragment lifecycle.
        Preconditions.checkNotNull(
                context,
                "You cannot start a load on a not yet attached View or a Fragment where getActivity() "
                        + "returns null (which usually occurs when getActivity() is called before the Fragment "
                        + "is attached or after the Fragment is destroyed).");
        return Glide.get(context).getRequestManagerRetriever();
    }
}

按照使用习惯，一般从 Glide.with(...) 开始得到 RequestManager，当然，也可以以 Glide.get(context).getRequestManagerRetriever() 方式获取。如果Glide没有初始化，则会调用 initializeGlide 进行初始化。

跟进一下代码，泛读即可

class Glide {
    private static void initializeGlide(@NonNull Context context) {
        initializeGlide(context, new GlideBuilder());
    }

    @SuppressWarnings("deprecation")
    private static void initializeGlide(@NonNull Context context, @NonNull GlideBuilder builder) {
        Context applicationContext = context.getApplicationContext();
        GeneratedAppGlideModule annotationGeneratedModule = getAnnotationGeneratedGlideModules();
        List<com.bumptech.glide.module.GlideModule> manifestModules = Collections.emptyList();
        if (annotationGeneratedModule == null || annotationGeneratedModule.isManifestParsingEnabled()) {
            manifestModules = new ManifestParser(applicationContext).parse();
        }

        if (annotationGeneratedModule != null
                && !annotationGeneratedModule.getExcludedModuleClasses().isEmpty()) {
            Set<Class<?>> excludedModuleClasses =
                    annotationGeneratedModule.getExcludedModuleClasses();
            Iterator<com.bumptech.glide.module.GlideModule> iterator = manifestModules.iterator();
            while (iterator.hasNext()) {
                com.bumptech.glide.module.GlideModule current = iterator.next();
                if (!excludedModuleClasses.contains(current.getClass())) {
                    continue;
                }
                if (Log.isLoggable(TAG, Log.DEBUG)) {
                    Log.d(TAG, "AppGlideModule excludes manifest GlideModule: " + current);
                }
                iterator.remove();
            }
        }

        if (Log.isLoggable(TAG, Log.DEBUG)) {
            for (com.bumptech.glide.module.GlideModule glideModule : manifestModules) {
                Log.d(TAG, "Discovered GlideModule from manifest: " + glideModule.getClass());
            }
        }

        RequestManagerRetriever.RequestManagerFactory factory =
                annotationGeneratedModule != null
                        ? annotationGeneratedModule.getRequestManagerFactory() : null;
        builder.setRequestManagerFactory(factory);
        for (com.bumptech.glide.module.GlideModule module : manifestModules) {
            module.applyOptions(applicationContext, builder);
        }
        if (annotationGeneratedModule != null) {
            annotationGeneratedModule.applyOptions(applicationContext, builder);
        }
        Glide glide = builder.build(applicationContext);
        for (com.bumptech.glide.module.GlideModule module : manifestModules) {
            module.registerComponents(applicationContext, glide, glide.registry);
        }
        if (annotationGeneratedModule != null) {
            annotationGeneratedModule.registerComponents(applicationContext, glide, glide.registry);
        }
        applicationContext.registerComponentCallbacks(glide);
        Glide.glide = glide;
    }
}

泛读之后，我们发现主要有 三步：

• 构建GlideBuilder
• 通过反射，加载 可能存在 的自定义模块，设置到Builder中
• 构建Glide

思危：如果直接使用GlideBuilder进行构建，则无法直接运用自定义模块的内容，需要自行注入。

模块职责划分，于Register挖细节

上一节中，我们略去了Glide实例化过程的一些细节，其实现内容为：向Register注册了各种模块，可以泛读一下源码：

 registry
        .append(ByteBuffer.class,new ByteBufferEncoder())
        .append(InputStream.class,new StreamEncoder(arrayPool))
        /* Bitmaps */
        .append(Registry.BUCKET_BITMAP,ByteBuffer.class,Bitmap.class,byteBufferBitmapDecoder)
        .append(Registry.BUCKET_BITMAP,InputStream.class,Bitmap.class,streamBitmapDecoder)
        .append(
        Registry.BUCKET_BITMAP,
        ParcelFileDescriptor.class,
        Bitmap.class,
        parcelFileDescriptorVideoDecoder)
        .append(
        Registry.BUCKET_BITMAP,
        AssetFileDescriptor.class,
        Bitmap.class,
        VideoDecoder.asset(bitmapPool))
        .append(Bitmap.class,Bitmap.class,UnitModelLoader.Factory.<Bitmap>getInstance())
        .append(
        Registry.BUCKET_BITMAP,Bitmap.class,Bitmap.class,new UnitBitmapDecoder())
        .append(Bitmap.class,bitmapEncoder)
        /* BitmapDrawables */
        .append(
        Registry.BUCKET_BITMAP_DRAWABLE,
        ByteBuffer.class,
        BitmapDrawable.class,
        new BitmapDrawableDecoder<>(resources,byteBufferBitmapDecoder))
        .append(
        Registry.BUCKET_BITMAP_DRAWABLE,
        InputStream.class,
        BitmapDrawable.class,
        new BitmapDrawableDecoder<>(resources,streamBitmapDecoder))
        .append(
        Registry.BUCKET_BITMAP_DRAWABLE,
        ParcelFileDescriptor.class,
        BitmapDrawable.class,
        new BitmapDrawableDecoder<>(resources,parcelFileDescriptorVideoDecoder))
        .append(BitmapDrawable.class,new BitmapDrawableEncoder(bitmapPool,bitmapEncoder))
        /* GIFs */
        .append(
        Registry.BUCKET_GIF,
        InputStream.class,
        GifDrawable.class,
        new StreamGifDecoder(registry.getImageHeaderParsers(),byteBufferGifDecoder,arrayPool))
        .append(Registry.BUCKET_GIF,ByteBuffer.class,GifDrawable.class,byteBufferGifDecoder)
        .append(GifDrawable.class,new GifDrawableEncoder())
        /* GIF Frames */
        // Compilation with Gradle requires the type to be specified for UnitModelLoader here.
        .append(
        GifDecoder.class,GifDecoder.class,UnitModelLoader.Factory.<GifDecoder>getInstance())
        .append(
        Registry.BUCKET_BITMAP,
        GifDecoder.class,
        Bitmap.class,
        new GifFrameResourceDecoder(bitmapPool))
        /* Drawables */
        .append(Uri.class,Drawable.class,resourceDrawableDecoder)
        .append(
        Uri.class,Bitmap.class,new ResourceBitmapDecoder(resourceDrawableDecoder,bitmapPool))
        /* Files */
        .register(new ByteBufferRewinder.Factory())
        .append(File.class,ByteBuffer.class,new ByteBufferFileLoader.Factory())
        .append(File.class,InputStream.class,new FileLoader.StreamFactory())
        .append(File.class,File.class,new FileDecoder())
        .append(File.class,ParcelFileDescriptor.class,new FileLoader.FileDescriptorFactory())
        // Compilation with Gradle requires the type to be specified for UnitModelLoader here.
        .append(File.class,File.class,UnitModelLoader.Factory.<File>getInstance())
        /* Models */
        .register(new InputStreamRewinder.Factory(arrayPool))
        .append(int.class,InputStream.class,resourceLoaderStreamFactory)
        .append(
        int.class,
        ParcelFileDescriptor.class,
        resourceLoaderFileDescriptorFactory)
        .append(Integer.class,InputStream.class,resourceLoaderStreamFactory)
        .append(
        Integer.class,
        ParcelFileDescriptor.class,
        resourceLoaderFileDescriptorFactory)
        .append(Integer.class,Uri.class,resourceLoaderUriFactory)
        .append(
        int.class,
        AssetFileDescriptor.class,
        resourceLoaderAssetFileDescriptorFactory)
        .append(
        Integer.class,
        AssetFileDescriptor.class,
        resourceLoaderAssetFileDescriptorFactory)
        .append(int.class,Uri.class,resourceLoaderUriFactory)
        .append(String.class,InputStream.class,new DataUrlLoader.StreamFactory())
        .append(String.class,InputStream.class,new StringLoader.StreamFactory())
        .append(String.class,ParcelFileDescriptor.class,new StringLoader.FileDescriptorFactory())
        .append(
        String.class,AssetFileDescriptor.class,new StringLoader.AssetFileDescriptorFactory())
        .append(Uri.class,InputStream.class,new HttpUriLoader.Factory())
        .append(Uri.class,InputStream.class,new AssetUriLoader.StreamFactory(context.getAssets()))
        .append(
        Uri.class,
        ParcelFileDescriptor.class,
        new AssetUriLoader.FileDescriptorFactory(context.getAssets()))
        .append(Uri.class,InputStream.class,new MediaStoreImageThumbLoader.Factory(context))
        .append(Uri.class,InputStream.class,new MediaStoreVideoThumbLoader.Factory(context))
        .append(
        Uri.class,
        InputStream.class,
        new UriLoader.StreamFactory(contentResolver))
        .append(
        Uri.class,
        ParcelFileDescriptor.class,
        new UriLoader.FileDescriptorFactory(contentResolver))
        .append(
        Uri.class,
        AssetFileDescriptor.class,
        new UriLoader.AssetFileDescriptorFactory(contentResolver))
        .append(Uri.class,InputStream.class,new UrlUriLoader.StreamFactory())
        .append(URL.class,InputStream.class,new UrlLoader.StreamFactory())
        .append(Uri.class,File.class,new MediaStoreFileLoader.Factory(context))
        .append(GlideUrl.class,InputStream.class,new HttpGlideUrlLoader.Factory())
        .append(byte[].class,ByteBuffer.class,new ByteArrayLoader.ByteBufferFactory())
        .append(byte[].class,InputStream.class,new ByteArrayLoader.StreamFactory())
        .append(Uri.class,Uri.class,UnitModelLoader.Factory.<Uri>getInstance())
        .append(Drawable.class,Drawable.class,UnitModelLoader.Factory.<Drawable>getInstance())
        .append(Drawable.class,Drawable.class,new UnitDrawableDecoder())
        /* Transcoders */
        .register(
        Bitmap.class,
        BitmapDrawable.class,
        new BitmapDrawableTranscoder(resources))
        .register(Bitmap.class,byte[].class,bitmapBytesTranscoder)
        .register(
        Drawable.class,
        byte[].class,
        new DrawableBytesTranscoder(
        bitmapPool,bitmapBytesTranscoder,gifDrawableBytesTranscoder))
        .register(GifDrawable.class,byte[].class,gifDrawableBytesTranscoder);

直接讲解 这段代码是 无意义 的，我们从 Register 类入手，分析注册的内容。

public class Registry {
    public static final String BUCKET_GIF = "Gif";
    public static final String BUCKET_BITMAP = "Bitmap";
    public static final String BUCKET_BITMAP_DRAWABLE = "BitmapDrawable";
    private static final String BUCKET_PREPEND_ALL = "legacy_prepend_all";
    private static final String BUCKET_APPEND_ALL = "legacy_append";

    private final ModelLoaderRegistry modelLoaderRegistry;
    private final EncoderRegistry encoderRegistry;
    private final ResourceDecoderRegistry decoderRegistry;
    private final ResourceEncoderRegistry resourceEncoderRegistry;
    private final DataRewinderRegistry dataRewinderRegistry;
    private final TranscoderRegistry transcoderRegistry;
    private final ImageHeaderParserRegistry imageHeaderParserRegistry;

    private final ModelToResourceClassCache modelToResourceClassCache =
            new ModelToResourceClassCache();
    private final LoadPathCache loadPathCache = new LoadPathCache();
    private final Pool<List<Throwable>> throwableListPool = FactoryPools.threadSafeList();

    public Registry() {
        this.modelLoaderRegistry = new ModelLoaderRegistry(throwableListPool);
        this.encoderRegistry = new EncoderRegistry();
        this.decoderRegistry = new ResourceDecoderRegistry();
        this.resourceEncoderRegistry = new ResourceEncoderRegistry();
        this.dataRewinderRegistry = new DataRewinderRegistry();
        this.transcoderRegistry = new TranscoderRegistry();
        this.imageHeaderParserRegistry = new ImageHeaderParserRegistry();
        setResourceDecoderBucketPriorityList(
                Arrays.asList(BUCKET_GIF, BUCKET_BITMAP, BUCKET_BITMAP_DRAWABLE));
    }
    //API略去
}

资源Model加载器

modelLoaderRegistry 用于注册 资源Model加载方式 信息。例如，资源的定义Model为 Uri 类，注册一个 ModelLoaderFactory ，生产对应的 ModelLoader，将 Uri 媒体实体，加载为 InputStream 或者其他形式的 内容

相关类：

• ModelLoaderFactory
• ModelLoader 等

编码器

encoderRegistry 用于注册 内容encode方式 信息。例如，媒体实体已被加载为 InputStream，注册一个对应处理的 Encoder<InputStream>， 用于处理内容的encode，如写入磁盘过程

相关类：Encoder 接口及其实现类

相应的，resourceEncoderRegistry 用于注册 Resource 的encode方式，这些encoder面向 Resource，相比于 InputStream 等低级形式的编码内容封装， Resource 实现类进行了更高级别的编码内容封装。

相关类：

• ResourceEncoder 接口及其实现类
• Resource 接口及其实现类
• EncodeStrategy

不难理解：媒体资源的数据封装存在不同 层级：

• 读取数据的InputSteam
• Bitmap，BitmapDrawable

所以 encode过程 对不同层级的封装类，有不同的处理，当然，encoder可以通过 wrapper，adapter,transfer 等形式，利用其它encoder扩展功能

解码器

decoderRegistry 用于注册 媒体数据解码为Resource方式 的信息。

前面我们提到 modelLoaderRegistry 注册的信息中，可以得到 ModelLoader， 它们负责将 资源Model 加载为 资源内容，这种 资源内容以 InputStream 等低级形式存在即可。

不难理解，这可以有效的解决 类数量爆炸 问题。

脑暴：假定 Model 的类数量为m个，解码后输出的形式有n个

• 不采用这种方式处理，一共需要 m*n 个 decoder 类
• 采用这种方式处理，一共需要 m+n 个 decoder 类

当 层级 增加时，差距会更加明显

按照经验推断，Glide在处理decode过程时，采用了 Wrapper/delegate 模式 或者 bridge 模式。

思变：项目中是否可以使用类似方式，处理不同层级之间 数据Bean 的 转化 或者 包装？

相关类：

• ResourceDecoder 及其实现类
• Resource 及其实现类

转换器

虽然直译为转码器，但是容易概念混淆，按照其功能称为转换器

transcoderRegistry 用于注册 转化器，及其负责的原始类型和转换类型 信息，转换器将资源从一种形式转换为另一种形式。例如: Bitmap -> byte[]

相关类：

• ResourceTranscoder 及其实现类
• Resource 及其实现类

头信息解析器

imageHeaderParserRegistry 用于注册 头信息解析器 信息

注，部分操作系统为了更简便的决定文件的处理方式，利用了文件扩展名。但文件实质内容的编码方式信息，存储在文件头信息中，又称： File Sigs、文件魔数 。

例如 FF D8 代表 Generic JPEG image file，即 JPE, JPEG, JPG

了解更多关于File Sigs内容

相关类：

• ImageHeaderParser 及其实现类
• ImageType

模块职责总结

通过前文的分析，并查阅Glide源码，我们可以对模块职责进行一次初步总结。

在之后的文章中，我们将对具体模块进行 更细致 的挖掘，此处总结的类信息，就是 突破口 。

考虑到目前收集的信息 并不全面 ，我不打算绘制一个图，下面的信息也 并非 十分重要，所以将其作为一个 临时的备忘录 即可。 在后续内容中，我会对各个模块单独总结成图

下一篇，我们将对 资源Model加载、获取流程 进行 深度挖掘。

缓存与池

• MemorySizeCalculator
• LruBitmapPool
• BitmapPoolAdapter
• LruArrayPool
• LruResourceCache
• InternalCacheDiskCacheFactory

资源获取

• RequestManagerRetriever
• RequestManager
• RequestBuilder
• Request
• DefaultConnectivityMonitorFactory

核心流程

• Engine

其他信息尚不能确定。主要流程的相关信息如下：

资源Model加载器

• ModelLoaderFactory
• ModelLoader 等

编码器

• Encoder 接口及其实现类
• ResourceEncoder 接口及其实现类
• Resource 接口及其实现类
• EncodeStrategy

解码器

• ResourceDecoder 及其实现类
• Resource 及其实现类

转换器

• ResourceTranscoder 及其实现类
• Resource 及其实现类

头信息解析器

• ImageHeaderParser 及其实现类
• ImageType

线程池

• GlideExecutor

Glide的创建与配置

GlideBuilder 用于创建，com.bumptech.glide.module 包下的内容用于自定义模块，诸如：

• AppGlideModule
• LibraryGlideModule

以及一些已废弃的内容，不再赘述

思危、思退、思变

可能有读者习惯性地拉到尾部，前面提到，结尾处的大篇幅内容都是 备忘录 性质,而且之后的系列文章会在这些内容的基础上展开，可读可不读

但既然拉到了这里，就思考一下吧，阅读优秀的框架，不仅仅可以深入了解框架内容，也可以锻炼设计能力：

• 思危：使用GlideBuilder构建Glide实例是否有没有注意到的危险？
• 思危：项目中再次对Glide实现单例是否存在危险？
• 思变：项目中是否存在可以借鉴Glide的设计思路的地方？

三思系列：Glide 4.X加载过程一文掌握 | Glide（二）

上一篇中，我们通过阅读Glide初始化的主要代码，对Glide中的模块进行了职责梳理。这一篇，我们在前文的基础上，对Glide的 资源加载过程 进行梳理。

当然，通过博文来看 大篇幅 的代码是相当 枯燥乏味 的，为了让阅读体验更佳，本文中会直接用 UML图 代替绝大多数的 代码拷贝。

注：本文基于Glide 4.12.0。另：我的UML功底不太牢，文中涉及的UML图未必是最恰当的，如图类型或者标识错用，如果读者对此有所建树，我真诚的希望你可以在留言区留下宝贵的参考意见。

再次介绍下三思系列：

三思系列是我最新的学习、总结形式，着重于:问题分析、技术积累、视野拓展，了解更多

攻坚突破口

在第一篇收尾时，我们总结了深度分析时的突破口，和加载过程强关联的内容摘录如下：

资源获取

• RequestManagerRetriever
• RequestManager
• RequestBuilder
• Request
• DefaultConnectivityMonitorFactory

核心流程

• Engine

资源Model加载器

• ModelLoaderFactory
• ModelLoader 等

如果读者在阅读本文时，手边刚好有Glide的源码，可以配合阅读。

Request的构建

不难理解，Glide在设计时，将 资源加载 & 资源处理 & 资源使用 等指令描述封装在了 Request 实现类中。

最简单的使用Sample代码：

// Samples/imgur
// com.bumptech.glide.samples.imgur.MainActivity

ImgurGlide.with(vh.imageView)
      .load(image.link)
      .into(vh.imageView);

调用 Glide.with 得到 RequestManagerRetriever 实例，并进一步调用 RequestManagerRetriever.get 得到 RequestManager 实例

而接下来的过程，则如下图所示，相比于此图，以文字形式描述的过程略显啰嗦

图中的 1、2、3 表示了Request的创建过程。

当创建完成后，需要执行 Request，但需要注意，Glide处理了一个 很重要 的问题：

Target复用场景下，与Resource并非 一一对应

并且这个问题在 网络环境变化、 生命周期协同 等背景下被放大。

所以在开始执行请求前，还需要进行一层判断：

对于该Target，本次 请求的Request是否与 前次 请求的Request一致？

• 一致，执行前次请求
• 不一致，清空与target绑定的各种关系；设置本次请求；执行请求

class RequestBuilder {
    private <Y extends Target<TranscodeType>> Y into(
            @NonNull Y target,
            @Nullable RequestListener<TranscodeType> targetListener,
            @NonNull RequestOptions options) {
        //...

        options = options.autoClone();
        Request request = buildRequest(target, targetListener, options);

        Request previous = target.getRequest();
        if (request.isEquivalentTo(previous)
                && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {
            request.recycle();
            if (!Preconditions.checkNotNull(previous).isRunning()) {
                previous.begin();
            }
            return target;
        }

        requestManager.clear(target);
        target.setRequest(request);
        requestManager.track(target, request);

        return target;
    }
}

其他代码忽略

Request的触发

前文中，我们已经阅读到了 新Request 的触发环节，入口代码如下：

class RequestManager {
    void track(@NonNull Target<?> target, @NonNull Request request) {
        targetTracker.track(target);
        requestTracker.runRequest(request);
    }
}

接下来挖掘下Request触发流程细节，依旧先看图：

1、2 两步对应了 RequestManager#track(Target<?> target, Request request), 标签中备注了1 处为 生命周期监测

简要扩展：TargetTracker 是一个 组合模式 实现，实现了 Glide 中的 LifecycleListener，当关联的对象的生命周期产生变化时，这些变化会被感知，并且 TargetTracker 会被回调，实现请求的生命周期协同管理。

而 2 则开始处理请求：

• 如果当前 RequestTracker 是运行中的，则直接调用 Request#begin() 执行请求； 5
• 否则加入等待队列，当 resumeRequests 或 restartRequests 被调用时，进入运行状态，调用 Request#begin() 执行请求； 3、4

Request执行细节

在开始阅读请求细节之前，不妨先了解下Request中的状态机制。

不难理解：Request的整个过程是 复杂的，设计中，将其设计成不同的 切面过程 ，处于不同的状态时，处理对应的切面，这样可以降低外部调度时的复杂度。

状态概览

状态的枚举如下：

private enum Status {
    /**
     * Created but not yet running.
     */
    PENDING,
    /**
     * In the process of fetching media.
     */
    RUNNING,
    /**
     * Waiting for a callback given to the Target to be called to 
     * determine target dimensions.
     */
    WAITING_FOR_SIZE,
    /**
     * Finished loading media successfully.
     */
    COMPLETE,
    /**
     * Failed to load media, may be restarted.
     */
    FAILED,
    /**
     * Cancelled by the user, may not be restarted.
     */
    CANCELLED,
    /**
     * Cleared by the user with a placeholder set, may not be restarted.
     */
    CLEARED,
    /**
     * Temporarily paused by the system, may be restarted.
     */
    PAUSED,
  }

阅读代码后，整理主要的状态变化图如下：在阅读处理细节时，还会提到相应的内容

Request处理流程一

这一小节，我们将涉及这三个细节：

• 尺寸获取
• 必要的PlaceHolder设置
• 向Engine 发起加载请求

如前文所提及:

• 当资源无法通过校验，将直接进入 FAILED
• 当一切都已准备就绪，即 COMPLETE，则进入资源处理流程 onResourceReady

否则进入 WAITING_FOR_SIZE，并处理尺寸处理

• 如果已经测量过的尺寸是合法的，进入 onSizeReady； 2、11
• 否则获取尺寸，并挂Callback； 3、5、6、7、8、9、10、11

注意：当onSizeReady后，状态将变为 RUNNING，进入资源获取流程，即11，并且，如果有必要处理PlaceHolder且满足条件，则会在begin时处理PlaceHolder设置，即4

不难理解：处理请求时，Target的尺寸未必处于可测量状态，Glide内利用了ViewTree的回调机制，以ViewTarget为例，当该Target进入 PreDraw状态 时， 开始测量尺寸，准确的讲是 获取尺寸。

至此，我们即将阅读到了 资源加载 过程。

Request处理流程二 -- 资源加载

这一小节，我们专注于一个流程细节：资源加载 过程

简单想象一下，一个媒体资源，它的真身可能存在于："网络中的某台主机"，"本地的磁盘的用户文件目录下"，"当前应用的核心资源目录下" 等等。

使用这些资源时，均从原始位置获取 的方式是不可取的，除了 最大的获取成本 外，还额外付诸 加载时间、解析算力成本。

不难理解：在资源有效时限可被信任的前提下，有必要设计缓存机制，牺牲空间换取时间和算力 。

下一篇中，我们将深入Glide的缓存机制，挖掘细节；在本篇中，读者仅需要先记住：

• Glide 设计了缓存
• 缓存包含 内存缓存，磁盘缓存；内存缓存中包含两个级别：已加载激活的缓存、LRU缓存以及映射； 磁盘缓存包含两个级别：已解码数据，原始数据
• 不同的缓存使用策略，同时对应了缓存的存储、获取

整个加载流程可以分为3个环节：

• 生成key
• 从内存缓存中获取
• 使用EngineJob 从磁盘缓存中获取

同样先给出图：为了方便阅读，将流程切分成了5张图

接下来我们逐步分析

1、2是生成key过程，注意：KEY的生成方式中，隐藏着危险。

不难理解，对同一个媒体资源，采用不同的处理方式，得到的结果存在差别，缓存时，必须 完整的 考虑到这些处理差别，否则会出现 资源错用。本文先不对此进行展开

接下来执行 loadFromActiveResources,即从 已加载激活的缓存 中获取

如果不允许使用内存缓存，则直接返回null进入下一级缓存获取

如果得到了缓存资源，则直接运用；否则进入下一级缓存获取

此时，激活缓存未取到目标资源，将进入LRU内存缓存获取

同样的，如果不允许使用内存缓存，则直接返回null进入下一级缓存获取

如果得到了缓存资源，将从LRU内存缓存中被remove，做LRU标记维护，并被加载到 激活缓存 中激活，则直接运用；否则进入下一级缓存获取。

至此，内存缓存无法支持目标资源的获取，需要转向磁盘缓存

不难理解：这里的内在细节会很复杂。将在缓存分析篇章中展开

同样不难理解：当细节非常复杂时，有必要进行 封装 ，隐藏实现细节，对调用者提供语义恰当的 API 即可。

Glide中，将这些细节封装为 EngineJob 和 DecodeJob；

不难理解：这种加载过程是 相对耗时 的，没有必要 阻塞式 等待结果以使用；因此，在加载的过程中，完全可能出现以下场景： 同一资源 被 多次要求 加载。 于是，对Job可以进行 复用 ，获取到还在加载中的Job时，增加回调即可，如下图所示：

如果没有可复用的Job，则创建相应的Job，维护Job资源池，设置回调，如下图所示：

Request处理流程三 -- 资源使用

在前文的讲解中，我们阅读到当资源加载成功后，会执行到： Request#onResourceReady(Resource<?>, DataSource)，而其实现内容即为资源使用。 当然加载失败，或者资源校验失败会执行 onLoadFailed(GlideException e)。

class SingleRequest {
    @Override
    public void onResourceReady(Resource<?> resource, DataSource dataSource) {
        stateVerifier.throwIfRecycled();
        loadStatus = null;
        if (resource == null) {
            GlideException exception = new GlideException("...");
            onLoadFailed(exception);
            return;
        }

        Object received = resource.get();
        if (received == null || !transcodeClass.isAssignableFrom(received.getClass())) {
            releaseResource(resource);
            GlideException exception = new GlideException("...");
            onLoadFailed(exception);
            return;
        }

        if (!canSetResource()) {
            releaseResource(resource);
            // We can't put the status to complete before asking canSetResource().
            status = Status.COMPLETE;
            return;
        }

        onResourceReady((Resource<R>) resource, (R) received, dataSource);
    }
    
    private void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {
        // We must call isFirstReadyResource before setting status.
        boolean isFirstResource = isFirstReadyResource();
        status = Status.COMPLETE;
        this.resource = resource;

        //log

        isCallingCallbacks = true;
        try {
            if ((requestListener == null
                    || !requestListener.onResourceReady(result, model, target, dataSource, isFirstResource))
                    && (targetListener == null
                    || !targetListener.onResourceReady(result, model, target, dataSource, isFirstResource))) {
                Transition<? super R> animation =
                        animationFactory.build(dataSource, isFirstResource);
                target.onResourceReady(result, animation);
            }
        } finally {
            isCallingCallbacks = false;
        }

        notifyLoadSuccess();
    }
}

注意:RequestListener 以及 TargetListener的处理，在使用监听器 附加 一些功能时，例如 采集埋点、 依赖状态触发，需要注意此处细节。

而Target实现类的具体实现，本文略去，感兴趣的读者还请自行阅读源码。

内容总结

这是一张Glide 3.x时代的架构图，仅供参考

图片有区域透明，使用了html加了背景色，如果被转义了，请看这里

图中，蓝色 和 紫色 区域对应了资源加载过程，黄色 区域对应了原始资源获取，品红色 区域对应了内部线程池。

虽然这张图已经无法和 Glide 4.x 完全对应，但是处理问题的主要流程还是没有变化的。

本文的内容，是在 Glide 4.12.0版本基础上 对 蓝色区域 的 深度挖掘 以及对 紫色区域 的 简要梳理 择去了缓存实现细节。

思危、思退、思变

在加载过程分析中，我们已经罗列了部分可能出现错误使用的地方。这些点需要注意并在使用中避开。

本文中没有涉及到具体案例，所以没有 更优做法 ， 更合适的做法 。

但阅读优秀的源码，可以分析其设计思路，思考这样设计的优劣。

如：

• Request 根据内在状态枚举处理切面，在异步处理的过程中，隐藏了内在实现，仅提供最简单的控制API，如 begin，pause；又为什么不使用 状态模式？
• Engine 作为整个流程的控制核心，这是一种 Facade模式 实践，如果没有它的存在，则使用者需要清晰的了解：
  • 缓存的使用细节
  • EngineJob的调度等

    而增加了 Facade层后，对使用者而言，仅需要知道其功能和API语义即可。

当然，这些内容以及更细致的思考，需要建立在 有目的 地源码阅读上，而本文所起到的作用，类似于 引子，参考。

假期到了，也希望读者们去踏踏青，锻炼锻炼，拥有健康的身体状态！

最近会降低写原创的频次，先前一周写两到三篇着实也有些累。

KSP

Kotlin Symbol Processing

好玩系列 | 拥抱Kotlin Symbol Processing(KSP),项目实战

写在最前

这一篇，我们抱着拥抱新事物的心态，尝试一些新事物。笔者在这一次历程中，对三项事物进行了尝鲜：

• 手动迁移一个小规模的Gradle项目，由 Groovy Script 转为 Kotlin Script
• Kotlin Symbol Processing
• Kotlin Poet

这次的 重点是KSP ，Kotlin Poet学习成本比较低，迁移 Kotlin Script 仅仅是比较繁琐。

既然要实战，那么就需要一个实际的项目来支持，笔者选取了个人的开源项目DaVinCi,.

关注笔者动态的读者可能注意到：笔者在过年时发布过一篇文章好玩系列：拥有它，XML文件少一半--更方便的处理View背景, 在这篇文章中，我们提到了一种 取代xml背景资源文件 的方案，并且提到之后会 实现Style机制。本篇文章中，以此为目标，展开 KSP的实战过程。

PS:对DaVinCi不了解并不影响本文内容的理解

如果读者对好玩系列感兴趣，建议点个关注，查看 关于好玩系列 了解笔者创作该系列的初衷。

KSP简介

在正式了解KSP之前，我们需要 复习 之前的知识：

• 编译期处理
• APT与KAPT
• Transformer

因为一些特定的需求，在项目进行编译的过程中，需要增加一定的处理，例如：生成源码文件并参与编译；修改编译的产物。

基于Gradle编译任务链中的 APT机制，可以实现 Annotation Processor，常见于 代码生成， SPI机制实现如AutoService ，也可以用来生成文档。

而APT仅支持Java源码，KAPT并没有 专门的注解处理器 ，所以kotlin项目使用KAPT时，需要 生成代码桩 即Java Stub 再交由APT 进行处理。

基于Gradle编译任务链中的 Transformer机制，可以动态的修改编译结果，例如利用 Javasist，ASM 等字节码操纵框架 增加、修改字节码中的业务逻辑。

这导致Kotlin项目想要针对注解进行处理时，要么用力过猛，采用Transformer机制，要么就使用KAPT并牺牲时间。Transformer机制并无时间优势，若KAPT可以等价处理时， Transformer机制往往呈现力大砖飞之势

那么顺理成章，KSP用于解决纯Kotlin项目下，无专门注解处理器的问题。

在KSP之前，Kotlin的编译存在有 Kotlin Compiler Plugin 了解更多 ，下文简称KCP，KCP用于解决Kotlin 的关键词和注解的编译问题，例如 data class，

而KCP的功能太过于强大，以至于需要 很大的学习成本 ，而将问题局限于 注解处理 时，这一学习成本是多余的，于是出现了KSP，它基于KCP，但 屏蔽了KCP的细节 ， 让我们 专注于注解处理的业务

KCP的复杂程度从其架构可见一斑

KSP-Alpha版本已于2月发布

正式开始之前

在正式开始之前，我们再简要的阐明一下实战的目标：DaVinCi中可以定义 Style 和 StyleFactory：

推荐使用 StyleRegistry.Style.Factory，而不要直接定义 StyleRegistry.Style

@DaVinCiStyle(styleName = "btn_style.main")
class DemoStyle : StyleRegistry.Style("btn_style.main") {
    init {
        this.register(
            state = State.STATE_ENABLE_FALSE,
            expression = DaVinCiExpression.shape().rectAngle().solid("#80ff3c08").corner("10dp")
        ).register(
            state = State.STATE_ENABLE_TRUE,
            expression = DaVinCiExpression.shape().rectAngle().corner("10dp")
                .gradient("#ff3c08", "#ff653c", 0)
        )
    }
}

@DaVinCiStyleFactory(styleName = "btn_style.main")
class DemoStyleFactory : StyleRegistry.Style.Factory() {
    override val styleName: String = "btn_style.main"

    override fun apply(style: StyleRegistry.Style) {
        style.register(
            state = State.STATE_ENABLE_FALSE,
            expression = DaVinCiExpression.shape().rectAngle().solid("#80ff3c08").corner("10dp")
        ).register(
            state = State.STATE_ENABLE_TRUE,
            expression = DaVinCiExpression.shape().rectAngle().corner("10dp")
                .gradient("#ff3c08", "#ff653c", 0)
        )
    }
}

并利用

osp.leobert.android.davinci.StyleRegistry#register(style: Style)
osp.leobert.android.davinci.StyleRegistry#registerFactory(factory: Style.Factory)

进行全局注册

我们并且期望将 StyleName 生成常量，且分别检查Style和StyleFactory是否有重复。

那么我们期望生成以下内容：

/**
 * auto-generated by DaVinCi, do not modify
 */
public object AppDaVinCiStyles {
  public const val btn_style_main: String = "btn_style.main"

  /**
   * register all styles and styleFactories
   */
  public fun register(): Unit {
    registerStyles()
    registerStyleFactories()
  }

  private fun registerStyles(): Unit {
    osp.leobert.android.davinci.StyleRegistry.register(com.example.simpletest.factories.DemoStyle())
  }

  private fun registerStyleFactories(): Unit {
    osp.leobert.android.davinci.StyleRegistry.registerFactory(com.example.simpletest.factories.DemoStyleFactory())
  }
}

正式开始

定义注解

@Target(AnnotationTarget.CLASS)
public annotation class DaVinCiStyle(val styleName: String)

@Target(AnnotationTarget.CLASS)
public annotation class DaVinCiStyleFactory(val styleName: String)

显然，需要单独建立Module，这并不复杂。

引入 com.google.devtools.ksp 插件

//project build.gradle.kts
plugins {
    id("com.google.devtools.ksp") version Dependencies.Kotlin.Ksp.version apply false
    kotlin("jvm") version Dependencies.Kotlin.version apply false
    id("org.jetbrains.dokka") version Dependencies.Kotlin.dokkaVersion  apply false
    id("com.vanniktech.maven.publish") version "0.15.1" apply false
}

//Module build.gradle.kts
plugins {
    id("com.google.devtools.ksp")
    kotlin("jvm")
//  kotlin("kapt")
}

dependencies {
    compileOnly(Dependencies.Kotlin.Ksp.api)

    implementation(Dependencies.AutoService.annotations)
    ksp("dev.zacsweers.autoservice:auto-service-ksp:0.5.2")
    implementation(Dependencies.KotlinPoet.kotlinPoet)
    implementation(Dependencies.guava)
    

//  todo use stable version when release
    implementation(project(":annotation"))
}

引入必要的依赖，这里我们使用ksp实现的auto-service实现SPI，具体可参考DaVinCi项目源码，此处不再赘述

实现 SymbolProcessorProvider 处理注解

必要的知识

核心非常简要，实现SymbolProcessorProvider接口 ，提供一个 SymbolProcessor 接口的实例

package com.google.devtools.ksp.processing

/**
 * [SymbolProcessorProvider] is the interface used by plugins to integrate into Kotlin Symbol Processing.
 */
interface SymbolProcessorProvider {
    /**
     * Called by Kotlin Symbol Processing to create the processor.
     */
    fun create(environment: SymbolProcessorEnvironment): SymbolProcessor
}

处理注解的入口：

package com.google.devtools.ksp.processing

import com.google.devtools.ksp.symbol.KSAnnotated

/**
 * [SymbolProcessor] is the interface used by plugins to integrate into Kotlin Symbol Processing.
 * SymbolProcessor supports multiple round execution, a processor may return a list of deferred symbols at the end
 * of every round, which will be passed to proceesors again in the next round, together with the newly generated symbols.
 * Upon Exceptions, KSP will try to distinguish the exceptions from KSP and exceptions from processors.
 * Exceptions will result in a termination of processing immediately and be logged as an error in KSPLogger.
 * Exceptions from KSP should be reported to KSP developers for further investigation.
 * At the end of the round where exceptions or errors happened, all processors will invoke onError() function to do
 * their own error handling.
 */
interface SymbolProcessor {
    /**
     * Called by Kotlin Symbol Processing to run the processing task.
     *
     * @param resolver provides [SymbolProcessor] with access to compiler details such as Symbols.
     * @return A list of deferred symbols that the processor can't process.
     */
    fun process(resolver: Resolver): List<KSAnnotated>

    /**
     * Called by Kotlin Symbol Processing to finalize the processing of a compilation.
     */
    fun finish() {}

    /**
     * Called by Kotlin Symbol Processing to handle errors after a round of processing.
     */
    fun onError() {}
}

环境可以给到的内容：

class SymbolProcessorEnvironment(
    /**
     * passed from command line, Gradle, etc.
     */
    val options: Map<String, String>,
    /**
     * language version of compilation environment.
     */
    val kotlinVersion: KotlinVersion,
    /**
     * creates managed files.
     */
    val codeGenerator: CodeGenerator,
    /**
     * for logging to build output.
     */
    val logger: KSPLogger
)

这里注意，ksp还无法像APT一样进行debug，所以开发阶段还有一些障碍，仅能 靠日志进行排查。

codeGenerator 用于生成kotlin源码文件，注意写入时 必须分离到子线程 ，否则KSP会进入无限等待。 options 用于手机、获取配置参数

开始编码

略去获取配置参数的部分

定义目标注解的信息：

val DAVINCI_STYLE_NAME = requireNotNull(DaVinCiStyle::class.qualifiedName)
val DAVINCI_STYLE_FACTORY_NAME = requireNotNull(DaVinCiStyleFactory::class.qualifiedName)

利用Resolver得到目标注解的KSName，e.g.:

resolver.getKSNameFromString(DAVINCI_STYLE_NAME)

并进一步得到被注解的类

resolver.getClassDeclarationByName(
    resolver.getKSNameFromString(DAVINCI_STYLE_NAME)
)

此刻，代码示例如下：

private class DaVinCiSymbolProcessor(
    environment: SymbolProcessorEnvironment,
) : SymbolProcessor {

    //忽略

    companion object {
        val DAVINCI_STYLE_NAME = requireNotNull(DaVinCiStyle::class.qualifiedName)
        val DAVINCI_STYLE_FACTORY_NAME = requireNotNull(DaVinCiStyleFactory::class.qualifiedName)
    }

    override fun process(resolver: Resolver): List<KSAnnotated> {


        val styleNotated = resolver.getClassDeclarationByName(
            resolver.getKSNameFromString(DAVINCI_STYLE_NAME)
        )?.asType(emptyList())

        val factoryNotated = resolver.getClassDeclarationByName(
            resolver.getKSNameFromString(DAVINCI_STYLE_FACTORY_NAME)
        )?.asType(emptyList())

        //暂未涉及


        return emptyList()
    }
}

进行必要的检查，如果没有任意的目标注解，按照自己的计划进行抛错或者其他；

此刻我们得到了目标注解的类型，即 KSClassDeclaration实例

扫描被注解的目标

利用 Resolver 和 目标注解的类型 进行扫描

而我们的既定目标是寻找被注解的类，所以直接过滤被注解的目标为 KSClassDeclaration，直接排除掉 Method 和 Property

factoryNotated?.let {
    handleDaVinCiStyleFactory(resolver = resolver, notationType = it)
}

private fun handleDaVinCiStyleFactory(resolver: Resolver, notationType: KSType) {
    resolver.getSymbolsWithAnnotation(DAVINCI_STYLE_FACTORY_NAME)
            .asSequence()
            .filterIsInstance<KSClassDeclaration>()
            .forEach { style ->
                //解析类上的注解信息、保存以待后续处理
                /*end @forEach*/
            }
}

解析注解信息

这里和APT有一点差异，无法直接将 KSAnnotation 转换为实际注解，但并不影响我们操作，可以判断注解的类型、获取注解中方法的返回值。

前面已经得到了被注解的 KSClassDeclaration实例，可以直接得到对于它的注解，并通过 KSType 比对得到目标注解，并进一步解析其 arguments， 得到注解中的值。

val annotation =
        style.annotations.find { it.annotationType.resolve() == notationType }
                ?: run {
                    logE("@DaVinCiStyleFactory annotation not found", style)
                    return@forEach
                }

//structure: DaVinCiStyle(val styleName: String, val parent: String = "")

val styleName = annotation.arguments.find {
    it.name?.getShortName() == "styleName"
}?.value?.toString() ?: kotlin.run {
    logE("missing styleName? version not matched?", style)
    return@forEach
}

//下面是简要的信息处理和保存
val constName = generateConstOfStyleName(styleName)
if (styleFactoryProviders.containsKey(constName)) {
    logE(
            "duplicated style name:${styleName}, original register:${styleFactoryProviders[constName]?.clzNode}",
            style
    )
    return@forEach
}

styleFactoryProviders[constName] = MetaInfo.Factory(
        constName = constName,
        styleName = styleName,
        clzNode = style
)

基于信息生成Kotlin源码

参考 kotlin poet 进行学习

鉴于此部分代码完全与DaVinCi的业务相关，故略去。

生成源码文件

//daVinCiStylesSpec 为利用Kotlin Poet编写的源码信息
val fileSpec = FileSpec.get(packageName ?: "", daVinCiStylesSpec)

val dependencies = Dependencies(true)
thread(true) {
    codeGenerator.createNewFile(
        dependencies = dependencies,
        packageName = packageName ?: "",
        fileName = "${moduleName ?: ""}DaVinCiStyles",
        extensionName = "kt"
    ).bufferedWriter().use { writer ->
        try {
            fileSpec.writeTo(writer)
        } catch (e: Exception) {
            logE(e.message ?: "", null)
        } finally {
            writer.flush()
            writer.close()
        }
    }
}

再次注意，需要在子线程中执行

若对碎片化的代码不太敏感，可以下载DaVinCi的源码进行对照阅读

在项目中使用

前面我们已经完成了KSP的核心逻辑，现在我们需要配置并使用它

这里注意，ksp的生成目录不属于默认sourceSets，需要单独配置

plugins {
    id("com.android.application")
    id("com.google.devtools.ksp") //version Dependencies.Kotlin.Ksp.version
    //略
}

android {
    //略

    buildTypes {
        getByName("release") {
            sourceSets {
                getByName("main") {
                    java.srcDir(File("build/generated/ksp/release/kotlin"))
                }
            }
            //略
        }

        getByName("debug").apply {

            sourceSets {
                getByName("main") {
                    java.srcDir(File("build/generated/ksp/debug/kotlin"))
                }
            }
        }
    }
}

ksp {
    arg("daVinCi.verbose", "true")
    arg("daVinCi.pkg", "com.examole.simpletest")
    arg("daVinCi.module", "App")
}

dependencies {

    implementation(project(":davinci"))
    ksp(project(":anno_ksp"))
    implementation(project(":annotation"))
    //略

}

运行 kspXXXXKotlin 任务即可

结语

至此，KSP的实战已告一段落，相信读者朋友们一定产生了浓厚的兴趣，并准备尝试一番了，赶紧开始吧！

写给对DaVinCi感兴趣的读者朋友们

继DaVinCi开源以及相关文章发布后，也引起了部分读者朋友们的讨论和关注，此次结合实战KSP的机会，对DaVinCi的功能进行了升级，这里也简单的交代一下， DaVinCi目前已经支持：

• GradientDrawable , StateListDrawable 的背景设置 （原有）
• ColorStateList 文字色设置（新增）
• 以上两者的Style定义和使用 （新增）

开发DaVinCi时，我的初衷是："既然难以管理Style和Shape资源，那索性就用一种更加方便的方式来处理"，但这件本身是违背"优秀代码、优秀项目管理"的。

而本次为DaVinCi添加Style机制，又将这一问题摆上桌面，笔者也将思考并尝试寻找一种 有效、有趣 的方式，来解决这一问题。如果各位读者对此有比较好的点子，非常希望能够分享一二。

Base

基础知识的创作计划尚未确立，有兴致时会挑一些手头遇到的内容写写，作为系统性（例如View系统、消息系统）知识之外的补遗

• 孔乙己：你可知道页面和弹窗“通信“的方式有四种？

孔乙己：你可知道页面和弹窗“通信“的方式有四种？

演示用源码和内容思维导图于文末

这日孔乙己照常走进星巴克，点了份大杯拿铁，还要脱脂奶的， 虽然过上了小康生活，但毛病还是没有改，照例掏出一大把硬币，排出三十二枚。

就在等待时，听到旁边一桌人说道："好兄弟，别摸鱼了，今天我请你喝咖啡，这个弹窗功能可务必要加好，不能出bug啊"。"呵呵，一个弹窗、还能难道我伟大的Android工程师？" 手指孔乙己说道："在他拿到咖啡前，我就能写好，bug不存在的！"

孔乙己看热闹不嫌事大，凑上前去，"哟嚯，小兄弟年纪不大口气不小，你可知道Android中界面使用弹窗，有四种写法？今天就让我孔乙己来和你说道说道"

众人哂笑："这孔乙己还真是孔乙己，茴香豆的茴字你是不是也要说道说道？"

孔乙己大怒道："这可不是茴香豆的茴字！这可是必备的基础知识啊，有些你今天用不着了，但遇上祖传代码呢？"

为了说的清晰些，我们约定："在界面点击按钮触发弹窗、弹窗中可输入文字，确定后将输入的内容显示在按钮上方的文本框中。让场景更加真实些，界面包含Activity界面和Fragment界面两种主流情况"。

孔乙己准备先做点准备工作：封装两种情况获取Context、绑定View、绑定事件

诸位可以忽略下面这段模板代码，仅仅是担心后续内容中的代码引起疑惑，可以直接跳跃到 最久远的做法: Dialog

sealed class Host {
    abstract val context: Context

    abstract fun <T : View> view(@IdRes id: Int): T
    abstract fun launchFragment(fragment: DialogFragment)
    abstract fun launchFragment2(fragment: DialogFragment, listener: FragmentResultListener)

    class ActivityHost(private val activity: AppCompatActivity) : Host() {
        override val context: Context
            get() = activity

        override fun <T : View> view(id: Int): T {
            return activity.findViewById(id)
        }

        override fun launchFragment(fragment: DialogFragment) {
            //下文展开
        }

        override fun launchFragment2(fragment: DialogFragment, listener: FragmentResultListener) {
            //下文展开
        }
    }

    class FragmentHost(private val fragment: Fragment) : Host() {
        override val context: Context
            get() = fragment.requireContext()

        override fun <T : View> view(id: Int): T {
            return fragment.requireView().findViewById(id)
        }

        override fun launchFragment(fragment: DialogFragment) {
            //下文展开
        }

        override fun launchFragment2(fragment: DialogFragment, listener: FragmentResultListener) {
            //下文展开
        }
    }
}

class Demo(val host: Host) {

    interface OnResultListener {
        fun onResult(text: String?)
    }

    companion object {
        const val BUNDLE_STR_INPUT = "BUNDLE_STR_INPUT"
        const val BUNDLE_BOOL_FROM_FG = "BUNDLE_BOOL_FROM_FG"
        const val KEY_INPUT = "KEY_INPUT"
    }

    fun onStart() {
        val btnDemo1: Button = host.view(R.id.btn1)
        val btnDemo2: Button = host.view(R.id.btn2)
        val btnDemo3: Button = host.view(R.id.btn3)
        val btnDemo4: Button = host.view(R.id.btn4)

        btnDemo1.setOnClickListener { demo1() }
        btnDemo2.setOnClickListener { demo2() }
        btnDemo3.setOnClickListener { demo3() }
        btnDemo4.setOnClickListener { demo4() }
    }

    fun setText(text: String?) {
        host.view<TextView>(R.id.tv_result).text = text
    }

    private fun demo1() {
    }

    private fun demo2() {
    }

    private fun demo3() {
    }

    private fun demo4() {
    }
}

很轻易的，孔乙己完成了准备工作

最久远的做法: Dialog

还能看到这种做法的，那项目一定是历史悠久了。

做法

孔乙己继续说道："这种做法只需要拿到 Context 和 业务回调函数即可"

private fun demo1() {
    val view = LayoutInflater.from(host.context).inflate(R.layout.view_input, null)
    val dialog = AlertDialog.Builder(host.context)
        .setView(view)
        .setPositiveButton("OK") { dialog, _ ->
            dialog?.dismiss()
            setText(view.findViewById<EditText>(R.id.et_input)?.text?.toString())
        }
        .setNegativeButton("cancel") { dialog, _ -> dialog?.dismiss() }
        .create()
    dialog.show()
}

优点

很显然，它的优点很明显：简单、易于封装，诸位可以很容易的按照产品和UI的需求、剥离弹窗UI部分，从而保持业务部分 "纯粹"， 既能够 高效复用 ，也 避免 UI变更时改动业务类。

缺点

孔乙己转头问小兄弟："你可知道它的缺点吗？"，小兄弟默默不言， 孔乙己也不去管他，笑道："你把弹窗弹出来、再转一下屏幕看。或者把不保留活动打开，退后台再进。哈哈，是不是弹窗没了？"

再仔细看看，是不是还发生了 WindowLeak？

这个设计需要开发者额外维护生命周期变化所导致的问题。

不操心生命周期变化的方式：DialogFragment + setTargetFragment

孔乙己继续说道："Google知道这个设计不好，于是再Fragment系统中增加弹窗交互系统，想要利用Fragment在宿主生命周期变化后的恢复特性来解决这一问题"

做法

孔乙己又做了点准备工作，和前文的Dialog保持了功能一致：

sealed class DemoDialogFragment : DialogFragment() {

    override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {
        val view = LayoutInflater.from(requireContext()).inflate(R.layout.view_input, null)
        return AlertDialog.Builder(requireContext())
            .setView(view)
            .setPositiveButton("OK") { _, _ ->
                dismissAllowingStateLoss()
                onPositive(view.findViewById<EditText>(R.id.et_input)?.text?.toString())
            }
            .setNegativeButton("Cancel") { _, _ -> dismissAllowingStateLoss() }
            .create()
    }

    protected abstract fun onPositive(text: String?)
}

孔乙己又按照两种界面形式区分了结果处理：

• Fragment来源则重新获得 targetFragment，约定调用onActivityResult进行回调
• Activity来源则约定Activity必须实现回调接口，获取宿主Activity后进行转型继而进行回调

class Demo2 : DemoDialogFragment() {
    private var fromFg = false

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        fromFg = arguments?.getBoolean(BUNDLE_BOOL_FROM_FG) ?: false
    }

    override fun onPositive(text: String?) {
        val intent = Intent()
        intent.putExtras(Bundle().apply {
            putString(BUNDLE_STR_INPUT, text)
        })

        if (fromFg) {
            targetFragment?.onActivityResult(targetRequestCode, Activity.RESULT_OK, intent)
        } else {
            (requireActivity() as OnResultListener).onResult(text)
        }
    }
}

编写好 "启动" 方式

 class ActivityHost(private val activity: AppCompatActivity) : Host() {

    override fun launchFragment(fragment: DialogFragment) {
        val arg = fragment.arguments ?: Bundle()
        arg.putBoolean(BUNDLE_BOOL_FROM_FG, false)
        fragment.arguments = arg
        fragment.show(activity.supportFragmentManager, fragment.javaClass.name)
    }
}

class FragmentHost(private val fragment: Fragment) : Host() {

    override fun launchFragment(fragment: DialogFragment) {
        val arg = fragment.arguments ?: Bundle()
        arg.putBoolean(BUNDLE_BOOL_FROM_FG, true)
        fragment.arguments = arg
        fragment.setTargetFragment(this.fragment, 2)
        //使用 fragment.requireActivity().supportFragmentManager 亦可
        fragment.show(this.fragment.requireFragmentManager(), fragment.javaClass.name)
    }
}

略去回调处理逻辑，简单的取数据和方法调用

private fun demo2() {
    host.launchFragment(DemoDialogFragment.Demo2())
}

优点

小兄弟拿起demo进行了把玩，不错不错，这个没bug了。

缺点

孔乙己又是邪魅一笑，你不觉得这 代码太TM多 了吗？使用很不方便啊，Activity和Fragment还有使用差异。

小兄弟试探的答道："改造下，全部干成回调函数？那不就基本统一了吗？"

孔乙己又是邪魅一笑，不错、这就是第三种做法了，你来试一试。

不靠谱的 DialogFragment + Callback

孔乙己在一旁看着小兄弟飞快的编码，左手一个Callback，右手一个invoke Callback，三下五除二就改完了

做法

class Demo3 : DemoDialogFragment() {
    var listener: OnResultListener? = null
    override fun onPositive(text: String?) {
        listener?.onResult(text) ?: Log.e("DEMO3", "listener is null!")
    }
}

private fun demo3() {
    host.launchFragment(DemoDialogFragment.Demo3().apply {
        this.listener = object : OnResultListener {
            override fun onResult(text: String?) {
                setText(text)
            }
        }
    })
}

优点

小兄弟对孔乙己说："孔兄，你看，它又变得 很简单、很容易封装 了，他们再改UI我也不担心改业务代码了，你看生命周期变化的时候它也不消失了！"

缺点

孔乙己邪魅一笑，"小兄弟别高兴的太早，转完了屏幕测一下功能还正常不？"

小兄弟闻言一试，大呼："回调函数怎么没了！可有解救之法？"

孔乙己说道："自然是有的，先想想为什么会这样？重新出现的弹窗是系统在处理宿主生命周期变化时为你恢复的，但并不保证所有的引用都恢复"

破解自然是有办法的，让Callback被恢复，或者让Callback不需要被恢复也能得到正确的对象即可，但需要注意不能带来宿主的内存泄漏问题。

改造自然是需要花费很多精力的，但是现在有福了。

拥抱新变化：FragmentResultListener

孔乙己说道："Google自然是知道方法二中的诸多问题，终于是提供了大一统解决方案"

先把AndroidX-Appcompat升级到 1.3.0

implementation 'androidx.appcompat:appcompat:1.3.0'

我们将会拥有新API：

FragmentManager#setFragmentResultListener(key:String, lifecycleOwner:LifecycleOwner, listener:FragmentResultListener)

FragmentManager#setFragmentResult(key:String, bundle:Bundle)

做法

孔乙己使用新API进行了修改

class ActivityHost(private val activity: AppCompatActivity) : Host() {
    //...

    override fun launchFragment2(fragment: DialogFragment, listener: FragmentResultListener) {
        activity.supportFragmentManager.setFragmentResultListener(Demo.KEY_INPUT, activity, listener)
        fragment.show(activity.supportFragmentManager, fragment.javaClass.name)
    }
}

class FragmentHost(private val fragment: Fragment) : Host() {
    //...

    override fun launchFragment2(fragment: DialogFragment, listener: FragmentResultListener) {
        this.fragment.parentFragmentManager.setFragmentResultListener(Demo.KEY_INPUT, this.fragment, listener)
        fragment.show(this.fragment.parentFragmentManager, fragment.javaClass.name)
    }
}

重新呼出弹窗后

private fun demo4() {
    host.launchFragment2(fragment = DemoDialogFragment.Demo4()) { requestKey, result ->
        if (requestKey != KEY_INPUT) return@launchFragment2
        setText(result.getString(BUNDLE_STR_INPUT))
    }
}

非常完美。此时店员的声音飘来："孔乙己先生，您的大杯脱脂奶拿铁好了"。

孔乙己对众人说道："我的咖啡好了，要走了，有这种官方方案，第三种方法便不再优化了，至于此方案是否有缺点，诸位还请阅读源码，江湖再见"。

附

演示代码

内容导图

SysApp

Android系统应用部分，基础部分。

系统应用一般通过ContentProvider对外提供服务，当然也包含Intent方式（一般在设计上会保持信息一致）。

本章节并不打算完全罗列所有的系统应用，只会挑选相对不常用、但产品方案中可能需要的部分。

使用日历丰富产品的用户体验

前言

经过一段时间的梳理和遴选，我挑选出了Android知识图谱中重要的部分，制作了一张脑图。读者朋友们可按照脑图查漏补缺了， 图片尺寸较大，仅附链接 。

当然，这是我按照自己的判断、结合参考其他博主的观点进行的挑选，不同的细分领域要求的重点有所不同，不可一以概之，且未曾遴选内容并非没必要掌握。图中的4-5层没有展示，以后文章见。

本篇属于 part2-系统应用部分。

在一些助手类的APP中，在使用应用的过程中会产生 "日程" 数据。作为用户理所当然的希望在事情发生前收到提醒。

而我们知道，通过 推送进行提醒 存在一定的不可靠性。那么 在用户手机日历中自动插入事件 则是一个重要的补充手段。

本篇中，我们将用 5-10分钟的时间，回顾操作日历的知识点。

注：开发者官网具有更详尽地说明，只是有点啰嗦，英文版 中文版

重点先行

值得关注的重点：

• 权限
• ContentResolver 进行 查询、插入、修改、删除 操作
• CalendarContract 中 各"表"含义和字段作用 （文中不会详细列举，看API doc即可，足够详细）
• 同步适配器以及何时需要使用同步适配器
• EntityIterator简化模板代码
• RFC 5545 简要规则
• 使用逻辑删除与物理删除
• 从日历日程跳转回APP

如果您已经掌握了这些内容，可忽略下文，下文面向初学者。

权限

小于23时，不需要获取动态权限，Manifest声明日历读写权限即可。

API 14 即 Android 4.0以下不支持，庆幸没那么古老的手机了

<manifest>
    <uses-permission android:name="android.permission.READ_CALENDAR"/>
    <uses-permission android:name="android.permission.WRITE_CALENDAR"/>
    ...
</manifest>

大于等于23时，用你喜欢的方式处理动态权限获取即可。

查询、创建本地日历

实际上，从这里开始的所有内容均和 ContentResolver 有关，相应的，日历应用通过 ContentProvider提供了这些服务，以及通过 Intent 做功能补充。

日历账户信息属于 CalendarContract.Calendars 范畴，可将其看做一张数据库表理解查询与插入

查询

定义关心的列，可理解为 SQL 语句中 Select片段的Column，当然使用null传参可获取所有列，这将增加I/O成本和内存开销。

 // dynamic lookups improves performance.
private val EVENT_PROJECTION: Array<String> = arrayOf(
    CalendarContract.Calendars._ID,                     // 0
    CalendarContract.Calendars.ACCOUNT_NAME,            // 1
    CalendarContract.Calendars.CALENDAR_DISPLAY_NAME,   // 2
    CalendarContract.Calendars.OWNER_ACCOUNT            // 3
)

// The indices for the projection array above.
private const val PROJECTION_ID_INDEX: Int = 0
private const val PROJECTION_ACCOUNT_NAME_INDEX: Int = 1
private const val PROJECTION_DISPLAY_NAME_INDEX: Int = 2
private const val PROJECTION_OWNER_ACCOUNT_INDEX: Int = 3

uri则类似SQL中的 FROM片段，代表了表名

val uri: Uri = CalendarContract.Calendars.CONTENT_URI

拼接条件模板，条件模板+参数 则类似SQL中的 Where片段。代码中演示了查询条件为 账户名为"张三" 且 账户类型为本地账户 且 账户拥有者为"张三"

val selection: String = "((${CalendarContract.Calendars.ACCOUNT_NAME} = ?) AND (" +
        "${CalendarContract.Calendars.ACCOUNT_TYPE} = ?) AND (" +
        "${CalendarContract.Calendars.OWNER_ACCOUNT} = ?))"
val selectionArgs: Array<String> = arrayOf("张三", CalendarContract.ACCOUNT_TYPE_LOCAL, "张三")

val cur: Cursor? = contentResolver.query(uri, EVENT_PROJECTION, selection, selectionArgs, null)

执行查询，注意此类操作均回避主线程，养成好习惯

遍历cursor，略

_ 注：可能您在使用Sqlite数据库时，因为表结构是自行定义的，已经习惯了编码操作cursor、或者依赖ORM框架。而在ContentResolver相关的模块中，您可以尝试使用 android.content.EntityIterator 进而遍历 Entity，可直接获得 ContentValue，减少很多模板代码_

插入

可以选择插入 本地账户 或 在线同步账户，区别就是是否通过服务器同步数据。

一般Exchange协议的邮件服务器适用性更强，但本地账户已经足够满足需求。

我们需要注意：这张表的数据列来自4处定义：

public static final class Calendars
        implements BaseColumns, SyncColumns, CalendarColumns {

}

牵涉到 SyncColumns 中定义的字段时，其写操作必须以 同步适配器 方式进行。

作者按：不需要死记，有十几个列，记住规则即可，开发时注意

需对uri做一定处理，包括：

• CALLER_IS_SYNCADAPTER 设置为 true
• 提供 ACCOUNT_NAME 和 ACCOUNT_TYPE，作为 URI 中的查询参数，插入时据实填写即可，修改时注意数据有效性。

代码固定如下：

private fun Uri.asSyncAdapter(accountName: String, accountType: String): Uri {
    return this.buildUpon()
        .appendQueryParameter(CalendarContract.CALLER_IS_SYNCADAPTER, "true")
        .appendQueryParameter(CalendarContract.Calendars.ACCOUNT_NAME, accountName)
        .appendQueryParameter(CalendarContract.Calendars.ACCOUNT_TYPE, accountType).build()
}

//例如：
CalendarContract.Calendars.CONTENT_URI.asSyncAdapter("张三", CalendarContract.ACCOUNT_TYPE_LOCAL)

以下代码演示插入的关键代码，您可以按照需求增加列参数，例如是否显示、时区、地区等

//构造行数据
val values = ContentValues().apply {
    // The new display name for the calendar
    put(CalendarContract.Calendars.CALENDAR_DISPLAY_NAME, "${username}的日历")
    put(CalendarContract.Calendars.ACCOUNT_NAME, username)
    put(CalendarContract.Calendars.OWNER_ACCOUNT, username)
    put(CalendarContract.Calendars.ACCOUNT_TYPE, CalendarContract.ACCOUNT_TYPE_LOCAL)
}

//插入
val resultUri = contentResolver.insert(
    CalendarContract.Calendars.CONTENT_URI.asSyncAdapter(username, CalendarContract.ACCOUNT_TYPE_LOCAL),
    values
)

//解析id
resultUri?.let {
    calendarId = ContentUris.parseId(it)
}

插入日程和提醒

注：源码中体现为Event、文档中直译为事件，文中采用日程，更符合用语习惯，并非新事物

日程数据隶属于日历，因此我们需要事先获取操作的日历的日历id，参见上一节。

插入日程

日程对应 CalendarContract.Events "表" ：

public static final class Events implements BaseColumns,
        SyncColumns, EventsColumns, CalendarColumns {
}

同理，写 SyncColumns 中的字段时，需要使用同步适配器，不再赘述。

业务相关字段主要定义于：EventsColumns，包含以下类别：

• 所属日历id
• 日程的名称、描述
• 颜色等样式相关
• 时间和规则描述，如起止时间、是否全天时间、如何重复
• 访客控制权限
• 等

如果是非重复日程，则必须提供起止时间，如下代码构建ContentValue：

val event = ContentValues().let {
    //UTC 毫秒级时间戳
    it.put(CalendarContract.Events.DTSTART, startMillis)
    it.put(CalendarContract.Events.DTEND, endMillis)

    //非全天
    it.put(CalendarContract.Events.ALL_DAY, 0)
    //标题和描述
    it.put(CalendarContract.Events.TITLE, title)
    it.put(CalendarContract.Events.DESCRIPTION, desc)

    //所属日历的id
    it.put(CalendarContract.Events.CALENDAR_ID, calendarId)
    //时区
    it.put(CalendarContract.Events.EVENT_TIMEZONE, SimpleTimeZone.getDefault().displayName)

    //API >=16
    // 来源APP的应用包名
    it.put(CalendarContract.Events.CUSTOM_APP_PACKAGE, pkg)
    // 为日程自定义uri，在支持的设备上，打开来源APP时可获取该uri值
    it.put(CalendarContract.Events.CUSTOM_APP_URI, uri)

    it
}

其他字段参考API文档选择使用。

如果是重复事件，则无需传递结束时间戳，而需要提供规则信息

//单次持续时间，而非从第一次起到最后一次截至的时间
it.put(CalendarContract.Events.DURATION, duration)
//日程的重复发生规则
it.put(CalendarContract.Events.RRULE, rRule)
//日程的日期重复规则
it.put(CalendarContract.Events.RDATE, rDate)

这三个参数的值，均遵循 RFC 5545

• DURATION: ”P600S” 标识持续600s即10分钟, “PT1H” 表示持续1小时， “P2W” 表示持续 2周。
• RRULE: ”FREQ=DAILY;WKST=SU;UNTIL=20230225T070000Z” 表示每日重复直至2023年2月25号7点；
• RDATE: 配合RRULE生成更加复杂的规则，如有必要，请研究 RFC 5545

插入日程并获取日程id：

val uri: Uri? = contentResolver.insert(CalendarContract.Events.CONTENT_URI, event)

// get the event ID that is the last element in the Uri
val eventID: Long = uri?.lastPathSegment?.toLong() ?: -1

从日程详情回到来源APP

插入日程时，我们使用了如下字段，标识了日程的来源APP和日程的自定义Uri。

//API >=16
// 来源APP的应用包名
it.put(CalendarContract.Events.CUSTOM_APP_PACKAGE, pkg)
// 为日程自定义uri，在支持的设备上，打开来源APP时可获取该uri值
it.put(CalendarContract.Events.CUSTOM_APP_URI, uri)

在大多数ROM的内置日历中，均支持在日程详情中跳转到来源应用。注意，存在一些例外。鸿蒙系统内置日历也并未完全支持该特性

您可以通过注册IntentFilter配合实现该功能：

<!--注意：exported需设置为true，进行适配-->
<activity android:name="XXXActivity">
    <intent-filter>
        <action android:name="android.provider.calendar.action.HANDLE_CUSTOM_EVENT"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="vnd.android.cursor.item/event"/>
    </intent-filter>
</activity>

并从Intent中获取日程的自定义Uri：

getIntent().getStringExtra(CalendarContract.EXTRA_CUSTOM_APP_URI)

为日程插入提醒

首先，要获取日程的id，可以在插入日程时从返回uri中解析得出，也可以通过查询日程解析得出

此时，操作的是提醒表，CalendarContract.Reminders:

public static final class Reminders implements BaseColumns,
        RemindersColumns, EventsColumns {

}

一般设置提前时间、 提醒方式、日程id即可

val values = ContentValues().apply {
    put(CalendarContract.Reminders.MINUTES, 1)
    put(CalendarContract.Reminders.EVENT_ID, eventID)
    put(CalendarContract.Reminders.METHOD, CalendarContract.Reminders.METHOD_ALERT)
}

contentResolver.insert(CalendarContract.Reminders.CONTENT_URI, values)

读取日程

掌握了插入之后，您已经掌握了表和字段含义，读取日程则更加简单

按实际需求拼接查询条件后，执行查询。

val selection = "((${CalendarContract.Events.CALENDAR_ID} = ?))"
val selectionArgs: Array<String> = arrayOf(calendarId.toString())
val cur: Cursor? = contentResolver.query(CalendarContract.Events.CONTENT_URI, null, selection, selectionArgs, null)

解析：

cur?.let {
    val events = CalendarContract.EventsEntity.newEntityIterator(cur, contentResolver)
        .asSequence()
        .map { entity -> entity.entityValues }
        .map {
            //解析转换实体对象
        }
        .toCollection(arrayListOf())
}

更改日程

通过向URI追加ID的方式，可以限定至修改的条目（类似数据库ORM框架中按主键更新），而不必使用限定条件。

val values = ContentValues().apply {
    // The new title for the event
    put(CalendarContract.Events.TITLE, "Kickboxing")
}
val updateUri: Uri = ContentUris.withAppendedId(CalendarContract.Events.CONTENT_URI, eventID)
//影响的行数
val rows: Int = contentResolver.update(updateUri, values, null, null)

而使用限定条件可以更加灵活

删除日程

同样的，删除也可以使用追加ID方式，或者使用限定条件方式。

删除可分为两种：应用删除（逻辑删除）、同步适配器删除（物理删除）

应用删除将 deleted 列的值设置为 1，即逻辑删除。此标记告知同步适配器该行已删除，并且应将此删除传播至服务器。

同步适配器删除将会从数据库中移除事件及其所有关联数据。

以下为逻辑删：

val deleteUri: Uri = ContentUris.withAppendedId(
    CalendarContract.Events.CONTENT_URI, 日程id
)
return contentResolver.delete(deleteUri, null, null)

物理删除则需通过URI构造同步适配器，参见上文。

DI

Android 知识体系 - part4 - 依赖注入

Hilt进阶--一文吃透Hilt自定义与跨壁垒

前言

本文隶属于我归纳整理的Android知识体系的第四部分，属于DI中Hilt的进阶内容

如果您需要学习Hilt的基础内容，可以通过Android开发者官方提供的 MAD Skills 12-15篇 和 官方使用教程

文章按照以下内容展开：

文中涉及的代码和案例，均可以于 workshop 中获得。

非常重要：经过反复思考，我删除了原先编写的关于Hilt工作原理和生成代码的部分。或许加上这部分，会让部分读者获得更深刻地理解，但我担心会让更多的读者陷入困境 而不敢使用。

正如同Google要创建Hilt一样，他们希望开发者以更简单的方式接入Dagger2，本篇文章也希望读者朋友能够先掌握如何使用，并结合场景选用最佳实践方案。在此基础上再行理解背后的设计原理。

跨越 IOC容器的壁垒

使用依赖注入（DI）时，我们需要它对 实例 、依赖关系 、 生命周期 进行管理，因此DI框架会构建一个容器，用于实现这些功能。这个容器我们惯称为IOC容器。

在容器中，会按照我们制定的规则：

• 创建实例
• 访问实例
• 注入依赖
• 管理生命周期

但容器外也有访问容器内部的需求，显然这里存在一道虚拟的 边界、壁垒。这种需求分为两类：

• 依赖注入客观需要的入口
• 系统中存在合理出现的、非DI框架管理的实例，但它不希望破坏其他实例对象的 生命周期 、作用域唯一性，即它的依赖希望交由DI框架管理

但请注意，IOC容器内部也存在着 边界、壁垒，这和它管理实例的机制有关，在Hilt（包括Dagger）中，最大颗粒度的内部壁垒是 Component。

即便从外部突破IOC容器的壁垒，也只能进入某个特定的Component

使用EntryPoint跨越IOC容器壁垒

在Hilt中，我们可以很方便地

• 使用接口定义 进入点（EntryPoint），并使用 @EntryPoint 注解使其生效；
• 用 @InstallIn 注解指明访问的Component；
• 并利用 EntryPoints 完成访问，突破容器壁垒

下面的代码展示了如何定义：

UserComponent是自定义的Component，在下文中会详细展开

@EntryPoint
@InstallIn(UserComponent::class)
interface UserEntryPoint {
    fun provideUserVO(): UserVO
}

下面的代码展示了如何获取进入点，注意，您需要先获得对应的Component实例。

对于Hilt内建的Component，均有其获取方法，而自定义的Component，需从外界发起生命周期控制，同样会预留实例访问路径

fun manualGet(): UserEntryPoint {
    return EntryPoints.get(
        UserComponentManager.instance.generatedComponent(),
        UserEntryPoint::class.java
    )
}

当获取进入点后，即可使用预定义的API，访问容器内的对象实例。

自定义Scope、Component

部分业务场景中，Hilt内建的Scope和Component并不能完美支持，此时我们需要进行自定义。

为了下文能够更顺利的展开，我们再花一定的笔墨对 Scope、Component、Module 的含义进行澄清。

Scope、Component、Module的真实含义

前文提到两点:

• DI框架需要 创建实例、访问实例、注入依赖、管理生命周期
• IOC容器内部也存在着 边界、壁垒，这和它管理实例的机制有关，在Hilt（包括Dagger）中，最大颗粒度的内部壁垒是 Component。

不难理解：

• 实例之间，也会存在依赖关系；
• DI框架需要管理内部实例的生命周期；
• 需要进行依赖注入的客户，本身也存在生命周期，它的依赖对象，应该结合实际需求被合理控制生命周期，避免生命周期泄漏；

因此，出现了 范围、作用域 即 Scope 的概念，它包含两个维度：实例的生命周期范围；实例之间的访问界限。

并且DI框架通过Component控制内部对象的生命周期。

举一个例子描述，以Activity为例，Activity需要进行依赖注入，并且我们不希望Activity自身需要的依赖出现生命周期泄漏，于是按照Activity的生命周期特点定义了：

• ActivityRetainedScoped ActivityRetainedComponent，不受reCreate 影响
• ActivityScoped、 ActivityComponent，横竖屏切换等配置变化引起reCreate 开始新生命周期

并据此对 依赖对象实例 实施 生命周期 和 访问范围 控制

可以记住以下三点结论：

• Activity实例按照 预定Scope对应的生命周期范围 创建、管理Component，访问Component中的实例；
• Component内的实例可以互相访问，实例的生命周期和Component一致；
• Activity实例（需要依赖注入的客户）和 Component中的实例 可以访问 父Component中的实例，父Component的生命周期完全包含子Component的生命周期

内建的Scope、Component关系参考：

而Module指导DI框架 创建实例、选用实例进行注入

值得注意的是，Hilt（以及Dagger）可以通过 @Inject 注解类构造函数指导 创建实例，此方式创建的实例的生命周期跟随宿主，与 通过Module方式 进行对比，存在生命周期管理粒度上的差异。

自定义

至此，已不难理解：因为有实际的生命周期范围管理需求，才会自定义。

为了方便行文以及编写演示代码，我们举一个常见的例子：用户登录的生命周期。

一般的APP在设计中，用户登录后会持久化TOKEN，下次APP启动后验证TOKEN真实性和时效性，通过验证后用户仍保持登录状态，直到TOKEN超时、登出。当APP退出时，可以等效认为用户登录生命周期结束。

显然，用户登录的生命周期完全涵盖在APP生命周期（Singleton Scope）中，但略小于APP生命周期；和Activity生命周期无明显关联。

定义Scope

import javax.inject.Scope

@Scope
annotation class UserScope

就是这么简单。

定义Component

定义Component时，需要指明父Component和对应的Scope：

import dagger.hilt.DefineComponent

@DefineComponent(parent = SingletonComponent::class)
@UserScope
interface UserComponent {
}

Hilt需要以Builder构建Component，不仅如此，一般构建Component时存在初始信息，例如：ActivityComponent需要提供Activity实例。

通常设计中，用户Component存在 用户基本信息、TOKEN 等初始信息

data class User(val name: String, val token: String) {
}

此时，我们可以在Builder中完成初始信息的注入：

import dagger.BindsInstance
import dagger.hilt.DefineComponent

@DefineComponent.Builder
interface Builder {
    fun feedUser(@BindsInstance user: User?): Builder

    fun build(): UserComponent
}

我们以 @BindsInstance 注解标识需要注入的初始信息，注意合理控制其可空性，在后续的使用中，可空性需保持一致

注意：方法名并不重要，采用习惯性命名即可，我习惯于将向容器喂入参数的API添加feed前缀

当我们通过Hilt获得Builder实例时，即可控制Component的创建（即生命周期开始）

使用Manager管理Component

不难想象，Component的管理基本为模板代码，Hilt中提供了模板和接口类：

如果您想避免模板代码编写，可以定义扩展模块，使用APT、KCP、KSP生成

此处展示非线程安全的简单使用Demo

@Singleton
class UserComponentManager @Inject constructor(
    private val builder: UserComponent.Builder
) : GeneratedComponentManager<UserComponent> {

    companion object {
        lateinit var instance: UserComponentManager
    }

    private var userComponent = builder
        .feedUser(null)
        .build()

    fun onLogin(user: User) {
        userComponent = builder.feedUser(user).build()
    }

    fun onLogout() {
        userComponent = builder.feedUser(null).build()
    }

    override fun generatedComponent(): UserComponent {
        return userComponent
    }

}

您也可以定义如下的线程安全的Manager，并使用 ComponentSupplier 提供实例

class CustomComponentManager(
    private val componentCreator: ComponentSupplier
) : GeneratedComponentManager<Any> {

    @Volatile
    private var component: Any? = null

    private val componentLock = Any()

    override fun generatedComponent(): Any {
        if (component == null) {
            synchronized(componentLock) {
                if (component == null) {
                    component = componentCreator.get()
                }
            }
        }

        return component!!
    }
}

您可以根据实际需求选择最适宜的方法进行管理，不再赘述。

在生命周期范围更小的Component中使用

至此，我们已经完成了自定义Scope、Component的主要工作，通过Manager即可控制生命周期。

如果想在生命周期范围更小的Component中访问 UserComponent中的对象实例，您需要谨记前文提到的三条结论。

该需求很合理，但下面的例子并不足够典型

此时，您需要通过一个合理的Component实现访问，例如在Activity中需要注入相关实例时。 因为 ActivityRetainedComponent 和 UserComponent 不存在父子关系，Scope没有交集，所以 需要找到共同的父Component进行帮助，并通过EntryPoint突破壁垒 ：

前文中，我们将 UserComponentManager 划入 SingletonComponent, 他是两种的共同父Component，此时可以这样处理：

@Module
@InstallIn(ActivityRetainedComponent::class)
object AppModule {

    @Provides
    fun provideUserVO(manager: UserComponentManager):UserVO {
        return UserEntryPoint.manualGet(manager.generatedComponent()).provideUserVO()
    }
}

解决独立library的依赖初始化问题

此问题属于常见案例，通过研究它的解决方案，我们可以更深刻地理解前文内容，做到吃透。

当处理主工程时，没有代码隔离，我们可以很轻易的修改Application的代码，因此很多问题难以暴露。

例如，我们可以在Application中通过注解标明依赖 （满足Singleton Scope前提） ，DI框架会帮助我们进行注入，在注入后可以编写逻辑代码，将对象赋值给全局变量，便可以 "方便" 的使用。

为方便下文表述，我们称之 "方案1"

显然，这是有异味的代码，虽然它有效且方便。

因此，我们选取一些场景来说明该做法的弊端：

• 场景1：创建独立Library，其中使用Hilt作为DI框架，Library中存在自定义Component，需要初始化管理入口
• 场景2：项目采用了组件化，该Library按照渠道包需求，渠道包A集成、渠道包B不集成
• 场景3：项目采用了Uni-App、React-Native等技术，该Library中存在实例由反射方式创建、不受Hilt管理，无法借助Hilt自动注入依赖

以上场景并不相互孤立

在场景1中，我们仍然可以通过 方案1 完成需求，但在场景2中便不再可行。

常规的组件化、插件化，都会完成代码隔离&使用抽象，因此无法在主工程的Application中使用目标类。通过定制字节码工具曲线救国，则属实是大炮打蚊子、屎盆子镶金边

使用hilt的聚合能力解决问题

在 MAD Skills 系列文章的最后一篇中，简单提及了Hilt的聚合能力，它至少包含以下两个层面：

• 即便一个已经编译为aar的库，在被集成后，Hilt依旧能够扫描该库中Hilt相关的内容，进行依赖图聚合
• Hilt生成的代码，依旧存在着注解，这些注解可以被注解处理器、字节码工具识别、并进一步处理。可以是Hilt内建的处理器或您自定义的扩展处理器

依据第一个层面，我们可以制定一个约定：

子Library按照抽象接口提供Library初始化实例，主工程的Application通过DI框架获取后进行初始化

我们将其称为方案2

例如，在Library中定义如下初始化类：

class LibInitializer @Inject constructor(
    private val userComponentManager: UserComponentManager
) : Function1<Application, Any> {

    override fun invoke(app: Application): Any {
        UserComponentManager.instance = userComponentManager
        return Unit
    }
}

不难发现，他是方案1的变种，将依赖获取从Application中挪到了LibInitializer中

并约定绑定实例&集合注入， 依旧在Library中编码 ：

@InstallIn(SingletonComponent::class)
@Module
abstract class AppModuleBinds {
    @Binds
    @IntoSet
    abstract fun provideLibInitializer(bind: LibInitializer): Function1<Application, Any>
}

在主工程的Application中：

@HiltAndroidApp
class App : Application() {
    @Inject
    lateinit var initializers: Set<@JvmSuppressWildcards Function1<Application, Any>>

    override fun onCreate() {
        super.onCreate()
        initializers.forEach {
            it(this)
        }
    }
}

如此即可满足场景1、场景2的需求。

但仔细思考一下，这种做法太 "强硬" 了，不仅要求主工程的Application进行配合，而且需要小心的处理初始化代码的分配。

在场景3中，这些技术均有相适应的插件初始化入口；组件化插件化项目中，也具有类似的设计。随集成方式的不同，很可能造成 初始化逻辑遗漏或者重复 。

注意：重复初始化可能造成潜在的Scope泄漏，滋生bug。

聚合能力+EntryPoint

前文中，我们已经讨论了使用EntryPoint突破IOC容器的壁垒，也体验了Hilt的聚合能力。而 SingletonComponent 作为内建Component，同样可以使用EntryPoint突破容器壁垒。

如果您对Hilt的源码或其设计有一定程度的了解，应当清楚：

内建Component均有对应的ComponentHolder，而SingletonComponent对应的Holder即为Application。

通过 Holder实例和 EntryPointAccessors 可以获得定义的 EntryPoint接口

为 SingletonComponent 自定义EntryPoint后，即可摆脱Hilt自定注入的传递链而通过逻辑编码获取实例。

@EntryPoint
@InstallIn(SingletonComponent::class)
interface UserComponentEntryPoint {
    companion object {
        fun manualGet(context: Context): UserComponentEntryPoint {
            return EntryPointAccessors.fromApplication(
                context, UserComponentEntryPoint::class.java
            )
        }
    }

    fun provideBuilder(): UserComponent.Builder

    fun provideManager():UserComponentManager
}

通过这一方式，我们只需要获得Context即可突破壁垒访问容器内部实例，Hilt不再约束Library的初始化方式。

至此，您可以在原先的Library初始化模块中，按需自由的添加逻辑！

注意：Builder由Hilt生成实现，无法干预其生命周期，故每次调用时生成新的实例，从一般的编码需求，获取Manager实例即可。您可以在WorkShop项目中获得验证

问题衍生

在场景3中，我们继续进行衍生：

Library作为动态插件，并不直接集成，而是通过插件化技术，动态集成启用功能。又该如何处理呢？

在MAD Skills系列文章的第四篇中，简单提及了Hilt的扩展能力。考虑到篇幅以及AAB（Dynamic Feature）、插件化的背景，我们将在下一篇文章中对该问题展开解决方案的讨论。

末

先做到正确使用，再逐步理解原理。我会在后续系列文章中，同读者酣畅淋漓的讨论Hilt的工作原理和实现原理。

Jetpack Compose

本系列将开始 Jetpack Compose 的学习之旅。

如无特殊说明，代码均基于 1.0.1版本

如无特殊说明，文中的 Compose 均指代 Jetpack compose

文中代码均可在 WorkShop 中获取

第一阶段：学习控件的特性、并掌握使用

• Jetpack Compose | 一文理解神奇的Modifier
• Jetpack Compose | 控件篇（一） -- Text、TextField、Button
• Jetpack Compose | 控件篇（二） -- Icon，Image
• Jetpack Compose | 控件篇（三） -- Switch、CheckBox、RadioButton
• Jetpack Compose | 控件篇（四）-- Box、Row、Column
• Jetpack Compose | 控件篇（五）-- Spacer、LazyRow、LazyColumn & 让Column可滑动

Jetpack Compose | 一文理解神奇的Modifier

写在最前

Jetpack Compose的预览版出来已经有很长时间了，相信很多读者都进行了一番尝试。注意：下文如无特殊说明，Compose均指代Jetpack Compose

可以说，Compose在声明布局时，其风格和React的JSX、Flutter 等非常的相似。

而且有一个高频出现的内容： Modifier，即 修饰器，顾名思义，它是对某些内容进行修饰的， 在Compose的设计中，和UI相关的内容都涉及到它，例如：尺寸，形状 等

这一篇文章，我们一起学习两部分内容：

• Modifier的源码和设计
• SDK中既有的Modifier实现概览

当然，最全面的学习文档当属：官方API文档 ， 后续查询API的含义和设计细节等都会用到，建议收藏

文中的代码均基于 1.0.1 版本

先放大招，Modifier的45行代码

其实有效代码行大约20行。

先举个使用示例：

Modifier.height(320.dp).fillMaxWidth()

这里的 Modifier 是接口 androidx.compose.ui.Modifier 的匿名实现，这也是一个很有意思的实用技巧。

我们先简单的概览下源码，再进行解读：

interface Modifier {
    // ...
    companion object : Modifier {
        override fun <R> foldIn(initial: R, operation: (R, Element) -> R): R = initial
        override fun <R> foldOut(initial: R, operation: (Element, R) -> R): R = initial
        override fun any(predicate: (Element) -> Boolean): Boolean = false
        override fun all(predicate: (Element) -> Boolean): Boolean = true
        override infix fun then(other: Modifier): Modifier = other
        override fun toString() = "Modifier"
    }
}

而本身的接口则为：

package androidx.compose.ui

import androidx.compose.runtime.Stable

interface Modifier {

    fun <R> foldIn(initial: R, operation: (R, Element) -> R): R

    fun <R> foldOut(initial: R, operation: (Element, R) -> R): R

    fun any(predicate: (Element) -> Boolean): Boolean

    fun all(predicate: (Element) -> Boolean): Boolean

    infix fun then(other: Modifier): Modifier =
        if (other === Modifier) this else CombinedModifier(this, other)
}

Modifier接口默认实现赏析

先看Modifier接口，和Java8类似，Kotlin的接口可以提供默认实现， 显然， foldIn 和 foldOut 在这里是看不出门道的，具体做什么 需结合 operation来看，如何做 则需看其实现，先略过。

any 和 all 也是看不出啥的，毕竟我把注释删了。

而 then 方法则有点意思，接收一个 Modifier 接口实例， 如果该实例是Modifier的内部默认实现，则认为是无效操作，依旧返回自身，否则则返回一个 CombinedModifier实例 将自身和 other 结合在一起。

从这里，我们可以读出一点 味道 ： 设计者一定会将一系列的Modifier设计成一个类似链表的结构，并且希望我们从Modifier的 companion实现开始进行构建链表。

如果结合注释，我们可以获知：Modifier会通过 then 组成一个链表，并且 any 和 all 是对链表的元素运行判断表达式，foldIn，foldOut 则会对链表的元素执行operation。

Modifier companion实现赏析

再回过头来看 companion实现。then、foldIn，foldOut 都是给啥返回啥， 再结合先前的接口默认实现，我们可以推断： 正常使用的话，最终的链表中不包含 companion实现 ，这从它的 any 和 all 的实现也可见一斑。

很显然这是一个有意思的技巧，这里不做过多解析，但既然我这样描述，一定可以让它进入链表中的。

CombinedModifier 实现

package androidx.compose.ui

import androidx.compose.runtime.Stable

class CombinedModifier(
    private val outer: Modifier,
    private val inner: Modifier
) : Modifier {
    override fun <R> foldIn(initial: R, operation: (R, Modifier.Element) -> R): R =
        inner.foldIn(outer.foldIn(initial, operation), operation)

    override fun <R> foldOut(initial: R, operation: (Modifier.Element, R) -> R): R =
        outer.foldOut(inner.foldOut(initial, operation), operation)

    override fun any(predicate: (Modifier.Element) -> Boolean): Boolean =
        outer.any(predicate) || inner.any(predicate)

    override fun all(predicate: (Modifier.Element) -> Boolean): Boolean =
        outer.all(predicate) && inner.all(predicate)

    override fun equals(other: Any?): Boolean =
        other is CombinedModifier && outer == other.outer && inner == other.inner

    override fun hashCode(): Int = outer.hashCode() + 31 * inner.hashCode()

    override fun toString() = "[" + foldIn("") { acc, element ->
        if (acc.isEmpty()) element.toString() else "$acc, $element"
    } + "]"
}

目前可以读出 foldIn 和 foldOut 的执行的次序，另外可以看出 any 和 all 没啥幺蛾子。

看完 Modifier.Element 之后我们赏析下 foldIn 和 foldOut的递归

Modifier.Element

不出意外，SDK内部的各种修饰效果都将实现这一接口，同样没啥幺蛾子。

package androidx.compose.ui

interface Modifier {
    //...

    interface Element : Modifier {
        override fun <R> foldIn(initial: R, operation: (R, Element) -> R): R =
            operation(initial, this)

        override fun <R> foldOut(initial: R, operation: (Element, R) -> R): R =
            operation(this, initial)

        override fun any(predicate: (Element) -> Boolean): Boolean = predicate(this)

        override fun all(predicate: (Element) -> Boolean): Boolean = predicate(this)
    }
}

foldIn 和 foldOut 赏析

这里举一个栗子来看 foldIn 和 foldOut 的递归：

class A : Modifier.Element
class B : Modifier.Element
class C : Modifier.Element

fun Modifier.a() = this.then(A())
fun Modifier.b() = this.then(B())
fun Modifier.c() = this.then(C())

那么 Modifier.a().b().c() 的到的是什么呢？为了看起来直观点，我们 以 CM 代指 CombinedModifier

CM (
    outer = CM (
        outer = A(),
        inner = B()
    ),
    inner = C()
)

结合前面阅读源码获得的知识，我们再假设一个operation：

val initial = StringBuilder()
val operation: (StringBuilder, Element) -> StringBuilder = { builder, e ->
    builder.append(e.toString()).append(";")
    builder
} 

显然：

Modifier.a().b().c().foldIn(initial, operation)

所得到的执行过程为：

val ra = operation.invoke(initial,A())
val rb = operation.invoke(ra,B())
return operation.invoke(rb,C())

从链表的头部执行到链表的尾部。

而foldOut 则相反，从链表的尾部执行到链表的头部。

当然，真正使用时，我们不一定会一直返回 initial。 但这和Modifier没啥关系，只影响到对哪个对象使用Modifier。

注意：Modifier 会构成一个链表，那么就有次序之说，次序不一致，最终得到的结果会有所不同，这一点需要牢记。

SDK中既有的Modifier实现概览

上文中，我们在 Modifier的源码和设计细节 上花费了很长的篇幅，相信各位读者也已经彻底理解，下面我们看点轻松的。

很显然，下面这部分内容 混个脸熟 即可，就像在Android中的原生布局，一时间遗忘了布局属性的具体拼写也无伤大雅，借助SDK文档可以很快的查询到， 但是 不知道有这些属性 就会影响到开发了。

三个重要的包

• androidx.compose.foundation.layout： Modifier和布局相关的扩展
• androidx.compose.ui.draw： Modifier和绘制相关的扩展
• androidx.compose.foundation：Modifier的基础包，其中扩展部分主要为点击事件、背景、滑动等

API文档的内容是很枯燥的，如果读者仅仅是打算先混个脸熟，可以泛读下文内容，如果已经准备开始结合API文档进行编码实践，可以Fork 我的WorkShop项目 ，将源码和效果对照起来

foundation-layout库 -- androidx.compose.foundation.layout

具体的API列表和描述见 Api文档

这个包中，和布局相关，诸如：尺寸、边距、盒模型等，很显然，其中的内容非常的多。关于Modifier的内容，我们不罗列API。

正如同 DSL 的设计初衷，对于Compose而言，了解Android原生开发的同学，或者对前端领域有一丁点了解的同学，70%的DSL-API可以一眼看出其含义， 并推断出效果，而剩下来的部分，多半需要实际测试下效果。

ui库 -- androidx.compose.ui.draw

这部分大多和绘制相关，所幸这部分API不太多，我们花费一屏来罗列下，混个脸熟。

具体的API列表和描述见 Api文档

• 透明度

Modifier.alpha(alpha: Float)

• 按形状裁切

Modifier.clip(shape: Shape)

• 按照指定的边界裁切内容, 类似Android中的子View内容不超过父View

Modifier.clipToBounds()

Clip the content to the bounds of a layer defined at this modifier.

• 在此之后进行一次指定的绘制

Modifier.drawBehind(onDraw: DrawScope.() -> Unit)

Draw into a Canvas behind the modified content.

• 基于缓存绘制, 用于尺寸未发生变化，状态未发生变化时

Modifier.drawWithCache(onBuildDrawCache: CacheDrawScope.() -> DrawResult)

• 人为控制在布局之前或者之后进行指定的绘制

Modifier.drawWithContent(onDraw: ContentDrawScope.() -> Unit)

• 利用Painter 进行绘制

Modifier.paint(painter: Painter, sizeToIntrinsics: Boolean, alignment: Alignment, contentScale: ContentScale, alpha: Float, colorFilter: ColorFilter?)

• 围绕中心进行旋转

Modifier.rotate(degrees: Float)

• 缩放

Modifier.scale(scaleX: Float, scaleY: Float)

• 等比缩放

Modifier.scale(scale: Float)

• 绘制阴影

Modifier.shadow(elevation: Dp, shape: Shape, clip: Boolean)

foundation库 -- androidx.compose.foundation

所幸这部分也不太多，罗列下

• 设置背景

Modifier.background(color: Color, shape: Shape = RectangleShape)

Modifier.background(brush: Brush, shape: Shape = RectangleShape, alpha: Float = 1.0f)

Brush 是渐变的，Color是纯色的

• 设置边界，即描边效果

Modifier.border(border: BorderStroke, shape: Shape = RectangleShape)

Modifier.border(width: Dp, color: Color, shape: Shape = RectangleShape)

Modifier.border(width: Dp, brush: Brush, shape: Shape)

• 点击效果

Modifier.clickable(enabled: Boolean = true, onClickLabel: String? = null, role: Role? = null, onLongClickLabel: String? = null, onLongClick: () -> Unit = null, onDoubleClick: () -> Unit = null, onClick: () -> Unit)

Modifier.clickable(enabled: Boolean = true, interactionState: InteractionState, indication: Indication?, onClickLabel: String? = null, role: Role? = null, onLongClickLabel: String? = null, onLongClick: () -> Unit = null, onDoubleClick: () -> Unit = null, onClick: () -> Unit)

长按、单击、双击均包含在内

• 可滑动

Modifier.horizontalScroll(state: ScrollState, enabled: Boolean = true, reverseScrolling: Boolean = false)

Modifier.verticalScroll(state: ScrollState, enabled: Boolean = true, reverseScrolling: Boolean = false)

结语

这一篇，我们学习了Modifier的源码，和Modifier的 各种效果 混了下脸熟。但是还有一个问题没有去探索：

Modifier 到底是如何产生作用的？

显然，要解答这个问题，需要探索 Compose如何渲染视图 ，这件事情不适合在本篇就安排，会在后续的学习中展开。

对比Android原生技术栈，这是一个全新的内容，要真正的全面掌握还需要积累很多的知识，就如同最开始入门Android开发那样，各类控件的使用都需要学习和记忆

但它也仅局限于：一种新的声明式、响应式UI构建框架，并不用过于畏惧，虽然有较高的上手成本，按部就班的学习积累就可以掌握使用方式。 它还没有颠覆整个Android客户端的开发方式，不用心急和焦虑。

另：WorkShop中的演示代码会跟随整个Compose系列的问题，我是兴致来了就更新一部分，这意味着可能会出现：有些效果在博客中提到了，但WorkShop中没有写进去

#Jetpack Compose | 控件篇（一） -- Text、TextField、Button

这一篇，我们一起学习 Jetpack Compose 中的部分控件 -- Text、TextField、Button，掌握其使用方式和特性。

文中代码均基于 1.0.1版本

如无特殊说明，下文中的 Compose 均指代 Jetpack compose

小互动

上一篇文章：Compose | 一文理解神奇的Modifier 在郭婶的号上有读者评论到不知道Compose从何学起， 无从下手，这里简单的谈一谈我的看法：

• Compose 以及 Jetpack Compose 对于Android从业人员而言确实是一门 全新的技术
• 目前才兴起，还没有达到一个辉煌的阶段

在此背景下，开始学习研究Compose 都可以算的上 先行者，而且这门技术还做不到诸如："一年内全面替代老技术"、"不掌握就找不到工作" 这种程度。

那么按部就班的学习它就行了，没有时间上的紧迫感。而学习一样东西，有这样几个阶段：

• 掌握如何使用
• 掌握实现细节，逐渐理解其本质
• 从其本质出发，利用对程序的理解，优化使用方式甚至优化这门技术

显然，我们现在要做的就是：

• 先结合官方资料以及源码，先掌握如何使用：它解决哪些问题，怎么使用它解决问题
• 鉴于部分读者已经有一定的基础，对类似技术有了一定的理解，在此过程中就可以提前阅读该技术的实现细节，尝试理解其本质。或者再掌握了使用方式后再开始。
• 再之后的道路就很清晰了

下面我们进入今天的正文。

Text

在Android中，有 TextView 这一控件，用于展示文本，Compose中对应的是 Text。

先看源码：

fun Text(
    text: String,
    modifier: Modifier = Modifier,
    color: Color = Color.Unspecified,
    fontSize: TextUnit = TextUnit.Unspecified,
    fontStyle: FontStyle? = null,
    fontWeight: FontWeight? = null,
    fontFamily: FontFamily? = null,
    letterSpacing: TextUnit = TextUnit.Unspecified,
    textDecoration: TextDecoration? = null,
    textAlign: TextAlign? = null,
    lineHeight: TextUnit = TextUnit.Unspecified,
    overflow: TextOverflow = TextOverflow.Clip,
    softWrap: Boolean = true,
    maxLines: Int = Int.MAX_VALUE,
    onTextLayout: (TextLayoutResult) -> Unit = {},
    style: TextStyle = LocalTextStyle.current
)

fun Text(
    text: AnnotatedString,
    modifier: Modifier = Modifier,
    color: Color = Color.Unspecified,
    fontSize: TextUnit = TextUnit.Unspecified,
    fontStyle: FontStyle? = null,
    fontWeight: FontWeight? = null,
    fontFamily: FontFamily? = null,
    letterSpacing: TextUnit = TextUnit.Unspecified,
    textDecoration: TextDecoration? = null,
    textAlign: TextAlign? = null,
    lineHeight: TextUnit = TextUnit.Unspecified,
    overflow: TextOverflow = TextOverflow.Clip,
    softWrap: Boolean = true,
    maxLines: Int = Int.MAX_VALUE,
    inlineContent: Map<String, InlineTextContent> = mapOf(),
    onTextLayout: (TextLayoutResult) -> Unit = {},
    style: TextStyle = LocalTextStyle.current
)

这两个方法原型的唯一差别就是形参 text 的类型，AnnotatedString 类似于Android中的 SpannableString, 可以标记各类效果。

其实阅读源码后可以发现，Text 基于 BasicText 实现，应用了样式。

val textColor = color.takeOrElse {
    style.color.takeOrElse {
        LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
    }
}
val mergedStyle = style.merge(
    TextStyle(
        color = textColor,
        fontSize = fontSize,
        fontWeight = fontWeight,
        textAlign = textAlign,
        lineHeight = lineHeight,
        fontFamily = fontFamily,
        textDecoration = textDecoration,
        fontStyle = fontStyle,
        letterSpacing = letterSpacing
    )
)
BasicText(
    text,
    modifier,
    mergedStyle,
    onTextLayout,
    overflow,
    softWrap,
    maxLines,
    inlineContent
)

参数含义：（翻译自API文档）

• text - 要显示的内容
• modifier - 需要应用的修饰器.
• color - 文字色. 如果是 Color.Unspecified, 同时 style 没有配饰颜色, 将会使用 LocalContentColor.
• fontSize - 字号. See TextStyle.fontSize.
• fontStyle - 文字样式，例如斜体，See TextStyle.fontStyle.
• fontWeight - 字重，例如加粗.
• fontFamily - 字体系列. See TextStyle.fontFamily.
• letterSpacing - 字间距. See TextStyle.letterSpacing.
• textDecoration - 文字装饰效果，例如下划线. See TextStyle.textDecoration.
• textAlign - 文字段落对齐方式. See TextStyle.textAlign.
• lineHeight - 行高. See TextStyle.lineHeight.
• overflow - 溢出时的处理方案，所谓溢出即文本框显示不下这么多文字.
• softWrap - 是否应用换行符. 如果不应用，则一行写完，overflow 、TextAlign 无效.
• maxLines - 最大行数，必须大于0.
• inlineContent - 占位的替代信息匹配
• onTextLayout - 绘制文字计算布局时的回调
• style - 样式，例如： color, font, line height 等.

WorkShop 中按照这些参数编写了一些样例代码，效果如下，因过度图片压缩导致有锯齿感，非Compose问题

考虑到阅读体验，代码请移步WorkShop

TextField

Android中有 EditText 控件，用于接收 用户的文本输入，Compose中为 TextField

和 TextField 类似的还有 OutlinedTextField，使用上和 TextField 一致，多一个描边外框效果

方法原型：

fun TextField(
    value: String,
    onValueChange: (String) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    readOnly: Boolean = false,
    textStyle: TextStyle = LocalTextStyle.current,
    label: @Composable (() -> Unit)? = null,
    placeholder: @Composable (() -> Unit)? = null,
    leadingIcon: @Composable (() -> Unit)? = null,
    trailingIcon: @Composable (() -> Unit)? = null,
    isError: Boolean = false,
    visualTransformation: VisualTransformation = VisualTransformation.None,
    keyboardOptions: KeyboardOptions = KeyboardOptions.Default,
    keyboardActions: KeyboardActions = KeyboardActions(),
    singleLine: Boolean = false,
    maxLines: Int = Int.MAX_VALUE,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    shape: Shape =
        MaterialTheme.shapes.small.copy(bottomEnd = ZeroCornerSize, bottomStart = ZeroCornerSize),
    colors: TextFieldColors = TextFieldDefaults.textFieldColors()
)

fun TextField(
    value: TextFieldValue,
    onValueChange: (TextFieldValue) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    readOnly: Boolean = false,
    textStyle: TextStyle = LocalTextStyle.current,
    label: @Composable (() -> Unit)? = null,
    placeholder: @Composable (() -> Unit)? = null,
    leadingIcon: @Composable (() -> Unit)? = null,
    trailingIcon: @Composable (() -> Unit)? = null,
    isError: Boolean = false,
    visualTransformation: VisualTransformation = VisualTransformation.None,
    keyboardOptions: KeyboardOptions = KeyboardOptions.Default,
    keyboardActions: KeyboardActions = KeyboardActions(),
    singleLine: Boolean = false,
    maxLines: Int = Int.MAX_VALUE,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    shape: Shape =
        MaterialTheme.shapes.small.copy(bottomEnd = ZeroCornerSize, bottomStart = ZeroCornerSize),
    colors: TextFieldColors = TextFieldDefaults.textFieldColors()
)

很巧，和Text类似，除了value 和 onValueChange 的类型不一致，其他均一致。

简单追溯代码后可以发现：

• 和Android不一致，它并没有依赖Text的实现，而Android中 Edittext 继承自 TextView
• TextField 同样是结合 较为通用的设计 组合而成的一个控件，并不仅仅只有文字相关部分

本篇注重于学习如何使用，故而略去源码部分

参数含义：

value: TextFieldValue 输入框中要显示的文本，包含了输入框编辑状态的信息，这个功能很强大，可以用来更新文本，光标等，然后还可以从其他位置直接观察到这些值的变化。也就是相当于双向绑定的意思；

• value: 显示的文本
• onValueChange: 更新后的回调
• modifier:修饰器
• enabled:是否可用，如果为false，将不可选中，不可输入，呈现出禁用状态
• readOnly:是否只读，如果是true，则不可编辑，但是可以选中，可以触发复制
• textStyle: 文字样式，前文中Text的诸多参数亦用于构建TextStyle
• label: 显示在文本字段内的可选标签，未获得焦点时呈现
• placeholder: 获得焦点时的默认呈现 类似Tint的效果
• leadingIcon: 输入框前部的图标；
• trailingIcon: 输入框后部的图标；
• isError: 输入内容是否错误，如果为true，则label，Icon等会相应的展示错误的显示状态；
• visualTransformation: 内容显示转变，例如输入密码时可以变成特定效果
• keyboardOptions: 软件键盘选项
• keyboardActions: ImeAction
• singleLine: 是否单行输入
• maxLines:最大行数，需要≥1。如果将singleLine设置为true，则将忽略此参数，
• interactionSource: 目前的知识体系暂不深入
• shape: 输入框的形状
• colors: 各种状态下的颜色 类似Android的ColorStateList

效果演示

TextField(
    value = "文字",
    onValueChange = {
        
    }
)

如果我们测试这样一段代码，会发现无论输入什么，显示内容都不会改变。Compose 需要我们在外部维护状态

一个有效的输入框代码示例：

var text by rememberSaveable { mutableStateOf("文字") }
TextField(
    value = text,
    onValueChange = {
        text = it
    }
)

如果读者仔细的观察一下，会发现这里的value 依旧对应 String 类型！这里充分利用了Delegate的特性！！

接下来，我们尝试一下几个有趣的属性。

而下述的一些简单属性，相信读者已经心中有数，就不在WorkShop中演示了：

• modifier
• enabled
• readOnly
• textStyle
• visualTransformation
• singleLine
• maxLines
• shape
• colors

label & placeholder

var text by rememberSaveable { mutableStateOf("") }
TextField(
    value = text,
    onValueChange = { text = it },
    label = { Text("Label") },
    placeholder = { Text("PlaceHolder") }
)

未获得焦点时，显示label：这里输入的是啥，获取焦点后，label缩小，如果没有初始值，则显示PlaceHolder，否则初始文字 PlaceHolder：输入示例

效果在章节末呈现

leadingIcon&trailingIcon

var text by rememberSaveable { mutableStateOf("") }

TextField(
    value = text,
    onValueChange = { text = it },
    placeholder = { Text("PlaceHolder") },
    leadingIcon = { Icon(Icons.Filled.Favorite, contentDescription = "Favorite") },
    trailingIcon = { Icon(Icons.Filled.Clear, contentDescription = "Clear",modifier = Modifier.clickable {
        text = ""
    }) }
)

如果在Android原生SDK下，做法可以是：

• 完全自定义View -- 完全通过继承
• 继承ViewGroup或者特定ViewGroup，内部通过组合控件方式 反射xml布局或者代码构建 实现逻辑 -- 继承 + 组合
• 定义类，内部通过组合控件方式 反射xml布局或者代码构建 实现逻辑 -- 组合

每种做法都有自身的优势和劣势，但代码量都会很多

这个例子下我们还无法去讨论 组合与继承的优劣对比 ，但代码量的感性对比非常明显

isError & keyboardActions & 输入校验

var text by rememberSaveable { mutableStateOf("") }
var isError by rememberSaveable { mutableStateOf(false) }

fun validate(text: String) {
    isError = text.count() < 5
}

TextField(
    value = text,
    onValueChange = {
        text = it
        isError = false
    },
    singleLine = true,
    label = { Text(if (isError) "Email*" else "Email") },
    isError = isError,
    keyboardActions = KeyboardActions { validate(text) },
    modifier = Modifier.semantics {
        // Provide localized description of the error
        if (isError) {
            Toast.makeText(this@P26TextFieldSample,"输入错误",Toast.LENGTH_SHORT).show()
        }
    }
)

代码含义清晰明了

上述例子的效果

读者可以clone项目后自行体验

相信有读者已经在思考Compose是如何实现 双向绑定 的了，按照我们的学习计划，这将在后续的文章中展开。

Button

相信看到这里，有读者已经在思考一个问题了：

Modifier 中有点击相关的内容，为什么还需要有Button呢？它真的是一个视图控件吗？还是一个特定的、带有点击效果的样式组合？

其实 Button 在人机交互中，是一个类似 隐喻 的存在，指代点击可触发特定行为的交互区，在设计发展中， 逐渐形成了一些约定：

• 可触发和不可触发的状态要可识别
• 从其所在环境中可以被轻易地识别出来
• 点击或者按压要有视觉反馈效果

所以样式上是一个不可忽略的侧重点。但是也要客观的承认一点：中式UI和欧美UI确实不是一个风格，所以多数情况下我们会修改掉默认效果。

看一下方法原型：

fun Button(
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    elevation: ButtonElevation? = ButtonDefaults.elevation(),
    shape: Shape = MaterialTheme.shapes.small,
    border: BorderStroke? = null,
    colors: ButtonColors = ButtonDefaults.buttonColors(),
    contentPadding: PaddingValues = ButtonDefaults.ContentPadding,
    content: RowScope.() -> Unit
): @Composable Unit

• onClick: 点击事件回调
• modifier: 修饰器
• enabled:是否可点击触发
• interactionSource:
• elevation: z轴投影效果
• shape: button和投影的形状
• border: 描边
• colors: 背景色、内容色、各个状态配色
• contentPadding: 容器和内容的间距
• content: 内容

代码示例

一个最简单的文字按钮：

Button(
    onClick = {
        toast("onClick")
    },
    modifier = Modifier.clickable {
        toast("Modifier.onClick")
    }
) {
    Text(
        text = "Button",
    )
}

显然，点击生效的是 onClick 的回调函数。

在 后面的效果图 或者 运行WorkShop后 可发现，这个文字Button已经运用了许多样式

Button的样式部分，读者可自行编码探索实践一二，可以很轻易的和Android原生内容对应上，不再展开。

前文的方法原型中，content: RowScope.() -> Unit 显然可以包含更多的东西。Row 的布局特性会在后续文章展开

例如：

Button(
    onClick = {
        toast("onClick")
    }
) {
    Icon(
        Icons.Filled.Favorite,
        contentDescription = "Favorite"
    )
    Text(
        text = "Button",
    )
}

可以在文字左边放置一个 Favorite 图标

结合样式的衍生物

而Compose中，还有一些内容，代表着Button的操作含义，但有更特殊的样式含义，例如：

• OutlinedButton：有边线的Button, 但非实质的，借用Android原生的内容比喻：有Stroke效果，无Solid效果
• IconButton：显示一个Icon的button 但编码上未强制约束
• IconToggleButton：两个状态图标的icon，相互切换，例如：收藏、取消收藏，表现含义上有别于 Switch，表现类似无文字的 CheckBox

OutlinedButton

fun OutlinedButton(
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    elevation: ButtonElevation? = null,
    shape: Shape = MaterialTheme.shapes.small,
    border: BorderStroke? = ButtonDefaults.outlinedBorder,
    colors: ButtonColors = ButtonDefaults.outlinedButtonColors(),
    contentPadding: PaddingValues = ButtonDefaults.ContentPadding,
    content: @Composable RowScope.() -> Unit
)

和Button参数含义一致

IconButton

fun IconButton(
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    content: @Composable () -> Unit
)

参数含义参考Button

适用场景如返回键、关闭按钮等

示例：

IconButton(
    onClick = {
        toast("onClick")
    },
) {
    Icon(
        imageVector = Icons.Filled.Favorite,
        contentDescription = "Favorite"
    )
}

IconToggleButton

fun IconToggleButton(
    checked: Boolean,
    onCheckedChange: (Boolean) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    content: @Composable () -> Unit
) 

• checked：默认状态
• onCheckedChange：状态变化后的回调

适用场景如：收藏、取消收藏等

示例：

val checkedState = remember { mutableStateOf(true) }

IconToggleButton(
    checked = checkedState.value,
    onCheckedChange = {
        checkedState.value = it
    },
) {
    Icon(
        imageVector = Icons.Filled.Favorite,
        contentDescription = "Favorite",
        tint = if (checkedState.value) {
            Color.Red
        } else {
            Color.Gray
        }
    )
}

上述所有内容的效果：

结语

在本篇文章中，我们一起学习了Compose的部分基础内容，这些内容学起来也比较枯燥，但适应了Compose之后，学习这些基础内容就会越来越快。

读者可以结合 WorkShop 实践一波，加深印象！

我们下一篇见。

Jetpack Compose | 控件篇（二） -- Icon，Image

写在最前

在上一篇，我们学习了Compose 中的 Text 、TextField 、Button，并在WorkShop中进行了一系列尝试。 除了对他们的效果有了直观的认识外，也感受了Compose的编码乐趣。

本篇我们将继续学习Icon和Image，从命名上我们可以看出他们和 图形、图片 有关，也是 内容呈现 中非常重要的一种载体和方式。

文中代码均基于 1.0.1版本

如无特殊说明，文中的 Compose 均指代 Jetpack compose

文中代码均可在 WorkShop 中获取，本篇代码集中于 post27 包下

Icon

使用方法

翻阅源码，我们可以获知有三个函数用于构建Icon组件。

分别是：

fun Icon(
    imageVector: ImageVector,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    tint: Color = LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
)

fun Icon(
    bitmap: ImageBitmap,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    tint: Color = LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
)

fun Icon(
    painter: Painter,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    tint: Color = LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
)

不难发现，仅第一个形参类型不一致，但均是Icon的实际内容。

而其他三个参数，含义分别为：

• contentDescription: 内容含义描述，用于 无障碍服务 ，如果这个Icon可以被触发，就需要解释它的含义，如果仅仅是装饰性质，可以忽略掉
• modifier: 修饰器
• tint: 着色器，可以直接修改Icon实质内容的颜色。从事Android行业的读者并不陌生

而实质内容可以以三种方式进行描述：

• ImageVector 矢量图
• ImageBitmap 位图
• Painter 可被绘制的内容，这是一个抽象的类，类似于Android中的 Drawable

效果

Compose中已经存在一些矢量图资源，例如：

public val Icons.Filled.Favorite: ImageVector
    get() {
        if (_favorite != null) {
            return _favorite!!
        }
        _favorite = materialIcon(name = "Filled.Favorite") {
            materialPath {
                moveTo(12.0f, 21.35f)
                lineToRelative(-1.45f, -1.32f)
                curveTo(5.4f, 15.36f, 2.0f, 12.28f, 2.0f, 8.5f)
                curveTo(2.0f, 5.42f, 4.42f, 3.0f, 7.5f, 3.0f)
                curveToRelative(1.74f, 0.0f, 3.41f, 0.81f, 4.5f, 2.09f)
                curveTo(13.09f, 3.81f, 14.76f, 3.0f, 16.5f, 3.0f)
                curveTo(19.58f, 3.0f, 22.0f, 5.42f, 22.0f, 8.5f)
                curveToRelative(0.0f, 3.78f, -3.4f, 6.86f, -8.55f, 11.54f)
                lineTo(12.0f, 21.35f)
                close()
            }
        }
        return _favorite!!
    }

当然，按照 MaterialDesign, 存在一系列的风格:

• Filled 默认，图形是内容填充风格
• Outlined 只有描边，不做填充
• Rounded 圆形，例如圆形启动图标
• TwoTone 双调，不确定doc是否写错，和Sharp完全一致，可以看情况搭讪下设计MM，顺带提升下审美
• Sharp 例如直角图标

均可以在Google Fonts进行定制与体验

Icon(
    Icons.Filled.Call,
    contentDescription = "Call"
)
Icon(
    Icons.Outlined.Call,
    contentDescription = "Call"
)
Icon(
    Icons.Rounded.Call,
    contentDescription = "Call"
)
Icon(
    Icons.TwoTone.Call,
    contentDescription = "Call"
)
Icon(
    Icons.Sharp.Call,
    contentDescription = "Call"
)

选取了部分内置图标进行直观感受。

三种资源使用方式以及Tint：

Icon(
    ImageBitmap.imageResource(id = R.drawable.baseline_fingerprint_black_24dp),
    contentDescription = "Check fingerprint",
    tint = Color.Green
)

Image

使用方式

和Icon的使用类似，同样有三个函数：

fun Image(
    bitmap: ImageBitmap,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    alignment: Alignment = Alignment.Center,
    contentScale: ContentScale = ContentScale.Fit,
    alpha: Float = DefaultAlpha,
    colorFilter: ColorFilter? = null
)

fun Image(
    imageVector: ImageVector,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    alignment: Alignment = Alignment.Center,
    contentScale: ContentScale = ContentScale.Fit,
    alpha: Float = DefaultAlpha,
    colorFilter: ColorFilter? = null
)

fun Image(
    painter: Painter,
    contentDescription: String?,
    modifier: Modifier = Modifier,
    alignment: Alignment = Alignment.Center,
    contentScale: ContentScale = ContentScale.Fit,
    alpha: Float = DefaultAlpha,
    colorFilter: ColorFilter? = null
)

和Icon对比，如下参数不同：

• alignment: 内容对齐方式
• contentScale: 缩放，类似Android ScaleType
• alpha: 内容的Alpha通道
• colorFilter: 色彩过滤器，可以实现tint、滤镜矩阵等，非Compose特有，不再展开

值得一提的是, 图片因其信息量大的特性，实际应用过程中，对于远程资源，总是需要考虑：

• 加载耗时
• 清晰度分级
• 缓存

等内容，本篇我们仅学习静态资源的加载, 而和Compose相关的 资源 加载函数，在Icon中已经有代码示例，本节不再赘述。

结语

又很愉快地学完了一些新知识，当然，在Icon和Image中，依旧存在很多我们没有挖掘的内容，但不用着急，在起始阶段，我们仅需要掌握控件的特性和使用方式。

当我们掌握了UI布局相关的内容后，我们会回过头来，再学习他的原理部分。

打个招呼：其实起始阶段的内容都非常简单，但因为我最近比较懒，而且正在处理一件有挑战的事情，占用了很多精力，所以更新有点拖沓

Jetpack Compose | 控件篇（三） -- Switch、CheckBox、RadioButton

写在最前

在之前的文章中，我们学习过Compose 中的 ImageButton。

本篇我们将继续学习 Switch 、 CheckBox 、RadioButton , 这三个控件在 人机交互界面 中也是由来已久。

文中代码均基于 1.0.1版本

如无特殊说明，文中的 Compose 均指代 Jetpack compose

文中代码均可在 WorkShop 中获取，本篇代码集中于 post28 包下

完整系列目录: Github Pages | 掘金 | csdn

Switch

当功能含义如同 开关 一般时，我们可以使用该控件，例如："深色模式"、"飞行模式"

使用方式

fun Switch(
    checked: Boolean,
    onCheckedChange: ((Boolean) -> Unit)?,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    colors: SwitchColors = SwitchDefaults.colors()
)

经过前面的学习，这些参数的含义应该不陌生了。

修改配色可以通过如下API构建 SwitchColors 对象实例

object SwitchDefaults {
    fun colors(
        checkedThumbColor: Color = MaterialTheme.colors.secondaryVariant,
        checkedTrackColor: Color = checkedThumbColor,
        checkedTrackAlpha: Float = 0.54f,
        uncheckedThumbColor: Color = MaterialTheme.colors.surface,
        uncheckedTrackColor: Color = MaterialTheme.colors.onSurface,
        uncheckedTrackAlpha: Float = 0.38f,
        disabledCheckedThumbColor: Color = checkedThumbColor
            .copy(alpha = ContentAlpha.disabled)
            .compositeOver(MaterialTheme.colors.surface),
        disabledCheckedTrackColor: Color = checkedTrackColor
            .copy(alpha = ContentAlpha.disabled)
            .compositeOver(MaterialTheme.colors.surface),
        disabledUncheckedThumbColor: Color = uncheckedThumbColor
            .copy(alpha = ContentAlpha.disabled)
            .compositeOver(MaterialTheme.colors.surface),
        disabledUncheckedTrackColor: Color = uncheckedTrackColor
            .copy(alpha = ContentAlpha.disabled)
            .compositeOver(MaterialTheme.colors.surface)
    ): SwitchColors
}

结合前文学习的知识，我们不难推测，下述的代码并不能真正起到 开关 的功能：

Switch(checked = false, onCheckedChange = {
    Log.d("tag", "onCheckChanged:$it")
})

实际效果可体验WorkShop

我们需要构建一个 "被观测" 的数据源 [注意：这个说法虽然比较形象但并不准确] ，它被 Compose构建的树的节点 所观测，即 该Switch，当其内容发生变化 后，可反映到UI上。

例如：

var checked by rememberSaveable { mutableStateOf(false) }

Switch(checked = checked, onCheckedChange = {
    checked = it
    Log.d("tag", "onCheckChanged:$it")
})

或者：

val checked = remember { mutableStateOf(false) }

Switch(checked = checked.value, onCheckedChange = {
    checked.value = it
    Log.d("tag", "onCheckChanged:$it")
})

当然，按照Compose的用法，这些函数必须要同时存在于 @Compose 的函数块中，这样才能被目标节点所 "观测"

效果将在文末给出

CheckBox

当形式为：选中/不选中 时，可以使用该控件。

使用方式

fun Checkbox(
    checked: Boolean,
    onCheckedChange: ((Boolean) -> Unit)?,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    colors: CheckboxColors = CheckboxDefaults.colors()
)

和 Switch 非常相似，同样的，我们可以修改配色：

object CheckboxDefaults {
   
    @Composable
    fun colors(
        checkedColor: Color = MaterialTheme.colors.secondary,
        uncheckedColor: Color = MaterialTheme.colors.onSurface.copy(alpha = 0.6f),
        checkmarkColor: Color = MaterialTheme.colors.surface,
        disabledColor: Color = MaterialTheme.colors.onSurface.copy(alpha = ContentAlpha.disabled),
        disabledIndeterminateColor: Color = checkedColor.copy(alpha = ContentAlpha.disabled)
    ): CheckboxColors
}

至此，我们意识到，Compose 固定了 Switch , Checkbox 的样式风格，如果定制图标，可以使用 ImageButton 。

如下代码将得到一个最简单可用的 CheckBox

var checked by rememberSaveable { mutableStateOf(false) }

Checkbox(checked = checked, onCheckedChange = {
    checked = it
    Log.d("tag", "onCheckChanged:$it")
})

不同于Android原生控件，Compose 中的 Checkbox 无法添加文字 -- 这很 Compose!.

Compose 贯穿始终的一个原则就是 组合 ， 显然：文字部分应该使用 Text。

RadioButton

Compose 中并没有 RadioButtonGroup 的内容。 也有可能是我没有找到。

但是，这并不重要！Compose 并不推崇在控件内部维护状态，否则会违背 纯函数 的理念。而且，我们可以很轻易地利用 组合 方式外挂一段逻辑，实现单选。

注意：按照一般性的UI设计语言，多选应该利用Checkbox，实现思路有类似之处

如何使用

@Composable
fun RadioButton(
    selected: Boolean,
    onClick: (() -> Unit)?,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },
    colors: RadioButtonColors = RadioButtonDefaults.colors()
)

和前两者不同，RadioButton 的回调函数是 点击回调 含义。

遵照UI设计语言，被点击则意味着 选中，而在单选中，通过逻辑保持该组仅目标项被选中。

通过以下API可以修改配色

object RadioButtonDefaults {
    
    @Composable
    fun colors(
        selectedColor: Color = MaterialTheme.colors.secondary,
        unselectedColor: Color = MaterialTheme.colors.onSurface.copy(alpha = 0.6f),
        disabledColor: Color = MaterialTheme.colors.onSurface.copy(alpha = ContentAlpha.disabled)
    ): RadioButtonColors
}

构建一个单选组：

val tags = arrayListOf("A", "B", "C", "D")
val selectedTag = remember { mutableStateOf("") }

Row {
    tags.forEach {
        Row {
            RadioButton(
                selected = it == selectedTag.value,
                onClick = {
                    selectedTag.value = it
                }
            )

            Text(text = it)
        }

        Spacer(modifier = Modifier.width(20.dp))
    }
}

同样，读者可以按照喜好利用代理的方式创建 可观测数据源

val tags = arrayListOf("A", "B", "C", "D")
var selectedTag by rememberSaveable { mutableStateOf("") }


Row {
    tags.forEach {
        Row {
            RadioButton(
                selected = selectedTag == it,
                onClick = {
                    selectedTag = it
                }
            )

            Text(text = it,modifier = Modifier.clickable {
                selectedTag = it
            })
        }

        Spacer(modifier = Modifier.width(20.dp))
    }
}

而且，按照UX的设计风格，可以灵活的为文字部分添加触发。

思考：如下代码可以实现多选吗？

val tags = arrayListOf("A", "B", "C", "D")
var selectedItems by rememberSaveable { mutableStateOf(linkedSetOf<String>()) }

Row {
    tags.forEach {
        Row {
            Checkbox(checked = selectedItems.contains(it), onCheckedChange = {selected->
                if (selected) {
                    selectedItems.add(it)
                } else {
                    selectedItems.remove(it)
                }
                Log.d("tag", "onCheckChanged:$it,$selected")
            })

            Text(text = it)
        }

        Spacer(modifier = Modifier.width(20.dp))
    }
}

当然不可以！Set 集合内容的变化并无法被观测！那么怎么处理呢？

以目前我们掌握的知识，可以：

• 利用位运算
• 添加一个观测源、组合判断，但这会被lint校验警告

//组合判断 会被警告的做法
val tags = arrayListOf("A", "B", "C", "D")
val selectedItems by rememberSaveable { mutableStateOf(linkedSetOf<String>()) }
var version by rememberSaveable { mutableStateOf(0) }

Row {
    tags.forEach {
        Row {
            Checkbox(
                checked = version != null && selectedItems.contains(it),
                onCheckedChange = { selected ->
                    if (selected) {
                        selectedItems.add(it)
                    } else {
                        selectedItems.remove(it)
                    }
                    version++
                    Log.d("tag", "onCheckChanged:$it,$selected")
                })

            Text(text = it)
        }

        Spacer(modifier = Modifier.width(20.dp))
    }
}

是否还有更加优雅的解法呢？我们先保留这一疑惑，使得我们的探索过程更加的 平稳 、 有趣 ， 而不必在开始阶段花费过多的精力。

效果

结语

很快又到了这一阶段，这意味着我们又掌握了新的知识，同时也产生了更多的疑惑，不过不用心急，所有的谜题最终都会解开。

Jetpack Compose | 控件篇（四）-- Box、Row、Column

在上一篇中，我们完成了 Switch、CheckBox、RadioButton 相关内容的学习，至此，最基本的简单控件我们已经学完，接下来我们将学习 基本的布局。

以Android 为例，我们已经完成了：TextView、Edittext、Button、ImageView、CheckBox、SwitchButton、RadioButton 等内容的学习。

接下来将开始学习布局规则，例如：FrameLayout、LinearLayout、RelativeLayout、ConstraintLayout 等

文中代码均基于 1.0.1版本

如无特殊说明，文中的 Compose 均指代 Jetpack compose

文中代码均可在 WorkShop 中获取，本篇代码集中于 post29 包下

完整系列目录: Github Pages | 掘金 | csdn

Box

类似Android中的 FrameLayout。

在UI设计中，不可避免的会将一些UI元素组合在一起，从外观上进行整体改变，将他们从环境中 "独立" 开来。很自然地诞生了这一方式：以一个节点包裹这些UI元素， 将整体外观设计运用于这一节点上。

注意：这个节点可以根据排布元素的需求灵活的选择布局 -- 在Compose中，这个节点可以是Box，但不一定必须是Box！

使用方式

@Composable
inline fun Box(
    modifier: Modifier = Modifier,
    contentAlignment: Alignment = Alignment.TopStart,
    propagateMinConstraints: Boolean = false,
    content: @Composable BoxScope.() -> Unit
)

很显然，这是一个内联函数，意味着它类似Facade模式的运用，其底层实现较为复杂，这里针对需求场景做了封装，隐匿了大量细节

在当前的学习阶段，我们克制住好奇心，先不探索细节。

参数含义：

• modifier: 修饰器
• contentAlignment：内容对齐方式 注意：这和FrameLayout有区别
• propagateMinConstraints：是否运用最小尺寸到内容，如果为TRUE，内容的最小尺寸将按照modifier中的信息进行设定，否则仅作用于Box
• content：内容 Android中子View的概念

在WorkShop中，我们沿用了 Google的一个demo

Box {
    Box(Modifier.fillMaxSize().background(Color.Cyan))
    Box(
            Modifier.matchParentSize().padding(top = 20.dp, bottom = 20.dp).background(Color.Yellow)
    )
    Box(
            Modifier.matchParentSize().padding(40.dp).background(Color.Magenta)
    )
    Box(
            Modifier.align(Alignment.Center).size(300.dp, 300.dp).background(Color.Green)
    )
    Box(
            Modifier.align(Alignment.TopStart).size(150.dp, 150.dp).background(Color.Red)
    )
    Box(
            Modifier.align(Alignment.BottomEnd).size(150.dp, 150.dp).background(Color.Blue)
    )
}

在这个Demo中，我们可以看到：

• 对齐方式、padding 对 Box的 位置和大小所产生的影响
• 内容按照声明的次序先后进行排布

根据Box的布局限制调整内容

这是不同屏幕尺寸下的一种适配手段

这将使用到：BoxWithConstraints

@Composable
fun BoxWithConstraints(
    modifier: Modifier = Modifier,
    contentAlignment: Alignment = Alignment.TopStart,
    propagateMinConstraints: Boolean = false,
    content: @Composable BoxWithConstraintsScope.() -> Unit
)

和Box的区别在于 content，lambda中的上下文是 BoxWithConstraintsScope 实例，而不再是 BoxScope 实例，据此，我们可以在布局时获知Box的尺寸限制：

@Stable
interface BoxWithConstraintsScope : BoxScope {
    /**
     * The constraints given by the parent layout in pixels.
     * Use [minWidth], [maxWidth], [minHeight] or [maxHeight] if you need value in [Dp].
     */
    val constraints: Constraints
    /**
     * The minimum width in [Dp].
     */
    val minWidth: Dp
    /**
     * The maximum width in [Dp].
     */
    val maxWidth: Dp
    /**
     * The minimum height in [Dp].
     */
    val minHeight: Dp
    /**
     * The maximum height in [Dp].
     */
    val maxHeight: Dp
}

下面展示一个例子：

当Box最大高度小于100dp时，放置一个50*50dp的Box，否则纵向放置两个；初始高度为80dp，通过点击按钮在100dp和80dp间来回切换：

var height by rememberSaveable { mutableStateOf(80) }
BoxWithConstraints(
    modifier = Modifier.height(height.dp)
) {
    val rectangleHeight = 50.dp
    if (maxHeight < rectangleHeight * 2) {
        Box(Modifier
            .size(50.dp, rectangleHeight)
            .background(Color.Blue))
    } else {
        Column {
            Box(Modifier
                .size(50.dp, rectangleHeight)
                .background(Color.Blue))
            Box(Modifier
                .size(50.dp, rectangleHeight)
                .background(Color.Gray))
        }
    }
}

Button(onClick = {
    height = if (height < 100) 100 else 80
}) {
    Text(text = "点击切换高度")
}

效果

高度为80dp时，仅显示一个蓝色色块：

高度为100dp时，显示两个色块：

Row

在Android中，也有Row的概念 TableRow ，它被用在TableLayout中，作为表格的行:

public class TableRow extends LinearLayout {
    //...
}

和Android的 TableRow 类似，Compose中的Row效果等同于 横向的 LinearLayout

使用方式：

@Composable
inline fun Row(
    modifier: Modifier = Modifier,
    horizontalArrangement: Arrangement.Horizontal = Arrangement.Start,
    verticalAlignment: Alignment.Vertical = Alignment.Top,
    content: @Composable RowScope.() -> Unit
)

参数含义：

• modifier: 修饰器
• horizontalArrangement: 纵向上的范围
• verticalAlignment: 横向的对齐方式
• content：内容声明

借用 Google的Demo

Row {
    // The child with no weight will have the specified size.
    Box(Modifier.size(40.dp, 80.dp).background(Color.Magenta))
    // Has weight, the child will occupy half of the remaining width.
    Box(Modifier.height(40.dp).weight(1f).background(Color.Yellow))
    // Has weight and does not fill, the child will occupy at most half of the remaining width.
    // Therefore it will occupy 80.dp (its preferred width) if the assigned width is larger.
    Box(
        Modifier.size(80.dp, 40.dp)
            .weight(1f, fill = false)
            .background(Color.Green)
    )
}

在一行中，先用掉 40*80dp的空间，剩下来的空间 （横向） ，利用Weight进行均分，如果不使用fill策略，将使用给定的宽度。

在WorkShop中，提供了更多的场景Demo，可以发现，使用Weight时，总是：先计算给定尺寸的元素，并对剩余空间使用Weight进行分配。

这一点和Android的LinearLayout相比要更加灵活、好用

纵向对齐方式

通过 verticalAlignment 可以指定纵向的对齐方式，例如纵向居中对齐：

Row(verticalAlignment = Alignment.CenterVertically) {
    //...
}

可以使用：

• Top 顶部对齐，默认
• CenterVertically 居中对齐
• Bottom 底部对齐

横向范围

当Row的尺寸大于内容的尺寸时，可以调整内容的位置：

例如横向的居中

 Row(
    modifier = Modifier.fillMaxWidth(),
    horizontalArrangement = Arrangement.Center) {
    // The child with no weight will have the specified size.
    Box(Modifier
        .size(40.dp, 80.dp)
        .background(Color.Magenta))
}

效果

Column

和 Row类似，但排布方向为纵向

读者可以自行编码以尝试效果，不再赘述

使用方式

inline fun Column(
    modifier: Modifier = Modifier,
    verticalArrangement: Arrangement.Vertical = Arrangement.Top,
    horizontalAlignment: Alignment.Horizontal = Alignment.Start,
    content: @Composable ColumnScope.() -> Unit
) 

参考Row的使用方式

结语

很快又到了说结束的时候，本篇中，我们一同学习了Compose中最基本的布局方式，当然，还有一些问题没有继续往下探索：如果内容超过容器的大小该如何处理呢？

我们将在后续的篇章中继续探索。

Jetpack Compose | 控件篇（五）-- Spacer、LazyRow、LazyColumn & 让Column可滑动

在上一篇中，我们完成了 Box、Row、Column 相关内容的学习，并且留下了一个疑问："如果容器大小不足以承载内容，怎么处理呢？"，这一篇我们一起学习这部分内容。

文中代码均基于 1.0.1版本

如无特殊说明，文中的 Compose 均指代 Jetpack compose

文中代码均可在 WorkShop 中获取，本篇代码集中于 post29 & post30 包下

完整系列目录: Github Pages | 掘金 | csdn

和Android进行简单对比

在Android中，SDK提供了诸如： ScrollView NestedScrollView ListView GridView RecyclerView，等针对各类场景下适用的控件， 基于滑动手势调整内容展示区域，以达到显示更多内容的目的。

进一步探索可以发现：View本身就包含了Scroll机制的 半成品实现，当然，本文我们不去深究Android的内容，借助我们已经掌握的Android知识，引出一点：

基于Scroll机制，用小容器展现大内容的本质：在视图测量的基础上，结合滑动手势处理，调整内容布局，绘制后展现。

在早期的一些文章中，有博主提到：Compose中对应的内容为 ScrollRow，ScrollColumn / LazyRow、LazyColumn。

在早期的预览版中，短暂的存在过 ScrollRow，ScrollColumn等内容，似乎已经被移除

Compose中也是按照这样的思路设计的，我们将在后续的文章中再细致地展开研究，本篇中仅学习如何使用它们。

在真正开始这部分内容之前，先补充一个简单的控件 Spacer，可以简单的创建占位间距，后续的文章中已经没有他的位置了。

Spacer

在之前的文章中，我们学习过Modifier，其中包含一些和布局相关的API，例如：padding、offset，但并无 margin 等内容，按照业内惯例， 如果已经存在一个广为接受的名词，一般不会使用新词，至少词根是一致的 ，在Compose中，使用了Spacer，取缔了Margin的一些使用场景。

注：计算总是有损耗的，不要滥用Spacer,并且很多场景下有特定的方式处理间距，后续会逐渐学习到

如何使用

@Composable
fun Spacer(modifier: Modifier)

一般只需要指定他的宽高尺寸即可，例如：

Spacer(modifier = Modifier.size(3.dp))

LazyColumn

在上一篇文章中，我们已经学习过 Row和Column，它们仅仅是在方向上不一致，在实现上非常类似。同样的，LazyRow和LazyColumn也是如此。

Doc中提到：

The vertically scrolling list that only composes and lays out the currently visible items. The content block defines a DSL which allows you to emit items of different types. For example you can use LazyListScope.item to add a single item and LazyListScope.items to add a list of items.

仅 组合计算 以及 布局 当前可见元素的纵向可滑动列表。内容块定义了一个DSL，允许创建不同类型的元素。

例如：使用 LazyListScope.item 添加单个元素， LazyListScope.items 添加元素列表。

注："内容块定义了一个DSL，允许创建不同类型的元素"，这并不同于Android中概念： RecyclerView#Adapter 具有将数据映射为同类型 ViewHolder 或 不同类型 ViewHolder 的能力。而是指 "添加元素时可以是 单个元素，或者是 元素的列表，这是不同的类型。 字面翻译在中文语境下容易造成误解。

很显然，它类似于Android中的 ListView,RecyclerView, 着重点在于 Lazy，不会将元素一股脑的全计算、布局出来。

所以，它并不对标ScrollView，在它的使用场景下，可滑动需求非常普遍，便默认实现了！

我们前面提到：

在早期的一些文章中，有博主提到：Compose中对应的内容为 ScrollRow，ScrollColumn / LazyRow、LazyColumn

这本没有啥错误，但绝不是被曲解的： "Row和Column 无法提供滑动能力，而是需要使用 LazyRow、LazyColumn"

但气氛已经烘托到这里了，那我们先将其学完，再学习 Row和Column 如何提供滑动能力。

如何使用

@Composable
fun LazyColumn(
    modifier: Modifier = Modifier,
    state: LazyListState = rememberLazyListState(),
    contentPadding: PaddingValues = PaddingValues(0.dp),
    reverseLayout: Boolean = false,
    verticalArrangement: Arrangement.Vertical =
        if (!reverseLayout) Arrangement.Top else Arrangement.Bottom,
    horizontalAlignment: Alignment.Horizontal = Alignment.Start,
    flingBehavior: FlingBehavior = ScrollableDefaults.flingBehavior(),
    content: LazyListScope.() -> Unit
)

各个参数含义：

• modifier：修饰器
• state：用于控制或者观测列表状态
• contentPadding：整体内容周围的一个Padding，注：内容四周的留白，以纵向列表为例，尾部没有展示时看不到尾部的留白 这通过Modifier无法实现， 注：Modifier只能实现列表容器固定的留白间距 。可以使用它在第一个元素前和最后一个元素后留白。 如果需要在元素间留出间距，可以使用 verticalArrangement
• reverseLayout：是否反转列表
• verticalArrangement：子控件纵向的范围。可用于添加子控件之间的间距，以及内容不足以填满列表最小尺寸时，如何排布
• horizontalAlignment：子控件横向对齐方式
• flingBehavior：fling行为的处理逻辑
• content：声明了如何提供子控件的DSL，有两种方式

@LazyScopeMarker
interface LazyListScope {

    fun item(key: Any? = null, content: @Composable LazyItemScope.() -> Unit)

    fun items(
        count: Int,
        key: ((index: Int) -> Any)? = null,
        itemContent: @Composable LazyItemScope.(index: Int) -> Unit
    )

    @ExperimentalFoundationApi
    fun stickyHeader(key: Any? = null, content: @Composable LazyItemScope.() -> Unit)
}

顺带一提：笔者参与的上一个项目中，高频使用RecycleView用作内容呈现，为了便捷的处理 "item之间的间距"、"首尾留白"、"特定item间不应用间距"， 在项目中写了一套部件，后续可以拆出来同大家分享下。

基于LazyListScope.item 方法

在上一篇文章对应的WorkShop内容中，已经出现了这一用法 post29包下。

例如：

private fun LazyListScope.rowDemo() {
    item {
        CodeSample(code = "row sample 1:")
        Row {
            // ignore
        }
    }

    item {
        CodeSample(code = "row sample 2:纵向居中对齐")
        // ignore
    }

    // ignore
}

基于LazyListScope.items 方法

除了直接使用API，SDK中同样提供了部分内联函数，消除处理数据结构的代码冗余：

inline fun <T> LazyListScope.items(
    items: List<T>,
    noinline key: ((item: T) -> Any)? = null,
    crossinline itemContent: @Composable LazyItemScope.(item: T) -> Unit
)

inline fun <T> LazyListScope.itemsIndexed(
    items: List<T>,
    noinline key: ((index: Int, item: T) -> Any)? = null,
    crossinline itemContent: @Composable LazyItemScope.(index: Int, item: T) -> Unit
)

inline fun <T> LazyListScope.items(
    items: Array<T>,
    noinline key: ((item: T) -> Any)? = null,
    crossinline itemContent: @Composable LazyItemScope.(item: T) -> Unit
)

inline fun <T> LazyListScope.itemsIndexed(
    items: Array<T>,
    noinline key: ((index: Int, item: T) -> Any)? = null,
    crossinline itemContent: @Composable LazyItemScope.(index: Int, item: T) -> Unit
)

按照以往Android中的开发经验，我们很容易写出如下的代码：

// WorkShop 中的入口页面，枚举了各个例子对应的Activity
@Composable
fun TestList(activity: Activity, cases: List<Pair<String, Class<out Activity>>>) {
    LazyColumn(contentPadding = PaddingValues(horizontal = 16.dp, vertical = 8.dp)) {
        itemsIndexed(items = cases) { _, item ->
            Column(
                horizontalAlignment = Alignment.CenterHorizontally,
            ) {
                Spacer(modifier = Modifier.size(3.dp))
                Box(
                    modifier = Modifier
                        .height(48.dp)
                        .fillMaxWidth()
                        .background(
                            color = Color.LightGray,
                            shape = RoundedCornerShape(CornerSize(6.dp))
                        )
                        .clickable {
                            activity.startActivity(Intent(activity, item.second))
                        },
                    contentAlignment = Alignment.Center
                ) {
                    Text(text = item.first, color = MainTxt, textAlign = TextAlign.Center)
                }
                Spacer(modifier = Modifier.size(3.dp))
            }
        }
    }
}

TestList(
    activity = this@MainActivity, cases = arrayListOf(
        "Layout samples" to P21LayoutSample::class.java,
        "Draw samples" to P21DrawSample::class.java,
        "Text samples" to P26TextSample::class.java,
        "TextField samples" to P26TextFieldSample::class.java,
        "Button samples" to P26ButtonSample::class.java,
        "Icon samples" to P27IconSample::class.java,
        "Image samples" to P27ImageSample::class.java,
        "Switch,Checkbox,RadioButton samples" to P28SwitchRbCbSample::class.java,
        "Box,Row,Column samples" to P29BoxRowColumnSample::class.java,
    )
)

如果从Android的视角出发，这段代码相当于创建 ViewHolder的ItemView 以及 onBindViewHolder 的实现

Column(
    horizontalAlignment = Alignment.CenterHorizontally,
) {
    Spacer(modifier = Modifier.size(3.dp))
    Box(
        modifier = Modifier
            .height(48.dp)
            .fillMaxWidth()
            .background(
                color = Color.LightGray,
                shape = RoundedCornerShape(CornerSize(6.dp))
            )
            .clickable {
                activity.startActivity(Intent(activity, item.second))
            },
        contentAlignment = Alignment.Center
    ) {
        Text(text = item.first, color = MainTxt, textAlign = TextAlign.Center)
    }
    Spacer(modifier = Modifier.size(3.dp))
}

也就是说，我们利用了ItemView固有的 "留白" 处理了Item之间的间距，显然这不是最佳实践方案！

更加优雅地处理间距和对齐

上文中已经提及：

• contentPadding
• verticalArrangement
• horizontalAlignment

基于此我们对代码进行改造，以减少没用的嵌套

@Composable
fun TestList(activity: Activity, cases: List<Pair<String, Class<out Activity>>>) {
    LazyColumn(
        contentPadding = PaddingValues(horizontal = 16.dp, vertical = 8.dp),
        verticalArrangement = spacedBy(6.dp, Alignment.Top),
        horizontalAlignment = Alignment.CenterHorizontally,
    ) {
        itemsIndexed(items = cases) { _, item ->
            Box(
                modifier = Modifier
                    .height(48.dp)
                    .fillMaxWidth()
                    .background(
                        color = Color.LightGray,
                        shape = RoundedCornerShape(CornerSize(6.dp))
                    )
                    .clickable {
                        activity.startActivity(Intent(activity, item.second))
                    },
                contentAlignment = Alignment.Center
            ) {
                Text(
                    text = item.first,
                    color = MainTxt,
                    textAlign = TextAlign.Center
                )
            }
        }
    }
}

可以得到一致的效果：

让Column可滑动

参考可以实现Row的可滑动

最开始在和Modifier混脸熟的过程中，我们提及了 androidx.compose.foundation 包，并且含有子包： androidx.compose.foundation.gestures，顾名思义，后者和手势处理有关。

• androidx.compose.foundation.gestures.ScrollableKt#scrollable
• androidx.compose.foundation.ScrollKt#verticalScroll
• androidx.compose.foundation.ScrollKt#horizontalScroll

经过这一阶段的学习，我们可以做出一个结论：

Compose 中包含一部分基本的函数，以及结合实际使用场景，在基本函数上 "装饰" 出高级函数

从命名上，我们很容易得知 scrollable 是比较基本的函数，verticalScroll，horizontalScroll 是基于 scrollable 装饰出的高级函数。

阅读源码后也确实验证了我们的推测。

以 verticalScroll 为例，horizontalScroll暂不展开

Doc内容如下：

Modify element to allow to scroll vertically when height of the content is bigger than max constraints allow. In order to use this modifier, you need to create and own [ScrollState] @see [rememberScrollState]

修饰布局元素，当其内容高度超过最大允许的限制时，允许在纵向进行滚动。

注：内容最大高度地限制需要考虑容器的高度、padding、offset等内容

为了使用它，你需要创建并持有 ScrollState 实例，参见 rememberScrollState

方法原型：

fun Modifier.verticalScroll(
    state: ScrollState,
    enabled: Boolean = true,
    flingBehavior: FlingBehavior? = null,
    reverseScrolling: Boolean = false
)

• state：滚动状态，ScrollState实例
• enabled：当触摸事件发生时，是否允许滑动
• flingBehavior：fling处理逻辑
• reverseScrolling：是否反向滑动

Demo

Column(
    modifier = Modifier
        .fillMaxWidth()
        .height(600.dp)
        .verticalScroll(
            state = rememberScrollState()
        )

) {
    Box(
        Modifier
            .fillMaxWidth()
            .height(400.dp)
            .background(Color.Green)
    )

    Spacer(modifier = Modifier.height(50.dp))

    Box(
        Modifier
            .fillMaxWidth()
            .height(400.dp)
            .background(Color.Blue)
    )

}

很显然，内容高度已经超过了最大限制！

效果

结语

至此，Compose中的列表我们已经学习完成，经过简单探索Modifier中滑动的相关内容，掌握了让Column在内容超出展示限制时可以响应滑动的方案。 较为遗憾的是，目前我们所掌握的知识还不足以支撑我们继续探索下去。

当然，在后续的文章中，我们会继续学习相关的基础知识，最终一起探索Compose中深层次的内容

另：最近祖传代码改的有点精神分裂，文章更新效率还是没上的来。读者朋友们，如果觉得我的分享对你有一些帮助，还请点个赞让我知道，给予我支持下去的动力；如果内容写的不好，也烦请留个言把想看的内容告知我，可以在后续的文章中一起交流！

MultiThreading

Java多线程系列

• 总纲
• Java多线程系列--基础知识手册
• Java基础--图解JVM内存模型和JVM线程模型
• Java多线程系列--掌控面试，一文吃透Synchronized锁
• Java多线程系列--一文吃透AQS
• Java多线程系列--一文吃透Lock锁
• Java多线程基础--线程生命周期与线程协作详解
• Java多线程基础--线程的创建与线程池管理
• Java多线程系列--掌握Future，轻松获取异步任务结果
• Java多线程系列--Fork&Join框架，分治的艺术
• Java多线程系列--掌握CompletableFuture，驾驭异步编程
• Java多线程系列--并发工具JUC

Java多线程系列总纲

终于，开始着手写Java多线程系列了。 Java多线程系列 写起来不会很容易，一来：照本宣科是没有必要的，二来，完全脱离书本性知识又是 "空中楼阁"。

在我的计划中，每一篇文章：

• 都从 基础知识 开始入手，整理 必知必会 的内容，这些内容也是面试的常客；
• 在此基础上，结合自身多年的工作经验，挑选、设计案例进行一定地展开，对于基础还不够牢的读者而言，可以在练手中理解书本内容；对于我以及诸位老司机，可以借机反思一下；
• 整理新收获，或者在某些点上深挖一下，尝试突破。

总纲

本篇作为系列的总纲，将发散性的谈一谈Java多线程的内容要点，系列文章将依次展开。

谈到多线程，绕不开的基本概念：操作系统中的 进程 和 线程 以及 JVM线程和操作系统线程的关系。在这个过程中，将涉及到：JVM内存模型 和 JVM方法执行过程 的知识；

*作者按：此处将产生一篇文章：Java基础--图解JVM内存模型和JVM线程模型 *

继而，我们又需要理解 临界资源 和 临界区 的概念，并且接触到 锁 、 内存屏障 、 CAS 、 AQS 的知识；

作者按：这部分基础知识，我将专门汇总一篇 Java多线程系列--基础知识手册，其内容未必能完全详尽，每一块的内容将会在对应篇章中进行展开。锁的知识十分重要，将独立一篇文章：Java多线程系列--掌控面试，一文吃透锁

作者按：一文吃透锁太难了，拆分二至三篇文章 "一文吃透Synchronized锁" 、 "一文吃透AQS"，"一文吃透Lock锁"，2022-03-19

谈及一个事物，绕不开其生命周期、管理、作用关系；对于线程也是如此。

作者按：此处将产生两篇文章：Java多线程基础--线程生命周期与线程协作详解 ; Java多线程基础--线程的创建与线程池管理

至此，我们发现，在多线程协作中，获取在异步的基础上获取结果非常的麻烦，庆幸的是，我们拥有Future这一利器；

作者按：此处将产生一篇文章 Java多线程系列--掌握Future，轻松获取异步任务结果

人总是贪心的，当我们想到可以异步去利用机器性能时，自然会考虑利用并发去充分利用机器性能，但 "左右互搏之术" 很难驾驭，一不小心就会走火入魔，写出bug。 如果一个大型任务可以很方便的被拆分成各种小任务并最终合并得到结果，参考阿姆达尔定律 (Amdahl's Law)，则可以充分利用计算资源。

作者按：此处将产生一篇文章 Java多线程系列--Fork&Join框架，分治的艺术

岁月静好，但Future也有缺陷，我们需要优雅、优雅、优雅地实现异步，驾驭异步。

作者按：此处将产生一篇文章 Java多线程系列--掌握CompletableFuture，驾驭异步编程

至此，武功已经练成，但工欲善其事必先利其器，我们需要还有各类工具帮助我们写好多线程代码。

作者按：此处将产生一篇文章 Java多线程系列--并发工具JUC

至此，我们将至少产生9篇文章，但多线程的知识远不止这么多，创作过程中可能会进行增加，完成情况可以参考下面，喜欢在其他平台阅读的可跳转到掘金或CSDN

完成情况：

• -[ ] Java多线程系列--基础知识手册
• -[x] Java基础--图解JVM内存模型和JVM线程模型, 其他平台：掘金, CSDN
• -[x] Java多线程系列--掌控面试，一文吃透Synchronized锁 Java多线程系列--掌控面试，一文吃透锁 更名为：Java多线程系列--掌控面试，一文吃透Synchronized锁 掘金 CSDN
• -[x] Java多线程基础--线程生命周期与线程协作详解，其他平台：掘金, CSDN
• -[x] Java多线程基础--线程的创建与线程池管理,其他平台: 掘金 , CSDN
• -[x] Java多线程系列--掌握Future，轻松获取异步任务结果,其他平台：掘金 , CSDN
• -[x] Java多线程系列--Fork&Join框架，分治的艺术 ，掘金 ， CSDN
• -[x] Java多线程系列--掌握CompletableFuture，驾驭异步编程，掘金 , CSDN停止更新
• -[ ] Java多线程系列--并发工具JUC

Java基础--图解JVM内存模型和JVM线程模型

前言

各位亲爱的读者朋友，我正在创作 Java多线程系列 文章，严格的说，JVM内存模型的知识并不隶属于Java多线程范畴，但在讨论多线程的过程中，会涉及到相关概念，考虑到它作为 面经常客，故单独成篇进行知识梳理。

在有意无意渲染之下，环境中充斥着焦虑，虽然我并不认为正经面试真的有必要考察这些，毕竟没有几个岗位是开发JVM的。本篇文章将尽最大努力做到容易记忆，帮助各位克服焦虑！

在本篇中，将JVM内存模型以及JVM线程模型的关键知识，形成凝练的图、辅以文字，同读者一起回顾并掌握这些知识。

作者按：本篇按照自己有限的知识进行整理，如有谬误，还请读者在评论区不吝指出

了解系列以及总纲：Java多线程系列

先来看一张 较为完整 的图：

作者按：图片源自亿图图示的模板

再右侧再补充GC部分后，就比较完整了。今天的文章中，类加载部分略去，GC部分略去。

作者按：读者朋友们还是应当将这两部分吃透的，如果面试遇到，可以顺着图展开作答

图中的 Java栈 又称为 Java虚拟机栈 、 虚拟机栈 、 JVM栈 等； 本地栈 即 本地方法栈

JVM内存模型

从上图中，我们将运行时数据区剥出来，形成下图，即JVM内存模型 (内存区域)：

在JVM1.8中，图中的 方法区 为 元数据区

在多线程背景下，我们应个景：

• 堆和方法区是 线程共享 的
• 虚拟机栈、本地方法栈、程序计数器是 线程隔离 的

下面展开谈一谈这五个区域的作用。

以Java虚拟机规范为界，不讨论具体实现

方法区（JVM1.8为元数据区）

方法区的作用为：存放虚拟机加载的：类型信息，域（Field）信息，方法（Method）信息，常量，静态变量，即时编译器编译后的代码缓存

值得注意的是，无法申请到内存时，将抛出 OutOfMemoryError

方法区中存在运行时常量池，字面量、符号引用等存放入其中。

在Hotspot的演变过程中：

• Java6及之前：方法区存在永久代，保存有静态变量
• Java7：进行去永久代工作，虽然还保留着，但静态常量池，如字符串常量池，已经移动到堆中
• Java8：移除永久代，类型信息、域（Field）信息、方法（Method）信息存放在元数据区；字符串常量池、静态变量存放在堆区

作者按：不同的虚拟机实现细节我也没有研究过，感兴趣的读者可以自行研究，如有靠谱文章希望分享下

虚拟机栈

虚拟机栈中保存了 每一次 方法调用 的信息。

每个Java线程创建时，都会创建对应的 虚拟机栈 ，每一次方法调用，都会往栈中压入一个 栈帧。如下图：

而栈帧中，包含：

• 局部变量表：保存函数 （即方法） 的局部变量
• 操作数栈：保存计算过程中的结果，即临时变量
• 动态链接：指向方法区的运行时常量池。字节码中的 方法调用指令 以常量池中指向方法的 符号引用 为参数。
• 方法的返回地址

本地方法栈

和虚拟机栈功能上类似，它管理了native方法的一些执行细节，而虚拟机栈管理的是Java方法的执行细节。

程序计数器

程序计数器记录线程执行的字节码行号，如果当前线程正在运行native方法则为空。也有称之为 PC寄存器

字节码解释器在工作时，通过改变计数器的值来选取下一跳需要执行的字节码指令，分支 、 循环 、 跳转 、 异常处理 、线程恢复 等基本功能都需要依赖计数器来完成。

Java虚拟机的多线程实现方式：通过 轮流切换并分配处理器执行时间 实现

所以，在任意确定的时间点，一个处理器只会处理一个线程中的指令。为了正确地处理 线程切换后的任务恢复 ，每一个线程都具有自身的程序计数器

堆

堆提供了类实例和数组的内存，可以按如下方式划分：

• 新生代 亦可称之年轻代、New Generation
  • Eden区
  • Survivor 区 S0和S1中存在互相移动，一些文章中的from、to是指移动上的逻辑关系
    • S0
    • S1
• 老年代 Old Generation

如下图所示：

划分和对象创建与GC有关，

• 新生成的对象在Eden区
• 触发 Minor GC后，还 "幸存" 的对象移动到S0
• 再次触发Minor GC后，S0和Eden 中存活的对象被移动到S1中，S0清空
• 每次移动时，自动递增计数器，超过默认值时 （印象中是16），移动到老年代，如果Eden中没有足够内存分配，也将直接在老年代中分配内存
• 老年代中依靠Major GC

小总结

将上文的知识点进行汇总后，我们可以得到一张新图：

图片来自亿图图示模板，再次不用画图了😂

JVM线程模型

一个Java线程的实现方式可以有三种：

• 使用内核线程实现
• 使用用户线程实现
• 使用用户线程加轻量级进程混合实现

印象中JVM没有规定线程实现的规范，具体研究需要结合具体的JVM实现，下面我们简单探索一下

内核线程模型

内核线程模型: 完全依赖操作系统内核提供的内核线程（Kernel-Level Thread ，KLT）来实现多线程。这种方式下：线程的切换调度 由 系统内核 完成。

一般而言，程序不会直接使用内核线程，而是使用一种 高级接口 即 轻量级进程（Light Weight Process,LWP）。

图片来自网络

用户进程中，通过 LWP 使用系统的 内核线程 。由于其一对一的关系，又称为 一对一模型

由于 用户线程 与 LWP 一一对应，LWP 是独立的调度单元，因此某个LWP在 用户进程调用过程中 发生阻塞，以及在 系统调用中 发生了阻塞，都不会影响整个进程的执行。

但是LWP依托内核线程，所以 线程操作 需要 依赖系统调用 ，代价是较高的，需要在 用户态（User Mode） 和 内核态（Kernel Mode） 中来回切换； 而且每个 LWP 都需要一个 内核线程 进行支持，因此 LWP 要消耗一定的内核资源，因此一个系统仅可支持 少量有限 的 LWP。

用户线程模型

排除掉 内核线程 ，JVM平台也可以实现 用户线程 User Thread 下文简称 UT ，完全自行实现创建、调度、销毁。

区别于内核线程模型，此时线程的调度不再依赖内核，极少占据内核资源，基本限定在用户态内，所以可以突破量的限制，并且减少线程切换时的损耗。

这样看起来似乎很美好，但难以利用多核CPU的优势，并且一旦产生系统调用发生中断，其他线程也将被中断。

这种 多对一模型 的实用性较低。

混合模型

又称 多对多模型 ，这种方式充分利用了上面两种方式的优点。

这种模型中，既存在UT，也存在LWP。

创建、切换线程(UT)依旧是廉价的，并且可以拥有大量的线程；同时利用 LWP作为UT到KLT（内核线程）的桥梁， 享受了系统内核的线程调度、CPU映射，免去了自行实现系统调用的部分，进行系统调用时，阻塞整个进程的概率也低于 用户线程模型 。

后记

又水了一篇文章，相信各位读者朋友已经基本记住了这些内容，可以愉快的侃大山了。希望疫情早日结束。

Java多线程系列--掌控面试，一文吃透Synchronized锁

前言

各位亲爱的读者朋友，我正在创作 Java多线程系列 文章，本篇我们将分析重点内容：锁

锁是 面试中的常客 ，也是多线程编码中 必不可少 的内容，无论是为了 "面试胜利" ，还是 "写出高质量的代码" ，我们都需要掌握它。

作者按：本篇按照自己有限的知识进行整理，如有谬误，还请读者在评论区不吝指出

了解系列以及总纲：Java多线程系列

本文篇幅较长，内容较为跳跃，可参考导图阅读：

前文拾遗 -- JAVA对象结构

先前已经发布过一篇系列文章：克服焦虑--图解JVM内存模型和JVM线程模型

其中还有一处关键知识没有展开："Java对象包含哪些内容"，这部分内容和锁的实现有关，本篇将由此继续展开。

单刀直入，在HotSpot虚拟机中，一个对象实例可以被划分出三块信息：

• 对象头 Header
• 实例数据 Instance Data，亦有称之对象体
• 对齐填充 Padding

其中对齐填充可能存在，实例数据是供给 应用程序逻辑 使用的，存储了实例的字段信息。接下来重点探讨对象头。

Java对象头

对象头部分的信息主要面向JVM，包含：

• Mark Word
• kclass, 对象对应的类的元数据指针
• array length ，仅数组对象才拥有

整体划分如图所示：

图片来自网络搜索，水印为Java帮帮

Mark Word

Mark Word 用于存储对象运行时数据： 哈希、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳 等。

查找 HotSpot中markOop的doc如下：

// The markOop describes the header of an object.
// Note that the mark is not a real oop but just a word.
// It is placed in the oop hierarchy for historical reasons.
//
// Bit-format of an object header (most significant first, big endian layout below):
//
//  32 bits:
//  --------
//  hash:25 ------------>| age:4    biased_lock:1 lock:2 (normal object)
//  JavaThread*:23 epoch:2 age:4    biased_lock:1 lock:2 (biased object)
//  size:32 ------------------------------------------>| (CMS free block)
//  PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
//
//  64 bits:
//  --------
//  unused:25 hash:31 -->| unused:1   age:4    biased_lock:1 lock:2 (normal object)
//  JavaThread*:54 epoch:2 unused:1   age:4    biased_lock:1 lock:2 (biased object)
//  PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
//  size:64 ----------------------------------------------------->| (CMS free block)
//
//  unused:25 hash:31 -->| cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && normal object)
//  JavaThread*:54 epoch:2 cms_free:1 age:4    biased_lock:1 lock:2 (COOPs && biased object)
//  narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
//  unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)

32位和64位的虚拟机（未开启压缩指针）中分别为32bit和64bit，开启压缩后为32bit

梳理64位虚拟机五种状态下的对象头：

|------------------------------------------------------------------------------------------------------------------|
|                                     Object Header(128bits)                                                       |
|---------------------|--------------------------------------------------------------------------------------------|
|       State         |                                   Mark Word(64bits)               |  Klass Word(64bits)    |
|---------------------|--------------------------------------------------------------------------------------------|
|       Nomal         | unused:25|identity_hashcode:31|unused:1|age:4|biase_lock:1|lock:2 | OOP to metadata object |
|---------------------|--------------------------------------------------------------------------------------------|
|       Biased        | thread:54|      epoch:2       |unused:1|age:4|biase_lock:1|lock:2 | OOP to metadata object |
|---------------------|--------------------------------------------------------------------------------------------|
|  Lightweight Locked |                     ptr_to_lock_record:62                 |lock:2 | OOP to metadata object |
|---------------------|--------------------------------------------------------------------------------------------|
|  Heavyweight Locked |                    ptr_to_heavyweight_monitor:62          |lock:2 | OOP to metadata object |
|---------------------|--------------------------------------------------------------------------------------------|
|     Marked for GC   |                                                           |lock:2 | OOP to metadata object |
|---------------------|--------------------------------------------------------------------------------------------|

排版不方便的话看下图：

如果运行在 HotSpot openJdk VM 上，可以借助："org.openjdk.jol:jol-core:0.9" 打印对象头进行对照。

五种状态下分析对象头的一份参考博客

作者按：此处的知识我们留一个印象即可，Android同学可能只能拿来吹牛

归纳后知识概要如图：

注：32位

锁的常见概念、分类

我们平时会听到关于锁的各种概念名词，前文的表中，我们也看到了 偏向锁 轻量级锁 重量级锁 的身影，接下来简单聊一聊分类以及常见概念。

乐观锁 / 悲观锁

乐观锁和悲观锁是一种相对的 态度 。在并发的背景下，访问临界区时 可能会 发生 "冲突"，不同的态度演变出不同的策略。

悲观 地看，可以 认为冲突一定会发生 ：访问临界区时，自身线程的写入行为一定会影响其他线程，自身线程的读取行为一定会受到其他线程的写入影响！ 所以 必须要进行锁保护 ，通过 "独占"，"排他" 等特性，保障无冲突。 即：悲观地认为，不加锁的并发操作一定会出现冲突，必须加锁

乐观 地看，可以 认为发生冲突是场景限定的事件 ：读不会有冲突，但写入存在冲突可能。所以 只有在写操作时，进行冲突检测，检测到冲突时操作就会失败，返回错误信息

在Java中，悲观锁即各种实际的锁实现，而乐观锁即无锁编程，转为使用CAS算法。

独享锁 / 共享锁

锁可以被访问者独享或者共享，直白地讲：独享锁在某一时间点，只能被一个线程获取，其它线程必须等待锁被持有者释放之后，才可能获取到锁，而共享锁可以被多个线程获取。

独享锁又称独占锁、排它锁。

显然，共享锁认为持有它的线程们在并发操作时并不会发生冲突。

可重入锁 / 非可重入锁

从概念上看：一个线程在持有一个锁的时候，它内部能否再次（多次）申请该锁，如果可以则为可重入锁，否则为不可重入锁。

显然易见：不可重入 将大大增加 死锁 的机率。

作者按：但在线程的基础上实现类似协程的机制时，非可重入将具有重要意义。

公平锁 / 非公平锁

锁需要通过竞争获取，公平 / 非公平指的是 是否按照"先来后到"获取锁。

如果按照申请顺序分配锁，则为公平锁，否则为非公平锁。

我们常用的Synchronized即非公平锁，Java的可重入锁（ReentrantLock）默认为非公平锁，但可以实例化为公平锁。

非公平锁的优点在于吞吐量比公平锁大。

互斥锁、读写锁

独享锁、共享锁的具体实现，读写锁作为读模式时是共享锁。

Java中的 ReentrantLock 是互斥锁，ReadWriteLock 是读写锁实现。

分段锁

分段锁并非是一种锁，而是一种提高效率的设计思路，将临界区进行划分，当某一块区域的写入并不影响其他区域的读取时，就可以采用分段的思路， 对写入区域加锁，读取其他区域则无需竞争锁从而提高效率，例如 ConcurrentHashMap 就采用了这一设计

偏向锁 / 轻量级锁 / 重量级锁

专指 synchronized 的三种锁状态，并且关系到后文中的 锁升级 部分。

在前文中，我们花了很多篇幅梳理 对象头 中的 Mark Word，其中有三种状态：Biased，Lightweight Locked，Heavyweight Locked 于此对应。

• 偏向锁状态：同步代码一直被同一线程访问时，该线程会自动获取锁，降低获取锁的代价。
• 轻量级锁状态：在偏向锁状态时，一旦另一线程竞争该锁，则升级为轻量级锁，竞争的线程通过 有限的自旋 尝试获取锁，如果锁的持有者在此过程中 释放了锁 ， 并被该线程成功获取锁，则可以避免阻塞，减少线程切换，* 挂起和恢复线程是较为昂贵的*。
• 重量级锁状态：当线程完成了有限的自旋后依旧未能获得锁，将不得不进行阻塞以免空耗CPU，此时锁升级为重量级锁

不难理解，按照Java的线程模型，仅多核CPU情况下，采用轻量级锁并利用自旋才有意义。如果是单核CPU，并不存在真正的时间意义上的线程并发，自旋时，持有锁的线程是挂起的，并无释放锁的可能

作者按：Java的线程模型可参见拙作：克服焦虑--图解JVM内存模型和JVM线程模型

自旋锁

基于CAS利用自旋去竞争锁实现同步的一种方式，如前文所言，发生竞争而产生自旋时，当前线程不会阻塞，所以不会直接导致系统调用，减少上下文切换的开销， 但如果一直竞争不到锁，将造成CPU空转，所谓的busy-waiting。对于计算密集型程序而言，可能会带来负面效果。

我们可以利用Atomic实现一个简单的 可重入自旋锁

public class ReentrantSpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    private int count;

    public void lock() {
        Thread current = Thread.currentThread();
        if (current == cas.get()) {
            count++;
            return;
        }
        while (!cas.compareAndSet(null, current)) {
            // Do nothing
        }
    }

    public void unlock() {
        Thread cur = Thread.currentThread();
        if (cur == cas.get()) {
            if (count > 0) {
                count--;
            } else {
                cas.compareAndSet(cur, null);
            }
        }
    }
}

很显然，这也是一个非公平锁、独享锁

Synchronized锁

synchronized 作为Java关键字，提供同步能力，其核心依赖于Java对象的对象头，当一个类对象被作为synchronized锁对象时，其即为 Monitor，JVM通过 进入、退出Monitor 来实现同步

class Foo {

    synchronized static foo() {
    }

    synchronized void bar() {
    }

    void baz() {
        synchronized (Foo.class) {
            //同步块
        }
    }
}

如上代码中展示了三种同步的方式：

• foo() 中锁对应的Monitor为 Foo.class
• bar() 中锁对应的Monitor为 Foo 的对象实例
• baz() 中的同步块可以用任意的对象作为Monitor，演示部分使用了 Foo.class 作为Monitor

注意，Monitor的选取务必慎重，不仅仅要从 同步 的需求角度出发，避免性能损耗，也要注意锁无法正常生效的问题。例如：

我们模拟5个线程同时竞争一个数（初始值为6）并做 -- 运算，读者是否认为它会按照 5、4、3、2、1 的顺序输出？

class Foo {

  Integer integer = 6;

  void minus() {
    synchronized (integer) {
      if (integer > 0) {
        integer--;
      }
      System.out.println(Thread.currentThread().getId() + " -> i:" + integer);
    }
  }

  static class MThread extends Thread {
    final Foo foo;
    final CountDownLatch latch;

    MThread(Foo foo, CountDownLatch latch) {
      this.foo = foo;
      this.latch = latch;
    }

    @Override
    public void run() {
      super.run();
      try {
        latch.await();
        foo.minus();
      } catch (InterruptedException e) {
        e.printStackTrace();
      }

    }
  }

  public static void main(String[] args) {
    Foo foo = new Foo();
    CountDownLatch latch = new CountDownLatch(1);

    for (int i = 0; i < 5; i++) {
      new MThread(foo,latch).start();
    }
    latch.countDown();
    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
}

多执行几次就会发现 可能 会像下面的结果，它并非是一个同步情况的结果，如果想要更顺利的模拟问题的出现，增大线程数即可

> Task :Foo.main()
13 -> i:3
15 -> i:4
12 -> i:3
14 -> i:1
11 -> i:2

如果读者注意了lint，会注意到提示：Synchronization on a non-final field 'integer'

很显然，上面的代码并未采用正确的Monitor，在 integer-- 的过程中，integer实例已经发生变化：

System.out.println(Thread.currentThread().getId() + 
        " -> i:" + integer+","+System.identityHashCode(integer));

我们增加identityHashCode，并增大并发数量到10，输出如下：

13 -> i:0,482590393
15 -> i:1,1722967101
11 -> i:3,1130778910
16 -> i:0,482590393
17 -> i:0,482590393
20 -> i:0,482590393
12 -> i:4,685260083
14 -> i:2,1983109557
19 -> i:0,482590393
18 -> i:0,482590393

显然，锁了个寂寞 。当然，该问题深入研究下去，读者可以一直挖到动态常量池，不再展开。

所以，编码中一定要保持好习惯：Monitor对象不可变，无形中就避开了bug。

锁升级

前文已经提到了锁的升级：

偏向锁 -> 轻量级锁 -> 重量级锁 , 锁的升级是单向的

这其实是 synchronized 内部实现上对锁方式的优化

转换原因

很显然，这一过程充分考虑各种锁的优点和缺点，在相应场景下以期获得最好的性能。

• 偏向锁：没有自旋、没有系统调用，所以 消耗少性能高 ，并且具有可重入特性，在 同一线程执行同步代码 场景下是最优选择，但它具有 撤销锁消耗高 的缺点。
• 轻量级锁：前面已经提到，用CAS取代了阻塞，在 锁持有时间短 的场景下是最优选择，可追求 快速响应 ，但缺点是短时间内无法获取锁时，自旋消耗CPU资源。
• 重量级锁：具备 大吞吐量 ，未竞争到锁的线程不会自旋消耗资源，适合 锁占用时间长，吞吐量需求大 的场景

而从 偏向锁到轻量级锁，意味着多线程竞争，假定锁的持有时间不会太长，有限的自旋可以等到持有者释放锁，而当 轻量级锁升级到重量级锁 ，意味着这一 假设不成立 ，自旋只是在白白消耗，通过挂起和等待唤醒以提升吞吐量

转换过程

从OpenJdk的 WIKI -- Synchronization 可以得到这张图。

为广泛流传的下图的原版

一图胜千言，图中表现的非常明确，读者可以结合WIKI内容自行理解，不再多做赘述。

经常在课程广告中出现的一张图如下,收藏不等于学会：

图片水印Blog.Dreamtobe.cn

一段很长的后记

在拟定系列大纲时，本篇的原名为：Java多线程系列--掌控面试，一文吃透锁，然而写至 JDK中的Lock接口 时， 后知后觉的意识到将 不得不深入源码 并且涉及到 AQS，AQS的内容在大纲中已有单篇计划，展开则篇幅过长不利于阅读，不展开则实在无内容可写。

原章节内容权且作为 开端 、 引子 留于文末：

JDK中的Lock接口

在Jdk1.5之后，存在Lock接口：

public interface Lock {
    //获取锁
    void lock();

    //获取锁，如果线程阻塞状态（未获取到而进入阻塞）被中断则抛出异常
    void lockInterruptibly() throws InterruptedException;

    //尝试获取锁
    boolean tryLock();

    //在给定时间内尝试获取锁，
    boolean tryLock(long var1, TimeUnit var3) throws InterruptedException;

    void unlock();

    Condition newCondition();
}

前四个API均为获取锁的API，unlock 释放锁，通过Condition提供线程通信能力. Condition将在以后的文章中展开

有别于语言关键字 synchronized , 在使用角度上，Lock将需要使用者自行获取锁、释放锁。在内部实现上，区别于 Monitor模式 ，增加了更丰富的功能：

• 支持 锁的公平性
• 获取 当前线程调用lock的次数
• 获取 等待锁的线程数
• 查询 是否存在线程等待获取该锁
• 查询 指定的线程是否在等待获取该锁
• 查询 当前线程是否持有该锁
• 判断 锁是否已被持有
• 加锁时如果中断则不加锁，抛出异常
• 尝试获取锁 的机制，如果锁未被其他线程持有则成功，否则返回失败，不会直接进入阻塞

很显然，限于目标和篇幅，这篇文章不会再和诸位读者一同探索源码，写至此处，我意识到真的无法做到标题中说的："一篇文章吃透锁"。 JDK中还有锁实现，例如常用的：

• ReentrantLock
• ReadWriteLock，一般使用实现类 ReentrantReadWriteLock

作者按：一旦开始深入，将势必谈及AQS，按照计划，这将于后续文章中展开，故本篇不再展开。望读者见谅

真正的后记

这一篇又断断续续写了超过一周，期间我也一度怀疑，这个系列要不要继续下去，对于读者而言，买本书钻研可能是比看本系列更加实在的行为，勘校后的知识准确性 、 文字的准确性 、 表达的结构性 都更胜一筹，博客仅能靠碎片化特性占点便宜。

但一件事情坚定了我将它写下去的信念，我翻看了往年的博客，清晰的意识到：

• 将脑海中的知识，整理后再做 结构化的输出 ，可以牢靠地掌握这些知识，并且在任意时刻都可以完成流畅的表达
• 通过对比，清晰的看到自己的成长
• 文字功力可以通过锻炼得到长足提升

Java多线程基础--线程生命周期与线程协作详解

前言

各位亲爱的读者朋友，我正在创作 Java多线程系列 文章，本篇我们将梳理基础内容：线程生命周期与线程协作

这是非常基础的内容，本篇仅从 知识完整性 角度出发，做一次梳理。

作者按：本篇按照自己有限的知识进行整理，如有谬误，还请读者在评论区不吝指出

了解系列以及总纲：Java多线程系列

线程生命周期

面向对象设计中，广义上对象均具备生命周期，在狭义上，Thread 类实例的 状态 状态的转变即为线程生命周期。

依据JDK 1.5 开始的代码，Thread实例的State存在6种：

• NEW
• RUNNABLE
• BLOCKED
• WAITING
• TIMED_WAITING
• TERMINATED

并且有如下生命周期图：

NEW 新建

尚未 start 的线程的状态，从代码上看：

Thread thread=new Thread();
        thread.start();

在调用start前，即为 NEW 状态。

RUNNABLE 可运行

当start方法被调用后，即进入 RUNNABLE 状态，注意：

• start方法多次调用将返回 IllegalThreadStateException 异常
• RUNNABLE 存在两种细分：ready（就绪）和 running（运行），调用start时，如果native方法 start0 调用成功则线程就绪，调用失败则从 ThreadGroup 中移除。 就绪状态的线程被处理器调度获得CPU时间片，则变为 running

BLOCKED 阻塞

注意，JVM中线程的阻塞状态不同于操作系统的I/O阻塞，仅仅是在等待获取监视器锁，在JVM中，发生在进入（或者 调用过 Object#wait() 之后重新进入）synchronized 块/方法

WAITING 等待

线程进入这种状态意味着："等待其他线程执行特定操作"，笼统的从意图上看，它在等待其他线程的执行结果，当对方完成后唤醒它继续工作。

• Object#wait() with no timeout
• Thread#join() with no timeout
• LockSupport#park()

如上三种方式可以让线程进入 WAITING 状态，只能等待其他线程进行唤醒

TIMED_WAITING 计时等待

类似于 WAITING 只不过这种等待是有时限的，

• 当前线程 Thread#sleep 调用
• 调用Object#wait() with timeout
• 对其他线程调用 Thread#join(long) with timeout
• LockSupport#parkNanos
• LockSupport#parkUntil

会进入这种状态

TERMINATED 终止

线程中的所有任务执行完毕后进入这种状态，运行时异常或者Error也会导致线程进入终止状态。

小结

务必注意，以上6种状态是从jdk1.5开始引入的。

在一些博客、操作系统相关的书籍中，会看到类似下图的内容：

注意，这是操作系统层面进程、或者早期的单线程进程时期的进程生命周期，不能简单的和Java线程生命周期混为一谈。

可以和Java的线程状态进行如下的映射关联：

操作系统是从 CPU使用 的角度谈论线程的状态，而JVM是从自身 管理、调度 的角度谈论线程的状态，更贴切地讲是 服务于监测 ，它受限于JVM显式引入的机制。不难理解：

• OS中的线程：ready、running均对应了 java线程的 RUNNABLE 状态；
• 而OS中的线程因为 I/O 或者 Event wait 让出CPU使用权进入 waiting，并且 I/O、Event 尚未完成时，并不会进入到可使用CPU的 ready 状态。 在JVM层面：
  • 线程可能处在等待监视器锁的 BLOCKED 状态，
  • 也可能是通过操作进入了 WAITING、TIMED_WAITING 状态，
  • 也可能处于 RUNNABLE 状态 ，例如I/O发生时

线程API与线程协作

除却 Thread 中的API，Object中还有和监视器锁有关的API

Object相关API

必须在同步代码中调用（准确的讲：获取了对应的锁方可调用），否则抛出 IllegalMonitorStateException

Object#wait()

使当前线程 立刻 释放锁对象 、进入 WAITING 状态，直到被其他线程唤醒，进入等锁池。

Object#wait(long /*timeout*/)

和

Object#wait(long /*timeout*/,int /*nanos*/)
//jdk 1.8 源码附于下

使当前线程 立刻 释放锁对象 、进入 TIMED_WAITING 状态，直到被其他线程唤醒或者达到时间自动唤醒，进入等锁池。

//附 jdk 1.8
class Object {

    public final void wait(long timeout, int nanos) throws InterruptedException {
        if (timeout < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException("nanosecond timeout value out of range");
        }

        if (nanos > 0) {
            timeout++;
        }

        wait(timeout);
    }
}

Object#notify()

在 同一个等待阻塞池中 随机唤醒一个处于等待中的线程

Object#notifyAll()

在 同一个等待阻塞池中 唤醒所有等待中的线程

Thread中相关的API

static Thread#interrupted()

检测当前线程是否已经中断,调用后将该线程的中断标志位设置为false

static Thread#sleep(long /*millis*/)

使当前线程睡眠，不释放锁对象，让其他线程具有被执行机会

static Thread#yield()

使当前线程放弃cpu的执行权。

但选择执行的线程依赖于线程的优先级，有可能又被重新选中

Thread#interrupt()

中断该线程，实际只是将中断标志设置为true

如果目标线程处在sleep(),join(),wait()中时，目标会收到抛出的 InterruptedException 异常

Thread#join()

阻塞当前线程，等待目标线程执行完毕后唤醒

Thread#join(long /*millis*/)

阻塞当前线程，等待目标线程执行完毕后、或者等待了设定的时间后唤醒

其他API略

线程之间的协作

不难理解，程序往往被设计为通过多个线程之间的协作完成一项复杂的任务，而每个线程所承担的职责也被简化。

但这种设计方式有利亦有弊，所面向的问题过于具化，模型难以复用。

作者按：当然，本文中所指的线程协作，仅局限于线程之间通过监视器锁、线程API让线程执行的顺序有序可控，在此基础上完成整体任务

本篇文章篇幅较短，内容也较为基础、浅显，但部分内容依旧值得深挖，例如JVM如何实现线程管理，可能短期内不会得到明显的提升但可以加深对JVM、OS、程序微观运行过程的理解。

另外，我删除了线程之间协作的WorkShop内容，内容过于干巴巴，如果有机会，我更希望以 三思系列 的形式结合具体实例展开讨论。

Java多线程基础--线程的创建与线程池管理

前言

各位亲爱的读者朋友，我正在创作 Java多线程系列 文章，如果您觉得内容还不错，还请点赞支持一下。

在上一篇文章 中，我们回顾了线程生命周期、线程之间相互协作的知识，本篇我们继续挖掘，增强对线程的理解。

作者按：本篇按照自己有限的知识进行整理，如有谬误，还请读者在评论区不吝指出

了解系列以及总纲：Java多线程系列

重要声明：

出于 方便叙述 或 帮助基础尚且薄弱的读者理解文章内容 的目的，文中举了一些例子，但这些例子并 不能 百分百准确的对应Java中的概念，甚至有些幼稚。

读者朋友们应当注意到这一点，并且清晰的意识到自己的目标是理解Java中的概念与设计，而不必纠结于例子是否有失偏颇。

本篇博客的内容较为散碎，以下是内容大纲，您可以结合它挑选感兴趣的内容片段阅读、重新梳理知识

线程的创建与启动

在上一篇文章中，我们提到，调用 Thread#start() 即可启动该线程，而并未挖掘虚拟机 真正启动 一个线程的 具体过程。

可能会让您失望，这一篇依旧不会挖掘这一细节，因为它对设计、编写优质的多线程应用毫无帮助。

如果您对此感兴趣，以下文章可能会有帮助：

• 面试官问如何启动Java 线程 未查询到源头作者信息
• 从Java到C++,以JVM的角度看Java线程的创建与运行 作者Van96

先回归到概念：

操作系统中的Thread：是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位

JVM中的Thread：A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently. -- 似乎解释了，又似乎没有

"编写应用程序时，不会为了展现自己已经掌握了启动线程的知识而去启动线程"，即线程是手段，这一点并不难理解。应用程序使用线程的目的在于 完成既定任务 ， 并且基于多线程并发能力提高程序的运行效率、或者基于线程的特性界定职责边界使程序有序运行。

举个例子，工厂接了一批订单，需要在能力一致的一批工人中选择一批完成订单的生产，不难理解：工厂老板在意的是订单的完成，而不是工人的名字、星座、爱好。

那么如何定义线程需要完成的任务呢？

在最初的JDK中，存在两种方式：

• 继承Thread类、覆写 run() 方法定义任务

class PrimeThread extends Thread {
    long minPrime;

    PrimeThread(long minPrime) {
        this.minPrime = minPrime;
    }

    public void run() {
        // compute primes larger than minPrime
    }
}

• 组合优于继承的典型例子：实现Runnable接口，作为Thread的任务

class Foo {
    class PrimeRun implements Runnable {
        long minPrime;

        PrimeRun(long minPrime) {
            this.minPrime = minPrime;
        }

        public void run() {
            // compute primes larger than minPrime
        }
    }

    foo() {
        PrimeRun p = new PrimeRun(143);
        new Thread(p).start();
    }
}

随着JDK的发展，也有更多的方式定义任务，我们将在后续的系列文章中展开。

至此，您应该已经意会了 JDK doc 中所说的 a Thread is a thread of execution in a program

线程池

回到前文举得例子，工厂经过长时间的运转，积累了足够的经验，老板突然顿悟：只要工人能够胜任工作，自己完全没有必要了解工人，只需要:

• 评估生产任务量
• 制定好生产计划
• 把任务和计划交给产线即可

完全不用在意是张三做还是李四做。

工人形如线程，产线便形如线程池。结合工厂的实际情况与任务的特性，可以凝练出 几种产线管理方式 。

在Java中，直接或者间接的依靠配置 ThreadPoolExecutor 获得线程池。

作者按：通过简单的搜索，可以发现大量的探讨线程池的博客，可能受面经影响，部分博客均围绕几个常见地面试问题展开。 但务必注意，线程池的知识内容远不止面试题题干所表现的那些内容！相比之下，理解线程池的设计更为重要。

而我的文字功力有限，无法像教科书那样，顺着严谨的大纲递进式展开，还让文字显得 深刻且有趣，只能尽可能推测读者的兴趣点，展开以下内容

接下来，让我们结合生活经验，以工厂产线为例子，反思推导线程池的设计，了解 ThreadPoolExecutor 最基本的知识。

ThreadPoolExecutor 核心设计

上文中，我们以 产线 类比 线程池 ，"工厂对工人的管理方式" 来类比 "线程池的管理设计" ，并且您一定注意到两处重点：任务 、 工人

在线程池中， 上岗工作的线程 可以类比为 工人 ，完成产线收到的任务。

注意，该类比并不完全准确

不难推测，线程池存在两个核心内容：

• 任务队列 BlockingQueue<Runnable> workQueue
• 工作者集合 HashSet<Worker> workers

任务队列用于存储任务，您应该已经注意到，它使用的是juc下的 BlockingQueue 接口。它的本质还是队列，附加了两种特殊的操作：

• 取 时满足 (或等待至满足) 队列非空
• 存 时满足 (或等待至满足) 队列有空余空间

既然是接口，自然可以有不同的实现，您可以使用不同的实现作为线程池的任务队列。

在线程池设计中，通过依赖抽象 即BlockingQueue 进行了解耦，只关心存取的时机。您可以自行决定队列的特性，诸如大小、存储方式、优先级排序等

在先前的系列文章中还未涉及 BlockingQueue ，计划将于后续系列文章中展开，故本文也不会围绕它展开内容

接下来，让我们看一看 一个人上岗成为产线工人的全过程 ，即 Thread 成为线程池 Worker 的过程

成为线程池中的工作者

产线确定了一个岗位，管理者把岗位信息给到人力资源部门，并申请配给人力：getThreadFactory().newThread(this)

人力资源部门派遣了一个 Thread 小T 给到产线，小T已经接受了技能培训，并且知道上岗后从产线的 任务队列 中取任务、出卖体力完成它即可， void runWorker(Worker w)。

小T 就成为了一个 Worker。

您可能意识到，线程池只关心线程的管理，并不关心线程的创建细节，所以再次依赖抽象，对线程创建细节进行了解耦：

public interface ThreadFactory {
    Thread newThread(Runnable r);
}

关于Worker的定义、职责，泛读以下源码即可了然于心：

public class ThreadPoolExecutor extends AbstractExecutorService {
    private final class Worker extends AbstractQueuedSynchronizer implements Runnable {

        /** Thread this worker is running in.  Null if factory fails. */
        final Thread thread;
        /** Initial task to run.  Possibly null. */
        Runnable firstTask;
        /** Per-thread task counter */
        volatile long completedTasks;

        /**
         * Creates with given first task and thread from ThreadFactory.
         * @param firstTask the first task (null if none)
         */
        Worker(Runnable firstTask) {
            setState(-1); // inhibit interrupts until runWorker
            this.firstTask = firstTask;
            this.thread = getThreadFactory().newThread(this);
        }

        /** Delegates main run loop to outer runWorker. */
        public void run() {
            runWorker(this);
        }

        //其他略
    }

    public ThreadFactory getThreadFactory() {
        return threadFactory;
    }

    final void runWorker(Worker w) {
        Thread wt = Thread.currentThread();
        Runnable task = w.firstTask;
        w.firstTask = null;
        w.unlock(); // allow interrupts
        boolean completedAbruptly = true;
        try {
            while (task != null || (task = getTask()) != null) {
                //锁处理和判断略
                try {
                    beforeExecute(wt, task);
                    Throwable thrown = null;
                    try {
                        task.run();
                    }
                    //异常略
                    finally {
                        afterExecute(task, thrown);
                    }
                } finally {
                    task = null;
                    w.completedTasks++;
                    w.unlock();
                }
            }
            completedAbruptly = false;
        } finally {
            processWorkerExit(w, completedAbruptly);
        }
    }
}

您可能留意到，近年来的一些社会不良事件中总会出现一个词：临时工。当然，我并没有任何在此讨论社会问题的意愿， 一条生产线有固定的岗位，也会有按需产生的临时工岗位，甚至完全是临时工岗位，这并不难理解。而线程池也有这样的设计。

public class ThreadPoolExecutor extends AbstractExecutorService {
    /**
     * Core pool size is the minimum number of workers to keep alive
     * (and not allow to time out etc) unless allowCoreThreadTimeOut
     * is set, in which case the minimum is zero.
     */
    private volatile int corePoolSize;

    /**
     * Maximum pool size. Note that the actual maximum is internally
     * bounded by CAPACITY.
     */
    private volatile int maximumPoolSize;
}

注意，线程池在管理时，对线程是一视同仁的，只关心核心线程数量、最大线程数量，并不会依据线程的特征将其分化为 核心/非核心。

产线如何确定一个岗位

上一节我们提到，产线确定了一个岗位后，向人力资源部门要人并安排成为产线工人。

那么产线是如何确定一个岗位的呢？即 线程池如何确定需要增加一个Worker？

产线不会无缘无故的安排工人上岗工作，必然是收到了生产任务，否则就成了合理摸鱼。

顺理成章的，线程池收到一个任务时，在相应的Size限制没有达到时，优先考虑安排线程进行处理，而不是丢到任务队列中等待。

在先前的系列文章中，我们已经了解到，启动线程是较为昂贵了，虽然线程池规划了 核心线程的数量 和 最大线程数量 ，但也不会一开始就全员上岗，而是在任务抵达时逐步的安排线程上岗。

尝试 安排线程上岗 时，

1. 需先判断线程池工作状态，如果线程池已经关闭，自然不会再增加线程，返回失败。比如产线准备停产了，已经接的任务会安排处理，但肯定不会再招工。
2. 如果线程池正常工作，则检查线程数量是否可以继续增加
3. 如果可以继续增加，则尝试更新线程总数，如果失败，则说明在其他线程中也触发了addWorker逻辑，那么线程池的工作状态也可能发生了改变，如果没有改变，则重复步骤2，否则回到步骤1继续检测
4. 上一节中的内容，得到Thread实例并让其成为Worker，开始干活

整个过程中有CAS操作，鉴于有系列文章的撰写计划，文中不再展开，相应代码可参考gist：

参考Gist

向产线（线程池）下达任务

联想一下，市场部门小王拿到了一笔单子，来到产线找到负责人老张，让老张安排干掉

1. 老张拿起了职工工作排期表，发现 还有固定岗位空着 ，则直接向人力资源要人上岗干活；
   1. 注意，招人上岗 可能失败 ，比如老张手上的信息不及时，现在已经满额了，也有可能厂长决定产线要停掉，通知人力资源不要再派人了
2. 假如固定岗位招不来人，老张继续核实： 产线未停产 且 可纳入计划，在未停产且可纳入计划的情况下，把任务排进了计划
   1. 老张还是很严谨的，又再次核实产线生产状态，如果产线已经停产并且该任务没有被领取，则把任务拒掉
   2. 否则检查工人是否在岗，如没有工人在岗，则向人力资源部门要一个 临时工 处理 任务队列中的任务， 如果要不来人，任务也放着
3. 如果产线停产了或者排不进计划了，老张精通人情世故，表示看看能不能拉个临时工来，能拿到人就直接处理，否则就只能拒绝了，
   1. 如果是产线停了或者达到了最大人数，则要不来人 -- 参考上个小节
   2. 否则临时工会处理该任务

而线程池中与此过程也非常类似，代码比较简短：

public class ThreadPoolExecutor extends AbstractExecutorService {
    public void execute(Runnable command) {
        if (command == null) // 小王在忽悠人
            throw new NullPointerException();

        int c = ctl.get();

        //1.
        if (workerCountOf(c) < corePoolSize) {
            //1.i
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        //2.
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            if (!isRunning(recheck) && remove(command)) // 2.i
                reject(command);
            else if (workerCountOf(recheck) == 0) // 2.ii
                addWorker(null, false);
        } else if (!addWorker(command, false)) // 3
            reject(command); // 3.i
    }
}

当你拒绝任务

虽然打工人和老板都想任务及时可靠的被完成，但总有不如意的时候，某些情况下，线程池将不得不拒绝任务。

上文中已经提到：线程池已经关闭、任务队列已经排满。

当线程池拒绝任务时，事情总得有个说法，JDK设计了接口：

public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

在线程池实例化时，需要指明拒绝策略。

JDK中提供了4个策略：

• CallerRunsPolicy -- 在线程池未关闭情况下，访问者线程直接负责处理
• AbortPolicy -- 抛出 RejectedExecutionException 异常，这是运行时异常， 默认策略
• DiscardPolicy -- 这个任务就此罢休
• DiscardOldestPolicy -- 只要线程池没关闭，这件事情就非得干，把排在最前的任务踢掉，重走任务下达流程

蓦然回首，回看构造函数

ThreadPoolExecutor 提供了一系列重载构造函数用于获取特定实例

public class ThreadPoolExecutor extends AbstractExecutorService {
    public ThreadPoolExecutor(
            int corePoolSize,
            int maximumPoolSize,
            long keepAliveTime,
            TimeUnit unit,
            BlockingQueue<Runnable> workQueue,
            ThreadFactory threadFactory,
            RejectedExecutionHandler handler
    ) {
        //ignore 参见gist https://gitee.com/leobert_253/codes/wh495q63tvlipum2snca131
    }
}

以此为例

• int corePoolSize, 核心线程数量
• int maximumPoolSize, 最大线程数量
• long keepAliveTime, 配合 unit 表示的时间，作为IDLE 线程等待任务的超时时间，核心线程如果不允许采用超时机制将一直等待任务（默认）
• TimeUnit unit, 配合 keepAliveTime
• BlockingQueue workQueue 任务队列
• ThreadFactory threadFactory 线程创建工厂
• RejectedExecutionHandler handler 拒绝任务时的策略

当然，这些参数存在一些限制和校验，可参考 gist 进一步阅读，摘自JDK1.8。

线程池的状态标识-ctl的设计

前面的内容中已经提到了线程池Shutdown的状态，线程池具有5个状态，先看一眼代码： 相应的二进制补码已标识

注意，计算机中以补码表示数，如果是有符号数，最高位表示符号，1为负、0为非负，非负数其原码和补码一致，负数的补码： 取原码，符号位不变（保持1），其他位取反，然后加1 得到补码

public class ThreadPoolExecutor extends AbstractExecutorService {
    private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

    /**
     * 即29
     * */
    private static final int COUNT_BITS = Integer.SIZE - 3;

    /**
     * 0010 0000 00000000 00000000 00000000 -1 => 
     * 0001 1111 11111111 11111111 11111111
     *
     * wc = ctl & CAPACITY 低29位存储wc
     * state = ctl & ~CAPACITY 高三位存储状态
     * */
    private static final int CAPACITY = (1 << COUNT_BITS) - 1;

    // runState is stored in the high-order bits
    //补码 111 29个0
    private static final int RUNNING = -1 << COUNT_BITS;
    //补码 000 29个0
    private static final int SHUTDOWN = 0 << COUNT_BITS;
    //补码 001 29个0
    private static final int STOP = 1 << COUNT_BITS;
    //补码 010 29个0
    private static final int TIDYING = 2 << COUNT_BITS;
    //补码 011 29个0
    private static final int TERMINATED = 3 << COUNT_BITS;

    private static int ctlOf(int rs, int wc) {
        return rs | wc;
    }
}

很显然，ThreadPoolExecutor 将32位的int分为不同的区域标识信息，在多线程背景下，使用AtomicInteger，但本质还是int。

将 32位中的 高三位用于存储状态信息，低29位存储 worker-count（即wc），信息存储于ctl中，非常传统的位运算设计。

考虑到篇幅和阅读体验，其他相关的位运算API已经剥离到 gist , 通过位运算解出状态、wc，判断状态大小等

• Running 运行状态（实例化后的默认状态）
• Shutdown 不接收新任务，处理任务队列中的任务
• Stop 不接收新任务，不处理任务队列中的任务，并且中断正在处理的任务
• Tidying 所有的任务已终止时的一个暂态，随后将执行terminate()，成功后进入Terminated状态
• Terminated 彻底终止

生命周期变化如下：

线程池目的

此时，请您想一想，创建线程池机制的目的是什么？

前文提到，线程池是对线程进行管理，显然还不是根源。

• 降低资源消耗。 重复利用已创建的线程，可降低线程创建和销毁造成的消耗。
• 提高响应速度。 线程池中有线程值守，当任务到达时，不需要每次都等待线程创建。注意，并不排除任务排队、必要的线程启动情况
• 提高线程的可管理性，对系统运行状态进行调优。 线程是稀缺资源，不能无限制的创建，使用线程池可以进行统一的分配、监控、调优。

面经常客，JDK中提供的线程池

您一定阅读过一些面经，其中包含线程池的题目。作者可能在引导您向着 "JDK中特定的API所提供的线程池特征" 方面展开作答，或者题目看起来就是这样，也许就是一个面试陷阱

作者按，不要单纯的为了应付面试和放弃了学习的初心。结合问题 讲清楚线程池的设计 要比 单纯的、枯燥的罗列通过调用Executors中的API得到的线程池对应的特征 有意义

在JDK1.5中，Java凝练了4种配置方式，可获得特定管理方式的线程池：

Java依据其特征作为Executors中的方法命名，借用它们作为这4类线程池的别名

• FixedThreadPool 数量固定、线程可重用
• SingleThreadExecutor 仅单个线程
• CachedThreadPool 会根据需要创建新线程的线程池
• ScheduledThreadPool 可定期或周期执行任务的线程池

前文已经提到，它们直接或者间接的使用了 ThreadPoolExecutor，而不是4个继承类！按照其API命名给了它们别名，但并不是类名！

FixedThreadPool

JDK中提供的包装方法如下：

public class Executors {

    public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                0L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<Runnable>());
    }
}

很显然，FixedThreadPool 是一个定额的池，nThreads 即为核心线程数量，亦为最大线程数量，注意值必须大于0。

这条产线的工人就很惨，活多了也不会加派人手，任务排队等待线程空闲；不来活也要在岗位上待着，不会释放线程。

以 LinkedBlockingQueue 作为任务队列，先到的任务先被处理，并且它是无界的。

SingleThreadExecutor

顾名思义，我们会得到一个单一线程的线程池。

public class Executors {
    public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
        return new FinalizableDelegatedExecutorService
                (new ThreadPoolExecutor(1, 1,
                        0L, TimeUnit.MILLISECONDS,
                        new LinkedBlockingQueue<Runnable>(),
                        threadFactory));
    }
}

可能您会疑惑，

new ThreadPoolExecutor(
    1, 1,
    0L, TimeUnit.MILLISECONDS,
    new LinkedBlockingQueue<Runnable>(),
    threadFactory
)

已经得到了一个 核心线程数、最大线程数均为1的线程池，为啥要增加 FinalizableDelegatedExecutorService 的参与？

前文未提及但您可能知道，ThreadPoolExecutor是可以重新配置的！例如重新设置核心线程数量：

public class ThreadPoolExecutor {
    public void setCorePoolSize(int corePoolSize) {
        if (corePoolSize < 0)
            throw new IllegalArgumentException();
        int delta = corePoolSize - this.corePoolSize;
        this.corePoolSize = corePoolSize;
        if (workerCountOf(ctl.get()) > corePoolSize)
            interruptIdleWorkers();
        else if (delta > 0) {
            int k = Math.min(delta, workQueue.size());
            while (k-- > 0 && addWorker(null, true)) {
                if (workQueue.isEmpty())
                    break;
            }
        }
    }

}

而 FinalizableDelegatedExecutorService 继承自 DelegatedExecutorService，扩展了在 finalize() 时关闭线程池。 而后者是一个Wrapper，仅暴露 ExecutorService 接口的功能，通过委托的方式封闭了重新配置线程池的能力。

CachedThreadPool

该池将使用 "线程对象" 缓存方案，核心线程数量为0，全部为临时工，并且基于上文的知识：

1. 如果池中没有Worker，则会新增Worker处理，否则任务放入任务队列等待。
2. 非核心线程可以运用获取任务超时时间，当获取任务超时时，则 processWorkerExit 下岗

public class Executors {
    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                60L, TimeUnit.SECONDS,
                new SynchronousQueue<Runnable>());
    }
}

ScheduledThreadPool

public class Executors {
    public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
        return new ScheduledThreadPoolExecutor(corePoolSize);
    }
}

不同于前三者，此时得到的线程池可 定时 处理任务。

为了实现这一点，ScheduledThreadPoolExecutor

• 使用 DelayedWorkQueue 改变了获取任务的具体实现
• 使用装饰模式包装原始任务，使得任务在满足 周期性 的条件时，能够重新进入任务队列

作者按：JDK中的源码实现非常精彩，值得深读。gist

相信您已经对线程池的设计有了一定的理解，JDK1.8之后也在线程池中增加了Future相关的内容，本文不再继续展开。通过Executors中API的源码，应当已经掌握得到的线程池的特征。

意犹未尽之处

行文至此，内容已经非常冗长，但也不得不告一段落。 文中的部分内容，例如Future、AtomicInteger、CAS等内容，计划在本系列的其他文章中具体展开，文中亦颇多回避。 而DelayedQueue、线程池生命周期变化时的具体细节、线程池的调优等内容，均需要结合代码、场景具体分析，限于文章主题未能尽兴，读者闲暇之余若能将源码再阅读一二，定能有更大的收获。

Java多线程系列--掌握Future，轻松获取异步任务结果

前言

最近因为一些个人原因，未能抽出太多精力更新Java多线程系列，一搁置就是好几个月，先向读者诸君致歉。

在本系列的其他文章中，已经提到过线程之间的相互协作， 通过分工，将程序系统的不同任务进行线程分离，充分利用机器性能、提升特定线程的利用率和程序的体验感。

详见拙作：Java多线程基础--线程生命周期与线程协作详解.

并在线程池相关文章中提到：作为程序构建者，我们更关心线程（组）的特性和它们所执行的任务，并不愿意分心去做线程操作。

详见拙作：Java多线程基础--线程的创建与线程池管理

然而实际开发中，我们同样关心一个任务对程序系统产生的影响，习惯上称之为任务的的执行结果。

Runnable的局限性

在前文中我们谈到，通过编码实现Runnable接口，将获得具有边界性的 "任务"，在指定的线程（或者线程池）中运行。

重新观察该接口，不难发现它并没有方法返回值：

public interface Runnable {
    void run();
}

在JDK1.5之前，想利用任务的执行结果，需要小心的操作线程访问临界区资源。使用 回调 进行解耦是非常不错的选择。

练手小Demo -- 回顾既往文章知识

注意，为了减少篇幅使用了lambda，但jdk1.5之前并不支持lambda

将计算任务分离到其他线程执行，再回到主线程消费结果

我们将计算、IO等耗时任务丢到其他线程，让主线程专注于自身业务，假想它在接受用户输入以及处理反馈,但我们略去这一部分

我们可以设计出类似下面的代码：

虽然它还有很多不合理之处值得优化，但也足以用于演示

class Demo {
    static final Object queueLock = new Object();
    static List<Runnable> mainQueue = new ArrayList<>();
    static boolean running = true;

    static final Runnable FINISH = () -> running = false;

    public static void main(String[] args) {
        synchronized (queueLock) {
            mainQueue.add(Demo::onStart);
        }
        while (running) {
            Runnable runnable = null;
            synchronized (queueLock) {
                if (!mainQueue.isEmpty())
                    runnable = mainQueue.remove(0);
            }
            if (runnable != null) {
                runnable.run();
            }
            Thread.yield();
        }
    }

    public static void onStart() {
        //...
    }

    public static void finish() {
        synchronized (queueLock) {
            mainQueue.clear();
            mainQueue.add(FINISH);
        }
    }
}

再模拟一个计算的线程和任务回调：

interface Callback {
    void onResultCalculated(int result);
}

class CalcThread extends Thread {

    private final Callback callback;

    private final int a;

    private final int b;

    public CalcThread(Callback callback, int a, int b) {
        this.callback = callback;
        this.a = a;
        this.b = b;
    }

    @Override
    public void run() {
        super.run();
        try {
            Thread.sleep(10);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        final int result = a + b;
        System.out.println("threadId" + Thread.currentThread().getId() + ",calc result:" + result + ";" + System.currentTimeMillis());

        synchronized (queueLock) {
            mainQueue.add(() -> callback.onResultCalculated(result));
        }
    }
}

填充一下onStart业务：

class Demo {
    public static void onStart() {
        System.out.println("threadId" + Thread.currentThread().getId() + ",onStart," + System.currentTimeMillis());

        new CalcThread(result -> {
            System.out.println("threadId" + Thread.currentThread().getId() + ",onResultCalculated:" + result + ";" + System.currentTimeMillis());
            finish();
        }, 200, 300).start();

    }
}

复习：优化为使用Runnable

在前文我们提到，如果业务仅关注任务的执行，并不过于关心线程本身，则可以利用Runnable：

class Demo {
    static class CalcRunnable implements Runnable {

        private final Callback callback;

        private final int a;

        private final int b;

        public CalcRunnable(Callback callback, int a, int b) {
            this.callback = callback;
            this.a = a;
            this.b = b;
        }

        @Override
        public void run() {
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            final int result = a + b;
            System.out.println("threadId" + Thread.currentThread().getId() + ",calc result:" + result + ";" + System.currentTimeMillis());

            synchronized (queueLock) {
                mainQueue.add(() -> callback.onResultCalculated(result));
            }
        }
    }

    public static void onStart() {
        System.out.println("threadId" + Thread.currentThread().getId() + ",onStart," + System.currentTimeMillis());

        new Thread(new CalcRunnable(result -> {
            System.out.println("threadId" + Thread.currentThread().getId() + ",onResultCalculated:" + result + ";" + System.currentTimeMillis());
            finish();
        }, 200, 300)).start();

    }
}

不难想象出：我们非常需要

• 让特定线程、特定类型的线程方便地接收任务，回顾本系列文章中的 线程池篇 ，线程池是应运而生
• 拥有比Synchronize更轻量的机制
• 拥有更方便的数据结构

至此，我们可以体会到：JDK1.5之前，因为JDK的功能不足，Java程序对于线程的使用 较为粗糙。

为异步而生的Future

终于在JDK1.5中，迎来了新特性： Future 以及先前文章中提到的线程池, 时光荏苒，一晃将近20年了。

/**
 * 略
 * @since 1.5
 * @author Doug Lea
 * @param <V> The result type returned by this Future's {@code get} method
 */
public interface Future<V> {

    boolean cancel(boolean mayInterruptIfRunning);

    boolean isCancelled();

    boolean isDone();

    V get() throws InterruptedException, ExecutionException;

    V get(long timeout, TimeUnit unit)
            throws InterruptedException, ExecutionException, TimeoutException;
}

尽管已经移除了API注释，但仍然能够理解每个API的含义，不多做赘述。

显而易见，为了增加返回值，没有必要用如此复杂的 接口来替代 Runnable。简单思考后可以对返回值的情况进行归纳：

• 返回Runnable中业务的结果，例如计算、读取资源等
• 单纯的在Runnable执行完毕后返回一个结果

从业务层上看，仅需要如下接口即可，它增加了返回值、并可以更友好地让使用者处理异常：

作者按：抛开底层实现，仅看业务方编码需要

public interface Callable<V> {
    /**
     * Computes a result, or throws an exception if unable to do so.
     *
     * @return computed result
     * @throws Exception if unable to compute a result
     * 防盗戳 leobert-lan https://juejin.cn/user/2066737589654327
     */
    V call() throws Exception;
}

显然，JDK需要提供后向兼容能力：

• Runnable 不能够丢弃，也不应当丢弃
• 不能要求使用者完全的重构代码

所以一并提供了适配器，让使用者进行简单的局部重构即可用上新特性

static final class RunnableAdapter<T> implements Callable<T> {
    final Runnable task;
    final T result;

    RunnableAdapter(Runnable task, T result) {
        this.task = task;
        this.result = result;
    }

    public T call() {
        task.run();
        return result;
    }
}

而Future恰如其名，它代表了在 "未来" 的一个结果和状态，为了更方便地处理异步而生。

并且内置了 FutureTask，在 FutureTask详解 章节中再行展开。

类图

在JDK1.8的基础上，看一下精简的类图结构：

FutureTask详解

构造函数

public class FutureTask {
    public FutureTask(Callable<V> callable) {
        if (callable == null)
            throw new NullPointerException();
        this.callable = callable;
        this.state = NEW;       // ensure visibility of callable
    }

    public FutureTask(Runnable runnable, V result) {
        this.callable = Executors.callable(runnable, result);
        this.state = NEW;       // ensure visibility of callable
    }
}

生命周期

public class FutureTask {
    //新建
    private static final int NEW = 0;

    //处理中
    private static final int COMPLETING = 1;

    //正常
    private static final int NORMAL = 2;

    //异常
    private static final int EXCEPTIONAL = 3;

    //已取消
    private static final int CANCELLED = 4;

    //中断中
    private static final int INTERRUPTING = 5;

    //已中断
    private static final int INTERRUPTED = 6;
}

可能的生命周期转换如下：

• NEW -> COMPLETING -> NORMAL
• NEW -> COMPLETING -> EXCEPTIONAL
• NEW -> CANCELLED
• NEW -> INTERRUPTING -> INTERRUPTED

JDK中原汁原味的解释如下：

The run state of this task, initially NEW. The run state transitions to a terminal state only in methods set, setException, and cancel. During completion, state may take on transient values of COMPLETING (while outcome is being set) or INTERRUPTING (only while interrupting the runner to satisfy a cancel(true)). Transitions from these intermediate to final states use cheaper ordered/lazy writes because values are unique and cannot be further modified.

核心方法

本节从以下三块入手阅读源码

• 状态判断
• 取消
• 获取结果

状态判断API的实现非常简单

public class FutureTask {
    public boolean isCancelled() {
        return state >= CANCELLED;
    }

    public boolean isDone() {
        return state != NEW;
    }
}

取消：

1. 当前状态为 NEW 且 CAS修改 state 成功，否则返回取消失败
2. 如果 mayInterruptIfRunning 则中断在执行的线程并CAS修改state为INTERRUPTED
3. 调用 finishCompletion
   1. 删除并通知所有等待的线程
   2. 调用done()
   3. 设置callable为null

public class FutureTask {
    public boolean cancel(boolean mayInterruptIfRunning) {
        if (!(state == NEW &&
                UNSAFE.compareAndSwapInt(this, stateOffset, NEW,
                        mayInterruptIfRunning ? INTERRUPTING : CANCELLED))) {

            return false;
        }

        try {    // in case call to interrupt throws exception
            if (mayInterruptIfRunning) {
                try {
                    Thread t = runner;
                    if (t != null)
                        t.interrupt();
                } finally { // final state
                    UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED);
                }
            }
        } finally {
            finishCompletion();
        }
        return true;
    }

    private void finishCompletion() {
        // assert state > COMPLETING;
        for (WaitNode q; (q = waiters) != null; ) {
            if (UNSAFE.compareAndSwapObject(this, waitersOffset, q, null)) {
                for (; ; ) {
                    Thread t = q.thread;
                    if (t != null) {
                        q.thread = null;
                        LockSupport.unpark(t);
                    }
                    WaitNode next = q.next;
                    if (next == null)
                        break;
                    q.next = null; // unlink to help gc
                    q = next;
                }
                break;
            }
        }

        done();

        callable = null;        // to reduce footprint
    }
}

获取结果： 先判断状态，如果未进入到 COMPLETING（即为NEW状态），则阻塞等待状态改变，返回结果或抛出异常

public class FutureTask {
    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }

    public V get(long timeout, TimeUnit unit)
            throws InterruptedException, ExecutionException, TimeoutException {
        if (unit == null)
            throw new NullPointerException();
        int s = state;
        if (s <= COMPLETING &&
                (s = awaitDone(true, unit.toNanos(timeout))) <= COMPLETING)
            throw new TimeoutException();
        return report(s);
    }

    private V report(int s) throws ExecutionException {
        Object x = outcome;
        if (s == NORMAL)
            return (V) x;
        if (s >= CANCELLED)
            throw new CancellationException();
        throw new ExecutionException((Throwable) x);
    }
}

如何使用

而使用则非常简单，也非常的朴素。

我们以文中的的例子进行改造:

1. 沿用原Runnable逻辑
2. 移除回调，增加 CalcResult
3. 将 CalcResult 对象作为既定返回结果，Runnable中设置其属性

class Demo {
   static class CalcResult {
      public int result;
   }
   public static void onStart() {
      System.out.println("threadId" + Thread.currentThread().getId() + ",onStart," + System.currentTimeMillis());

      final CalcResult calcResult = new CalcResult();
      Future<CalcResult> resultFuture = Executors.newSingleThreadExecutor().submit(() -> {
         try {
            Thread.sleep(10);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
         final int result = 200 + 300;
         System.out.println("threadId" + Thread.currentThread().getId() + ",calc result:" + result + ";" + System.currentTimeMillis());
         calcResult.result = result;
      }, calcResult);

      System.out.println("threadId" + Thread.currentThread().getId() + "反正干点什么," + System.currentTimeMillis());
      if (resultFuture.isDone()) {
         try {
            final int ret = resultFuture.get().result;
            System.out.println("threadId" + Thread.currentThread().getId() + ",get result:" + ret + ";" + System.currentTimeMillis());
         } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
         }
      }
      finish();
   }
}

如果直接使用新特性Callback，则如下：

直接返回结果，当然也可以直接返回Integer，不再包裹一层

class Demo {
   public static void onStart() {
      System.out.println("threadId" + Thread.currentThread().getId() + ",onStart," + System.currentTimeMillis());

      ExecutorService executor = Executors.newSingleThreadExecutor();
      Future<CalcResult> resultFuture = executor.submit(() -> {
         try {
            Thread.sleep(10);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
         final int result = 200 + 300;
         System.out.println("threadId" + Thread.currentThread().getId() + ",calc result:" + result + ";" + System.currentTimeMillis());
         final CalcResult calcResult = new CalcResult();
         calcResult.result = result;
         return calcResult;
      });

      System.out.println("threadId" + Thread.currentThread().getId() + "反正干点什么," + System.currentTimeMillis());
      if (resultFuture.isDone()) {
         try {
            final int ret = resultFuture.get().result;
            System.out.println("threadId" + Thread.currentThread().getId() + ",get result:" + ret + ";" + System.currentTimeMillis());
         } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
         }
      }
      executor.shutdown();
      finish();
   }
}

相信读者诸君会有这样的疑惑：

为何使用Future比原先的回调看起来粗糙？

首先要明确一点：文中前段的回调Demo，虽然达成了既定目标，但效率并不高！！在当时计算很昂贵的背景下，并不会如此莽撞地使用！

而在JDK1.5开始，提供了大量内容支持多线程开发。考虑到篇幅，会在系列文章中逐步展开。

另外，FutureTask中的CAS与Happens-Before本篇中亦不做展开。

接下来，再做一些引申，简单看一看多线程业务模式。

引申，多线程业务模式

常用的多线程设计模式包括：

• Future模式
• Master-Worker模式
• Guarded Suspension模式
• 不变模式
• 生产者-消费

Future模式

文中对于Future的使用方式遵循了Future模式。

业务方在使用时，已经明确了任务被分离到其他线程执行时有等待期，在此期间，可以干点别的事情，不必浪费系统资源。

Master-Worker模式

在程序系统中设计两类线程，并相互协作：

• Master线程（单个）
• Worker线程

Master线程负责接受任务、分配任务、接收（必要时进一步组合）结果并返回；

Worker线程负责处理子任务，当子任务处理完成后，向Master线程返回结果；

作者按：此时可再次回想一下文章开头的Demo

Guarded Suspension模式

1. 使用缓存队列，使得 服务线程/服务进程 在未就绪、忙碌时能够延迟处理请求。
2. 使用等待-通知机制，将消费 服务的返回结果 的方式规范化

不变模式

在并行开发过程中，为确保数据的一致性和正确性，有必要对对象进行同步，而同步操作会对程序系统的性能产生相当的损耗。

因此，使用状态不可改变的对象，依靠其不变性来确保 并行操作 在 没有同步机制 的情况下，保持一致性和正确性。

1. 对象创建后，其内部状态和数据不再发生改变
2. 对象被共享、被多个线程访问

生产者-消费

设计两类线程：若干个生产者线程和若干个消费者线程。

生产者线程负责提交用户请求，消费者线程负责处理用户请求。生产者和消费者之间通过共享内存缓冲区进行通信。

内存缓冲区的意义：

• 解决是数据在多线程间的共享问题
• 缓解生产者和消费者之间的性能差

这几种模式从不同角度出发解决特定问题，但亦有一定的相似之处，不再展开。

后记

至此，我们已经进入尾声，JDK1.5中，对多线程的支持迎来一波井喷。本文以及系列文章中关于线程池的内容也仅仅是基础中的基础，仍旧有大量的内容值得深入，本篇不再往下挖掘。

在后续的系列文章中，我们将展开AQS、HAPPENS-BEFORE等内容，以及和本文高度关联的CompleteFutureTask，JUC工具等。

Java多线程系列-- Fork&Join框架，分治的艺术

前言

本篇是多线程系列中的一篇，我们在先前的一篇文章中回顾了线程池的主要知识

Java多线程基础--线程的创建与线程池管理

过去了很长时间，我们简单提要一下：

• 设计目的：简化线程的使用，管理与复用，避免直接操作线程
• 如何使用线程池
• 设计实现与源码细节

本篇我们延续下去，回顾 Fork&Join。主要内容如下：

• 使用场景和注意事项
• 设计原理
• 示例代码演示使用方式以及和线程池简单对比

全文总结

内容为基础部分，简单拾遗的读者扫一眼总结即可，若均已掌握，没必要浪费时间阅读细节

• ForkJoinPool是线程池的补充，并不是替代。线程池一般用于处理 独立的 请求、任务
• 适合实现 "分治" 类算法，尤其是分治后递归调用的函数
• 适用于计算密集型，如果是I/O密集型，或者线程间同步等造成长时间阻塞时，可配合ManagedBlocker使用
• Work Stealing（工作窃取）机制 和 双端队列，已经了解设计细节便不需要再看下去了

如何使用

本章非常的基础，已经掌握如何使用，但没有思考过Fork&Join设计思路的读者，可以跳跃到 原理

我们挑选一道简单题 计算斐波那契数 ,并使用递归算法求解。

斐波那契数 （通常用 F(n) 表示）形成的序列称为 斐波那契数列 。该数列由 0 和 1 开始，后面的每一项数字都是前面两项数字的和。也就是：

F(0) = 0，F(1) = 1

F(n) = F(n - 1) + F(n - 2)，其中 n > 1

给定 n ，请计算 F(n) 。

来源：力扣（LeetCode）

Fork&Join 实现

如题，我们需要定义计算任务，这将通过继承 ForkJoinTask 实现，当计算任务不可分（或者没有必要分解）时，自行处理结果返回，否则分解任务。

static class Fibonacci extends RecursiveTask<Long> {
    final int n;

    public Fibonacci(int n) {
        this.n = n;
    }

    @Override
    protected Long compute() {
        System.out.println("compute fib(" + n + "), in thread:" + Thread.currentThread().getName());
        if (n <= 1) {
            return (long) n;
        }
        Fibonacci f1 = new Fibonacci(n - 1);
        f1.fork();

        Fibonacci f2 = new Fibonacci(n - 2);
        f2.fork();

        return f2.join() + f1.join();
    }
}

我们通过 fork() 将子任务丢入任务队列，并通过 join() 得到计算后的结果。

接下来看一看使用ForkJoinPool执行任务：

我们定义一个最大工作线程数为4的ForkJoinPool，并计算 Fib(5) 的结果。可按照CPU核心数取最大工作线程数

注意，因为没有针对计算过程做任何优化，并且使用了输出，不要计算过大的值折腾电脑

class Demo {

    public static void main(String[] args) {
        ForkJoinPool forkJoinPool = new ForkJoinPool(4);
        Fibonacci fib = new Fibonacci(5);
        Long result = forkJoinPool.invoke(fib);
        System.out.println(result);
    }
}

通过 invoke(ForkJoinTask<T> task) 可以在当前线程阻塞式获取计算结果。

通过 execute(ForkJoinTask<?> task) 可以进行异步处理，因为 class ForkJoinTask<V> implements Future<V>， 使用方式和Future一致，复习链接

可以看到，递归过程中有很多的重复,但这源于算法本身，

当递归算法本身会使得子任务产生重复计算或者重复任务时，应当考虑处理中间结果缓存，减少不必要的任务，可以减少重复计算和GC压力。

如果移除控制台输出，一般可以尝试下计算第40个，不建议再计算你更靠后的值。

compute fib(5), in thread:ForkJoinPool-1-worker-1
compute fib(3), in thread:ForkJoinPool-1-worker-1
compute fib(1), in thread:ForkJoinPool-1-worker-1
compute fib(2), in thread:ForkJoinPool-1-worker-3
compute fib(0), in thread:ForkJoinPool-1-worker-3
compute fib(1), in thread:ForkJoinPool-1-worker-0
compute fib(4), in thread:ForkJoinPool-1-worker-2
compute fib(2), in thread:ForkJoinPool-1-worker-2
compute fib(0), in thread:ForkJoinPool-1-worker-2
compute fib(1), in thread:ForkJoinPool-1-worker-2
compute fib(3), in thread:ForkJoinPool-1-worker-2
compute fib(1), in thread:ForkJoinPool-1-worker-2
compute fib(2), in thread:ForkJoinPool-1-worker-0
compute fib(0), in thread:ForkJoinPool-1-worker-0
compute fib(1), in thread:ForkJoinPool-1-worker-3
5

原理

实际上，关于Java ForkJoin设计原理的分析，均源自其开发者 Doug Lea 的论文 A Java Fork/Join Framework 以及结合源码展开讨论。

时间充裕的读者可以看一看论文原文，接下来我们节选论文重要内容进行理解。

分治算法的核心思路

以伪代码描述分治的思想如下，当问题足够小（无需再拆分）时，直接处理，否则拆分问题，处理并汇总结果

Result solve(Problem problem){
    if(problem is small){
        directly solve problem
    }else{
        split problem into independent parts
        fork new subtasks to solve each part
        join all subtasks
        compose result from subresults
    }
}

分治+并行的核心要求

核心要求:框架能够让构建的子任务并行执行，并且拥有一种等待子任务运行结束的机制。

不难理解这一要求。

让我们思考一下，线程池+Future是不是满足这一要求？

很显然，线程池满足这个要求，但线程池的部分策略，甚至Thread的很多核心设计，对于 Fork/Join思路 而言是多余（过剩）的。

哪些是过剩的

包含这几个方面的过剩：

• Thread本身跟踪记录阻塞的手段
• 线程池对线程的管理
• 线程池对任务的管理

首先， 在同步和管理方面，Fork/Join任务只有简单的和常规的需求。例如，Fork/Join任务除了等待子任务执行结果，其他情况下不需要阻塞。 因此传统的用于跟踪记录阻塞线程的代价，是一种过剩。

但这种过剩不会为了Fork/Join而推翻重建

其次，对于合理的基础任务粒度而言，构建和管理一个线程的代价，可能比执行任务花费的代价更大。线程池对线程的多种管理手段，大多是不必要的。

再者，Fork&Join 是处理同一个任务的子任务，它更像是一组 "事务"，只在意最终结果，否则就全部取消并丢弃。 而线程池是面向独立的任务，并且采用了BlockingQueue暂存任务，以保障并发时高效且准确。这些对于Fork&Join 而言，都是没有必要的。

FJTask框架思路图示

注:论文从开始就以 "FJTask框架" 指代了Java中将要实现的Fork&Join框架，以 "FJTask" 指代一个可由分治解决的任务

很朴素的思路，让任务得到拆分，并被指派到合适的工作线程中执行，汇总出结果。

work-stealing

上文中我们已经提及，线程池对于任务的管理机制对于 FJTask框架 而言是过剩的。除此之外，Fork&Join倾向于 "大任务优先" 去窃取任务。

这也是Java API文档中提到的，ForkJoinPool和线程池最大的不同（毕竟核心线程数和最大线程数一致的线程池，管理线程是类似的）

all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist).

This enables efficient processing when most tasks spawn other subtasks (as do most ForkJoinTasks), as well as when many small tasks are submitted to the pool from external clients.

Especially when setting asyncMode to true in constructors, ForkJoinPools may also be appropriate for use with event-style tasks that are never joined.

按照该设计思路，先让每一个工作线程拥有自己的任务队列，这样在管理方式上才有减负的空间。

参考CILK的设计，给FJTask框架制定如下的任务管理策略

• 每一个工作线程维护自身调度队列中的可运行任务
• 队列以双端队列的形式被维护，支持后进先出:LIFO的push和pop操作; 和先进先出:FIFO的take操作
• 工作线程将任务所产生的子任务，放入到工作线程自身的双端队列中
• 处理队列中的任务时，工作线程使用后进先出（LIFO）的策略，递归
• 当一个工作线程，没有本地任务可运行时，它将尝试窃取其他工作线程的任务。此时按照先进先出(FIFO)的策略，即大任务优先。
• 当一个工作线程触及了join操作，它将尝试处理其他任务，直到目标任务被告知已经结束（通过isDone方法）。所有的任务都会无阻塞的完成。

当一个工作线程，没有本地任务可运行，且无法从其他线程中获取任务时，它就会退出（通过yield、sleep和/或者优先级调整）并经过一段时间之后再度尝试直到所有的工作线程都被告知他们都处于空闲的状态。在这种情况下，他们都会阻塞直到其他的任务再度被上层调用。

其中的1-5条，均在下图中得到体现。

椭圆代表了工作线程，它内部维护一个双端队列，通过Pushing 放入任务，通过Popping弹出任务执行，并可能被其他工作者从另一端窃取任务

作者按：源码部分本篇不展开，建议没有读过源码的读者，花点时间泛读一二

ManagedBlocker

这是 ForkJoinPool中采用的，为任务提供扩展管理并行数的接口。

在FJTask中，我们希望充分的发挥多核CPU的计算性能，它被设计的擅长计算，但遇到会阻塞的任务时，CPU则会被浪费。

往往在可能会阻塞的任务中，我们期望能增加线程来处理任务，而不是单纯的阻塞等待。

public static interface ManagedBlocker {

    boolean block() throws InterruptedException;
    
    boolean isReleasable();
}

实现并调用：ForkJoinPool#managedBlock。

isReleasable(): 如果不需要阻塞，则返回 true;

block(): 可能阻塞当前线程，例如等待锁定或条件, 如果没有额外的阻塞必要，返回true。

关于创建补偿线程的细节，不再展开。

Java多线程系列--掌握CompletableFuture，驾驭异步编程

前言

本文隶属于我归纳整理的Android知识体系的第四部分，属于 异步 部分的多线程内容

您可以通过访问 总纲 阅读系列内的其他文章。

作者按：草稿进行了几次大改，移除了Demo部分、源码解析部分、设计原理部分。结合实际工作经验，"掌握API能熟练使用、能无障碍阅读相关框架源码" 已基本够用。

读者可结合下面的导图进行快速的知识自查

一个美好的期望

通常情况下，我们希望代码的执行顺序和代码的组织顺序一致，即代码表述了同步执行的程序，这样可以减少很多思考。

而 阅读异步的程序代码，需要在脑海中建立事件流，当程序业务复杂时，将挑战人的记忆力和空间想象力，并非所有人都擅长在脑海中构建并分析异步事件流模型。

所以，我们期望拥有一个非常友好的框架，能够让我们方便地进行异步编程，并且在框架内部设计有线程同步、异常处理机制。

并且，基于该框架编写的代码具有很高的可读、可理解性。

而Future基本无法满足这一期望。

Future的不足与CompletableFuture的来源

Future的不足

在先前的系列文章中，我们已经回顾了Future类的设计，在绝大多数场景下，我们选择使用多线程，是为了 充分利用机器性能 以及 避免用户交互线程出现长时间阻塞 以致影响体验。

所以我们将耗时的、会引起长时间阻塞的任务分离到其他线程执行，并在 合适时机 进行线程同步，于主线程（一般负责用户交互处理、界面渲染）中处理结果。

详见拙作 掌握Future，轻松获取异步任务结果 、掘金链接

Future 于 Java 1.5版本引入，它类似于 异步处理的结果占位符 ， 提供了两个方法获取结果：

• get(), 调用线程进入阻塞直至得到结果或者异常。
• get(long timeout, TimeUnit unit), 调用线程将仅在指定时间 timeout 内等待结果或者异常，如果超时未获得结果就会抛出 TimeoutException 异常。

Future 可以实现 Runnable 或 Callable 接口来定义任务，一定程度上满足 使用框架进行异步编程 的期望，但通过整体源码可知它存在如下 3个问题 ：

• 调用 get() 方法会一直阻塞直到获取结果、异常，无法在任务完成时获得 "通知" ，无法附加回调函数
• 不具备链式调用和结果聚合处理能力，当我们想链接多个 Future 共同完成一件任务时，没有框架级的处理，只能编写业务级逻辑，合并结果，并小心的处理同步
• 需要单独编写异常处理代码

使用 get(long timeout, TimeUnit unit) 和 isDone() 判断，确实可以缓解问题1，但这需要结合业务单独设计（调优），存在大量的不确定性。不再展开

Java 8中引入 CompletableFuture 来解决 Future 的不足。

CompletableFuture来源

CompletableFuture 的设计灵感来自于 Google Guava 库的 ListenableFuture 类，它实现了 Future接口 和 CompletionStage接口 ， 并且新增一系列API，支持Java 8的 lambda特性，通过回调利用非阻塞方法，提升了异步编程模型。

它解决了Future的不足，允许我们在非主线程中运行任务，并向启动线程 (一般是主线程) 通知 任务完成 或 任务失败，编写异步的、非阻塞的程序。

使用CompletableFuture

最简方式获取实例

使用 CompletableFuture.completedFuture(U value) 可以获取一个 执行状态已经完成 的 CompletableFuture 对象。

这可以用于快速改造旧程序，并进行逐步过渡

class Demo {
    @Test
    public void testSimpleCompletableFuture() {
        CompletableFuture<String> completableFuture =
                CompletableFuture.completedFuture("testSimpleCompletableFuture");

        assertTrue(completableFuture.isDone());
        try {
            assertEquals("testSimpleCompletableFuture", completableFuture.get());
        } catch (InterruptedException | ExecutionException e) {
            e.printStackTrace();
        }
    }
}

改造线程同步部分

部分老旧程序已经建立了多线程业务模型，我们可以使用 CompletableFuture 改造其中的线程同步部分，但暂不改造数据传递。

使用 runAsync() 方法，该方法接收一个 Runnable 类型的参数返回 CompletableFuture<Void>:

//并不改变原项目中数据传递的部分、或者不关心结果数据，仅进行同步
class Demo {
    @Test
    public void testCompletableFutureRunAsync() {
        AtomicInteger variable = new AtomicInteger(0);
        CompletableFuture<Void> runAsync = CompletableFuture.runAsync(() -> process(variable));
        runAsync.join();
        assertEquals(1, variable.get());
    }

    public void process(AtomicInteger variable) {
        System.out.println(Thread.currentThread() + " Process...");
        variable.set(1);
    }
}

进一步改造结果数据传递

当我们关心异步任务的结果数据、或者改造原 多线程业务模型 的 数据传递方式 时，可以使用 supplyAsync() 方法，该方法接收一个 Supplier<T> 接口类型的参数，它实现了任务的逻辑，方法返回 CompletableFuture<T> 实例。

class Demo {
    @Test
    public void testCompletableFutureSupplyAsync() {
        CompletableFuture<String> supplyAsync =
                CompletableFuture.supplyAsync(this::process);
        try {
            // Blocking 
            assertEquals("testCompletableFutureSupplyAsync", supplyAsync.get());
        } catch (ExecutionException | InterruptedException e) {
            e.printStackTrace();
        }
    }

    public String process() {
        return "testCompletableFutureSupplyAsync";
    }
}

指定执行线程池

"获取用于执行任务的线程" 类似 Java 8 中的 parallelStream， CompletableFuture 默认从全局 ForkJoinPool.commonPool() 获取线程，用于执行任务。同时也提供了指定线程池的方式用于获取线程执行任务，您可以使用API中具有 Executor 参数的重载方法。

class Demo {
    @Test
    public void testCompletableFutureSupplyAsyncWithExecutor() {
        ExecutorService newFixedThreadPool =
                Executors.newFixedThreadPool(2);
        CompletableFuture<String> supplyAsync = CompletableFuture.supplyAsync(this::process,
                newFixedThreadPool);
        try {
            // Blocking 
            assertEquals("testCompletableFutureSupplyAsyncWithExecutor", supplyAsync.get());
        } catch (ExecutionException | InterruptedException e) {
            e.printStackTrace();
        }
    }

    public String process() {
        return "testCompletableFutureSupplyAsyncWithExecutor";
    }
}

CompletableFuture 中有众多API，方法命名中含有 Async 的API可使用线程池。

截至此处，以上使用方式均与 Future 类似，接下来演示 CompletableFuture 的不同

回调&链式调用

CompletableFuture 的 get()API是阻塞式获取结果，CompletableFuture 提供了

• thenApply
• thenAccept
• thenRun

等API来避免阻塞式获取，并且可添加 任务完成 后的回调。这几个方法的使用场景如下：

• <U> CompletableFuture<U> thenApply(Function<? super T,? extends U> fn) 收到结果后，可以进行转化
• CompletableFuture<Void> thenAccept(Consumer<? super T> action) 收到结果后，对其进行消费
• CompletableFuture<Void> thenRun(Runnable action) 收到结果后，执行回调，无法消费结果只能消费 这一事件

API较为简单，不再代码演示

显然，通过链式调用可以组装多个执行过程。

有读者可能会疑惑：Function 和 Consumer 也可以进行链式组装，是否存在冗余呢？

两种的链式调用特性确实存在重叠，您可以自行选择用法，但 thenRun 只能采用 CompletableFuture的链式调用。

另外，前面提到，我们可以指定线程池执行任务，对于这三组API，同样有相同的特性，通过 thenXXXXAsync 指定线程池，这是 Function 和 Consumer 的链式组装所无法完成的。

class Demo {
    @Test
    public void testCompletableFutureApplyAsync() {
        ExecutorService newFixedThreadPool = Executors.newFixedThreadPool(2);
        ScheduledExecutorService newSingleThreadScheduledExecutor = Executors.newSingleThreadScheduledExecutor();
        // 从线程池 newFixedThreadPool 获取线程执行任务 
        CompletableFuture<Double> completableFuture =
                CompletableFuture.supplyAsync(() -> 1D, newFixedThreadPool)
                        .thenApplyAsync(d -> d + 1D, newSingleThreadScheduledExecutor)
                        .thenApplyAsync(d -> d + 2D);
        Double result = completableFuture.join();
        assertEquals(4D, result);
    }

}

聚合多个CompletableFuture

通过 聚合 多个 CompletableFuture，可以组成更 复杂 的业务流，可以达到精细地控制粒度、聚焦单个节点的业务。

注意：操作符并不能完全的控制 CompletableFuture 任务执行的时机，您需要谨慎的选择 CompletableFuture 的创建时机

thenCompose、thenComposeAsync

compose 原意为 组成， 通过多个 CompletableFuture 构建异步流。

在操作的 CompletableFuture 获得结果时，将另一个 CompletableFuture compose 到异步流中，compose的过程中，可以根据操作的 CompletableFuture 的结果编写逻辑。

与 thenApply 相比，thenCompose 返回逻辑中提供的 CompletableFuture 而 thenApply 返回框架内处理的新实例。

注意，这一特性在使用 FP编程范式进行编码时，会显得非常灵活，一定程度上提升了函数的复用性

API含义直观，不再进行代码演示

thenCombine、thenCombineAsync

thenCombine 可以用于合并多个 独立任务 的处理结果。

注意： thenCompose 进行聚合时，下游可以使用上游的结果，在业务需求上一般表现为依赖上一步结果，而非两者相互独立。

例如，产品希望在博客详情页同时展示 "博客的详情" 和 "作者主要信息" ，以避免内容区抖动或割裂的骨架占位。这两者 可以独立获取时 ，则可以使用 thenCombine 系列API，分别获取，并合并结果。

combine 的特点是 被合并的两个 CompletableFuture 可以并发，等两者都获得结果后进行合并。

但它依旧存在使用上的不便捷，合并超过2个 CompletableFuture 时，显得不够灵活。可以使用 static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) API。

allOf 创建了 CompletableFuture<Void>，并不会帮助我们合并结果，所以需要自行编写业务代码合并，故存在 Side Effects。

runAfterBoth、runAfterBothAsync;runAfterEither、runAfterEitherAsync

• runAfterBoth 系列API在两个 CompletableFuture 都获得结果后执行回调
• runAfterEither 系列API在两个 CompletableFuture 任意一个获得结果后执行回调

通过API，不难理解它们需要使用者自行处理结果

• CompletableFuture<Void> runAfterBoth(CompletionStage<?> other, Runnable action);
• CompletableFuture<Void> runAfterEither(CompletionStage<?> other, Runnable action)

同样可以增加编码灵活性，不再赘述。

applyToEither、applyToEitherAsync；acceptEither、acceptEitherAsync;thenAcceptBoth、thenAcceptBothAsync

• applyToEither 系列API表现如 thenApply 和 Either 的组合，两个同类型的 CompletableFuture 任意一个获得结果后，可消费该结果并进行改变，类似 thenApply
• acceptEither 系列API表现如 thenAccept 和 Either 的组合，两个同类型的 CompletableFuture 任意一个获得结果后，可消费该结果，类似 thenAccept
• thenAcceptBoth 系列API表现如 thenCombine，但返回 CompletableFuture<Void>

同样可以增加编码灵活性，不再赘述

结果处理

使用回调处理结果有两种API，注意，除了正常获得结果外还可能获得异常，而这两组API簇差异体现在对 异常 的处理中。

<U> CompletableFuture<U> handle(BiFunction<? super T, Throwable, ? extends U> fn) CompletableFuture<T> whenComplete(BiConsumer<? super T, ? super Throwable> action)

handle 使用 BiFunction，无论是正常结果还是异常情况，均视作可被逻辑接受，消费后转化

而 whenComplete 使用 BiConsumer，仅可消费但不能转化，异常情况被视作不可被逻辑接受，仍会抛出。

举个例子，进行网络编程时会遇到 Exception, 如果业务设计中使用的模型实体包含了 正常结果、异常 两种情况：

open class Result<T>(val t: T?) {
    open val isThr: Boolean = false
}

class FailResult<T>(val tr: Throwable) : Result<T>(null) {
    override val isThr: Boolean = true
}

则适合使用 handle API在底层处理。否则需要额外的异常处理，可依据项目的设计选择处理方式，一般在依据FP范式设计的程序中，倾向于使用handle，避免增加side effect。

异常处理

在多线程背景下，异常处理并不容易。它不仅仅是使用 try-catch 捕获异常，还包含程序异步流中，节点出现异常时流的业务走向。

在 CompletableFuture 中，节点出现异常将跳过后续节点，进入异常处理。

_如果您不希望某个节点抛出异常导致后续流程中断，则可在节点的处理中捕获并包装为结果、或者对子 CompletableFuture 节点采用 handle、exceptionally API转换异常 _

除前文提到的 handle whenComplete，CompletableFuture 中还提供了 exceptionally API用于处理异常

CompletableFuture<T> exceptionally(Function<Throwable, ? extends T> fn)

从表现结果看，它类似于 handle API中对异常的处理，将异常转换为目标结果的一种特定情形。

IO

IO系列

• Java IO 系列总纲
• Java IO系列 | 经典 IO
• Java IO 系列 | NIO-1.0一文速览
• Java IO系列 | NIO-1.0拾遗、NIO-2.0 & 零拷贝必吹的牛皮
• IO系列 | 一文掌握OKHTTP中的OKIO为什么这么OK

Java IO 系列总纲

在Android开发中，不可避免的会接触到IO，抛开系统部分的IO，在应用开发领域，仍然会接触到IO，诸如：

• 文件读写
• 网络通信

或许您在开发中不再直接使用JDK中的API完成IO部分的功能，但仍有必要了解相关知识。

JAVA的IO，通过虚拟机建立在操作系统的IO之上，在梳理JAVA的IO时，可适当了解操作系统部分IO的相关知识，但本系列不会深究。

大纲

本系列中，计划包含以下内容：

• JAVA 经典IO 一篇
• JAVA NIO 1-3篇
• OK-IO 1篇
• Linux系统中的IO（如有必要）
• IO模型概览 本文顺带

下图表现了一个冯诺依曼机的结构：

在操作系统中，IO操作会涉及到 用户空间、内核空间的切换 ，以及 内核空间、用户空间之间的数据拷贝 ，接下来就常见的IO模型，简单了解下概念和设计理念。

注：不同操作系统在实现时会存在一定差异，不做深究

IO模型

• 阻塞I/O(blocking I/O)
• 非阻塞I/O(non-blocking I/O)
• I/O复用(I/O multiplexing)
• 信号驱动式I/O(signal-driven I/O)
• 异步I/O(asynchronous I/O)

阻塞I/O(blocking I/O)

阻塞IO、BIO、Blocking IO

在 内核IO操作 彻底完成后，才返回 用户空间 执行应用的操作。

此过程中，用户空间程序的执行状态是阻塞的，程序需等到IO操作彻底完成。

以读为例，示意图如下

非阻塞I/O(non-blocking I/O)

注意，此处不要与 JAVA的nio包 内容混淆

非阻塞IO

相比于BIO，NIO中 数据等待阶段 是非阻塞的，操作系统不会挂起应用。

类似于JAVA中使用Future进行非阻塞多线程编程，以读为例，应用 轮询 内核，数据是否完成，数据准备就绪后，发起系统调用获取数据，系统调用的过程中，应用阻塞。

轮询： 应用进程对非阻塞描述符循环发送系统调用，以查看某个操作是否就绪

以读为例，示意图如下

I/O复用(I/O multiplexing)

I/O复用

经典的Reactor设计。进程通过将一个或者多个操作阻塞在 select 阶段，select可以帮我们检测 fd（文件操作符） 是否处于就绪状态。

如果有数据准备好，就返回可操作的信息，再进行进一步地读写操作

当需要观测的fd很多时，数据准备的占比可能变高，轮询的收益会降低，而多路复用会得到更高的收益。

以读为例，示意图如下

信号驱动式I/O(signal-driven I/O)

信号驱动式I/O

在数据准备阶段，不再阻塞等待，内核准备好数据后，通过信号通知用户空间，用户空间的应用发起系统调用，阻塞获取数据

以读为例，示意图如下

异步I/O(asynchronous I/O)

异步I/O

不同于信号驱动式I/O，在数据等待完成后，进行内核到用户空间的数据拷贝，完成后信号通知应用程序处理数据

Java IO系列 | 经典 IO

前言

Android 开发中不可避免会接触到IO，本篇作为系列中的第一篇，将和大家一同花费5分钟的时间，梳理 经典IO 的知识。

重点内容脑图如下，文章亦按照此结构展开，如已熟练掌握，可跳过

作者按：在一些文章、资料中，将JDK1.4前的IO内容，称为 经典IO、 BIO 、 标准IO 、 Blocking IO 、传统IO 、 Java IO。 都有一定的道理，但注意 BIO 、Blocking IO 此类称谓可能引起混淆。本系列中以 经典IO 指代JDK1.4 前的IO

JAVA 经典IO 概述

流模型与分类

在经典IO中，流(stream)是对数据传输的总称。流代表数据的流动。

• 按 操作单位 ，可以分为
  • 字节流 ，操作对象为字节
  • 字符流 ，操作对象为字符，涉及到编码
• 按 数据流方向 ， 可以分为：
  • 输入流 ， 输入流代表从某个地方(硬盘、内存、网络等)读入内存
  • 输出流 ， 输出流代表从内存写出到某个地方
• 按 功能类型 ， 可以分为：
  • 节点流 ， 节点流代表数据的源头和终点，常见的有文件流、数组流和管道流等
  • 处理流 ， 处理流是连接在节点流之上，为节点流提供某种额外的功能,如缓冲、转换等

优点

不难想象，IO的 场景 和 处理过程 是多而繁杂的，因此需要 加以抽象 、并 建立类簇，以满足程序设计的通用性和扩展性，而 流 的抽象非常贴切，包含了最基础的操作API。 对于调用方而言非常友好。

局限性

经典IO 设计中采用 同步阻塞机制 。以读为例，调用 read() 方法时，如果数据尚未就绪，线程会阻塞。这会降低程序的运行效率，在网络IO中更加明显。

对于IO负荷较小的客户端程序，尚可接受，但对于 高负载 、高并发 的服务器环境，经典IO存在明显的瓶颈，并不能充分发挥硬件性能和带宽。

字节流

按照数据流方向，JDK中设计有两个基类：

• InputStream 读取字节数据的抽象父类
• OutputStream 写出字节数据的抽象父类

UML

JDK中主要的类UML图如下：

作者按：每个子类的具体作用不再展开，如您尚不清楚部分类的作用，可直接阅读JDK中的注释

• FileInputStream 和 FileOutputStream:用于读写文件
• BufferedInputStream 和 BufferedOutputStream:带缓冲的文件流,可以提高读写效率
• DataInputStream 和 DataOutputStream:用于读写基本数据类型
• ByteArrayInputStream 和 ByteArrayOutputStream:操作内存中的字节数组
• ObjectInputStream 和 ObjectOutputStream:用于读写可序列化的对象

当下，应用中 ObjectInputStream、ObjectOutputStream 使用相对较少，一般会将其序列化为JSON、XML存储或映射到数据库。

对象类必须满足以下条件：

• 实现 java.io.Serializable 接口。
• 该类 除transient关键字修饰 的所有属性必须是可序列化的。

class Demo {
    public static void main(String[] args) throws Exception{
        // 写对象
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("object.txt"));
        oos.writeObject(new Person("张三", 25));
        oos.close();

        // 读对象
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("object.txt"));
        Person p = (Person) ois.readObject();
        ois.close();

        System.out.println(p.getName() + ", " + p.getAge());
        // 张三, 25
    }
}

字符流

按照数据流的方向，JDK中设计有两大基类：

• Reader :读取字符数据的抽象父类。
• Writer :写出字符数据的抽象父类。

UML

JDK中主要的类UML图如下：

• FileReader 和 FileWriter :用于读取和写入字符文件
• BufferedReader 和 BufferedWriter :带缓冲的文件字符流,可以提高读写效率
• CharArrayReader 和 CharArrayWriter :读取和写入内存字符数组
• PipedReader 和 PipedWriter :pipe输入流、输出流,线程间通信
• InputStreamReader 和 OutputStreamWriter:将字节流转化为字符流,作为桥梁使用

不再展示使用方式

缓冲流

缓冲流内部有一个缓冲区,可以减少实际读取数据的次数,从而提高流的读取、写入效率。

缓冲流是一种加强的流, 内部拥有一个 缓冲区 ,可以 减少系统调用的次数,从而提高读写效率 。

Java 提供了以下的缓冲流:

• 字节缓冲流 BufferedInputStream 和 BufferedOutputStream : 对 FileInputStream 和 FileOutputStream 加以缓冲
• 字符缓冲流 BufferedReader 和 BufferedWriter : 对 FileReader 和 FileWriter 加以缓冲