谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose

大家好,我是扔物线朱凯。前两天,我在 GDG DevFest 2020 的 Android Day 做了一次面向全国 Android 工程师的技术分享直播,主题是 Android 最新的 UI 框架 Jetpack Compose。今天我把演讲的内容整理成文字 + 图片的形式在这里发出来,各位自取吧。

另外现场视频我也已经剪辑了出来(大概 35 分钟),要看视频的扫码加我的小助理,让她把视频发给你。

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第1张图片

话不多说,以下是整理稿原文。大家如果觉得有用,请帮忙点赞和转发呀。

啥?Compose 是啥?这是 Android 会场吗?

我们今天的主题大家都看到了:Jetpack Compose。看到这个主题,大家的反应我猜是不一样的:有人会说哎呀太好了,早就想学 Compose 了;

相反呢也有一些人会一头雾水:这是啥?我走错片场了?有的人知道很久了,有的人还没听过。这是为什么呢,因为 Compose 虽然早就公布了,但到现在还没有发布。

Compose 是 Jetpack 中的一个新成员,是 Android 团队在 2019 年 I/O 大会上公布的新的 UI 库。不过虽然 2019 年 I/O 大会就公布了,可是到现在一年半了才到 alpha 阶段,而直到明年也就是 2021 年中或者下半年才会上正式版,也就是正式的发布。所以如果你没听过 Compose,或者只是听过这个名字但不知道它是什么,很正常。

那么问题就来了:

这才 Alpha 阶段怎么就开始推广了?大家要知道,我们在这里分享的主题,都是经过慎重挑选的,给大家讲的都是我们认为该讲的东西。那为什么我要来讲一个还在 alpha 的东西呢?

  • 因为这是一个特别大的东西。从项目规模上来讲,Compose 差不多是 Android 团队这几年在开发者这边除了宣布对 Kotlin 的官方支持之外,动作最大的一件事了。

  • Compose 这个库——或者说这个框架——它是重新定义了 Android 上 UI 的写法。如果我们用它来写界面,我们的开发效率和我们能够达到的能力都会提升很多。用官方的说法就是,它「让困难的事情变简单,让不可能的事情变得有可能」。

  • 但是,就像我说的,它换了一套全新的 UI 写法,是真的 UI 的写法一整套完全替换了。那这就意味着什么呢?学习成本。所以虽然明年才会正式发布,但我们需要提早做准备,才能在它发布之后可以第一时间用上。

  • 那么说到学习,大家就会有疑问了:

    • 首先是:怎么学啊?

      怎么学?我这不是来给大家讲了嘛。

      另外我接下来的一段时间也会视频形式发布更多的 Jetpack Compose 的分享,所以你们记得关注我,搜索扔物线就是我。

    • 另外,大家还会有一个更加尖锐的问题:我凭什么学啊?是吧?好气啊,怎么又来个新东西,不学!凭什么学?其实就一个原因:它太好了。或者我这么说:等我今天讲完这几十分钟,等你明白 Compose 有什么不同,你很可能就想学了。当然气可能还是会气啊,因为毕竟学不动了吗,烦是吧,但是你会想要学它的。

不过我也刚说了,这是一套非常大的框架,所以今天这几十分钟把它讲透了也是不可能的,今天我讲的核心内容是相对于具体的写法来说更重要的——Compose 整体是什么,或者熟悉我的人知道我喜欢用的一个词:扒皮。

今天主要是把 Compose 的皮扒了,给它做一个清晰的画像。是会讲到代码的,但是对于入门来说,Compose 需要一个专门的认识过程。大家都知道协程,如果你听过我讲协程,应该记得我是有一个对于协程是什么的专门讲解的,对吧?这个过程对于后面学会协程是必不可少的。而 Compose 同理,它很大,大到了你需要先对它的概念有一个了解才能更好地学会它。

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第2张图片

Compose 怎么写?

那么我们就从 Compose 长什么样说起,也就是它的代码是怎么写的。

Compose 的代码是只能用 Kotlin 写的,它的每个控件都是一个函数调用。比如你要显示一块文字,就这么写:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第3张图片

这看起来还挺简单吧?好像是就调用构造函数创建了个对象而已,但其实这么写就可以显示一块文字出来了。

