哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

开场

大家好！我是扔物线朱凯。

Java 和 Kotlin 的反射我们都知道啊，高级特性，它能帮我们突破禁忌，去做一些正常情况下做不到的事，很强。

另外它也有劣势，比如性能和兼容性。尤其是性能，对于 Android 这种性能受限的场景，我们对所有「性能差」的方案都是非常谨慎的。有个典型的例子就是 Dagger：Google 很早就有一个基于注解的依赖注入库 Guice，但是 Square 却又创建了一个用途和用法都差不多的库——Dagger。区别主要在于底层实现，Guice 是通过运行时用反射读取注解来实现的，而 Dagger 基本上没有用反射，而是用的 Annotation Processor。你看，废了一大番工夫，做了个一样的东西，只是为了避免反射所带来的性能损耗，足以说明反射的可怕。另外网上也有很多文章，告诉我们反射的性能非常差，一定要谨慎使用。

那么这儿其实就有个问题：它的性能到底有多差？摸到它的边界，我们才知道什么时候用它、用到什么程度，对吧？这就是今天咱要聊的话题。

反射是啥

反射之所以慢，跟它的原理是直接相关的。 

大家想过为什么这个功能叫「反射」吗？它原本的英文叫 reflection。这个词有「反射」的意思，但是它用在编程里的时候的本意其实不是反射，而是「自省」，指的是人对于自己的行为啊、发生过的事啊进行深刻的反思，并且期望通过这些反思来让自己以后可以做得更好或者避免同样的问题之类的，这种行为在英文里也叫 reflection。而这个，才是编程里的 reflection——也就是反射——的本意。在 Java 里面，reflection 的意思就是「程序进行自我探查，看到自己深处的、没有直接通过 API 暴露出来的性质」，比如列出自己内部的所有方法，或者根据方法名的字符串来获取指定的方法；另外在实际的功能上，Java 还做了延伸，Java 的反射还允许程序对自己进行性质和功能的动态修改。reflection 这个词的本意只有自省，没有自我修改的意思——人怎么自我修改啊，长出第三条腿？是吧。但是 Java 的反射是支持的。 

所以「反射」这个词，它实质上是「自省」或者说「自我探查」的意思——如果从这个翻译来解释，它的名字就比较直观了吧？

反射有什么用

反射具体的用途有很多，大致可以归为两类：一类是用来访问那些本来访问不到的 API，一类是动态的功能拓展。 

有些 API 由于加了 private 的限制，不能被公开访问，但是我们又需要在某些情况去访问它们——比如在测试流程里我们可能需要通过一些私有 API 来做测试场景的初始化——但并不希望真的把这些 API 给写成 public 的，那么就可以用反射来在程序运行过程中强行进行这些访问。

反射还有个经典的应用场景是动态代理，也就是在运行时根据实时需求来动态地创建新的类型，以及这些类型的实例化对象。比如 Retrofit 的网络访问就是通过动态代理来实现的。

反射为什么慢

反射的功能和定位大概就是这么回事。然后，我们更深入一步：反射为什么慢？——很简单，因为它是动态的。

Java 的 JIT（Just-In-Time），也就是即时编译的优化，反射绝大多数情况下是用不了的。因为 JIT 需要从字节码里获取足够多的上下文信息才能做优化，而反射都是动态的，没什么上下文，就很难优化。 

另外，由于反射是通过「自我探查」的方式来动态获取信息，这种动态获取所包含的信息查找过程——例如通过方法名来查找方法——也需要耗时。相比起来，正常的代码是我们要访问的时候，虚拟机已经知道我们要访问的对象在什么位置了，运行时就不用再查找了。

还有更多的原因，比如反射的调用还需要程序对访问权限做动态检查，以及需要我们在代码里增加异常处理，等等等等，这些都是会耗时的。我们不需要对它们做完整了解，只要知道反射的「动态自我探查」这个本质，的确导致了它是一定比普通代码要慢的，这是个脱不掉的本质弱点。由于动态，所以灵活；但同样由于动态，所以性能差。

有多慢？

不过，到底有多慢呢？ 我做了一个测试：在我的三星 S20 上面，执行一个直接返回数值 1 的 Java 方法：

我分别用直接调用和反射调用的方式来执行它：

执行一千万次，正常调用的耗时是 24 ms，而反射的耗时是 4716 ms，也就是 4 秒多。

可以看出来什么？

很明显，反射的性能比正常调用是差很多的。对吧？所以相比起普通的代码，我们在使用反射的时候的确会耗时更久，从而更容易导致界面的卡顿，甚至是 ANR（程序无响应）。大致估一下，一百多倍的差距，很大了。

我不止在这部真机上，还在两个虚拟机上做了测试，结果是差不多的：

这个「一百多倍」的比值，其实并没有经过太精细的考究，比如这两行代码实际上是做了两次的反射操作的，一次方法获取，一次方法调用：

如果只把第二步的方法调用放进循环里，得出的耗时就会减少：

另外，我测试的是方法调用的性能，但反射还有其他的功能，那些我都没测。到底要怎么制定测量规则才更精准，其实取决于最终我要考查的是什么。而我现在只是想做大致的性能对比，那么姑且就这么测，然后取个大致的中间值：一百倍。至少在数量级上，这么估算问题不大吧？ 

然后，我们还需要具体看一下，这个看起来「相当差」的反射，它具体的性能是多少。

我把 4716 ms 除以 1 千万之后，得到的结果是每次耗时大约 0.0004716 毫秒。这是个什么概念？按照 Android 设备通常的 60-120 Hz 的刷新率来说，一帧的耗时在 8.3 到 16.7 毫秒左右，我们在一帧内做的所有事情加起来的耗时不能超过这个数值，才能确保不掉帧。那么 0.0004716 毫秒一次的操作，我们要做多少次会达到 8.3 毫秒呢？至少要 17000 多次：

这不是个精确的值，但就像我刚才说的，在数量级的层面，这个值是完全可以参考的，对吧？那么，什么事会需要我们在一帧里面做 17000 次反射？除了循环之外，基本不会发生这种事。当然了我们不可能把一帧的所有时间都让给反射，我们有很多别的事要做，比如动画的计算。但是我就算除以 10，只给反射留 10% 的时间，那也有 1700 次了吧？有什么需要我反射 1700 下？依然是除了循环，基本不可能。

所以结论是什么？反射虽然慢，但是你正常地用，有关系吗？完全没关系。

除非像刚才说的：如果你在循环里——或者任何高频调用的场景里使用反射——那还是要小心的，一不留神也许就耗时过久，把界面搞掉帧了。至于具体什么时候会用循环或者高频调用，那我就没法告诉你了，只有咱自己知道自己的代码的逻辑，是吧？这个得自己判断。

所以这份测试结果，实际上给了我们两个信息：

● 一，反射的确比正常调用要更慢，而且慢很多。

● 二，虽然慢很多，但它还是很快。所以正常情况下依然可以放心用而不至于造成可见的影响；只是对于高频调用的场景，就真的需要注意一下，用得太猛还是有可能把界面搞卡顿的。

整体来说，不算可怕。

旧版本 Android 的表现

但是，既然并不可怕，那为什么江湖上有那么多「反射的性能很差」的传言呢？难道又是一个以讹传讹的假知识？

如果你在搜索引擎把时间做一下限制，你会发现从十几年前开始，网上就已经有了对于反射在 Android 设备上比较慢的讨论了：

十几年前，还没有进入对 Android 进行极致性能优化的时代，所以如果那时候就有人在讨论反射性能差，那么过度担忧或者危言耸听的可能性就很小了。那为什么大家都说反射性能很差，但我实际的测试结果却还行呢？

会不会……跟时代有关？我去试试。

当我把同样的代码，在更早期版本的 Android 设备上一个个进行测试的时候，我发现在 API 19——也就是 Android 4.4——以及更早版本的设备上，性能出现了严重的下降。降到了什么程度呢，我需要让循环从一千万次减少到十万次，才能正常地测试，不然我每次等测试结果都要等老半天：

另外，我发现并不是只有反射，连正常的函数调用的性能也严重下降了。
实际的耗时算下来，单次反射调用的耗时从 0.0003-0.0004 毫秒增加到了 0.008-0.09 毫秒，大概是 20-300 倍的差距——浮动有点大，不过咱看个大概的数量级，就取个粗略的中间值：也姑且按照 100 倍吧。刚看的是反射和普通调用的性能差距，100 倍；现在看的是旧版和新版 Android 的反射的性能差距，也是 100 倍。那么如果依然只给反射分配 10% 的单帧时间，单次耗时按照 100 倍的话就是 0.04 毫秒，这样的话就算是按照旧版 Android 的 60 帧的刷新率——每帧可以有 16.7 毫秒，是 8.3 毫秒的两倍了——但每帧也只有 41 次调用的机会：

这就明显有点捉襟见肘了，是吧？

所以，「反射性能很差」这个说法是有依据的，对于旧版的 Android 来说，反射的性能真的是很差的。

为什么差距这么大？

为什么呢？为什么不同版本 Android 之间的差距这么大？

这是有多方面原因的。比如 Android 5.0 推出的 ART 虚拟机，性能是强过旧版的 Dalvik 的。这个很好证明：Android 是在 4.4 推出的测试版 ART，这是唯一一个允许设备在 Dalvik 和 ART 之间切换的版本。我把我 API 19 的测试虚拟机切换到 ART 之后，它的性能表现就提升了很多：

所以 ART 的引入，肯定对性能提升有帮助。

另外，新版 Android 对垃圾回收的处理机制也做了大幅优化，这个也会对性能表现有很好的影响。

完整的原因有很多，我也说不全，没正经研究过。但咱能看到的结果是，新版 Android 的性能比旧版是强很多倍的，是吧？

这样来看，似乎就说得通了：为什么网上很多说「反射性能差」的文章，但我们的实测结果虽然也是差，但远远没到不可用的程度？——因为时代变了，旧时代它真的差得可怕，而新时代里，其实还好。

总结

那么到这里，差不多可以总结一下了：

● 反射的性能差吗？差，比不用反射来说，差很多；

● 为什么？因为它的动态特性，让它注定会失去各种优化，所以必然会慢得多，这是不可改变的事实；

● 从绝对表现来说，它的性能差到不可用了吗？其实还行，只要不在大规模调用的场景下使用反射，一般是不会影响软件的性能表现的；

● 但，如果你开发的软件会在旧版本的 Android——尤其是 5.0 之前——的设备上运行，那你还是需要非常谨慎地使用反射。在旧版本设备上用反射，还是有点容易把软件搞卡顿的。

我只做了 Java 的反射的测试，但对于 Kotlin 来说道理是一样的，因为 Kotlin 的反射实质上也是基于 Java 的反射来做的。以上的结论，不仅适用于 Java，也适用于 Kotlin 的反射。

反射是 Java 和 Kotlin 上非常有用的一套机制，它能给我们带来很大的帮助。但是，它的性能陷阱也让我们经常对它有所忌惮，甚至不敢轻易使用它。正是因为这个原因，我做了这个视频，希望能帮助大家对于反射的性能有更清楚的理解和认识，能让你在开发里可以更清楚反射代码的性能表现，从而更好地判断能不能、要不要用反射。

行，就这么多！关注我，了解更多 Android 开发相关的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

哔哩哔哩

Youtube

下面是视频内容的脚本文案原稿分享。

小剧场

面试官：「既然协程和泛型你都熟悉，flow() 函数是怎么实现类型推断的有了解过吗？」

求职者：「嗯……」

求职者：「嗯……在Kotlin协程中，flow 是一种构建器，用于创建 Flow 类型的实例。Flow 是 Kotlin 中处理异步数据流的——」

面试官：「你在 ChatGPT 吗？」

求职者：「没有啊——什么是 ChatGPT？」

面试官忽然从视频聊天界面里把头伸出屏幕，求职者吓一大跳，扶起椅子向后退一下：「诶！」面试官伸出来以后，回头看屏幕里的 ChatGPT。求职者在旁边安静地、不知所措地静静看着面试官。看了一会儿，面试官若有所思地、不置可否地：「Huh。」

开场

大家好，我是扔物线朱凯。

泛型是 Java 里一个很方便的特性，它的优势很多，其中之一就是提高了代码的复用能力，让我们只用写一个类或者接口或者方法，就能在调用时去应用到不同的类型：

List<String> list1 = new ArrayList<>(); // String
List<Integer> list2 = new ArrayList<>(); // Integer
List<Service> list3 = new ArrayList<>(); // Service
TextView textView = findViewById(R.id.textView); // TextView
ImageView imageView = findViewById(R.id.imageView); // ImageView

这种动态应用本来就很方便了，泛型还允许我们在调用时连类型都不用指定，而是让代码自动推断：

而 Kotlin 在沿袭了 Java 泛型的这些功能的同时，还进行了多项进化，其中就包括咱这期要聊的话题：它支持一种更强、更深的类型推断。

flow() 的类型推断

Java 的类型推断，是通过上下文信息来推断类型的。比如通过方法参数的类型来推断，或者通过赋值的目标变量的类型来推断：

Kotlin 也可以做这类推断：

另外，Kotlin 还能做一种加强的推断：它不仅能看函数的参数类型，还能钻进参数里，通过参数内部的内容来做更深的类型推断。什么叫参数内部呢？就是当你的参数是函数类型的时候：

Kotlin 有能力钻到它的大括号的里面，去一行行分析里面的代码，来进行类型推断。 比如我如果只调用 flow {}，它会报错，这是因为 flow() 是个泛型函数：

而我既没有指明类型参数的类型，也没有给出足够的上下文让它去做类型推断。 如果我直接写明：

它就不报错了。 或者，我也可以在大括号里生产一个 Flow 的元素：

Kotlin 也可以从中推断出类型，所以也不会报错。 而这种推断，是 Java 所没有的。

@BuilderInference

它是怎么推断的呢？

它并不是对每一行代码都检查，而是只查看对 this 的每一次函数调用，通过这些调用来进行类型推断，然后把推断出的类型汇总之后得到外部函数的推断类型。

我这么说可能比较绕，我来举实际的例子。就还以 flow() 函数为例，它这个大括号，实际上是一个函数类型的参数，也就是这个：

这个函数类型的参数，它的参数类型、返回值类型、是不是挂起函数，这些对类型推断都不重要：

关键在于，它设置了一个 receiver 类型：

这么写，可以让大括号里有一个这个类型的 this，也就是所谓的 implicit receiver，隐式的 receiver——关于「隐式的 receiver」这个概念，我上上条视频专门讲过，如果你没了解过可以去看一下——那么大括号里有了这个 FlowCollector 类型的 this，我就可以在里面调用它的函数，比如我这个 emit()，生产 Flow 元素的函数，其实就是它下面的：

然后呢，这个 FlowCollector 是一个泛型类型：

而 emit() 的参数就是它的类型参数的类型，也就是这个 T：

那么，Kotlin 就会在实际的调用中利用 emit() 的传入参数来作为推断出的实例化类型，也就是外面的 FlowCollector 的 T 的类型。比如我这里填入的是个字符串：

那么 Kotlin 就会推断出这个 T 的类型是 String：

这种推断其实比较特殊：典型的类型推断，是用对象的类型来得出函数的参数和返回值类型，比如用 FlowCollector 对象的实例化类型来推断出 emit() 的参数类型；而这个，它是反过来的，它是由函数调用来推断出对象的实例化类型，也就是由 emit() 的参数类型推断出 FlowCollector 的 T 的类型。 这个 FlowCollector 的 T，其实是用的 flow() 函数的类型参数。所以推断出了它的 T，也就等于推断出了 flow() 函数的 T。也就是对咱这个例子来说，flow() 函数的实例化类型就是 String：

整个类型推断的逻辑，就是这样的。它不是直接看函数调用时的传入参数的类型，而是要求参数必须是函数类型的，然后去看这个函数类型的参数的内部代码，去进行类型推断：

另外，Kotlin 还要求我们必须给这个参数设置一个 receiver 类型：

并且，这个 receiver 还需要是泛型类型的，同时我们还要用函数的类型参数来作为它的实例化类型——或者直白地说，就是要把这个 T 写在这里：

这样，整个链条就全都接上了，从技术的角度，我们就可以让 Kotlin 通过在大括号里对 this 的调用来推断类型了。 而在实操的角度，Kotlin 还有一个语法上的额外要求：我们还要给参数加上一个叫 BuilderInference 的注解：

因为这种推断默认是不开启的，我们需要加上这个 @BuilderInference 来手动开启它。为什么这么设计？一般是出于向前兼容性、代码的复杂性和可读性以及编译性能之类的综合考虑——具体我不知道，没考证过。

多次调用和综合推断

咱写的是大括号里只有一次函数调用，那么就只有一次类型推断：

而如果我们进行多次调用，Kotlin 会对多次调用的结果进行综合之后，得出统一的推断类型：

总结

Kotlin 跟 Java 相比，最大的改动之一就是它增加了「函数类型」的概念，这种概念上的突破给语言增加了很多灵活性。比如这个 BuilderInference，它本质上是借助对函数类型的对象的内部代码进行查看，来实现的一种间接的——或者说路径更长的——类型推断。 Kotlin 的标准库、协程以及各种第三方库——比如 Jetpack Compose——都有不少对于这个特性的使用，它可以让我们很方便地写一些通用的功能函数。如果你在公司或者团队里负责基础架构的搭建，或者你是某些开源库的作者，它很可能会对你有帮助。 行，今天就这么多。关注我，了解更多开发知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

前戏

Compose 的某些 API 只能在指定的组件内部才能使用，在它的外部、甚至它的子组件里，都是被禁止的：

这种规则很合理，对吧？

但是，有一个事实是，Compose 是用函数来写界面的，它的每个组件都是一个函数，而不是类：

类和接口要做这种访问性的隔离，是很容易的。而函数并不具备这样的功能——你想限制某些公开的属性或者函数只能在特定的函数内部才能被使用，Kotlin 是没有提供这种功能的，Java 也没有。

那……Compose 是怎么做到的呢？

开场

大家好，我是扔物线朱凯。

今天咱聊一下 Compose 的作用域机制。「作用域」这个词在 Compose 底层原理的角度有它单独的含义，它是用来讨论在界面结构的组合过程中，每个层级之间的关系的一个关键概念。不过今天，咱不聊这个，我们来借着 Compose 的躯壳，聊一聊 Kotlin 语言这个层面的作用域机制。

Compose 和 DSL

Compose 的写法是声明式的，但是跟同为声明式的 Flutter 有一个很大的不同是，它的界面组件是用函数来写的，而不是用类。

用函数来写，有一个很大的好处就是，它的写法可以做到极致的简洁，简洁到它可以被看作是一种 DSL。——哎，啥是 DSL？

做 Android 开发的人，很多应该都见过 DSL 这个词，因为我们用的 Gradle 就是一种 DSL。但是可能很多人对于「到底 DSL 是啥意思」的概念还是比较模糊。所谓 DSL，它的全称是 Domain-Specific Language，中文翻译叫「领域特定语言」，其实就是「专属于某个领域的语言」。相对于 C++、Java、Kotlin 这些通用的编程语言，DSL 是被设计来专门针对某种特定场景的专用化的语言。比如 HTML，就是一种专门用来写网页界面的 DSL：

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Simple HTML Page</title>
  </head>
  <body>
    <h1>Welcome to My Simple HTML Page</h1>
    <p>This is a paragraph of text in the body of the HTML page.</p>
    <p>Here is a link to an interesting <a href="https://www.wikipedia.org/">website</a>.</p>
  </body>
</html>

还有 SQL，它是专门用来访问关系型数据库的 DSL：

SELECT * FROM Customers WHERE Country = 'CN';

SELECT CustomerID, FirstName, LastName, Email FROM Customers;

SELECT COUNT(*) AS NumberOfCustomers FROM Customers;

SELECT * FROM Customers ORDER BY LastName ASC;

SELECT Country, COUNT(*) AS NumberOfCustomers FROM Customers GROUP BY Country;

SELECT Orders.OrderID, Customers.FirstName, Customers.LastName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID;

INSERT INTO Customers (FirstName, LastName, Email, Country)
VALUES ('Kai', 'Zhu', 'rengwuxian@gmail.com', 'CN');

UPDATE Customers SET Email = 'rengwuxian@gmail.com' WHERE CustomerID = 1;

DELETE FROM Customers WHERE CustomerID = 1;

另外很多程序员写文档喜欢用的 Markdown，它是一种「格式」，但它也是一种专门用来写格式化文档的 DSL：

# Header 1
## Header 2
### Header 3

This is a paragraph with some *italic* text and some **bold** text.

Here's an unordered list:
- Item 1
- Item 2
  - Nested Item 2a
  - Nested Item 2b

And here's an ordered list:
1. First item
2. Second item
3. Third item

`Inline code` can be included within backticks.

有个边界案例是 XML：它通常被认为像 JSON 一样是一种数据格式，而不是一种 DSL：

<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
  <book category="programming">
    <title lang="en">Learn XML</title>
    <author>John Doe</author>
    <year>2021</year>
    <price>39.95</price>
  </book>
  <book category="fiction">
    <title lang="en">XML for Storytellers</title>
    <author>Jane Austen</author>
    <year>2020</year>
    <price>29.99</price>
  </book>
  <book category="reference">
    <title lang="en">The XML Handbook</title>
    <author>Robert Smith</author>
    <year>2019</year>
    <price>49.99</price>
  </book>
</bookstore>

为啥？因为它不是领域特定的，它可以用在很多地方，但并不针对任何领域。而你如果针对某种场景，使用 XML 去设计一种专用的格式，那它就是 DSL——比如 SVG，一种矢量图的表达格式，它就是 DSL，因为它是专用于矢量图这个领域的，虽然它本质上也是一种 XML：

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="2" fill="blue" />
</svg>

所以，DSL 是一个宽松的概念，它关键在于是否是用于特定领域的。你可以从零去创造一门 DSL，也可以拿现成的东西去改成 DSL。

不止 XML，咱还可以用通用编程语言来改成 DSL。比如 Gradle，就是一种基于 Groovy 语言的 DSL 它针对场景的是 Java 项目的架构配置——当然也包括 Android 项目。另外现在 Gradle 也支持 Kotlin 了，这就是它又添加了使用 Kotlin 来写 Gradle 脚本的支持。你大眼一看，这就是个配置文件，但它实际上是用 Kotlin 写的，只不过被精心做成了长得很像配置文件的样子。

而 Compose，也是一样的道理：它是一个定制化的、专门用来写界面的 DSL；但本质上，它依然是 Kotlin。

implicit receiver

那么既然是 Kotlin，它就可以完全享受 Kotlin 的所有功能，但也完全承受了 Kotlin 的限制。比如，我们在写传统的 XML 布局的时候——哎对了，Android 的布局文件格式，也是一种 DSL，跟 SVG 的逻辑一样——我们在写 Android 的 XML 布局的时候，如果把属性写在不合适的位置，是会看到警告的对吧：

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_weight="1"
        android:text="" />

</RelativeLayout>

这是因为 Android Studio 会利用专门的 Lint 规则来自动检查文件结构，这就能在格式不对的时候给我们报警。——这套规则我们不用写，但 Android 的研发团队是花了精力去写它的。

而 Compose 是用 Kotlin 来写的，那么理论上就不需要专门再写 Lint 了，把代码设计好，直接利用 Kotlin 的特性就能检查和报错了。是吧？实际上，Compose 也是这么做的。

但是具体到作用域这个问题，就有一个障碍：就像我刚才说的，它的组件不是用类写的，而是函数。函数并没有像类和接口那样的层级结构，成员属性和成员函数这些东西，函数是没有的——你可以写局部变量和局部函数，但这些东西是完全私有的，没法从外部调度，所以不是一回事。这样的话，虽然用的是 Kotlin，但我们还是没法像传统布局文件那样对作用域做规则管理。直白点说就是，你想限制某个属性或者函数只能在指定的函数内部被调用，这是做不到的。

但是！实际情况却不是这样。Compose 的 Row() 组件内部可以使用一个叫 align() 的 Modifier 函数，它可以设置 Row() 内部每个组件的纵向对齐规则，比如纵向居中：

而你如果在 Row() 的外面尝试使用它，就会报错：

这是为啥？

这其实是利用了 Kotlin 的另一个概念，叫 implicit receiver，隐式的 receiver。这个概念我上个视频专门讲过，就不重复说了，建议大家去看一下（视频导航一下）。Compose 把这个 align() 写成了 RowScope 的成员函数，来限制它只能在 RowScope 对象的内部被调用；同时，它还给 Row() 组件的函数类型的参数——也就是这个大括号参数——给它设置了一个 RowScope 类型的隐式 receiver，这就让 Row() 后面的这个大括号里有了一个隐式的、RowScope 类型的 this。这样，最终的效果就是：我们只能在 Row() 的大括号里调用这个 align()，而在其他地方用不了。通过这种方式，Compose 就实现了用函数——而不是类——也能进行作用域限制的目的。

@DslMarker

不过这还没完。

这一套打法，它只限制了「不能在外部使用」，却没有限制「不能在内部的内部使用」。比如我在 Row() 的内部又摆了个 Column()，也就是纵向的线性布局：

Row() 组件的这种「纵向对齐规则」，它是只对直接子组件才有意义的。比如这个 Text() 和 Column()：

但对于 Column() 内部的 Text()，设置这种「纵向对齐」就没有意义了——子组件的子组件，隔着一层呢，怎么对齐呀，是吧？它可以设置在它的父组件——也就是这个 Column()——里的横向对齐规则：

——注意，这里虽然函数名一样，但其实是另一个函数，它只接受横向对齐类型的参数。

横向对齐没问题，但更外面的 Row() 所管理的纵向对齐，对于这个二级子组件的 Text() 是没有意义的。所以按理说，在这个 Text() 里就也不应该允许调用那个纵向对齐的 align() 了，是吧？但是，按照 Kotlin 的逻辑，这么写却是被允许的：

——哎？也不允许？ 这，怎么做到的？（惊奇转变成笑）
Kotlin 有一个特殊的注解，叫 DslMarker，这个限制就是靠它来实现的：

哎？D-S-L-Marker，DSL，咱刚才刚说过的，是吧？这是个专门用来写 DSL 的注解吗？

还真的是的，这个注解就是专门用来让我们设计 DSL 的时候用的。Compose 就是个 DSL，刚才我说过了，是吧？

不过咱刚才也说过了，DSL 是个泛指的、广义的词，具体的有很多种 DSL，它们的定位和用法是完全不同的。而这个 DslMarker，只是实现了其中一种 DSL 的一种功能。什么功能？就是咱现在说的这种。Compose 通过高阶函数和隐式的 receiver 实现了作用域向外的限制：只能在某个函数调用的大括号内部去访问某些属性和函数，在外面是不行的。对吧？而 DslMarker 的限制是向内的：就算在作用域内，就算在大括号的里面，如果你再套一层，那么在这个更内层的里面我也不让你用。也就是咱看到的这个，Row() 的大括号里可以用，但里面再套一层 Column() 之后，Column() 的里面就不让用了。这种「向内切断作用域传递」的工作，就是靠 DslMarker 来实现的。

我们去看一下 Row() 和 Column() 所提供的隐式 receiver 的类型，也就是这个 RowScope 和 ColumnScope：

它们有一个共同的注解，叫 LayoutScopeMarker，对吧？然后我再去看这个 LayoutScopeMarker：

就能看到它是加了这个叫 DslMarker 的注解。

通过这种方式，我就把 RowScope 和 ColumnScope 标记为「互相隔离作用域」的。当我在 RowScope 的里面套一层 ColumnScope，本来从 ColumnScope 的里面应该是能访问到外面的 RowScope 的，但加了这个 LayoutScopeMarker 之后，就没法访问了，RowScope 的所有属性和函数被强行禁止在它里面的 ColumnScope 的内部使用了。——同理，如果 ColumnScope 的里面套一个 RowScope，也是不能往外访问的。

这种限制，可以防止 API 的污染。就像我们例子里这种，既然某些 API 只在直接的内部有意义，而在「内部的内部」就失去了意义，那就干脆禁用这些 API 在「内部的内部」的访问，让我们不要被没用的 API 淹没，从而减少问题，也能提升开发体验。

这就是 DslMarker 这个注解的作用：向内的隔离访问。Compose 只是一个例子，在其他地方——比如 Gradle 里——也有类似的使用。

总结

Compose 是用 Kotlin 写的，它享受了 Kotlin 的便利，但也要承受 Kotlin 的限制。它用 Kotlin 的函数来实现了界面组件，就继承了「函数不具备作用域」的缺陷。但是，通过高阶函数、隐式 receiver 和 DslMarker 注解，Compose 用这样综合的花活解决了作用域管理的问题，还解决得挺好。它完全不依赖 Lint 规则，直接依靠 Kotlin 的功能和语法就全都搞定了。

行，差不多就这些吧。讲了讲 Compose 的作用域机制，希望可以对大家有帮助，不管是在 Compose 还是 Kotlin 的角度。关注我，了解更多开发知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

小剧场

朱凯：「比如，user.name 如果可以直接写成 name，那么这个不用写的 user 就是 Kotlin 的 implicit receiver。」

对手：「那不就是 this？」

朱凯：「不是不是，this 是个传统概念，Java 里面就有。implicit receiver 是个新概念，这俩不一样。」

对手：「哪不一样？」

朱凯：「比如说吧」，（逐渐愣住……）「哎？」

开场

大家好，我是扔物线朱凯。

今天咱说说 Kotlin 的 implicit receiver。这是一个我们写 Kotlin 经常会用的东西，虽然你可能都没听过这个词，但你一定用过它。Kotlin 的很多高级功能，都利用到了这个概念——比如协程，协程是重度依赖它的，非常重。所以，弄明白它是个什么、怎么用、怎么去发挥它最大的价值，对我们的能力提升是非常有帮助的。

定义：其实就是 this

我们从它的定义说起。它的名字 implicit receiver，直接翻译到中文的话，叫隐式的接收器或者说接收者。啥叫「接收」啊？所谓的接收，其实指的就是接收调用，或者说接受调用。接受函数的调用啊，接受属性的访问啊。比如这个 user.name：

user.name

左边的 user 就是它的 receiver。谁的 receiver？对于 name 的访问的 receiver。

而 implicit receiver，隐式的 receiver，指的就是不用写也自动存在的 receiver。也就是如果我把这个 user. 给删了，它依然能取到某个 User 对象的 name：

name

那么这个隐式地被应用的 User 对象，就是对这个 name 的访问的 implicit receiver，隐式的 receiver。

这就是 implicit receiver 的定义。

不过，咱把脑子转个弯想一下，这其实就是啥？就是 this 呗？对吧？

所谓的 implicit receiver，其实就是指的这个 this。

但 Java 里却没有隐式 receiver 这个概念，这是在 Kotlin 才增加了的概念。为啥呢？因为 Java 里的 this 很简单，就叫 this 就行了，不需要额外的专用名字；而 Kotlin 对它进行了一些关键的拓展，在拓展的同时，为了方便描述和沟通，就也给它起了专属的名字：implicit receiver。

那么它做了什么关键拓展呢？咱来从它的基本特性说起。

嵌套的 implicit receiver

this，或者说隐式的 receiver，是可以嵌套的，比如在 Java 里我们可以这么写：

我在这个内部类的里面，想访问内部类和外部类的成员都是可以的，是吧：

这个 innerInt 是 InnerClass 里的，所以它等价于加上 this 的写法：

而下面的 outerInt 属于外面的 OuterClass，但为了避免歧义，Java 不允许我们直接写 this：

而需要显式地加上 OuterClass 的前缀：

而上面的 innerInt 如果展开，前缀是 InnerClass：

也就是说，在内部类的里面，我是有内部类和外部类的双重 this 的。对吧？

另外，对于它们同名的成员变量或者方法，如果我也省略掉 this：

拿到的就是内部类的成员。如果想拿外部类的，就必须把 this 写完整：

到现在为止，做 Java 的基本是都懂的。我们继续。

在 Kotlin 里，也是一样的逻辑。只不过写法稍微变了一下：

所以，Java 和 Kotlin 不仅都有 implicit receiver，而且也都是能嵌套的，同一个方法里可以有多个 this，或者说多个 implicit receiver。对吧？

这是基本概念。

Kotlin 增加的 implicit receiver 嵌套：通过函数的 receiver 指定

然后，Kotlin 对于这种嵌套，又新增了一类场景——咱刚才看的是通过内部类来嵌套是吧？Kotlin 让我们还可以直接通过函数来嵌套新的 this。比如你有一个在类型内部声明的扩展函数：

——这种函数叫 member extension function，成员扩展函数，其实就是字面意思：它既是成员函数又是扩展函数，对吧？

这种「成员扩展函数」有一个问题：一方面，因为它是 Int 的扩展函数，所以你需要对 Int 类型的对象才能调用它；但同时，它也是 IntMultiplier 的成员函数，所以你还要求你对 IntMultiplier 对象调用它：

也就是说，这里需要的是个双重 receiver：既要这个直接的 Int，又要那个外部的 IntMultiplier，缺一不可。——那我到底对谁调用？

Java 没有扩展函数的概念，所以不存在这种写法，但 Kotlin 是可以的。Kotlin 提供的解法是，你专门创建一个函数，并给它设置一个函数类型的参数：

函数不用做什么特别的事，关键是执行一下它的那个函数类型的参数：

另外，你要给这个函数类型的参数，设置一个 receiver 的类型：

这么一指定，就把参数的函数体内部——注意，是这个 block 的函数体，不是外部函数本身的函数体——在它内部强行安插了一个隐式的 receiver。换句话说，我在调用这个外部函数的时候，它的函数类型的参数的大括号里就有一个 IntMultiplier 类型的 this 了：

那么，我在里面就可以这么写了：

哎，就这么通过给参数设置 receiver 的方式，我强行插了一层 this，不用写内部类也实现了这种「双重 this」的环境，是吧？

但是需要注意，这个 this 它也不是从空气里蹦出来的：当我们这么声明 block 参数的时候，就只有对 IntMultiplier 类型的对象才能调用它。不过咱这个例子里，外部函数正好也是在 IntMultiplier 类里声明的，所以直接写就行：

但这种结构并不是必须的，你也可以用你能想到的其他方式去写这种安插。比如我可以直接给 Int 写个扩展函数，去插入一个 Int 类型的 this：

那么我就能把里面这层 this 也做成隐式的了：

或者我如果不想写成扩展函数，我想把 Int 对象放在参数里来提供，也是行的：

只要把调用的格式对应地调整一下就可以了：

写法多种多样，但套路是一样的，对吧？

通过这种写法，我们就可以任意地往代码里插入我们指定的 implicit receiver，或者说指定的 this，去应对「多个 this」的需求场景了。

而且实际上，Kotlin 已经给我们提供了一套通用的函数。比如我例子里的代码，其实可以直接换成 apply() 和 with()：

这两个函数 ，写 Kotlin 的应该很多人都用过吧？但是，也有很多人并不明白它本质上是怎么一回事。实际上，它就是像我刚才说的那样，通过函数类型的参数来强行插入了一层 this。

不管是使用 Kotlin 现成的函数还是我们自己来实现，Kotlin 允许我们通过这种「指定」的方式来手动安插新的 this 到代码里，而不用非得用内部类才能实现。之前 Java 里嵌套的 this，对应的全都是嵌套的类型结构；而 Kotlin 对能力这么一扩充，this 的嵌套就变得非常自由了。所以，Kotlin 引入了 implicit receiver 的概念，来方便我们对这种扩充了的场景进行描述和沟通。而本质上，所谓的 implicit receiver，指的依然是那些 this——那些不用写的 receiver——这个本质是没有变的。

协程里的应用

Kotlin 的官方代码，以及很多第三方库，都重度地依赖这个叫做 implicit receiver 的东西。虽然我们可以说「它不就是 this 嘛」，但关键是，它给我们带来了很大的方便，怎么叫其实是次要的。随便举个例子，我们知道协程的启动是一定要用 CoroutineScope 才行的：

但是为什么在协程的内部再启动新的协程，就不用写 CoroutineScope 了？

因为它有一个隐式的 CoroutineScope 作为 this 被提供了：

怎么提供的？还是一样的方法：

总结

其他很多官方源码以及第三方库，都有类似的应用，而我们自己也可以在代码里用这样的写法去安插新的 this 层级，或者说——安插 implicit receiver，隐式的 receiver。看起来好像很复杂，但当你明白它的这些本质逻辑，写起来就很简单了。

试一下？试一下你就会发现，真的不难。

好今天内容就到这里。关注我，了解更多开发知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

文案原稿

大家好，我是扔物线朱凯。
Kotlin 的 by 关键字，我们平时用得挺多的，比如用 by lazy 来设置属性的懒加载：

val lazyUser by lazy {
    User()
}

这种写法叫「属性委托」，也就是把属性的读写操作委托给另一个对象。
除了这种写法，by 其实还能写在类声明里，在实现的接口的右边：