不过——这其实并没有创建对象,这个 Text() 是一个普通的函数。如果你跳到它的定义就会发现,这个 Text 并不是一个构造函数,而是一个普通函数。谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第4张图片

哎?普通函数用大写开头干嘛?这不符合规矩啊!其实原因很简单,Compose 规定用大写字母开头的命名方式,这样可以有更好的辨识度:一看就知道,哦,这是个 Compose 的函数。所以说它的这种「不合规矩」,恰恰是 Compose 自己的特殊规矩。

Text 不是 TextView

那么这个 Text() 到底是个什么东西呢?是个 TextView 吗?是 TextView 到了 Compose 里就改名用 Text 来表示了?或者说,这个 Text 的底层实现是用的 TextView ?

都不是的,它俩完全不是一个东西。而且并不是因为它俩的名字不一样,在 Compose 里有一个叫 Button  的函数,我们平时写 UI 也有个控件叫 Button  对吧?但这两个 Button  也不是一个东西。而且不仅不是一个东西,它们连概念都不一样了:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第5张图片在 Compose 里的 Button ,里面可以包东西——包文字也就是 Text 、包图片,什么都能包。这个所谓的「包」,就是里面加上子元素,相当于我们传统 UI 系统的子 View:

所以不仅 Compose 的 Text() 不是 TextView,Compose 的 Button 更不是我们平时用的 Button。

那么说到这儿大家发现没有:Compose 和我们平时用的那个 View 和 ViewGroup 的系统,不仅是写法不一样,它并不是仅仅创造了一套全新的写法。

Compose 并不是对 View 和 ViewGroup 这套系统做了个上层包装来让写法更简单,而是完全抛弃了这套系统,自己把整个的渲染机制从里到外做了个全新的。

大家知道 Flutter 吗?Flutter 是个跨平台的 UI 框架对吧?它为什么火?因为它不仅跨平台,而且流畅。它流畅就是因为它没有用原生控件,而是从底层利用更下层的渲染 API——比如对 Android 来说就是 Canvas 的 API——独立做了一套渲染逻辑。这套渲染逻辑直接和上层的 Flutter API 对接,而不是使用原生控件来间接渲染,这是没有性能损耗的,所以流畅。传统的跨平台框架都是用原生控件来做拼装,这样他的渲染要经过一层逻辑的转换,性能就会比原生差一些。

而 Compose,也是像 Flutter 这样,在创造了新的 UI 写法的同时,也创造了与这套写法对应的整个渲染核心——当然了不只是渲染,还有布局和触摸,全是重新写的。

所以对于 Jetpack Compose 的学习,你就算 View 那套系统不熟悉,学习起来也几乎没影响。

但……这也同时意味着,就算是熟悉了 View 那套系统,你依然需要把整个 Compose 的框架全学一遍,因为它从头到尾都是个新东西。

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第6张图片

@Composable

好我们继续说。刚才说 Text() 是个普通函数对吧?其实说它是个普通函数,它其实也有不普通的地方,比如上面的 @Composable 注解。谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第7张图片

那么我们现在就来说一下这个 @Composable 。实际上,这个 @Composable 是 Compose 里你会遇到和用到最多的一行代码,因为 Compose 提供的这些界面函数全都是带有这个注解的,而且所有的这些带有 @Composable 的函数,也全都需要在另一个这种 Composable 函数的里面被调用。

实质上,这个 @Composable 就是 Compose 这个框架最关键的魔法入口:在编译过程中,Compose 会对于加了这个注解的函数做出不一样的编译逻辑,让这些函数可以在 App 运行时变成我们的界面,正确地显示。

  • 说到干预编译过程,我们很容易想到 Annotation Processor,也就是注解处理器。不过它利用的不是 Annotation Processor,而是编译器插件,直接干预的编译过程。

  • 要说干预编译过程和 Annotation Processor 有什么区别,那主要就是 AP 是修改 Kotlin 代码,而编译器插件是直接修改的字节码的输出逻辑。

  • 跟它更像的其实是另一个东西:协程的 suspend 关键字。只不过Compose 选择的不是关键字方案,而是注解。

    • 为什么不用关键字?

    因为它不配!

    关键字是谁用的?是语言用的,是整个语言层面通用的东西。Compose 是语言层面的东西吗?当然不是了,它是一个 Android 的 UI 库而已。如果用关键字方案来做 Compose,那就相当于污染了 Kotlin 了。