internal class IntrinsicsMeasureScope(
    intrinsicMeasureScope: IntrinsicMeasureScope,
    override val layoutDirection: LayoutDirection,
) : MeasureScope, IntrinsicMeasureScope by intrinsicMeasureScope {

这种写法，Kotlin 官方的叫法是 Delegation，中文叫委托，实际上它就是接口委托，功能是把类对接口的实现委托给指定的对象。
它在概念上其实很简单，官方文档就写得清清楚楚：

但正是这种简单，也带来了一些迷惑：怎么括号里面外面都是它呀？

这种量子纠缠的结构，让人有点摸不明白：这啥意思呀？我应该怎么用、什么时候用？以及如果我看到别人写了这样的代码，应该怎么去理解？

Java 的委托模式

实际上 Kotlin 的这种语法虽然比较新，但它背后的设计模式是早就有了的，叫做「委托模式」。委托模式指的是把类的一部分功能委托给一个辅助对象，比如 Android 里 View 这个类的点击回调功能，就是通过 setOnClickListener() 方法来委托给了一个 OnClickListener 类型的对象：

view.setOnClickListener {
    ...
}

这是一个非常典型的委托模式的案例。
委托模式还有个变种，是把类对于接口的实现，局部地或者完全地委托给自己内部的一个成员对象。比如 Android 里有一个叫做 ContextWrapper 的类，它实现了 Context 接口，但在 ContextWrapper 的内部，对于这个接口的每个的实现，全都委托给了自己内部的一个 Context 类型的成员变量：

public class ContextWrapper extends Context {
    @UnsupportedAppUsage
    Context mBase;

    ...

    public ContextWrapper(Context base) {
        mBase = base;
    }

    ...

    @Override
    public AssetManager getAssets() {
        return mBase.getAssets();
    }

    @Override
    public Resources getResources() {
        return mBase.getResources();
    }

    @Override
    public PackageManager getPackageManager() {
        return mBase.getPackageManager();
    }

    @Override
    public ContentResolver getContentResolver() {
        return mBase.getContentResolver();
    }

    @Override
    public Looper getMainLooper() {
        return mBase.getMainLooper();
    }

    @Override
    public Executor getMainExecutor() {
        return mBase.getMainExecutor();
    }

    @Override
    public Context getApplicationContext() {
        return mBase.getApplicationContext();
    }

    ...
}

这么啰嗦着套一层是为了什么呢？它可以让实现类不用关心接口的核心功能的具体实现，而只要关注额外的功能定制和扩展。
什么意思？我们再举个例子，比如对于 Java 的 List 这个接口，我们可以用 ArrayList 和 LinkedList 这两个类对它做出不同的内部实现，去应对不同的性能需求。这种对于接口的核心功能的实现，是不需要委托模式的。而如果我想给 List 接口定制额外的功能，比如我想定制一个元素类型是 User 的 List，让它有各种和用户相关的功能，像「筛出高风险用户」、「按年龄重排」这样的，那么我应该继承 ArrayList 还是 LinkedList 呢？我只能两个都继承，各自实现一遍。是吧？但相比之下，一个更合适的选择就是，我去直接实现 List 接口，在实现类的内部设置一个 List 类型的成员，来让它作为核心功能的代理：

public class UserList implements List<User> {
    List<User> userList;

    public UserList(List<User> userList) {
        this.userList = userList;
    }

   @Override
    public int size() {
        return userList.size();
    }

    @Override
    public boolean isEmpty() {
        return userList.isEmpty();
    }

    @Override
    public boolean contains(@Nullable Object o) {
        return userList.contains(o);
    }

    ...
}

然后，就可以随便给它加功能了：

public class UserList implements List<User> {
    List<User> list;

    public UserList(List<User> list) {
        this.list = list;
    }

    public List<User> highRiskUsers() {
        ...
    }

    public void sortWithAge() {
        ...
    }

    @Override
    public int size() {
        return userList.size();
    }

    @Override
    public boolean isEmpty() {
        return userList.isEmpty();
    }

    @Override
    public boolean contains(@Nullable Object o) {
        return userList.contains(o);
    }

    ...
}

这里面的 List 对象具体是用 ArrayList 还是 LinkedList 或者别的实现，都无所谓，你想用哪个填哪个。也就是，我扩展出来的功能对 ArrayList 和 LinkedList 都是适用的。对吧？
通过这种写法，我就可以对接口进行功能扩展，而不需要关心接口的核心功能是怎么实现的。很自由很方便。
但是……这么一大长串的方法重写，多多少少有点啰嗦，是吧？那也没办法，这已经是最优解法了。
不过！咱说的是 Java。

Kotlin 的接口委托

同样的做法，你用 Kotlin 也能写：

class UserList(private val list: List<User>) : List<User> {
    override val size: Int get() = list.size

    override fun get(index: Int): User = list[index]

    override fun isEmpty(): Boolean = list.isEmpty()

    override fun iterator(): Iterator<User> = list.iterator()

    override fun listIterator(): ListIterator<User> = list.listIterator()

    override fun listIterator(index: Int): ListIterator<User> = list.listIterator(index)

    override fun subList(fromIndex: Int, toIndex: Int): List<User> = list.subList(fromIndex, toIndex)

    override fun lastIndexOf(element: User): Int = list.lastIndexOf(element)

    override fun indexOf(element: User): Int = list.indexOf(element)

    override fun containsAll(elements: Collection<User>): Boolean = list.containsAll(elements)

    override fun contains(element: User): Boolean = list.contains(element)
}

但其实 Kotlin 有更简便的写法，也就是咱刚才说的：接口委托。你只要把 list 参数放在接口的右边用 by 连接起来：

class UserList(private val list: List<User>) : List<User> by list {
    override val size: Int get() = list.size

    override fun get(index: Int): User = list[index]

    override fun isEmpty(): Boolean = list.isEmpty()

    override fun iterator(): Iterator<User> = list.iterator()

    override fun listIterator(): ListIterator<User> = list.listIterator()

    override fun listIterator(index: Int): ListIterator<User> = list.listIterator(index)

    override fun subList(fromIndex: Int, toIndex: Int): List<User> = list.subList(fromIndex, toIndex)

    override fun lastIndexOf(element: User): Int = list.lastIndexOf(element)

    override fun indexOf(element: User): Int = list.indexOf(element)

    override fun containsAll(elements: Collection<User>): Boolean = list.containsAll(elements)

    override fun contains(element: User): Boolean = list.contains(element)
}

就自动实现了这种委托。下面那一堆函数重写就都可以删掉了：

class UserList(list: List<User>) : List<User> by list {
  
}

然后你想加什么功能，正常加就可以了：

class UserList(list: List<User>) : List<User> by list {
    fun highRiskUsers(): List<User> {
        return ...
    }

    fun sortWithAge() {
        ...
    }
}

这就是 Kotlin 的委托，或者说接口委托。
别光觉得不错啊，看完视频，该不会用还不会用，那可不行。小结一下，干嘛用的？当你想让一个类实现某个接口，但不想关心核心实现，只想给它做功能拓展，那么就用 by 关键字来个接口委托，让核心实现由指定对象进行插件式提供。是吧？
当然了，对 Kotlin 来说，做功能拓展也可以用扩展函数和扩展属性，这个你可以自己选，看情况而定。
在 Jetpack Compose 的 LazyColumn() 和 LazyRow() 组件里都用到了一个叫做 LazyListMeasureResult� 的类，它就是用委托来对 MeasureResult 这个接口进行的拓展：

internal class LazyListMeasureResult(
    // properties defining the scroll position:
    /** The new first visible item.*/
    val firstVisibleItem: LazyListMeasuredItem?,
    /** The new value for [LazyListState.firstVisibleItemScrollOffset].*/
    val firstVisibleItemScrollOffset: Int,
    /** True if there is some space available to continue scrolling in the forward direction.*/
    val canScrollForward: Boolean,
    /** The amount of scroll consumed during the measure pass.*/
    val consumedScroll: Float,
    /** MeasureResult defining the layout.*/
    measureResult: MeasureResult,
    /** The amount of scroll-back that happened due to reaching the end of the list. */
    val scrollBackAmount: Float,
    // properties representing the info needed for LazyListLayoutInfo:
    /** see [LazyListLayoutInfo.visibleItemsInfo] */
    override val visibleItemsInfo: List<LazyListItemInfo>,
    /** see [LazyListLayoutInfo.viewportStartOffset] */
    override val viewportStartOffset: Int,
    /** see [LazyListLayoutInfo.viewportEndOffset] */
    override val viewportEndOffset: Int,
    /** see [LazyListLayoutInfo.totalItemsCount] */
    override val totalItemsCount: Int,
    /** see [LazyListLayoutInfo.reverseLayout] */
    override val reverseLayout: Boolean,
    /** see [LazyListLayoutInfo.orientation] */
    override val orientation: Orientation,
    /** see [LazyListLayoutInfo.afterContentPadding] */
    override val afterContentPadding: Int,
    /** see [LazyListLayoutInfo.mainAxisItemSpacing] */
    override val mainAxisItemSpacing: Int
) : LazyListLayoutInfo, MeasureResult by measureResult {
    override val viewportSize: IntSize
        get() = IntSize(width, height)
    override val beforeContentPadding: Int get() = -viewportStartOffset
}

它没有实现 MeasureResult 的任何核心功能，这些核心功能全都交给了委托对象；它只是作为一个针对 LazyList() 的 MeasureResult，添加了很多额外的属性进来。
你看，挺好用，也挺容易用的，是吧？

对核心功能进行定制修改

延伸一下。除了增加额外功能，接口委托也可以对接口的核心功能进行定制或者修改。比如 Kotlin 协程的源码有一个 SubscribedSharedFlow：

private class SubscribedSharedFlow<T>(
    private val sharedFlow: SharedFlow<T>,
    private val action: suspend FlowCollector<T>.() -> Unit
) : SharedFlow<T> by sharedFlow {
    override suspend fun collect(collector: FlowCollector<T>) =
        sharedFlow.collect(SubscribedFlowCollector(collector, action))
}

它对 SharedFlow 接口进行了委托，但并没有完全交给委托对象，而是重写了这个接口的 collect() 函数，对它进行了修改定制。——当你在实现类里重写了接口的某个函数，那么这个函数就不再交给委托对象，而是以你重写的为准。这样就很灵活，你可以按需求对接口进行局部定制。算是个延伸用法。

总结

就这么简单。接口委托在 Kotlin 协程和 Jetpack 各个库的源码里有很多的应用，只要你把它背后的东西弄明白了，它其实是一个非常简单好用的特性，又好读懂又好写。希望这个视频对你有用，关注我，了解更多 Android 开发相关的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

问题是真实存在的

大家好，我是扔物线朱凯。
刚才那个 0.1 + 0.2 不等于 0.3 的情况是真实存在的，不信你可以亲自试一下。我用的是 Kotlin，你换成 Java、JavaScript、Python、Swift 也都是这样的结果。要解决它也简单，在数值的右边加个 f，把它从双精度改成单精度的就可以了：


但这并不是一个通用的解决方案，比如有的时候情况会反过来：双精度的没有问题，而单精度的却有问题：


要知道，这些偏差都是开发里真实会发生的，所以了解这些问题的本质原因和解决方案是非常必要的——比什么内存抖动重要多了。
今天咱就说一下这个。不难啊，别害怕，你看进度条不长。

浮点数的范围优势和精度问题

大多数编程语言对小数的存储，用的都是浮点数的形式。浮点数其实就是一种科学计数法，只不过它是电脑用的、二进制的科学计数法：

十进制：500000
科学计数法：5 * 105
二进制：1111010000100100000
浮点数（二进制科学计数法）：1.111010000100100000 * 218

科学计数法的好处我们上学的时候老师就说过，可以用较少的数位来记录绝对值非常大或者非常小的数：

1000000000 -> 1 x 109
0.000000001 -> 1 x 10-9

但当你要记录的数位比较长的时候：

1000000001 -> 1.000000001 x 109
1.000000001 -> 1.000000001 x 100

科学计数法的优势就没了。所以科学计数法都会规定有效数字的个数，有效数字之外的就四舍五入掉了：

1000000001 -> 1.0 x 109 // 有效数字 2 位
1.000000001 -> 1.0 x 100 // 有效数字 2 位

这就造成了精度的损失。你看到一个 1.0 x 109，你不知道它是从 10 亿这个数转换过来的，还是从 9.6 亿或者 10.3 亿或者别的什么数转过来的，因为它们都可以写成 1.0 x 109。1.0 x 109 代表的不是 10 亿这一个数，而是它附近范围内的一大堆数，这就是精度的损失。不过这是故意的，科学计数法就是用精度作为代价来换取记录的简洁。
计算机的浮点数也是完全一样的道理。它本质上就是一种科学计数法，只不过是二进制的。比如，同样在 JVM 里占 32 位的 float (Float) 和 int (Int)，float 却可以表达比 int 更大的整数：

32 位的二进制数据只有 232 个取值，再加上还要区分正负，所以 int 的最大值是 231 - 1 也就是这个数：

2,147,483,647

但是 float 同样是 32 位，却能突破这个限制，赋值为这么大的一个数。别说 int 了，它的范围比 64 位的 long 还大：

除此之外，它还能表示小数：

小数代码。

怎么做到的？靠牺牲精度来做到的。float 虽然也是 32 位，但它会从里面拿出 8 位来保存指数值，也就是小数点的位置。8 位的指数可以达到 ±27 也就是 ±128，也就是小数点往左或者往右 128 个二进制位，换算成十进制是左右各 38 个十进制位。每移动一位就是放大或者缩小 10 倍，38 位呀，非常大的放大和缩小倍数了——int 只记录整数，不记录小数，但它最大的值也只是一个十位数：

2,147,483,647

这就是为什么 Java 和 Kotlin 的 float (Float) 可以保存某些很大的整数，因为它有专门的指数位：

但同样，它用这 8 位来保存指数，那么相应的它的有效数字就变短了，所以它的精度是比 int 要低的。这就导致某些 int 能表达的整数，float 却表达不了，比如 50000005（五千万零五）：

这个数虽然不长，但是精度——太高了。
虽然只是超出精度而不是超出取值范围，所以只显示了黄线警告而不会拒绝编译，但由于 Float 确实表达不了 50000005，所以在运行时只能在它的能力范围内拿一个最接近的数来进行使用，而无法使用这个数本身：


可能跟很多人的直观想法不太一样，为什么末位是 5 不行，但换成 4 就可以了？不是应该换成 0 才行吗？因为这是二进制的。我们看着这个数不够整、精度不够低，这是因为我们是十进制的思维，但只要二进制觉得它挺整的、觉得它没有超出精度范围就够了。

50000000: 10111110101111000010000000 // 有效数字 19 位，holde 得住
50000004: 10111110101111000010000100 // 有效数字 24 位，同样 hold 得住
50000005: 10111110101111000010000101 // 有效数字 26 位，hold 不住，「四舍五入」到 50000004

而 int 在这时候就很靠谱了，它是可以表达自己范围内的任何整数的，50000005 对它完全没问题：



这是整数的情况，换成小数也是同样的道理。你用 Float 可以表示 500000，也可以表示 0.05，但无法表示 500000.05，因为它超出精度范围了：

不过二进制的数值并不能直接照抄十进制的小数点平移，所以你会发现加了小数点之后，500000.05f 会被「四舍五入」到 500000.06 而没有跟前面一样是 04：


而如果把小数点往右移一位，改成 5000000.5，就直接不用「四舍五入」了：


你看，黄线没了，打印出来也是没问题的。因为 0.5 的二进制格式是 0.1，只用一位小数就表达了，所以整个数的精度没有超：

5000000.5： 10011000100101101000000.1 // 有效数字 24 位，hold 得住

同样是 32 位的大小，float 却比 int 少了 8 位有效数字长度，降低了精度，这是浮点数的弱点所在。而这个弱点也是故意的，因为这少了的 8 位用来存储指数了，也就是小数点的位置，改变指数的值就是改变小数点的位置——这也就是「浮点数」这个名字的含义。所以它是用精度作为代价，换来了更大的表达范围，让它可以表达小数，也可以表达很大的整数，远远超过 int 上限的整数。
浮点数可以用于表示小数，所以我们通常把它跟小数画等号；但其实对于一些数值特别大但有效数字并不多的整数的情况，也可以考虑使用浮点数。
不过就是刚才说过的，有得有失，浮点数的精度比较低。有多低呢？对于 float 来说，它的有效数字换算成十进制是 6-7 位。到了 8 位的时候，有很多数就无法精确表达了，比如 500000.05。而 double 的长度是 float 的两倍，有 64 位，它的精度就比较高了，它的有效数字相当于 15-16 位的十进制有效数字，能应付大部分的需求了——当然了如果你面向的是整数，那直接用 int 和 long 可能更好。

float vs double

说到这儿呢，咱就说一下关于 float (Float) 和 double (Double) 的选择问题。这其实是一个很容易出错但是经常被忽略的地方：float 的精度是比较低的，对于很多场景都可能会不够用。比如你如果用来做金额的计算，去掉小数点右边的两位之后，只有五位数字可以用了，也就是 10 万级的金额就不能用 float 了。那么在选择浮点数的类型的时候，你要时刻意识到这件事，在精度不够用的时候就选 double。
这其实也是为什么在 Java 和 Kotlin 里整数的默认类型虽然是更短的 int (Int) 而不是 long (Long)，但浮点数的默认类型却是更长的 double (Double)，而不是 float (Float)：

类型是 double (Double)。

因为 float (Float) 的适用场景过于受限了。
当然了如果你明确知道在某个场景下 float 够用了，那肯定用 float 更好，省内存嘛。
不过说到省内存我又要说了，不用过于纠结，对于很多场景来说，double 的双倍内存占用带来的性能损耗其实是很小的，小到完全可以忽略——你想想，32 位和 64 位才差多少？差 32 位，也就是 4 个字节，4 个 B，你省 1000 个才 4K 的大小——所以如果你真的想懒省事，全都用 double 大多数时候也是没有任何问题的。一个字符都 16 位了，也没见谁因为这个去精简软件界面的文字啊是吧。不过一些计算密集型或者内存密集型的工作，比如高频的循环过程或者某些需要大量复用的数据结构，还是得慎重考虑数值类型的啊，能用 float 就用 float。何止是 float 呀，在性能要求高的场景里，你甚至可能需要考虑要不要用单个 int 或者 long 变量来代替多个 boolean 变量去进行联合存储，以此来节约内存。而对于一般场景，double 虽然占双倍内存，但其实影响不大。

0.1 + 0.2 != 0.3 的问题

除了精度，浮点数还有个问题是，它是二进制的。这对整数还好，但对于小数来说，有很多十进制小数是无法转换成有限的二进制小数的。
二进制只有 0 和 1，所以它的 0.1 就是 2 的 -1 次方，也就是十进制的 0.5——二进制的 0.1 跟十进制的 0.5 是相等的；同理，它的 0.01 就是 2 的 -2 次方，也就是十进制的 0.25；而它俩相加的结果 0.11，对应的就是十进制的 0.75 。总之，你用 1 去反复地除以二，这些结果——以及这些结果的加和——都可以被二进制的小数完美表示。但如果一个小数无法被拆成这种形式，那它就无法被完美转换成二进制，比如——0.1。
可能有点反直觉，但十进制的 0.1 是无法被转换成一个有限的二进制小数的，它只能用一个无限循环小数来表达：

0.00011001100110011...

而且，浮点数并不会真的把它当做无限循环小数来保存，而是在自己的精度范围内进行截断，把它当一个有限小数来保存。这就造成了一定的误差。我们用的各种编程语言和运行时环境会对这种问题进行针对性优化，让我们尝试打印 0.1 的时候依然可以正常打印出 0.1，但在进行了运算之后，叠加的误差可能就会落在这种优化的范围之外了，这就是为什么在很多语言里，0.1 + 0.2 不等于 0.3，而是等于 0.300000……4：


同样的例子还有很多，比如 0.7 / 5.0 不等于 0.14：


注意了，我这里用的是不带 f 的小数，也就是用的 double。如果我给它们加上 f 也就是改用 float 的话，就恢复正常了：


这是为啥？这可不是因为 float 的精度比较低所以误差被掩盖了，而是对于这两个算式来说，恰好 float 的精度在截断之后的计算结果，误差依然在优化范围内，而 double 的掉到了优化范围之外而已。我如果把这个 0.1 换成 0.15，那状况就相反了，float 出现了问题，而 double 反而没问题了：


为啥？因为这次 float 掉到范围之外了。
所以，这种计算之后出现数值偏差的问题，是普遍存在的，它甚至不是精度太低而导致的，而就是因为十进制小数无法往二进制进行完美转换所导致的，不管你用多高精度的都会出这种问题，只要你用的是浮点数。我们用的各种编程语言的浮点数的实现，遵循的都是同一套标准，这个标准是 IEEE 推出的——要怪怪它去。

应对一：主动限制精度

那怎么办呢？一般来说有两种应对方向。
第一种是在计算之后、输出或者比较的时候，主动限制精度：

val a = ((0.1 + 0.2) * 1000).round() / 1000 // 0.3

if (abs(0.1 + 0.2 - 0.3) < 0.001) {
    ...
}

看着有点憨是吧？甚至有一丝羞耻。没办法，写吧！我也这么写的，大家都这么写的。浮点数就这样！

应对二：不用浮点数（不是开玩笑）

除此之外，另一个应对方向就是，你干脆别用浮点数了，用别的方案。比如 Java 有个叫 BigDecimal 的东西，就是专门进行精确计算用的。不过 BigDecimal 的使用没有浮点数这么简单，运算速度也比浮点数慢，所以大多数情况下，忍一忍，用浮点数还是会好一点。

总结

好，浮点数的东西大概就这么多。
下期有点想再说点 Compose 的东西了，不过也不一定，我看情况吧。如果你喜欢我的视频，还请帮我点赞和转发。关注我，了解更多 Android 开发的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

视频先行

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

文案原稿

Kotlin 的 Nothing 类，无法创建出任何实例：

public class Nothing private constructor()

所以所有 Nothing 类型的变量或者函数，都找不到可用的值：

val nothing: Nothing = ???
fun nothing(): Nothing {
  ...
  return ???
}

就这么简单。但——它有啥用啊？

Nothing 的本质

大家好，我是扔物线朱凯。上期讲了 Kotlin 的 Unit，这期讲 Nothing。
Nothing 的源码很简单：

public class Nothing private constructor()

可以看到它本身虽然是 public 的，但它的构造函数是 private 的，这就导致我们没法创建它的实例；而且它不像 Unit 那样是个 object：

public object Unit {
  override fun toString() = "kotlin.Unit"
}

而是个普通的 class；并且在源码里 Kotlin 也没有帮我们创建它的实例。

这些条件加起来，结果就是：Nothing 这个类既没有、也不会有任何的实例对象。

基于这样的前提，当我们写出这个函数声明的时候：

fun nothing(): Nothing {

}

我们不可能找到一个合适的值来返回。你必须返回一个值，但却永远找不到合适的返回值。悖论了。

作用一：作为函数「永不返回」的提示

怎么办？

不怎么办。这个悖论，就是 Nothing 存在的意义：它找不到任何可用的值，所以，以它为返回值类型的一定是个不会返回的函数，比如——它可以总是抛异常。
什么意思？就是说，我这么写是可以的：

fun nothing() : Nothing {
  throw RuntimeException("Nothing!")
}

这个写法并没有返回任何结果，而是抛异常了，所以是合法的。

可能有的人会觉得有问题：抛异常就可以为所欲为吗？抛异常就可以忽略返回值了吗？——啊对，抛异常就是可以忽略返回值，而且这不是 Nothing 的特性，而是本来就是这样，而且你本来就知道，只是到这里的时候，你可能会忘了。
例如这个写法：

fun getName() : String {
  if (nameValue != null) {
    return nameValue
  } else {
    throw NullPointerException("nameValue 不能为空！")
  }
}

——其实这个函数可以有更加简洁的写法：

fun getName() = nameValue ?: throw NullPointerException("nameValue 不能为空！")

不过我们为了方便讲解，就不简化了：

fun getName() : String {
  if (nameValue != null) {
    return nameValue
  } else {
    throw NullPointerException("nameValue 不能为空！")
  }
}

在这个函数里，一个 if 判断，true 就返回，false 就抛异常，这个写法很常见吧？它在 else 的这个分支，是不是就只抛异常而不返回值了？实际上 Java 和 Kotlin 的任何方法或者说函数，在抛异常的时候都是不返回值的——你都抛异常的还返回啥呀返回？是吧？

所以我如果改成这样：

fun getName() : String {
  throw NullPointerException("不能为空！")
}

其实也是可以的。只是看起来比较奇怪罢了，会让人觉得「怎么会这么写呢」？但它的写法本身是完全合法的。而且如果我把函数的名字改一下，再加个注释：

/**
 当遇到姓名为空的时候，请调用这个函数来抛异常
*/
fun throwOnNameNull() : String {
  throw NullPointerException("姓名不能为空！")
}

这就很合理了吧？不干别的，就只是抛异常。这是一种很常用的工具函数的写法，包括 Kotlin 和 Compose 的官方源码里也有这种东西。

那么我们继续来看它的返回值类型：我都不返回了，就没必要还写 String 了吧？那写什么？可以把它改成 Unit：

/**
 当任何变量为空的时候，请统一调用这个函数来抛异常
*/
fun throwOnNameNull() : Unit {
  throw NullPointerException("姓名不能为空！")
}

有问题吗？没问题。

不过，Kotlin 又进了一步，提供了一个额外的选项：你还可以把它改成 Nothing：

/**
 当任何变量为空的时候，请统一调用这个函数来抛异常
*/
fun throwOnNameNull() : Nothing {
  throw NullPointerException("姓名不能为空！")
}

虽然我找不到 Nothing 的实例，但是这个函数本来就是永远抛异常的，找不到实例也没关系。哎，这不就能用了吗？对吧？

不过，能用归能用，这么写有啥意义啊？是吧？价值在哪？——价值就在于，Nothing 这个返回值类型能够给使用它的开发者一个明确的提示：这是个永远不会返回的函数。这种提示本身，就会给开发提供一些方便，它能很好地避免函数的调用者对函数的误解而导致的一些问题。我们从 Java 过来的人可能第一时间不太能感受到这种东西的用处，其实你要真说它作用有多大吧，我觉得不算大，主要是很方便。它是属于「你没有的话也不觉得有什么不好的，但是有了之后就再也不想没有它」的那种小方便。就跟 120Hz 的屏幕刷新率有点像，多少带点毒。

Kotlin 的源码、Compose 的源码里都有不少这样的实践，比如 Compose 的 noLocalProviderFor() 函数：

private fun noLocalProvidedFor(name: String): Nothing {
  error("CompositionLocal $name not present")
}

好，这就是 Nothing 的作用之一：作为函数的返回值类型，来明确表达「这是个永不返回的函数」。

其实 Nothing 的「永不返回」除了抛异常之外，还有一种场景，就是无限循环：

fun foreverRepeat(): Nothing {
  while (true) {
    ...
  }
}

不过一般很少有人这么去用，大部分都是用在我刚才说的抛异常的场景，这是非常常见的一种用法，你写业务可能用不到，但是基础架构团队给全公司写框架或者对外写 SDK 的话，用到它的概率就非常大了。

作用二：作为泛型对象的临时空白填充

另外 Nothing 除了「没有可用的实例」之外，还有个特性：它是所有类型共同的子类型。这其实是违反了 Kotlin 的「类不允许多重继承」的规定的，但是 Kotlin 强行扩充了规则：Nothing 除外，它不受这个规则的约束。虽然这违反了「类不允许多重继承」，但因为 Nothing 不存在实例对象，所以它的多重继承是不会带来实际的风险的。——我以前还跟人说「Nothing 是所有类型的子类型」这种说法是错误的，惭愧惭愧，是我说错了。

不过，这个特性又有什么作用呢？它就能让你对于任何变量的赋值，都可以在等号右边写一个 Nothing：

val nothing: Nothing = TODO()
var apple: Apple = nothing

这儿其实有个问题：我刚说了 Nothing 不会有任何的实例，对吧？那么这个右边就算能填 Nothing 类型的对象，可是这个对象我用谁啊？

val nothing: Nothing = ???
var apple: Apple = nothing

谁也没法用。

但是我如果不直接用 Nothing，而是把它作为泛型类型的实例化参数：

val emptyList: List<Nothing> = ???
var apples: List<Apple> = emptyList

这就可以写了。一个元素类型为Nothing 的 List，将会导致我无法找到任何的元素实例来填充进去，但是这个 List 本身是可以被创建的：

val emptyList: List<Nothing> = listOf()
var apples: List<Apple> = emptyList

只不过这种写法看起来好像有点废，因为它永远都只能是一个空的 List。但是，如果结合上我们刚说的「Nothing 是所有类型的子类型」这个特性，我们是不是可以把这个空的 List 赋值给任何的 List 变量？

val emptyList: List<Nothing> = listOf()
var apples: List<Apple> = emptyList
var users: List<User> = emptyList
var phones: List<Phone> = emptyList
var images: List<Image> = emptyList

这样，是不是就提供了一个通用的空 List 出来，让这一个对象可以用于所有 List 的初始化？有什么好处？既省事，又省内存，这就是好处。

这种用法不只可以用在 List，Set 和 Map 也都没问题：

val emptySet: Set<Nothing> = setOf()
var apples: Set<Apple> = emptySet
var users: Set<User> = emptySet
var phones: Set<Phone> = emptySet
var images: Set<Image> = emptySet

val emptyMap: Map<String, Nothing> = emptyMap()
var apples: Map<String, Apple> = emptyMap
var users: Map<String, User> = emptyMap
var phones: Map<String, Phone> = emptyMap
var images: Map<String, Image> = emptyMap

而且也不限于集合类型，只要是泛型都可以，你自定义的也行：

val emptyProducer: Producer<Nothing> = Producer()
var appleProducer: Producer<Apple> = emptyProducer
var userProducer: Producer<User> = emptyProducer
var phoneProducer: Producer<Phone> = emptyProducer
var imageProducer: Producer<Image> = emptyProducer

它的核心在于，你利用 Nothing 可以创建出一个通用的「空白」对象，它什么实质内容也没有，什么实质工作也做不了，但可以用来作为泛型变量的一个通用的空白占位值。这就是 Nothing 的第二个主要用处：作为泛型变量的通用的、空白的临时填充。多说一句：这种空白的填充一定是临时的才有意义，你如果去观察一下就会发现，这种用法通常都是赋值给 var 属性，而不会赋值给 val：

val emptyProducer: Producer<Nothing> = Producer()
// 没人这么写：
val appleProducer: Producer<Apple> = emptyProducer
val userProducer: Producer<User> = emptyProducer
val phoneProducer: Producer<Phone> = emptyProducer
val imageProducer: Producer<Image> = emptyProducer

因为赋值给 val 那就是永久的「空白」了，永久的空白那不叫空白，叫废柴，这个变量就没意义了。

作用三：语法的完整化

另外，Nothing 的「是所有类型的子类型」这个特点，还帮助了 Kotlin 语法的完整化。在 Kotlin 的下层逻辑里，throw 这个关键字是有返回值的，它的返回值类型就是 Nothing。虽然说由于抛异常这件事已经跳出了程序的正常逻辑，所以 throw 返回不返回值、返回值类型是不是 Nothing 对于它本身都不重要，但它让这种写法成为了合法的：

val nothing: Nothing = throw RuntimeException("抛异常！")

并且因为 Nothing 是所有类型的子类型，所以我们这么写也行：

val nothing: String = throw RuntimeException("抛异常！")

看起来没用是吧？如果我再把它改改，就有用了：

var _name: String? = null
val name: String = _name ?: throw NullPointerException("_name 在运行时不能为空！")

throw 的返回值是 Nothing，我们就可以把它写在等号的右边，在语法层面假装成一个值来使用，但其实目的是在例外情况时抛异常。

Kotlin 里面有个 TODO() 函数对吧：

val someValue: String = TODO()

这种写法不会报错，并不是 IDE 或者编译器做了特殊处理，而是因为 TODO() 的内部是一个 throw：

TODO() 返回的是 Nothing，是 String 的子类，怎么不能写了？完全合法！虽然 throw 不会真正地返回，但这让语法层面变得完全说得通了，这也是 Nothing 的价值所在。

除了 throw 之外，return 也是被规定为返回 Nothing 的一个关键字，所以我也可以这么写：

fun sayMyName(first: String, second: String) {
  val name = if (first == "Walter" && second == "White") {
    "Heisenberg"
  } else {
    return // 语法层面的返回值类型为 Nothing，赋值给 name
  }
  println(name)
}

这段代码也是可以简化的：

fun sayMyName(first: String, second: String) {
  if (first == "Walter" && second == "White") println("Heisenberg")
}

不过同样，咱不是为了讲东西么，就不简化了：

fun sayMyName(first: String, second: String) {
  val name = if (first == "Walter" && second == "White") {
    "Heisenberg"
  } else {
    return // 语法层面的返回值类型为 Nothing，赋值给 name
  }
  println(name)
}

虽然直接强行解释为「return 想怎么写就怎么写」也是可以的，但 Kotlin 还是扩充了规则，规定 return 的返回值是 Nothing，让代码从语法层面就能得到解释。

这就是 Nothing 的最后一个作用：语法层面的完整化。

总结

好，Nothing 的定义、定位和用法就是这些。如果没记全，很正常，再看一遍。你看视频花的时间一定没有我研究它花的时间多，所以多看两遍应该不算浪费时间。
下期我会讲一个很多人不关注但很有用的话题：Kotlin 的数值系统，比如 Float 和 Double 怎么选、为什么 0.7 / 5.0 ≠ 0.14 这类的问题。关注我，了解更多 Android 开发相关的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

视频先行

哔哩哔哩

YouTube

下面是视频内容的脚本文案原稿分享。

文案原稿

很多从 Java 转到 Kotlin 的人都会有一个疑惑：为什么 Kotlin 没有沿用 Java 的 void 关键字，而要引入这个叫 Unit 的新东西？

// Java
public void sayHello() {
  System.out.println("Hello!");
}

// Kotlin
fun sayHello(): Unit {
  println("Hello!")
}

不过这个问题一般也不会维持很久，因为就算你不明白，好像……也不影响写代码。

直到这两年，大家发现 Compose 的官方示例代码里竟然有把 Unit 填到函数参数里的情况：

LaunchedEffect(Unit) {
  xxxx
  xxxxxx
  xxx
}

我们才觉得：「啊？还能这么写？」

Unit 的本质

大家好，我是扔物线朱凯。

今天来讲一讲 Unit 这个特殊的类型。

我们在刚学 Kotlin 的时候，就知道 Java 的 void 关键字在 Kotlin 里没有了，取而代之的是一个叫做 Unit 的东西：

// Java
public void sayHello() {
  System.out.println("Hello!")
}

// Kotlin
fun sayHello(): Unit {
  println("Hello!")
}

而这个 Unit，和 Java 的 void 其实是不一样的。比如 Unit 的返回值类型，我们是可以省略掉不写的：

// Kotlin
fun sayHello() {
  println("Hello!")
}

不过省略只是语法上的便利，实际上 Kotlin 还是会把它理解成 Unit。

Unit 和 Java 的 void 真正的区别在于，void 是真的表示什么都不返回，而 Kotlin 的 Unit 却是一个真实存在的类型：

public object Unit {
    override fun toString() = "kotlin.Unit"
}

它是一个 object，也就是 Kotlin 里的单例类型或者说单例对象。当一个函数的返回值类型是 Unit 的时候，它是需要返回一个 Unit 类型的对象的：

// Kotlin
fun sayHello() {
  println("Hello!")
  return Unit
}

只不过因为它是个 object ，所以唯一能返回的值就是 Unit 本身。

另外，这一行 return 我们也可以省略不写：

// Kotlin
fun sayHello() {
  println("Hello!")
}

因为就像返回值类型一样，这一行 return，Kotlin 也会帮我们自动加上：

// Kotlin
fun sayHello(): Unit {
  println("Hello!")
  return Unit
}

这两个 Unit 是不一样的，上面的是 Unit 这个类型，下面的是 Unit 这个单例对象，它俩长得一样但是是不同的东西。注意了，这个并不是 Kotlin 给 Unit 的特权，而是 object 本来就有的语法特性。你如果有需要，也可以用同样的格式来使用别的单例对象，是不会报错的：

object Rengwuxian

fun getRengwuxian(): Rengwuxian {
  return Rengwuxian
}

包括你也可以这样写：

val unit: Unit = Unit

也是一样的道理，等号左边是类型，等号右边是对象——当然这么写没什么实际作用啊，单例你就直接用就行了。

所以在结构上，Unit 并没有任何的特别之处，它就只是一个 Kotlin 的 object 而已。除了对于函数返回值类型和返回值的自动补充之外，Kotlin 对它没有再施加任何的魔法了。它的特殊之处，更多的是在于语义和用途的角度：它是个由官方规定出来的、用于「什么也不返回」的场景的返回值类型。但这只是它被规定的用法而已，而本质上它真就是个实实在在的类型。也就是在 Kotlin 里，并不存在真正没有返回值的函数，所有「没有返回值」的函数实质上的返回值类型都是 Unit，而返回值也都是 Unit 这个单例对象，这是 Unit 和 Java 的 void 在本质上的不同。

Unit 的价值所在

那么接下来的问题就是：这么做的意义在哪？

意义就在于，Unit 去掉了无返回值的函数的特殊性，消除了有返回值和无返回值的函数的本质区别，这样很多事做起来就会更简单了。

例：有返回值的函数在重写时没有返回值

比如？

比如在 Java 里面，由于 void 并不是一种真正的类型，所以任何有返回值的方法在子类里的重写方法也都必须有返回值，而不能写成 void，不管你用不用泛型都是一样的：

public abstract class Maker {
  public abstract Object make();
}

public class AppleMaker extends Maker {
  // 合法
  @Override
  public Apple make() {
    return new Apple();
  }
}

public class NewWorldMaker extends Maker {
  // 非法
  @Override
  public void make() {
    world.refresh();
  }
}

public abstract class Maker<T> {
  public abstract T make();
}

public class AppleMaker extends Maker<Apple> {
  // 合法
  Override
  public Apple make() {
    return new Apple();
  }
}

public class NewWorldMaker extends Maker<void> {
  // 非法
  Override
  public void make() {
    world.refresh();
  }
}

你只能去写一行 return null 来手动实现接近于「什么都不返回」的效果：

public class NewWorldMaker extends Maker {
  @Override
  public Object make() {
    world.refresh();
    return null;
  }
}

而且如果你用的是泛型，可能还需要用一个专门的虚假类型来让效果达到完美：

public class NewWorldMaker extends Maker<Void> {
  @Override
  public Void make() {
    world.refresh();
    return null;
  }
}

而在 Kotlin 里，Unit 是一种真实存在的类型，所以直接写就行了：

abstract class Maker {
  abstract fun make(): Any
}

class AppleMaker : Maker() {
  override fun make(): Apple {
    return Apple()
  }
}

class NewWorldMaker : Maker() {
  override fun make() {
    world.refresh()
  }
}

abstract class Maker<T> {
  abstract fun make(): T
}

class AppleMaker : Maker<Apple>() {
  override fun make(): Apple {
    return Apple()
  }
}

class NewWorldMaker : Maker<Unit>() {
  override fun make() {
    world.refresh()
  }
}

这就是 Unit 的去特殊性——或者说通用性——所给我们带来的便利。

例：函数类型的函数参数

同样的，这种去特殊性对于 Kotlin 的函数式编程也提供了方便。一个函数的函数类型的参数，在函数调用的时候填入的实参，只要符合声明里面的返回值类型，它是可以有返回值，也可以没有返回值的：

fun runTask(task: () -> Any) {
  when (val result = task()) {
    Unit -> println("result is Unit")
    String -> println("result is a String: $result")
    else -> println("result is an unknown type")
  }
}

...

runTask { } // () -> Unit
runTask { println("完成！") } // () -> String
runTask { 1 } // () -> Int

Java 不支持把方法当做对象来传递，所以我们没法跟 Java 做对比；但如果 Kotlin 不是像现在这样用了 Unit，而是照抄了 Java 的 void 关键字，我们就肯定没办法这样写。

小结：去特殊化

这就是我刚才所说的，对于无返回值的函数的「去特殊化」，是 Unit 最核心的价值。它相当于是对 Java 的 void 进行了缺陷的修复，让本来有的问题现在没有了。而对于实际开发，它的作用是属于润物细无声的，你不需要懂我说的这一大堆东西，也不影响你享受 Unit 的这些好处。

…………

那我出这期视频干嘛？

——开个玩笑。了解各种魔法背后的实质，对于我们掌握和正确地使用一门语言是很有必要的。

延伸：当做纯粹的单例对象来使用

比如，知道 Unit 是什么之后，你就能理解为什么它能作为函数的参数去被使用。

Compose 里的协程函数 LaunchedEffect() 要求我们填入至少一个 key 参数，来让协程在界面状态变化时可以自动重启：

LaunchedEffect(key) {
  xxxx
  xxxxxx
  xxx
}

而如果我们没有自动重启的需求，就可以在参数里填上一个 Unit：

LaunchedEffect(Unit) {
  xxxx
  xxxxxx
  xxx
}

因为 Unit 是不变的，所以把它填进参数里，这个协程就不会自动重启了。这招用着非常方便，Compose 的官方示例里也有这样的代码。不过这个和 Unit 自身的定位已经无关了，而仅仅是在使用它「单例」的性质。实际上，你在括号里把它换成任何的常量，效果都是完全一样的，比如 true、比如 false、比如 1、比如 0、比如 你好，都是可以的。所以如果你什么时候想「随便拿个对象过来」，或者「随便拿个单例对象过来」，也可以使用 Unit，它和你自己创建一个 object 然后去使用，效果是一样的。

总结

好，这就是 Kotlin 的 Unit，希望这个视频可以帮助你更好地了解和使用它。下期我会讲 Kotlin 里另一个特殊的类型：Nothing。关注我，了解更多 Android 开发的知识和技能。我是扔物线，我不和你比高低，我只助你成长。我们下期见！

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了。

正文

「学 Compose 还是学自定义 View？」这个问题从去年初我发第一个 Compose 主题的视频到现在，一直有人问我。这个问题的背后表达了一种担忧：会不会等我学完自定义 View，它却过时了？

大家好，我是扔物线朱凯。

最近情况比较特殊，我被封在小区里了。虽然办公室就在马路对面，但是咫尺天涯，我还是拿不到我的摄像设备。所以今天就用手机来录一期。

今天来跟大家聊聊「学 Compose 还是学自定义 View」的问题。

首先我们确定一下前提：这是个个人职业发展角度的讨论，也就是所谓的利益导向。关于 Compose 和自定义 View 哪个更好或者我更喜欢哪个，在这个视频里不做讨论。

从原理看，Compose 似乎可以取代 View

大家更关心的是【**现在】**学哪个，如果让我简单直接地回答：自定义 View。但这个话题不是一句话这么简单，如果你打算做出最适合自己的决定，你最好把整个视频看完。

首先，我们来做一个对未来的展望：Compose 作为 Android 官方给出的新的 UI 方案，未来可以完全取代 View 的方案吗？

Compose 是基于 View 系统的，它的原理是通过一个自定义的 View，去对它的 onMeasure()、onLayout()、onDraw()、dispatchTouchEvent() 等等方法进行深度定制，来实现「在同一个 View 的内部完成整个 UI 组件树」这样的效果。也就是在 Compose 代码里面，你写的一个包含了多层复杂组件的完整界面，它实际上有可能全都被绘制在了同一个 View 上，并且触摸事件也都是由同一个 View 来进行实际承载和识别的。

由于这样的底层原理，Compose 是不会有能力上的天然限制的，也就是传统 View 方案能做的事 Compose 全都可以做，比如各种复杂的动画、手势、嵌套的多层级布局，Compose 都可以做到。这个我在读 Compose 的代码之前还有点打鼓，在读完它的代码之后我是非常确定的。

Compose 没有做出对等实现的只有 SurfaceView 和 TextureView 这两个类，它们是用于高速刷新的内容的，比如视频播放或者相机的取景器界面。你在写 Compose 代码的时候如果想用到它俩的效果，你找不到对应的 Compose 组件，而是需要老老实实去用原生的 SurfaceView 或者 TextureView。但是这是因为它俩的核心并不是 View，而是 Android 所提供的那一套跟 Surface 类相关的显示系统，所以不管你用 Compose 还是不用 Compose，这俩东西都是单独学的。换句话说，就算不用 Compose，有几个人知道怎么用 SurfaceView 的？——就是这个道理。

所以，从原理的角度来看，Compose 是有能力完全取代 View 的。

但短期内不会发生

那么下一个问题就是：这件事真的会发生吗？Compose 理论上有能力取代 View 是吧？但它未来真的会取代 View，成为写 UI 的主流做法吗？

首先我觉得是会的。Compose 发展到现在，虽然还没有达到完善的形态——比如传统 View 系统的某些官方组件或者开源组件，Compose 里还没有相应的实现，以及滑动组件的性能现在和传统的 RecyclerView 还有差距——但是到现在为止，Compose 和 View 系统的这些差距，已经没有不可弥合的了。只要给它几年时间，这些差距都能补齐。Compose 这个东西，最大的风险在于官方开发了几年之后，发现它的坑太大，怎么都填不平，最终弃坑，宣布砍掉 Compose 项目，让大家回到 View 去。官方弃坑，这是 Compose 最大的风险。但是我可以告诉大家，现在 Compose 已经迈过这个坎了，它现在遗留的都是一些靠时间来慢慢打磨就可以解决的小问题。再加上 Android 官方的态度也是非常坚决，要让 Compose 替代 View 成为新的 UI 方案，所以 Compose 取代 View，已经是必然会发生的事情了。

但是！有一个问题是，这种替代短期内并不会完成。

为什么？因为当下几乎所有公司的现有代码都是基于 View 系统的。你写新代码当然可以选择 Compose，但是老代码维护的时候不还是要和 View 打交道吗，是吧？——不过这个其实也和环境有关系，我们国内有一个情况是，巨型 App 比较多。一个软件的规模越庞大，它转身就越慢，那些巨型 App，它本身就非常复杂了，你往里面加任何一个新依赖都会进一步增加它的复杂度。更不用说 Compose 这种 UI 库，它的接入一定不是一个所谓的大规模重构就替换完成了，没人敢这么干，肯定会是一个渐进式的替换过程，今天替换这个界面，明天替换那个界面。那么对于大项目来说，就会在相当长的时间里，团队需要同时面对两种 UI 方案进行开发，这样一是增加了出问题的风险，二是会长时间降低团队的开发效率——Compose 是提升开发效率的对吧？但是在切换过程中，它是降效的。所以你会发现，大公司很多都已经在尝试 Compose 了，但没有一个是已经进入了全面替换的流程了的。这个国内和国外的公司都是这样，而我们的大公司往往 App 的规模要比国外的大很多，这个大家应该知道。

所以在接下来的几年，我们的大公司肯定会是在谨慎的探索中，慢慢地切换到 Compose。

学哪个？

那么，回到刚才开头的问题：学哪个？

我的观点是：对于当下这个时代，你如果有时间，双修——Compose 和自定义 View 两个都学——是对我们的职业发展最负责的选择。而如果你的时间不够，只能先学一个，那么去学自定义 View。虽然我现在有一门 Compose 的课程，但是我还是得说，这玩意是面向未来的，现在从找工作的角度考虑，最硬的还是自定义 View。其实我对我这门 Compose 课程的期待也是面向未来的，虽然它目前的销量已经大大超出我的设想。

不过有些人学 Compose 是为了吃时代红利，是想在早期成为一个 Compose 高手，然后出名啊或者在公司做 Compose 方向的顶梁柱啊什么的，这个我觉得没问题，那你现在就学 Compose 是可以的。但这就是另一个思维方向了。

总结

好，关于「学 Compose 还是学自定义 View」，今天就聊到这里。如果你喜欢我的视频，还请点赞关注收藏转发，你们的支持对我非常重要。我是扔物线，我不和你比高低，我只助你成长。

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了。

正文

这是我在网上找到的一份 Android 键值对存储方案的性能测试对比（数越小越好）：

可以看出，DataStore 的性能比 MMKV 差了一大截。MMKV 是腾讯在 2018 年推出的，而 DataStore 是 Android 官方在 2020 年推出的，并且它的正式版在 2021 年 8 月才发布。一个官方发布的、更（gèng）新的库，性能竟然比不过比它早两年发布的、第三方的库。而且我们能看到，更离谱的是，它甚至还比不过 SharedPreferences 。Android 官方当初之所以推出 DataStore，就是要替代掉 SharedPreferences，并且主要原因之一就是 SharedPreferences 有性能问题，可是测试结果却是它的性能不如 SharedPreferences。

所以，这到底是为什么？

啊，我知道了——因为 Google 是傻逼！

SharedPreferences：不知不觉被嫌弃

大家好，我是扔物线朱凯。

键值对的存储在移动开发里非常常见。比如深色模式的开关、软件语言、字体大小，这些用户偏好设置，很适合用键值对来存。而键值对的存储方案，最传统也最广为人知的就是 Android 自带的 SharedPreferences。它里面的 -Preferences，就是偏好设置的意思，从名字也能看出它最初的定位。

SharedPreferences 使用起来很简单，也没什么问题，大家就这么用了很多年。——但！渐渐地，有人发现它有一个问题：卡顿，甚至有时候会出现 ANR。

MMKV：好快！

怎么办？换！2018 年 9 月，腾讯开源了一个叫做 MMKV 的项目。它和 SharedPreferences 一样，都是做键值对存储的，可是它的性能比 SharedPreferences 强很多。真的是强，很，多。在 MMKV 推出之后，很多团队就把键值对存储方案从 SharedPreferences 换到了 MMKV。

DataStore：官方造垃圾？

再然后，就是又过了两年，Google 自己也表示受不了 SharedPreferences 了，Android 团队公布了 Jetpack 的新库：DataStore，目标直指 SharedPreferences，声称它就是 Android 官方给出的 SharedPreferences 的替代品。

替代的理由，Android 团队列了好几条，但不出大家意料地，「性能」是其中之一：

也就是说，Android 团队直接抛弃了 SharedPreferences，换了个新东西来提供更优的性能。

但是，问题随之就出现了：大家一测试，发现这 DataStore 的性能并不强啊？跟 MMKV 比起来差远了啊？要知道，MMKV 的发布是比 DataStore 早两年的。DataStore 比人家晚两年发布，可是性能却比人家差一大截？甚至，从测试数据来看，它连要被它替代掉的 SharedPreferences 都比不过。这么弱？那它搞个毛啊！

Android 团队吭哧吭哧搞个新东西出来，竟然还没有市场上两年前就出现的东西强？这是为啥？

首先，肯定得排除「DataStore 是垃圾」这个可能性。虽然这猛一看、粗一想，明显就是 DataStore 垃圾、Google 傻逼，但是你仔细想想，这可能吗？

那如果不是的话，又是因为什么？——因为你被骗了。

MMKV 的一二三四

被谁骗了？不是被 MMKV 骗了，也不是具体的某个人。事情其实是这样的：

大家知道 MMKV 当初为什么会被创造出来吗？其实不是为了取代 SharedPreferences。

最早是因为微信的一个需求（来源：MMKV 组件现在开源了）：

微信作为一个全民的聊天 App，对话内容中的特殊字符所导致的程序崩溃是一类很常见、也很需要快速解决的问题；而哪些字符会导致程序崩溃，是无法预知的，只能等用户手机上的微信崩溃之后，再利用类似时光倒流的回溯行为，看看上次软件崩溃的最后一瞬间，用户收到或者发出了什么消息，再用这些消息中的文字去尝试复现发生过的崩溃，最终试出有问题的字符，然后针对性解决。

那么这个「时光倒流」应该怎么做，就成了问题的关键。我们要知道，程序中的所有变量都是存活在内存里的，一旦程序崩溃，所有变量全都灰飞烟灭。

所以要想实现「时光倒流」，就需要把想回溯的时光预先记录下来。说人话就是，我们需要把界面里显示的文字写到手机磁盘里，才能在程序崩溃、重新启动之后，通过读取文件的方式来查看。

更麻烦的是，这种记录的目标是用来回溯查找「导致程序崩溃的那段文字」，而同时，正是因为没有人知道哪段文字会导致程序崩溃才去做的记录，这就要求每一段文字都需要先写入磁盘、然后再去显示，这样才能保证程序崩溃的时候那段导致崩溃的文字一定已经被记录到了磁盘。

对吧？

这就有点难了。

我们来想象一下实际场景：

• 如果用户的微信现在处于一个对话界面中，这时候来了一条新的消息，这条消息里可能会包含微信处理不了的字符，导致微信的崩溃。
  
• 而微信为了及时地找出导致崩溃的字符或者字符串，所以给程序增加了逻辑：所有的对话内容在显示之前，先保存到磁盘再显示：

val bubble: WxTextView = ...
recordTextToDisk(text) // 显示之前，先保存到磁盘
bubble.setText(text)

• 那么你想一下，这个「保存到磁盘」的行为，我应该做成同步的还是异步的？
  
  • 为了不卡主线程，我显然应该做成异步的；
  • 但这是马上就要显示的文字，如果做成异步的，就极有可能在程序崩溃的时候，后台线程还没来得及把文字存到磁盘。这样的话，就无法进行回溯，从而这种记录也就失去了价值。
    
  • 所以从可用性的角度来看，我只能选择放弃性能，把它做成同步的，也就是在主线程进行磁盘的写操作。
    
  • 一次磁盘的写操作，花个一两毫秒是很正常的，三五毫秒甚至超过 10 毫秒也都是有可能的。具体的方案可以选择 SharedPreferences，也可以选择数据库，但不管选哪个，只要在主线程去完成这个写操作，这种耗时就绝对无法避免。一帧的时间也就 16 毫秒而已——那时候还没有高刷，我们就先不谈高刷了，一帧就是 16 毫秒——16 毫秒里来个写磁盘的操作，用户很可能就会感受到一次卡顿。
• 这还是相对比较好的情况。我们再想一下，如果用户点开了一个活跃的群，这个群里有几百条没看过的消息：
  • 那么在他点开的一瞬间，是不是界面中会显示出好几条消息气泡？这几条消息的内容，哪些需要记录到磁盘？全都要记录的，因为谁也知道哪一条会导致微信的崩溃，任何一条都是可能的。
  • 而如果把这几条消息都记录下来，是不是每条消息的记录都会涉及一次写磁盘的操作？这几次写磁盘行为，是发生在同一帧里的，所以在这一帧里因为记录文字而导致的主线程耗时，也会相比起刚才的例子翻上好几倍，卡顿时间就同样也会翻上好几倍。
• 还有更差的情况。如果用户看完这一页之后，决定翻翻聊天记录，看看大家之前都聊了什么：
  • 这时候，是不是上方每一个新的聊天气泡的出现，都会涉及一次主线程上的写磁盘行为？
  • 而如果用户把手猛地往下一滑，让上面的几十条消息依次滑动显示出来，这是不是就会导致一次爆发性的、集中式的对磁盘的写入？
  • 用户的手机，一定会卡爆。

所以这种「高频、同步写入磁盘」的需求，让所有的现有方案都变得不可行了：不管你是用 SharedPreferences 还是用数据库还是别的什么，只要你在主线程同步写入磁盘，就一定会卡，而且是很卡。

但是微信还是有高手，还是有能想办法的人，最终微信找到了解决方案。他们没有用任何的现成方案，而是使用了一种叫做内存映射（mmap()）的底层方法。

它可以让系统为你指定的文件开辟一块专用的内存，这块内存和文件之间是自动映射、自动同步的关系，你对文件的改动会自动写到这块内存里，对这块内存的改动也会自动写到文件里。

更多更深的原理，说实话我也不是看得很懂，就不跟大家装了。但关键是，有了这一层内存作为中间人，我们就可以用「写入内存」的方式来实现「写入磁盘」的目标了。内存的速度多快呀，耗时几乎可以忽略，这样一下子就把写磁盘造成卡顿的问题解决了。

而且这个内存映射还有一点很方便的是，虽然这块映射的内存不是实时向对应的文件写入新数据，但是它在程序崩溃的时候，并不会随着进程一起被销毁掉，而是会继续有条不紊地把它里面还没同步完的内容同步到它所映射的文件里面去。

至于更下层的原理，我也说了，没看懂，你也别问我。

总之，有了这些特性，内存映射就可以让程序用往内存里写数据的速度实现往磁盘里写数据的实际效果，这样的话，「高频、同步写入磁盘」的需求就完美满足了。不管是用户打开新的聊天页面，还是滑动聊天记录来查看聊天历史，用内存映射的方式都可以既实时写入所有即将被渲染的文字，又不会造成界面的卡顿。这种性能，是 SharedPreferences 和数据库都做不到的——顺便提一句，虽然我总在提 SharedPreferences，但其实这种做法本来是先在 iOS 版的微信里应用的，后来才移植到了 Android 版微信。这也是我刚才说的，MMKV 的诞生并不是为了取代 SharedPreferences。

再后来，就是 2018 年，微信把这个叫做 MMKV 的项目开源了。它的名字，我猜就是直白的「Memory-Map based Key-Value（方案）」，基于内存映射的键值对。不过没有找作者求证，如果说错了欢迎指正。

在 MMKV 开源之后，很多团队就把键值对存储方案从 SharedPreferences 迁移到了 MMKV。为什么？因为它快呀。

MMKV 并不总是快如闪电

不过……事情其实没那么简单。MMKV 虽然大的定位方向和 SharedPreferences 一样，都是对于键值对的存储，但它并不是一个全方位更优的方案。

比如性能。我前面一直在说 MMKV 的性能更强，对吧？但事实上，它并不是任何时候都更强。由于内存映射这种方案是自行管理一块独立的内存，所以它在尺寸的伸缩上面就比较受限，这就导致它在写大一点的数据的时候，速度会慢，而且可能会很慢。我做了一份测试：

在连续 1000 次写入 Int 值的场景中，SharedPreferences 的耗时是 1034 毫秒，也就是 1 秒多一点；而 MMKV 只有 2 毫秒，简直快得离谱；而且最离谱的是，Android 官方最新推出的 DataStore 是 1215 毫秒，竟然比 SharedPreferences 还慢。这个前面我也提过，别人的测试也是这样的结果。

可是，SharedPreferences 是有异步 API 的，而 DataStore 是基于协程的。这就意味着，它们实际占用主线程的时间是可以低于这份测试出的时间的，而界面的流畅在意的正是主线程的时间消耗。所以如果我统计的不是全部的耗时，而是主线程的耗时，那么统计出的 SharedPreferences 和 DataStore 的耗时将会大幅缩减：

还是比 MMKV 慢很多，是吧？但是这是对于 Int类型的高频写入，Int 数据是很小的。而如果我把写入的内容换成长字符串，再做一次测试：

MMKV 就不具备优势了，反而成了耗时最久的；而这时候的冠军就成了 DataStore，并且是遥遥领先。这也就是我在开头说的：你可能被骗了。被谁骗了？被「耗时」这个词：我们关注性能，考量的当然是耗时，但要明确：是主线程的耗时。所以视频开头的那张图，是不具备任何参考意义的。

但其实，它们都够快了

不过在换成了这种只看主线程的耗时的对比方案之后，我们会发现谁是冠军其实并不是很重要，因为从最终的数据来看，三种方案都不是很慢。虽然这半秒左右的主线程耗时看起来很可怕，但是要知道这是 1000 次连续写入的耗时，而我们在真正写程序的时候，怎么会一次性做 1000 次的长字符串的写入？所以真正在项目中的键值对写入的耗时，不管你选哪个方案，都会比这份测试结果的耗时少得多的，都少到了可以忽略的程度，这是关键。

各自的优势和弱点

那……既然它们的耗时都少到了可以忽略，不就是选谁都行？那倒不是。

MMKV 优势：写速度极快

我们来看一个 MMKV 官方给出的数据对比图：

从这张图看来，SharedPreferences 的耗时是 MMKV 的接近 60 倍。很明显，如果 SharedPreferences 用异步的 API 也就是 apply() 来保存的话，是不可能有这么差的性能的，这个一定是使用同步的 commit() 的性能来做的对比。那么为什么 MMKV 官方会这样做对比呢？这个又要说到它的诞生场景了：MMKV 最初的功能是在文字显示之前先把它记录到磁盘，然后如果接下来这个文字显示失败导致程序崩溃，稍后就可以从磁盘里把这段文字恢复出来，进行分析。而刚才我也说过，这种场景的特殊性在于，导致程序崩溃的文字往往是刚刚被记录下来，程序就崩溃了，所以如果采用异步处理的方案，就很有可能在文字还没来得及真正存储到磁盘的时候程序就发生了崩溃，那就没办法把它恢复出来进行分析了。因此这样的场景，是不能接受异步处理的方案的，只能同步进行。所以 MMKV 在意的，就是同步处理机制下的耗时，它不在意异步，因为它不接受异步。

而在同步处理的机制下，MMKV 的性能优势就太明显了。原因上面说过了，它写入内存就几乎等于写入了磁盘，所以速度巨快无比。这就是 MMKV 的优势之一：极高的同步写入磁盘的性能。

另外 MMKV 还有个特点是，它的更新并不像 SharedPreferences 那样全量重新写入磁盘，而是只把要更新的键值对写入，也就是所谓的增量式更新。这也会给它带来一些性能优势，不过这个优势并不算太核心，因为 SharedPreferences 虽然是全量更新的模式，但只要把保存的数据用合适的逻辑拆分到多个不同的文件里，全量更新并不会对性能造成太大的拖累。所以这个性能优势虽然有，但并不是关键。

还有刚才提到的，对于大字符串的场景，MMKV 的写入性能并不算快，甚至在我们的测试结果里是最慢的，对吧？这一点算是劣势。但是实事求是地说，我们在开发里不太可能连续不断地去写入大字符串吧？所以这个性能劣势虽然有，但也并不是关键。

整体来说，MMKV 比起 SharedPreferences 和 DataStore 来说，在写入小数据的情况下，具有很高的写入性能，这就让高频写入的场景非常适合使用 MMKV 来处理。因此如果你的项目里也有像微信的崩溃回溯的这种高频写入的需求，MMKV 就很可能是你的最佳方案。而如果你除了「高频写入」，还和微信一样要求「同步写入」，那 MMKV 就可能是你的唯一选择了。不过，如果你真的主要是存储大字符串的——例如你写的是一个文本编辑软件，需要保存的总是大块的文本——那么用 MMKV 不一定会更快了，甚至可能会比较慢。

MMKV 优势：支持多进程

另外，MMKV 还有一个巨大的优势：它支持多进程。

行业内也有很多公司选用 MMKV 并不是因为它快，而是因为它支持多进程。SharedPreferences 是不支持多进程的，DataStore 也不支持——从 DataStore 提交的代码来看，它已经在加入多进程的支持了，但目前还没有实现。所以如果你们公司的 App 是需要在多个进程里访问键值对数据，那么 MMKV 是你唯一的选择。

MMKV 劣势：丢数据

除了速度快和支持多进程这两个优势之外，MMKV 也有一个弱点：它会丢数据。

任何的操作系统、任何的软件，在往磁盘写数据的过程中如果发生了意外——例如程序崩溃，或者断电关机——磁盘里的文件就会以这种写了一半的、不完整的形式被保留。写了一半的数据怎么用啊？没法用，这就是文件的损坏。这种问题是不可能避免的，MMKV 虽然由于底层机制的原因，在程序崩溃的时候不会影响数据往磁盘的写入，但断电关机之类的操作系统级别的崩溃，MMKV 就没办法了，文件照样会损坏。对于这种文件损坏，SharedPreferences 和 DataStore 的应对方式是在每次写入新数据之前都对现有文件做一次自动备份，这样在发生了意外出现了文件损坏之后，它们就会把备份的数据恢复过来；而 MMKV，没有这种自动的备份和恢复，那么当文件发生了损坏，数据就丢了，之前保存的各种信息只能被重置。也就是说，MMKV 是唯一会丢数据的方案。

可能会有人好奇，为什么 MMKV 不做全自动的备份和恢复。我的猜测是这样的：MMKV 底层的原理是内存映射，而内存映射这种方式，它从内存往磁盘里同步写入的过程并不是实时的，也就是说并不是每次我们写入到映射的内存里就会立即从这块内存写入到磁盘，而是会有一些滞后。而如果我们要做全自动的备份，那就需要每次往内存里写入之后，立即手动把内存里最新的数据同步到磁盘。但这就和 MMKV 的定位不符了：因为这种「同步」本质上就是一次从内存到磁盘的写入，并且是同步的写入；而 MMKV 是要高频写入的，如果在高频写入内存的同时，还要实时地把数据从内存同步到磁盘，就会一下子把写入速度从内存级别下降到磁盘级别，MMKV 的性能优势也就荡然无存了。所以从原理上，自动备份是个很难实现的需求，因为它和 MMKV 的定位是矛盾的。不过正好 MMKV 所要记录的这些要显示的文字，也并不是不能丢失的内容——真要是丢了就丢了呗，反正是崩溃日志，丢了就不要了，我下次启动程序之后继续记录就是了——所以既然要求必须高频写入而导致很难实现自动备份，并且也确实能接受因为不做自动备份而导致的数据损坏，那就干脆不做自动备份了。不过这也是我猜的啊，大家如果有不同意见欢迎留言评论指正。

所以如果你要用 MMKV，一定要记得只能用它来存可以接受丢失、不那么重要的数据。或者你也可以选择对数据进行定期的手动备份——全自动的实时备份应该是会严重影响性能的，不过我没试过，你如果有兴趣可以试试。另外据我所知，国内在使用 MMKV 的团队里，几乎没有对 MMKV 数据做了备份和恢复的处理的。

那么说到这里，很容易引出一个问题：微信自己就不怕丢数据吗？（大字：微信就不怕丢数据？）关于这一点，我相信，微信绝对不会把用户登录状态相关的信息用 MMKV 保存并且不做任何的备份，因为这一定会导致每天都会有一些用户在新一次打开微信的时候发现自己登出了。这会是非常差的用户体验，所以微信一定不会让这种事发生。至于一些简单的用户设置，那我就不清楚了。比如深色主题重要吗？这是个不好说的事情：某个用户在打开软件的时候，发现自己之前设置的深色主题失效了，软件突然变回了亮色方案，这肯定是不舒服的事；但我们要知道，MMKV 的文件损坏终归是个概率极低的事件，所以偶尔地发生一次这样的事件在产品的角度是否可以接受，那可能是需要产品团队自身做一个综合考量的事了。对于不同的产品和团队，也许不可接受，也许无伤大雅。而对于你所开发的产品应该是怎样的判断，就得各位自己和团队去商量了。所以像深色主题这种「可以重要也可以不重要」的信息，用不用 MMKV 保存、用的时候做不做备份，大家需要自己去判断。

总之，大家要知道这件事：MMKV 是有数据损坏的概率的，这个在 MMKV 的官方文档就有说明：MMKV 的 GitHub wiki 页面显示，微信的 iOS 版平均每天有 70 万次的数据校验不通过（即数据损坏）。这还是 2020 年的数据，现在可能会更多。

所以我们在使用 MMKV 的时候，一定要考虑到这个问题，你要知道这件事。至于具体的应对，是接受它、坏就坏了，还是要认真应对、做好备份和恢复，这就是大家自己的决策了。

SharedPreferences 的优势：不丢数据

好，那么说完了 MMKV，我来说一下 SharedPreferences，这个最传统的方案。

它有什么优势呢？——它没有优势。跟 MMKV 比起来，它不会丢数据，这个倒是它比 MMKV 强的地方，但是我觉得更应该归为 MMKV 的劣势，而不是 SharedPreferences 的优势，因为只有 MMKV 会丢数据嘛，是吧？

不过不管是这个的优势还是那个的劣势，如果你不希望丢数据，并且也不想花时间去做手动的备份和恢复，同时对于 MMKV 的超高写入性能以及多进程支持都没有需求，那你其实更应该选择 SharedPreferences，而不是 MMKV。对吧？

SharedPreferences 的劣势：卡顿

但更进一步地说：如果你选择了 SharedPreferences，那么你更应该考虑 DataStore。因为 DataStore 是一个完全超越了 SharedPreferences 的存在。你看 SharedPreferences 和 MMKV 它俩是各有优劣对吧？虽然 MMKV 几乎完胜，但是毕竟 SharedPreferences 不会丢数据呀，所以它俩是各有优劣的。但当 DataStore 和 SharedPreferences 比起来，那就是 DataStore 完胜了。这其实也很合理，因为 DataStore 被创造出来，就是用于替代掉 SharedPreferences 的；而 MMKV 不一样，它的诞生有它独特的使命，它是为了「高频同步写入」而诞生的，所以不能全角度胜过 SharedPreferences 也很正常。

我们还说回 DataStore。DataStore 被创造出来的目标就是替代 SharedPreferences，而它解决的 SharedPreferences 最大的问题有两点：一是性能问题，二是回调问题。

先说性能问题：SharedPreferences 虽然可以用异步的方式来保存更改，以此来避免 I/O 操作所导致的主线程的耗时；但在 Activity 启动和关闭的时候，Activity 会等待这些异步提交完成保存之后再继续，这就相当于把异步操作转换成同步操作了，从而会导致卡顿甚至 ANR（程序未响应）。这是为了保证数据的一致性而不得不做的决定，但它也确实成为了 SharedPreferences 的一个弱点。而 MMKV 和 DataStore 用不同的方式各自都解决了这个问题——事实上，当初 MMKV 被公布的时候之所以在业界有相当大的反应，就是因为它解决了 SharedPreferences 的卡顿和 ANR 的问题。

不过有一点我的观点可能和一些人不同：SharedPreferences 所导致的卡顿和 ANR，其实并不是个很大的问题。它和 MMKV 的数据损坏一样，都是非常低概率的事件。它俩最大的区别在于其实是政治上的：SharedPreferences 的卡顿很容易被大公司的性能分析后台监测到，所以不解决的话会扣绩效，而解决掉它会提升绩效；而 MMKV 的数据损坏是无法被监测到的，所以……哈？事实上，大家想一下：卡顿和数据损坏，哪个更严重？当然是数据损坏了，对吧。

其实除了写数据时的卡顿，SharedPreferences 在读取数据的时候也会卡顿。虽然它的文件加载过程是在后台进行的，但如果代码在它加载完成之前就去尝试读取键值对，线程就会被卡住，直到文件加载完成，而如果这个读取的过程发生在主线程，就会造成界面卡顿，并且数据文件越大就会越卡。这种卡顿，不是 SharedPreferences 独有的，MMKV 也是存在的，因为它初始化的过程同样也是从磁盘里读取文件，而且是一股脑把整个文件读完，所以耗时并不会比 SharedPreferences 少。而 DataStore，就没有这种问题。DataStore 不管是读文件还是写文件，都是用的协程在后台进行读写，所有的 I/O 操作都是在后台线程发生的，所以不论读还是写，都不会卡主线程。

简单来说，SharedPreferences 会有卡顿的问题，这个问题 MMKV 解决了一部分（写时的卡顿），而 DataStore 完全解决了。所以如果你的目标在于全方位的性能，那么你应该考虑的是 DataStore，因为它是唯一完全不会卡顿的。

SharedPreferences 的劣势：回调

DataStore 解决的 SharedPreferences 的另一个问题就是回调。SharedPreferences 如果使用同步方式来保存更改（commit())，会导致主线程的耗时；但如果使用异步的方式，给它加回调又很不方便，也就是如果你想做一些「等这个异步提交完成之后再怎么怎么样」的工作，会很麻烦。