所以,这就是 Compose:调用一个带有 @Composable 注解的函数,来显示出一个元素;而拼凑一下,调用一大堆嵌套的这样的函数,就是一个复杂的、精细的界面。那么这么看来,这个 Compose 还是可以用的嘛!

但是……它好在哪呢?

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第8张图片

Compose 好在哪

也就是说,明明已经有一套用了很久的 UI 框架了,Android 为什么要推出一个新的呢?这个应该是相对于「怎么用」,大家更关心的问题对吧?就是我刚才说的:我凭啥要学它啊?给我个理由!它好在哪?

好在哪其实很简单:好在好用。

具体来说主要是两点:

  • 它的声明式 UI

  • 去掉了 xml,只使用 Kotlin 一种语言

  • 另外它还有别的好处,比如 Compose 是独立于操作系统的,所以方便调试。

但它最核心的优势就是上面这两个:声明式 UI 和去掉了 xml。我现在就对这两点展开解释一下。

声明式 UI

首先来说「声明式 UI」。从 Compose 诞生以来,声明式 UI 就一直是它最被大家称赞的点,说相比起传统写法的「命令式 UI」,「声明式 UI」怎么怎么好。但是关于什么是声明式 UI 以及传统的 UI 写法为什么叫命令式 UI,很多人却表示看不懂。看文章、看视频,都看不懂。所以今天我的重点之一就是给大家讲一下,到底什么是声明式 UI。

首先我们再来近距离对比一下传统的 xml 代码和 Compose 的代码分别是怎么写的。先来看一个 xml 代码:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第9张图片

这是一个 LinearLayout,里面有一个 TextView 和一个 Button 是吧?那么这个界面如果用 Compose 写,应该是怎么写呢?是这样的:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第10张图片

哎,还挺像的!不错,Compose 看起来没那么难学啊。等会儿!什么难学不难学,我们在讲什么?在讲什么是声明式 UI 对吧?这两段代码看起来完全没区别啊,怎么就一个是命令式一个是声明式了?谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第11张图片

其实,所谓命令式 UI 和声明式 UI,和语言是无关的,也和写法是无关的。换句话说,一段 UI 代码摆在你面前的时候,你是不一定有办法判断出这是声明式还是命令式的。就比如这段 Compose 的代码——Compose 是声明式的对吧?但这段代码不能就直接被认定为是「声明式」的。

那到底什么是「声明式」呢?所谓声明式 UI,指的就是你只需要把界面给「声明」出来,而不需要手动更新

关键就在于这个「不需要手动更新」。

你看 xml 和 Compose 这两块代码,是不是都是把界面给声明出来的?是吧?是的啊,不要怀疑。但是当数据发生改变,需要跟着更新界面的时候,就不一样了。比如我现在要更新这个传统写法里 TextView 里面的值,我怎么写?谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第12张图片findViewById(),然后 setText() 是吧?而 Compose 呢?我们用 Compose 怎么处理界面的更新?

我们——不处理。我们什么都不做,界面会自动更新。听我这么说你可能会有点懵:什么?这不可能啊,界面都不知道它需要跟什么数据做联动,它怎么可能知道自己应该怎么更新?界面不知道,但我们可以告诉它啊!比如你这么写代码,你把文字的内容存到一个变量里:然后把这个变量作为参数放进 Text() 函数:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第13张图片

那么当 text 的值改变的时候,Text() 里的显示会自动跟着改变。Compose 里的界面元素会对依赖的数据自动进行订阅,这样数据改变了,界面马上就跟着变。这样的话,你只需要声明界面的规则,而并不需要具体去操作界面。当数据改变的时候,界面会自动改变,你不需要手动更新。这,就是声明式 UI。

而和它相对的,传统写法叫做「命令式 UI」,其实并不是指的 xml 这种写法,而是指的使用 Java 或者 Kotlin 代码来手动地更新界面,这种「手动更新」,或者说你具体指派、具体命令界面的每一步应该怎么更新,这就叫「命令式 UI」。

所以你看,声明式 UI 和语言相关吗?和写法相关吗?都是不相关的,对吧?所谓的声明式 UI,其实是从框架角度,描述的一个框架特性:全自动的对数据的变化进行联动的界面更新。

同样的,「声明式 UI」和「命令式」UI 比起来为什么好?因为你省事了,因为界面更新这个工作,本来是要我们自己做的,现在全由框架来帮我们做了。这个对于开发是非常有帮助的。多有帮助?大家都听说过数据绑定这种编程模式吧?

Android 官方也推出了这么一个 Data Binding 库,就专门是帮我们做这件事的:你把某个数据和某个界面控件用 Data Binding 关联起来,这样当这个数据改变的时候,界面控件的显示就也跟着改变。Android 官方专门出了这么个库,你说声明式 UI 有用不?非常有用对吧?

哎?不对啊?又不对了。我用 Data Binding 就能实现声明式 UI 了,还要 Compose 干嘛?是吧?

不是的。为什么不是?因为 Data Binding (不管是这个库还是这种编程模式)并不能做到「声明式 UI」,或者说,声明式 UI 是一种比数据绑定更强的数据绑定。比如在 Compose 里,你除了简单地绑定字符串的值,还可以用布尔类型的数据来控制界面元素是否存在。例如你再创建另外一个布尔类型的变量,用它来控制你的某个文字的显示:谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第14张图片谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第15张图片

注意,当 show 先是 true 然后又变成 false 的时候,不是设置了一个 setVisibility(GONE) 这样的做法,而是直接上面的 Text() 在界面中消失了。每次数据改变所导致的界面更新,看起来就跟界面关闭又重启、并用新的数据重新初始化了一遍一样。这,才叫声明式 UI,这是数据绑定做不到的。而且 Compose 并不是真的把界面重启了,它只会刷新那些需要刷新的部分,这样的话就能保证,它自动的更新界面跟我们手动更新一样高效。比如上面这里 show 的值从 true 变成 false 了,if 里面的 Text() 会被重新调用一次,但是外面的 Column() 和里面的 Text() 却不会被重新调用。很神奇吧?怎么做到的?靠的 @Composable 关键字,或者说靠的 Compose 的编译器插件,这个插件通过对编译过程的干预,把代码的逻辑拆到了我们看不到的细粒度,让这种看起来是连续的代码可以做到互相独立地执行。

这就是所谓的「声明式 UI」:

  • 传统的 UI 编写方式是,我们不可避免地要对界面进行直接修改,例如用 xml 来对界面进行「声明式」的设置,但在之后需要在 Java 或者 Kotlin 代码里对界面进行「命令式」的更新,例如控件的显示和隐藏、背景色的改变等等。这种「声明」加「命令」的写法,就叫「命令式 UI」。好吧我们可以称它为「混合式 UI」,但这没有实际的指导性意义,因为就像前面说的,「命令式」的叫法是为了针对像 Compose 这种「声明式」,作为区分而存在的。不管它是「纯命令式」还是「声明式初始化 + 命令式更新」,它的核心在于程序员需要指定更新的具体逻辑,这就是开发成本。

  • 而 Compose 是声明式的,我们只需要说明界面的规则,然后在依赖的数据改变的时候,Compose 会自动帮我们更新。

  • 那你说,Compose 的这种声明式 UI 爽不爽?很爽吧?

  • 另外我专门讲一下:

    传统 UI 能做到的事,Compose 都是可以做到的:比如自定义绘制、自定义布局、自定义触摸,还有动画,Compose 都是可以做到的。动画也是声明式的:你让界面依赖某个数据,然后对这个数据做渐变,界面就发生动画了。有的人可能会担心 Compose 会不会因为这种「声明式 UI」设计太过于放飞自我而导致功能受到限制,某些边界情况还得依赖传统的 View。这种担心是多余的,不存在这种情况。Compose 的功能是不受限的,什么都能做。

第二点好处:去掉了 xml

这是 Compose 的第一个好处:声明式 UI。然后说一下它的第二个好处:去掉了 xml。这算什么好处啊是吧?现在就说一下。传统的 UI 写法是 xml + Java(Kotlin):