而 DataStore 由于是用协程来做的，线程的切换是非常简单的，你就把「保存完成之后做什么」直接写在保存代码的下方就可以了，很直观、很简单。

对比来说，MMKV 虽然没有使用协程，但是它太快了，所以大多数时候并不需要切线程也不会卡顿。总之，在这件事上，只有 SharedPreferences 最弱。

总结

区别大概就是这么些区别了，大致总结一下就是：

如果你有多进程支持的需求，MMKV 是你唯一的选择；如果你有高频写入的需求，你也应该优先考虑 MMKV。但如果你使用 MMKV，一定要知道它是可能丢失数据的，不过概率很低就是了，所以你要在权衡之后做好决定：是自行实现数据的备份和恢复方案，还是直接接受丢数据的事实，在每次丢失数据之后帮用户把相应的数据进行初始化。当然了，一个最鸡贼的做法是：反正数据监测不会监测到 MMKV 的数据丢失，又不影响绩效，那就不管它呗！不过我个人是不太赞同这种策略的，有点不负责哈。

另外，如果你没有多进程的需求，也没有高频写入的需求，DataStore 作为性能最完美的方案，应该优先被考虑。因为它在任何时候都不会卡顿，而 MMKV 在写大字符串和初次加载文件的时候是可能会卡顿的，而且初次加载文件的卡顿不是概率性的，只要文件大到了引起卡顿的程度，就是 100% 的卡顿。不过如果你的团队没有在用协程，甚至没有在用 Kotlin，那 DataStore 也暂时不适合你们，因为它是完全依赖 Kotlin 协程来实现和使用的。