xml 负责界面框架的设置,Java(Kotlin)负责细节的调整;另外如果考虑到自定义 View,Java(Kotlin)也负责一部分的界面框架设置。但无论如何,App 要想快速开发,界面是需要 xml 和 Java(Kotlin)都用的。而都用就不可避免地涉及到两种语言的交互。

这种交互一般来说对于每个界面只有一次,就是把布局从 xml 文件读到 Java 里,然后就可以去布局和绘制了。但是这种交互虽然只有一次,但交互往往并不是 Java 和 xml 唯一的牵扯,因为 Java 还需要对布局里的控件进行操作,比如要用 findViewById() 来拿到 xml 里定义的控件。两种语言互相牵扯,就会带来很多局限性。

比如 ViewBinding 库为什么被推出?因为它解决了 findViewById() 的问题,比如空安全问题,对吧?如果没有问题,会需要解决吗?对吧?而 findViewById() 的问题就是因为界面需要 xml 和 Java(Kotiln) 一起写所导致的。

  • 而如果你试过用纯代码(Java 或者 Kotlin)来代替 xml 文件写布局,你就会体会到,在不需要双语言交互的情况下,代码会自由和方便得多。

  • 而 Jetpack Compose 就是纯 Kotlin 的,不用 xml。

  • 不过……我为啥不直接用上面说的「纯代码写布局」,而要去学Compose?

    我不用 Compose 也可以抛弃 xml 啊。

  • 你如果真的试过,应该就不会这么说了。

  • 首先,我们想想为什么当初 Android 官方会推出 xml + Java 的写法?

  • 因为这种写法简单啊!xml + Java 这种双语言的写法只是有局限性,但在简单直观这个角度,它是完胜纯 Java 的写法的。

  • 而 Compose 不仅是只用了 Kotlin 这一种代码,还跟 xml 布局文件一样有写法简单的优点。——另外说实话,Compose 作为一个 2019 年诞生、2021 年正式版的全新 UI 框架,它的写法从目前看来是比 xml 还要方便得多的。

所以这就是 Compose 的另一个好处:它在抛弃了 xml 的同时还保持了写法的简单,完全解除了混合写法所带来的局限性,这也是它的一大优点。去掉一种语言而已,算是好处吗?太算了,这是一件非常棒的事。。

那么基于这两点好处:声明式 UI、抛弃 xml 变成单一语言的写法,Compose 很明显是要比传统的 UI 写法要更好的。这个所谓的「好」,解释开的话就是:写界面更简单更快速,并且我们能写出更复杂的界面。

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第16张图片

Compose 的未来?

再说一个小话题:Compose 的未来如何?或者说,谷歌会弃坑吗?(让人害怕)

Android 团队和 JetBrains 团队现在在 Compose 上面花的精力非常大,而且就目前的情形来看,Compose 已经基本成型了。所以不可能被弃坑的。

另外一个关于未来的问题是:大厂会用它吗?我认为会,但我十分怀疑大厂的边缘团队可能不会太早用它。具体的我也说不准,我们拭目以待吧。

快教我!

那么我讲到这里,大家应该明白 Compose 是什么了。也到了我要真正讲 Compose 的硬核代码的时候了。

不过……演讲的时间比较有限,我只能把最重要的事情讲了,也就是刚才我说的:Compose 的本质、Compose 的扒皮,给大家讲讲 Compose 是什么、大概怎么用、好在哪、为什么好。至于更多的内容,大家如果想了解,可以在等我一下。我最近也正在准备更多的 Compose 的技术分享,等我准备好了,会以视频或者视频加文章的形式发布出来。

所以如果你有兴趣,欢迎在微信、 B 站、掘金、知乎搜索「扔物线」关注我,我很快就会更新的。

那欧了,以上就是我这次技术分享的文字形式的整理。如果你需要视频回放,可以去扫上面出现过的二维码找我的小助理要回放。另外如果你对 Jetpack Compose 或者其他 Android 开发的内容感兴趣,一定记得关注「扔物线」,更多的高质量视频分享很快就到,再等我准备一下下。

谷歌开发者大会扔物线演讲原稿整理:Jetpack Compose_第17张图片

你可能感兴趣的:(编程语言,java,移动开发,android,python)