哦对了，其实我今天说的 DataStore 只是面向简单键值对存储的 DataStore 方案，它的全称叫 Preferences DataStore，而 DataStore 还有用于保存结构化数据的方案，叫做 Proto DataStore，它内部用的是 Protocol Buffer 作为数据结构的支持。但是这个有点跑题，我就不展开了。

至于 SharedPreferences 嘛，在这个时代，它真的可以被放弃了。除非——像我刚说的——如果你们还没在用协程，那 SharedPreferences 可能还能苟延残喘一下。

今天的内容就是这些了。如果你喜欢我的内容，还请多多点赞转发收藏分享，以后我会讲更多和 Android 开发相关的有趣、有用的分享。关注我，不错过我的任何新内容。我是扔物线，我不和你比高低，我只助你成长。我们下期见。

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了，直接翻到底部评论区吧。

文字版

属性动画怎么写？

简单，先拿到 View 的对象，再创建一个针对它的属性的 ObjectAnimator，然后调用 animator 的 start() 函数，就可以播放动画了：

我们还可以用 reverse() 函数来反向播放动画：

很简单，很方便。

而 Compose 的动画竟然还能更简单。你只要把变量用一个函数包住，剩下的就都不用管了，动画是自动的：

提高开发效率，我们就可以轻松一点。我们轻松了，公司就可以少招几个程序员啊！（不是）

「更简单」并不是真正原因

大家好，我是扔物线朱凯。

Android 的属性动画，是很好用的：又强大，又简单。然而在 Jetpack Compose 里，属性动画这一套东西却没有移植过去。

为什么？你刚才也看到了，Compose 的动画写起来比属性动画更简单。但！这并不是它没有移植属性动画的原因，因为它只是个表象，真正的原因在背后的本质。

属性动画和 Compose 动画的本质区别

Android 的属性动画，实质上是对 View 的属性做渐变，也就是连续不断地修改 View 对象的属性值。所以我们需要先拿到 View 对象，再去对它的属性做动画。而到了 Compose 里，没有 View 了；不止没有 View，也没有相当于 View 的其它形式的界面元素。我们写的 Compose 代码只是对界面的描述，而并不是界面元素本身。界面元素当然有，界面肯定不是从空气里蹦出来的，但是 Compose 的界面元素是在底层活动的，我们拿不到，所以也操作不了。

但我们可以用一种叫做 State Hoisting——状态提升——的方式来把界面里的属性暴露出来，然后直接去对这些属性做动画。由于 Compose 的声明式特性，属性在改变之后会直接被应用到界面，动画就被呈现出来了。这就是 Compose 里动画的写法，也就是我在开头演示的函数：animateFloatAsState()。除了 animateFloatAsState()，Compose 还有 animateDpAsState() animateColorAsState()，这一套函数比较适合状态转移型的动画；另外，对于多个属性的状态切换、特殊场景的动画以及复杂动画的精细定制，Compose 也有相应的 API。

真正的原因

那……为什么要换一种写法，而不继续沿用属性动画呢？就是我刚才说的：属性动画是「拿到 View 对象，操作对象的属性」，而 Compose 里已经没有可以拿到的界面元素的对象了。

那又为什么啊？为什么不让我们拿到？——这又要回到那个词了：「声明式」。Compose 的界面是声明式的，它的核心理念就是让开发者去描述界面，而不是操作界面组件。这样的思维更直白、更傻瓜，写起来也更轻松。所以这其实是一种进步。

可是，如果我真的需要操作界面元素来干其他事，那可怎么办？——你想干什么？自定义绘制、自定义布局、自定义触摸操作、自定义各种监听，Compose 都可以做，而且都不需要拿到所谓的「界面元素」。听起来可能比较不可思议，但是你学一学、写一写就知道了。Compose 是一个经过成熟设计的、体系完整的框架，所以虽然它不可能突破 Android 系统本身的能力限制，但是该有的功能，你得相信，它一定是有的。

针对 Compose 的知识体系，我做了一张框架图，有需要的扫码自取。

所以，为什么属性动画没有被移植到 Compose 来？因为 Compose 里拿不到界面元素的对象，从而导致属性动画的整个理论模型不再适用了。如果硬要把属性动画移植过来，拿给 Compose 用，能做到吗？这个在技术上是能做到的，但没必要，也不应该。虽然属性动画我们都用得比较熟了，但既然 Compose 做出了比属性动画更强大、更好用的动画系统，那换就换呗？

Compose 可以开始搞了

Compose 真的可以学起来了。我用事实来跟你们说明一下。我是有一门 Compose 课程的，这门课从去年下半年开始重制，现在「动画」这一章节就要更新完了，这段时间我们经常会收到一些海外的学员的反馈——主要是美国和新加坡的——说他们那边已经用上 Compose 了，公司要求必须学会 Compose，所以希望我能快点更新。虽然说，对于新技术我们国内整体上会比国外保守一些，比如当年从 Eclipse 到 Android Studio，从 Java 到 Kotlin，包括对 RxJava 的广泛接纳，国内对于新技术的接受总会比国外晚一些。但是早晚，我们国内也会还是会逐渐切换到 Compose 的，这只是个时间问题。而且其实现在国内也已经有一些公司和团队在上 Compose 了，所以这个「全面切换」的时间也不会太久了。

广告部分：如果你要学 Compose，可以考虑一下我的课程。
我花了一年多的时间几乎全职在研究 Compose，而且对于一些比较深的问题我还会和 Android 核心团队的人直接交流，并且大家也能从我的公开视频来验证我讲解知识——尤其是深度知识——的能力，所以你如果要找 Compose 的导师，希望让一个人把你从入门带成专家，我几乎可能是你最好的选择。当然了，你不报我的课也能学会 Compose，我的作用是帮你光速学会，以及帮你达到极致的深度。一个人想在短时间内利用业余时间成为 Compose 高手是很难的，但有了我的课程，一个月的业余时间足够你成为高手了——是真的高手，你的 Compose 知识将能打败大多数大厂的面试官——不过面试官也报了课的除外啊——这是我的价值所在。

不过不管你学不学我的课，Compose 确实可以开始学了。它能帮我们极大地提升开发界面的效率，以及降低复杂界面的开发难度。这两件事情一直都是非常有价值也非常困难的，而 Compose 对于这两件事情都有立竿见影的效果。所以，搞起来吧！现在上车 Compose，应该是对于国内开发者的最后一波早鸟红利了。

最后

下期我可能会继续聊 Compose，也可能是 Jetpack 的其他内容，或者其他 Android 开发的事情。或者大家如果有什么问题想问我的，也可以在评论区告诉我，我可以选择一些在以后的视频里进行回答。好了，本期视频就到这里，如果你喜欢的话，欢迎点赞转发收藏关注，大家的认可对我做好这个账号很有帮助。我是扔物线，我不和你比高低，我只助你成长，我们下期见。

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了，直接翻到底部就行。

开场

大家好，我是扔物线朱凯。

去年我发过几个视频讲 Compose，有做 Compose 的介绍的，有讲原理的，但唯独没有实际代码的讲解。倒是有一节我的 Compose 课程的试听课我也放了出来，但是那个是课程，是三个小时的，有人嫌长，嫌啰嗦。

我真是……

所以今天，我就给大家来一个 Compose 代码的演示。

这个，是我用 Compose 写的一个叫做「围观」的虚构的 App，「虚构」的意思就是里面的功能是我编的，因为我只是要把界面和交互给做出来。这界面看着复杂，但是用 Compose 写起来其实特别简单。今天我就用最流畅的方式给大家讲解一下它的代码，让大家看看 Compose 的界面代码到底长什么样。

功能

我先简单介绍一下这个软件的「功能」。「功能」两个字得加个引号，因为都是假的嘛。

首先顶部是一些基本信息，例如当前用户是谁、通知按钮，以及一个搜索框。

然后中间就是围观的内容。

最上面你可以选择你要围观谁——实际上是选不了的啊，我没写这个功能，所以我就不点了；往下是这个你围观的人他喜欢的东西，比如你看这是在围观我对吧，我就喜欢这么几个东西。你也可以点击其中一项，来查看详情。

详情页的顶部是一个预览图，图的下方就是各种详细信息。

然后关掉详情页之后，下方是这个被围观的人最近的行动轨迹。

在页面的最下方，是一个切换标签页的导航条，不过这个条的导航功能我也没做，只做了点击效果。

就这么简单的一个虚构的示例 App，叫做《围观》。那么接下来我们就来看看它的代码是怎么写的。

代码

首先，由于它的界面是用 Compose 写的，所以我要把 setContentView() 删掉，换成 Compose 专用的 setContent {}：

setContentView(R.layout.activity_main)

...

setContent {
  
}

然后就可以写内容了。

鉴于这是个上下结构的分栏布局，所以二话不说，我先把底部的导航条给做了。用一个 Row() 来做横向布局，里面用 4 个连续的 Icon() 来显示 4 个图标：

setContent {
  NavBar()
}

->
  
@Composable
private fun NavBar() {
  Row {
    Icon(painterResource(R.drawable.icon1), "图标")
    Icon(painterResource(R.drawable.icon2), "图标")
    Icon(painterResource(R.drawable.icon3), "图标")
    Icon(painterResource(R.drawable.icon4), "图标")
  }
}

很难看，没关系，我去调整一下这些图标。我把图标抽到单独的函数里：

再调整一下图标的尺寸：

再归整一下它们的位置布局：

就一下子变得整齐了。

然后我再给它们涂上色：

哎，就又好看了很多。

这时候为了让这些图标有点击的波纹效果，我再把它外面包上一层 Button()：

好，这样底栏就完成了。

代码的细节我在这个视频里就不深入拆解了，今天主要是快速演示、快速感受，让你感受一下用 Compose 写界面大概是怎么一回事。要看细节的可以去看这个项目的源码，扫码加我的助教，让她发给你就行，暗号「围观」。或者看我的 Compose 课程的试听课也行，那个也很细，也可以加助教让助教发你。

导航条完成之后，就可以做上面的部分了。那么在做这部分之前，我要先用一个 Column() 来做纵向布局来把整个界面上下分开，下面是导航条，上面就是我接下来要写的部分：

Column {
    
    NavBar()
}

由于这一部分的内部也是纵向的布局，所以我再套一层 Column()：

Column {
    Column {
    }
    NavBar()
}

然后加个 fillMaxWidth() 让它横向撑满；再给它个 weight()，让它纵向撑满剩余空间，也就是把导航条踩到底：

Column {
  Column(Modifier
      .fillMaxWidth()
      .weight(1f)
      .background(Color(0xfffafafa))) {
  }
  NavBar()
}

好，接下来就要填充上面这一大块空白了。

从上到下地做，所以第一步是顶部的基本信息的横条。

我可以先用一个 Row() 来给出横向的布局：

Column {
  Column(
    Modifier
      .fillMaxWidth()
      .weight(1f)
      .background(Color(0xfffcfcfc))
  ) {
    Row {
      
    }
  }
  NavBar()
}

然后往里面依次塞一个头像的图片：

Column {
  Column(
    Modifier
      .fillMaxWidth()
      .weight(1f)
      .background(Color(0xfffcfcfc))
  ) {
    Row {
      Image(
        painterResource(id = R.drawable.avatar_rengwuxian),
        "头像",
      )
    }
  }
  NavBar()
}

一个纵向包着两块文字的 Column()：

Column {
    Column(
        Modifier
            .fillMaxWidth()
            .weight(1f)
            .background(Color(0xfffcfcfc))
    ) {
        Row {
            Image(
                painterResource(id = R.drawable.avatar_rengwuxian),
                "头像",
            )
            Column {
                Text("欢迎回来！")
                Text("小朱")
            }
        }
    }
    NavBar()
}

和一个小铃铛：

Column {
    Column(
        Modifier
            .fillMaxWidth()
            .weight(1f)
            .background(Color(0xfffcfcfc))
    ) {
        Row {
            Image(
                painterResource(id = R.drawable.avatar_rengwuxian),
                "头像",
            )
        }
        Column {
            Text("欢迎回来！")
            Text("小朱")
        }
        Image(
            painterResource(R.drawable.notification_new),
            "通知"
        )
    }
    NavBar()
}

东西都显示出来了，接下来给它们调调样式。

头像做成圆角的，尺寸也调一下：

Image(
    painterResource(id = R.drawable.avatar_rengwuxian),
    "头像",
    Modifier
        .size(64.dp)
        .clip(CircleShape)
)

文字的颜色和样式也打磨打磨：

Text("欢迎回来！", fontSize = 14.sp, color = Color(0xffb4b4b4))
Text("小朱", fontSize = 18.sp, fontWeight = FontWeight.Bold)

小铃铛给缩小点：

Image(
    painterResource(R.drawable.notification_new),
    "通知",
    Modifier.size(32.dp)
)

再加个圆形的底子：

Surface(
    Modifier.clip(CircleShape),
    color = Color(0xfffef7f0)
) {
    Image(
        painterResource(R.drawable.notification_new),
        "通知",
        Modifier.padding(10.dp).size(32.dp)
    )
}

样式调好之后，再统一调整一下它们的布局：

Row(
    Modifier.fillMaxWidth(),
    verticalAlignment = Alignment.CenterVertically
) {
    Image(
        painterResource(id = R.drawable.avatar_rengwuxian),
        "头像",
        Modifier.size(64.dp).clip(CircleShape)
    )
    Column(
        Modifier.padding(start = 14.dp).weight(1f)
    ) {
        Text("欢迎回来！", fontSize = 14.sp, color = Color(0xffb4b4b4))
        Spacer(modifier = Modifier.height(6.dp))
        Text("小朱", fontSize = 18.sp, fontWeight = FontWeight.Bold)
    }
    Surface(
        Modifier.clip(CircleShape),
        color = Color(0xfffef7f0)
    ) {
        Image(
            painterResource(R.drawable.notification_new),
            "通知",
            Modifier
                .padding(10.dp)
                .size(32.dp)
        )
    }
}

然后给整个 Row() 加上个 padding()：

Row(
    Modifier
        .fillMaxWidth()
        .padding(28.dp, 36.dp, 28.dp, 16.dp),
    verticalAlignment = Alignment.CenterVertically
)

好，这个顶栏就完成了。我把它的代码也抽到单独的函数里，干干净净：

Column {
    Column(
        Modifier
            .fillMaxWidth()
            .weight(1f)
            .background(Color(0xfffcfcfc))
    ) {
        TopBar()
    }
    NavBar()
}

往下是一个搜索栏：
Column(...) {
    TopBar()
    SearchBar()
}

->

@Composable
fun SearchBar() {

}

一样的写法，基本没什么好说的：

@Composable
fun SearchBar() {
  Row(
    Modifier
      .padding(24.dp, 12.dp)
      .fillMaxWidth()
      .height(56.dp)
      .clip(RoundedCornerShape(28.dp))
      .background(Color.White), verticalAlignment = Alignment.CenterVertically
  ) {
    var searchText by remember { mutableStateOf("") }
    BasicTextField(
      searchText, { searchText = it }, Modifier
        .padding(start = 24.dp)
        .weight(1f), textStyle = TextStyle(fontSize = 16.sp)
    ) {
      if (searchText.isEmpty()) {
        Text("搜搜看？", color = Color(0xffb4b4b4), fontSize = 16.sp)
      }
      it()
    }
    Box(
      Modifier
        .padding(6.dp)
        .fillMaxHeight()
        .aspectRatio(1f)
        .clip(CircleShape)
        .background(Color(0xfffa9e51))
    ) {
      Icon(
        painterResource(R.drawable.ic_search), "搜索",
        Modifier
          .size(24.dp)
          .align(Alignment.Center),
        tint = Color.White
      )
    }
  }
}

只有一点：它的提示文字的写法和传统的 EditText()不一样，是我自己手写的：

这种写法看起来比较麻烦，但是极大地增加了灵活性。比如我可以给它加个图标、加个帮助文字、报错文字，直接加就行，而且格式完全不受限制，而在传统的 EditText 里只能靠自定义 View 来实现这些功能。其实 Compose 官方也其实提供了更简单的提示文字的写法，直接填写一个字符串类型的 label 参数就行：

TextField(
    value = text,
    onValueChange = { text = it },
    label = { Text("Label") }
)

只是这种写法要用 Material Design 的样式，而我想完全自己定制样式，所以就没用它。

搜索栏再往下，就是核心区域了，也就是被围观的人的信息。——刚才我说过，这是个叫做《围观》的 App 还记得吗？虽然是虚构的。

围观区域最上面是被围观的人名列表，这个很简单，横向布局里包着一些文字就完了，其中被选中的文字底部有一个圆头的横条：

TopBar()
SearchBar()
NamesBar()

...

@Composable
fun NamesBar() {
    val names = listOf("扔物线", "朱凯", "老冯", "郝哥", "张三", "孙悟空")
    var selected by remember { mutableStateOf(0) }
    LazyRow(Modifier.padding(0.dp, 8.dp), contentPadding = PaddingValues(12.dp, 0.dp)) {
        itemsIndexed(names) { index, name ->
            Column(Modifier.padding(16.dp, 4.dp).width(IntrinsicSize.Max)) {
                Text(name, color = if (index == selected) Color(0xfffa9e51) else Color(0xffb4b4b4))
                if (index == selected) {
                    Box(
                        Modifier.fillMaxWidth().height(2.dp).clip(RoundedCornerShape(1.dp))
                            .background(Color(0xfffa9e51))
                    )
                }
            }
        }
    }
}

关于这里唯一需要说的是，由于列表的内容是可以滑动的，所以需要用 LazyRow() 而不是 Row()。这个 LazyRow() 的功能对标的是传统写法的 RecyclerView，不过写起来简单一些，不用 Adapter，也不用 ViewHolder，直接循环遍历每一项然后直接写每个项目的布局就完了：

虽然看起来是遍历的写法，但 Compose 依然会和 RecyclerView一样动态加载，用到哪一项才布局和绘制哪一项，不会像代码看起来那样老老实实地把每一项都按顺序全部计算，所以虽然是遍历的写法，但性能上不会爆炸。

名字列表再往下，是一个叫做「TA 爱的」的区域，也就是这个被围观的人他都喜欢什么。那么首先，来个标题栏：

TopBar()
SearchBar()
NamesBar()
LovesArea()

...

@Composable
fun LovesArea() {
  Row(
    Modifier
      .padding(24.dp, 12.dp, 24.dp)
      .fillMaxWidth()
  ) {
    Text("TA 爱的", fontSize = 16.sp, fontWeight = FontWeight.Bold)
    Spacer(Modifier.weight(1f))
    Text("查看全部", fontSize = 15.sp, color = Color(0xffb4b4b4))
  }
}

好，标题栏的下方是横向排布的那些「爱」的列表：

@Composable
fun LovesArea() {
  Column {
    Row(
      Modifier
        .padding(24.dp, 12.dp, 24.dp)
        .fillMaxWidth()
    ) {
      Text("TA 爱的", fontSize = 16.sp, fontWeight = FontWeight.Bold)
      Spacer(Modifier.weight(1f))
      Text("查看全部", fontSize = 15.sp, color = Color(0xffb4b4b4))
    }
    // 就这里
  }
}

由于是个列表，所以我用 LazyRow() 而不是 Row()：

LazyRow {
}

里面内容的填充还是同样的套路，做完之后就是这个样子：

然后我用 LazyRow() 的 horizontalArrangement 参数来把元素互相隔开：

LazyRow(horizontalArrangement = Arrangement.spacedBy(24.dp)) {
    ...
}

再用 contentPadding 来给两头也加上点空白：

LazyRow(horizontalArrangement = Arrangement.spacedBy(24.dp),
       contentPadding = PaddingValues(24.dp, 0.dp)) {
    ...
}

这个 contentPadding，它和 padding() 的区别是，在滑动的时候内容不会在两头被切掉，而是会触达到滑动区域的边缘：

那么这个「TA 爱的」部分就也做完了。看着还不错，是吧？

剩下的也都是这个写法，比如再往下的「TA 去过」板块：

以及这里的项目被点开后的新页面：

所以布局代码我就不反复说了。重点说一下这个打开和关闭的动画：

动画是分多种的，这种实质上属于界面跳转的过渡动画。要做这种动画，最传统的方式是用 Android 提供的 Transition API。不过 Transition API 的的效果会差一些，如果不涉及 Activity 或者 Fragment 的跳转，过渡动画也可以选择用 Jetpack 的 MotionLayout 来实现。MotionLayout 在 Compose 里也是可以用的，不过我还没试过 Compose 里的 MotionLayout 的功能全不全，我在这里是直接用 Compose 的动画 API 来实现的这个过渡效果。原理很简单：给这个详情页设置四种状态：未打开、已打开、打开中以及关闭中，通过状态来渐变式操作详情页中的各个属性的值——比如每个组件的尺寸和偏移——从而达到详情页的显示和关闭动作的动画形式的呈现。

效果还不错哈？实际上如果你不会 Compose，或者你们公司的项目里没在用 Compose，而是用的传统的 View 系统，这种效果也是可以实现的，你有两个选择：自定义 View，或者 MotionLayout。其中自定义 View 会麻烦一点，MotionLayout 就简单很多，性能上也不一定会比 Compose 更差——甚至对于现在来说可能会好一点，这个我不确定，因为虽然 Compose 的理论性能是比 View 系统更好的，包括 MotionLayout，但它不是比较新嘛，所以我不确定它每个部分的细节优化跟没跟上。

另外据我所知，Compose 在动画方面也正在做更多的工作，其中就包括让这种过渡动画的开发可以更加简便。虽然像我这样手写整个动画过程也不是很麻烦，但是如果有了官方的更省事的 API，那肯定还是更好的。谁还不是个小懒蛋呢？

这部分动画的详细代码大家可以去看我的源码，加我的助教，让她发你就行，而且我的 Compose 课程正式版中也会紧跟官方的脚步，扩充动画相关的内容。

结尾

今天就是这些了，喜欢的话请大家点个赞，你们的支持对我很重要。关于 Compose，以及刚才我提到的 MotionLayout，还有更多的各种 Android 开发的内容，我以后也会做更多分享。
关注我，不错过我的任何新内容。我是扔物线，我不和你比高低，我只助你成长。

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了，直接翻到底部评论区吧。

文字版

大家好，我是扔物线朱凯。

在我每期的视频开始以后，右下角的个人介绍里都有两个 GDE 的身份标签。一个 Android 的，一个 Kotlin 的。自从我上线这个 GDE 标签之后，就一直有人来问我要怎么才能成为 GDE。这个问题郭霖专门写过一篇文章——郭霖也是个 Android GDE——我觉得写得很好，所以大家去看他的文章就行了。（传送门：分享我成为GDE（Google开发者专家）的经历 - CSDN）

那么好，今天的视频就到这里……要做一个转折了，我们来聊另一个我更想跟大家分享的问题：为什么要成为 GDE。我认为这是每个人在提出「怎么成为 GDE」之前要更先确定的问题，而不是一看「诶，扔物线是 GDE 啊，我能不能也弄一个」——弄什么弄，先知道它是什么再说。GDE 的身份确实能给你一些好处，比如官方认可的光环，比如免费参加 I/O 大会；但我做 GDE 这三年来慢慢感受到，成为 GDE 对我们来说有更有价值的意义，这个意义就是：影响。

我作为 GDE 都干嘛了

说到影响，大家可能最直接想到的是对社区、对开发者们的影响，因为 GDE 可以去做演讲，或者像我这样做视频嘛。这个倒是有，但我要说的是另一个角度：对 Google 的影响，对世界的影响。

我是在 2018 年 10 月成为 Android GDE 的，当时申请的原因很简单，我的工作就是 Android 技术的分享，又碰上在 Google 工作的朋友程路来问我有没有兴趣申请 GDE，那当然有兴趣了！就申请了。（感谢路总！）

成为 GDE 这么久以来，我和 Google 的同事有过很多次的沟通，中国这边的、美国那边的，都有。沟通的内容除了一些演讲的邀请之外，主要是两类：技术动向的通报以及观点的交流。

• 所谓技术动向的通报主要是 Android 团队内部的一些技术动向会给到我，因为我作为 GDE 是需要提前知道这些东西才可以更方便地做事的嘛。
• 另一类就是观点的交流，这个是因为 Android 团队在一些技术决策上，会把 GDE 这个群体的意见作为他们决策的参考来源之一，所以他们会来询问 GDE 对于技术的发展有什么意见。我们有时候会见到 Android 发布新版系统的时候说，「我们参考来自开发者的意见，因此做了什么什么改动」，这个「开发者」，就包括 GDE。不过我一般提的不是 Android 系统的，我提的比较多的是 Jetpack 和 Kotlin 相关的意见和想法，比如我觉得当下应该先推广哪个库，原因是什么，或者如果 Google 当下非常想推某个库的话，我认为比较合适的推广逻辑是什么。我们 GDE 的意见 Google 还是会当回事的，起码我是一直能感受得到。

更大的意义：影响

然后做着做着，我就慢慢意识到一件事：我是在影响 Google 啊？

那我觉得这个事就有点牛逼了。

强调一下，不是我牛逼，是这个事牛逼。

为什么呢？大家都做开发，肯定知道我们在平时的开发中有很多的痛点。这些痛点靠谁解决？一部分靠自己，还有一部分靠厂商，也就是 Android。Android 是愿意帮我们解决问题的，因为服务好了开发者，软件的生态才能好，这是个简单的道理。但是要让他们帮我们解决问题，首先得让他们听到我们的问题吧？怎么让他们听？说啊！谁说？GDE 啊！GDE 可以把大家的痛点告诉 Google 或者说告诉 Android，让他们了解我们哪里不舒服，他们才会去帮我们解决。但是我一个 Android GDE 是不够的——哦早就不是一个了，现在是四个了——四个也是不够的，我们还需要更多，中国那么大呢对不对？GDE 越多，我们可以和 Google 讲的就越多，Google 能帮我们解决的问题就越多。

开发的痛点有些是全世界通用的，比如 UI、比如性能优化；还有一部分是不通用的，是中国独有的，比如热更新、比如保活，这些是由于中国的特殊国情而导致只有中国市场存在的痛点。全世界的 Android 工程师都做开发，也都在做创新。中国人不管是开发能力还是创新能力，是不弱的，这个不是吹，咱去看看世界知名 App 的排行榜、去翻翻 GitHub 都能看出来。但是如果全世界的工程师都在舒适地做着开发和创新的时候，我们却需要分出很大一部分精力去研究热更新和保活，这个事情就……很不对劲。热更新技术和保活技术，中国是全世界做得最好的，为什么？因为是硬需求啊！我们没有统一的应用商店，所以应用的自动更新成了问题；我们没有统一稳定的消息推送机制，所以消息推送只能靠保活来自己推。（保活这件事的初衷是好的，但在走向上逐渐被加入了一些的恶，不过这个就是另一个话题了，今天暂且不谈。）我们有人、有技术，但却被迫花很多的人和精力去解决一些本来不应该存在的问题，那我们的生产能力其实就被限制了。所以这些问题，我们也应该去推动 Google 来帮我们解决。

要知道，全世界有很多的 GDE，每个国家也多少有一些自己独有的问题。Android 是要帮助全世界的开发者解决问题，但解决谁的问题？当然是解决提出问题的人的问题。所以首先要有人来提出问题。我们作为 GDE，把我们的痛点、我们的需求，有条理、有依据地向 Google 反馈，去影响、去推动 Google 帮助我们打造一个更好的开发环境，这，是我认为除了个人的光环和免费的 I/O 大会门票之外，GDE 这个身份更重要的意义。我相信，这也是 Google 对 GDE 项目的真正期望。他们希望被我们影响，只要我们的影响是好的、是有意义的。

更多的影响：世界

其实除了影响 Google，我们还可以影响更多。当我们对 Google 的影响越来越多、越来越大，我们的这些影响也一定会进一步渗透到其他地区的开发者社区中，让我们的技术、我们的解决方案被世界上更多的地方看到，让他们看看「中国的 App 是怎么优化性能的」「中国的音视频 App 是怎么高效加载的」「中国的互联网公司是怎么协同工作的」「中国人是怎么在家办公的」。现在中国的互联网公司和开发者社区已经不是当年只能学别人的水平了，很多时候我们甚至是世界领先的水平，这个我就不打广告了，建议大家可以把你认为世界顶尖的中国公司和中国 App 的名字打在弹幕里。随着我们的技术和解决方案被世界上更多的地方看到，中国开发者在世界上的话语权也一定会更大，我们就可以用自己努力做出的技术去一点点地影响世界、领导世界。

不过这个可能就不是 Google 在意的事了，因为它超出 Google 的生态了——但我们是可以做的。

来和我们一起

所以，如果你认同我的想法，并且也希望可以帮助大家打造一个更好的开发生态，非常欢迎你也来申请 GDE！让我们一起来，影响！

其实也不限于 GDE，主要我是做 Android 开发的，最重要的就是影响 Google，所以 GDE 就成了最好的选择。如果你是做其他方向开发的，你可以去做你那个方向的「DE」。总之，让我们一起来，影响！

如果你想和我们一起影响，想加入 GDE，可以联系你认识的任何一个 Google 员工或者 GDE。我是扔物线，我不和你比高低，我只助你成长，我们下期见！

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了，直接翻到底部评论区吧。

文字版

在今年（2021 年）的 Google I/O 大会中的 Jetpack Q&A 环节，Android 团队被问了一个很有意思的问题：LiveData 是要被废弃了吗？

问题不是瞎问的

大家好，我是扔物线朱凯。今天来聊个轻松的，不那么硬核的——LiveData。

LiveData 是 Android 官方在 2017 年推出的一系列架构组件中的一个，跟它一起的还有 ViewModel 和 Lifecycle 等等，以及这几年陆续出现的一个个新成员。这些组件后来有了统一的名字：Jetpack；而 Jetpack 的各个组件也越来越被 Android 开发者接受。LiveData 作为 Jetpack 的架构组件的元老级成员，发展势头也一直不错，可是——它从今往后要开始往下走了。就像你在视频开头看到的，有人问 Android 团队「你们是要废弃 LiveData 了吗？」这个问题可不是瞎问的。

那是咋问的呢？这还得从当年的 RxJava 说起。

从 RxJava 说起

LiveData 在 2017 年刚一面世，就受到了很大的关注，其中一个原因是它让很多人想到了 RxJava。LiveData 是一个以观察者模式为核心，通过让界面对变量进行订阅来实现自动通知刷新的组件，而 RxJava 最核心的关键词就是观察者模式和事件流，所以当时很多人拿它去和 RxJava 做比较：有人说它比 RxJava 好用，有人说它没有 RxJava 强大，还有人说它俩根本就不是一个东西，放在一起比较是没有意义的。

至于我的观点嘛……这就说。

RxJava 是在 2014、2015 年这个时间火起来的，国内晚一些，大概在 2016 年开始爆火。当时全世界的劳动人民用 RxJava 一般是做两件事：网络请求，以及 event bus。网络请求这个就不用说了，RxJava 配合 Retrofit 来做网络请求，各种复杂操作和线程切换，谁用谁知道——现在用协程就可以了，比 RxJava 方便；而 event bus，当时比较火的是两个开源库：GreenRobot 的 EventBus——同名库——，和 Square 的 Otto，在 RxJava 流行起来之后，大家发现，哎，这 RxJava 稍微定制一下也能实现 event bus 的功能啊？那既然我都用 RxJava 了，我为啥不把 event bus 也交给它做？就这样，一种叫做 RxBus 的模式就流行了起来，后来也有人开源了这样的库。

就在这样的时代背景下，LiveData 在 2017 年发布了。它的功能是让变量可以被订阅。跟一般的订阅比起来，LiveData 有两个特点：一是它的目标非常直接，直指界面刷新，所以它的数据更新只发生在主线程；二是它借助了另一个架构组件——Lifecycle——的功能，让它可以只在界面到了前台的时候才通知更新，在后台的时候就闷不吭声，避免浪费性能，也避免了 bug。

为什么不用 RxJava？

很方便，很好用。但是这里就会有一个问题：变量的订阅，用 RxJava 不能做吗？为什么要搞一个新库出来呢？RxJava 就是专门做事件订阅的呀？

• 是因为…… LiveData 的数据更新发生在主线程？RxJava 也可以啊，一个操作符的事（ observeOn(AndroidSchedulers.MainThread)) ），安排。
• 那……是因为它结合了 Lifecycle，对生命周期的支持比较到位？RxJava 也可以啊，改吧改吧就能支持了，总比写一个新库容易吧？

所以 LiveData 的功能，用 RxJava 可以实现吗？是完全可以的，没有任何问题。那 Android 官方为什么要做一个 LiveData 出来，而不是直接推荐大家去用 RxJava 来实现这样的功能？或者退一步，用 RxJava 来做 LiveData 的底层实现也行啊？为什么都没有？——因为 RxJava 太大了，而且它还不是 Android 自己官方的东西，而是别人的。

这个倒不是说 Google 小心眼子，只许宣传我自己的东西，不许壮大别人，而是 Android 作为一个平台方，它肯定要考虑开发者们的普遍水平的。RxJava 说实话虽然好用，但是太复杂了，上手成本忒高，所以如果 Android 要用 RxJava 来实现 LiveData，或者推荐开发者们用 RxJava 来自己实现 LiveData 的功能，那么它就需要考虑怎么让我们开发者学会 RxJava。怎么让我们学会？就只能自己教呗！写文档、出视频，教大家用 RxJava。那这个动作就有点大了，就把事情变复杂了。再加上 RxJava 还既不是 Android 体系里的东西，也不是 Google 体系里的东西，那么如果 Android 团队就为了一个 LiveData 的功能要去全网推广和教学 RxJava，这个逻辑就有点不对了，事情不是这么玩的。所以 RxJava 太大了，并且是第三方的，这两个原因结合起来，就让 Android 的 LiveData 没有使用 RxJava。这并不是一个竞争或胸怀的问题，而是一个「不要把事情变复杂」的问题。——当然这是我自己的观点啊。

2017 - 2021 的变化

但！这只是当时的情况。当时是什么时候？2017 年。2017 是 Android 的大年，这一年发生了好几件大事：

• 官方发布了几个架构组件；
• 官方宣布对 Kotlin 的支持；
• HenCoder 发布（假）。

HenCoder 是我乱讲的啊。我要说的是 Kotlin，Kotlin 在 2017 得到了 Android 官方的公开支持，在接下来这几年里，Kotlin 自身越来越完善，它的协程也越来越完善。2017 年之前，事件订阅大部分人是用 EventBus 或者 Otto，并且在 RxJava 流行起来之后，EventBus 和 Otto 的使用开始持续下降；2017 之后，对于简单场景大家慢慢过渡到了 LiveData，复杂场景还在用 RxJava，因为 LiveData 不适合复杂场景；而现在，我们有了 Flow。协程的 Flow 和 RxJava 的功能范围非常相似——其实我觉得就是一样的——但是 Flow 是协程里必不可少的一部分，而协程是 Kotlin 里必不可少的一部分，而 Kotlin 是 Android 开发里必不可少的一部分——哦这个说的不对，重新说——而 Kotlin 又是 Android 现在主推的开发语言以及未来的趋势，这样的话，Flow 一出来，那就没 LiveData 什么事了。别说 LiveData 了，以后 RxJava 也没什么事了。不过这个肯定需要一个过程的，LiveData 和 RxJava——尤其是 RxJava——肯定会继续坚挺一段时间的，只是趋势会是这么一个趋势。

「不会废弃 LiveData」……吗？

视频（文章）开头那个问题，Yigit 的回答是：LiveData 不会被废弃，因为两个原因：

1. 用 Java 写 Android 的人还需要它——Flow 是协程的东西，所以如果你是用 Java 的，那其实没办法用 Flow；
2. LiveData 的使用比较简单，而且功能上对于简单场景也是足够的，而 RxJava 和 Flow 这种东西学起来就没 LiveData 那么直观。

简单说就是，为了 Java 语言的使用者和不想学 RxJava 或者 Flow 的人，LiveData 会被保留。不过你如果用发展的眼光去看他这番话……你懂我意思吧？

那我走？

那……对于不会 LiveData 的人，还有必要学 LiveData 吗？以及已经在用 LiveData 的项目，需要快点移除 LiveData 吗？

如果你不会 LiveData，对于当下（2021 年）来说，还是很有必要学一下的，因为 LiveData 现在的应用率还是很高的，所以你就算你现在不用，你未来工作的团队也可能会用，反正这东西很简单，学一下不费事。另一方面，在用 LiveData 的人，确实可以考虑摘除它了；但也不是着急忙慌地把它拿走，它不是毒药不是地雷，只是协程的 Flow 现在可以做这件事了，而未来 Flow 一定是会成为主流的，就像现在的 Kotlin 一样；在项目里用两样东西来做同一件事（事件订阅）不如只用一样，因此你可以考虑摘除 LiveData，是这么个逻辑。所以你就算是着急，也应该去着急学 Flow，而不是着急地把 LiveData 拆掉，它没有毒，等以后你觉得它给你带来不方便了，你自然会把它拆掉。

好，今天就是这样，如果你喜欢我的内容，别忘了点赞订阅关注。我是扔物线，我不和你比高低，我只助你成长，我们下期见。

涨价预警

对了，插播一句，Jetpack Compose 的正式版已经发布了，我的 Compose 课程的基于正式版的重制版本也在制作中了，已经报了名的人不用担心，我们会像当初承诺的那样，把重制版课程直接更新给你们，但是我也要跟大家说一下，这次更新之后，课程会涨回我们预期的价格，不会是现在这个价。所以，有兴趣在观望的可以来扫货了（关注公众号后可以在对话界面底部看到课程试听按钮）。

视频先行

下面是视频内容的脚本整理稿。如果你看了视频，那下面的文稿就不用看了，直接翻到底部就行。

开场

做 Android 开发的都知道一个规矩：布局文件的界面层级要尽量地少，越少越好，因为层级的增加会大幅拖慢界面的加载。这种拖慢的主要原因就在于各种 Layout 的重复测量。虽然重复测量对于布局过程是必不可少的，但这也确实让界面层级的数量对加载时间的影响变成了指数级。而 Jetpack Compose 是不怕层级嵌套的，因为它从根源上解决了这种问题。它解决的方式也非常巧妙而简单——它不许重复测量。

……嗯？

View 层数和界面加载性能的关系

大家好，我是扔物线朱凯。

在定制 ViewGroup 的布局过程的时候，我们需要重写两个方法： onMeasure() 用来测量子 View，onLayout() 用来摆放测量好的子 View。测量和摆放明明是连续的过程，为什么要拆成两步呢？因为我们在 ViewGroup 里可能会对子 View 进行多次测量。

比如一个纵向的 LinearLayout，当它的宽度被设置成了 wrap_content 的时候：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:orientation="vertical">
  ...
</LinearLayout>

它会依次测量自己所有的子 View，然后把它们最宽的那个的宽度作为自己最终的宽度。

但……如果它内部有一个子 View 的宽度是 match_parent：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:orientation="vertical">

    <View
        android:layout_width="match_parent"
        android:layout_height="48dp" />

    <View
        android:layout_width="120dp"
        android:layout_height="48dp" />

    <View
        android:layout_width="160dp"
        android:layout_height="48dp" />
</LinearLayout>

这时候， LinearLayout 就会先以 0 为强制宽度测量一下这个子 View，并正常地测量剩下的其他子 View，然后再用其他子 View 里最宽的那个的宽度，二次测量这个 match_parent 的子 View，最终得出它的尺寸，并把这个宽度作为自己最终的宽度。

这是对单个子 View 的二次测量，如果有多个子 View 写了 match_parent ，那就需要对它们每一个都进行二次测量。

而如果所有的子 View 全都是 match_parent——哎呀跑题了。总之，在 Android 里，一个 ViewGroup 是可能对子 View 进行二次测量的。不只是二次，有时候还会出现三次甚至更多次的测量。而且这不是特殊场景，重复测量在 Android 里是很常见的。

重复测量是 ViewGroup 实现正确测量所必需的手段，但同时也让我们需要非常注意尽量减少布局的层级。

为什么呢？来看一个最简单的例子，如果我们的布局有两层，其中父 View 会对每个子 View 做二次测量，那它的每个子 View 一共需要被测量 2 次：

如果增加到三层，并且每个父 View 依然都做二次测量，这时候最下面的子 View 被测量的次数就直接翻倍了，变成 4 次：

同理，增加到 4 层的话会再次翻倍，子 View 需要被测量 8 次：

也就是说，对于会做二次测量的系统，每个 View 的测量算法的时间复杂度是 O(2ⁿ) ，其中这个 n 是 View 的层级深度。

当然了，现实中并不是每个父 View 都会进行二次测量，以及有些父 View 会对子 View 做三次或者更多次的测量，所以这只是一个粗略估计，不过——大致就是这个数量级了。

而 O(2ⁿ) 这种指数型的时间复杂度，说白了就是，View 的层级每增加 1，加载时间就会翻一倍。

所以为什么 Android 官方文档会建议我们的布局文件少一些层级？因为它对性能的影响太大了！

Compose 的 Intrinsic Measurement

而 Compose 是禁止二次测量的。

如果每个父组件对每个子组件只测量一次，那就直接意味着界面中的每个组件只会被测量一次：

这样的话，就把组件加载的时间复杂度从 O(2ⁿ) 降到了 O(n)。

不过……如果禁用二次测量这么好用的话，Android 干嘛不在传统的 View 系统直接禁掉？——因为它有用啊！

那 Compose 禁用了二次测量，它就不用了吗？

这就是 Compose 巧妙的地方了：Compose 禁用了二次测量，但加入了一个新东西：Intrinsic Measurement，官方把它翻译做「固有特性测量」。

这个「固有特性测量」，你要说翻译得不对吧，其实字面上已经非常精确了，但这么翻却又完全没抓住这个功能的灵魂。

所谓的 Intrinsic Measurement，指的是 Compose 允许父组件在对子组件进行测量之前，先测量一下子组件的「固有尺寸」，直白地说就是「你内部内容的最大或者最小尺寸是多少」。这是一种粗略的测量，虽说没有真正的「二次测量」模式那么自由，但功能并不弱，因为各种 Layout 里的重复测量，其实本来就是先进行这种「粗略测量」再进行最终的「正式测量」的——比如刚才说的那种「外面 wrap_content 里面 match_parent」的，对吧？想想是不是？这种「粗略」的测量是很轻的，并不是因为它量得快，而是因为它在机制上不会像传统的二次测量那样，让组件的测量时间随着层级的加深而不断加倍。

当界面需要这种 Intrinsic Measurement——也就是说那个所谓的「固有特性测量」——的时候，Compose 会先对整个组件树进行一次 Intrinsic 测量，然后再对整体进行正式的测量。这样开辟两个平行的测量过程，就可以避免因为层级增加而对同一个子组件反复测量所导致的测量时间的不断加倍了。

总结成一句话就是，在 Compose 里疯狂嵌套地写界面，和把所有组件全都写进同一层里面，性能是一样的！

这……还怕嵌套？

刚才那个「固有特性测量」的翻译，我为什么觉得没有灵魂呢，主要是那个「固有特性」指的其实就是「固有尺寸」，也就是这个组件它自身的宽度和高度。而翻译成「固有特性测量」就有点太直了，直到反而让含义有点扭曲了。不过无伤大雅啊，不管是「固有尺寸测量」还是「固有特性测量」，这个设计真的很好，它让 Compose 逃过了 Android 原生 View 系统里的一个性能陷阱。

事实上，你用一用 Compose 也会发现，它的性能已经在一些方面超越原生了——尤其是对于复杂场景，比如多组件共同参与的动画。不过目前为止，还只是一些方面而已，并没有全方位超越。比如滑动列表的性能，Compose 目前是不如原生的 RecyclerView 的。现在 Compose 的正式版发布已经越来越近了，而且从发布日志来看，目前 Compose 的开发重心还在 API 完整性的填补和 Bug 修复上，所以到了正式发布那天能不能看到 Compose 全方位超越原生的性能，我是有点怀疑的。不过从原理上看，就算发布的时候不行，未来应该是有可能的。

总结

如果你做 Android 开发，Compose 真的是时候了解一下了。我以后还会发布更多关于 Compose 以及 Android 开发相关的内容，所以关注我吧，没错的！如果你想快速成为 Compose 高手，也可以了解一下我的 Compose 课程，我的同名公众号「扔物线」里面有免费试听课。

好了今天的内容就到这里，我是扔物线，我不和你比高低，我只助你成长，我们下期见。