jetpack compose what and why, 6个问题

1.这个技术出现的背景, 初衷, 要达到什么样的目标或是要解决什么样的问题.

jetpack compose是什么?
它是一个声明式的ui工具包(declarative ui toolkit for android).

它的主要目的就是改变之前命令式地(imperatively)写ui的方法, 改成声明式(declarative)的.

命令式

android之前的写法就叫命令式: view hierarchy是一个ui widgets构成的tree, 当app的状态改变时, ui需要更新. 通常的做法是通过findviewbyid()等手段找到要更新的节点, 通过settext(), addchild(), setimagebitmap()等方法更新控件的内部状态. 每个控件都有自己的内部状态, 并且暴露getter/setter, 允许程序逻辑和控件交互.

命令式为什么不好呢:

• 这样手动地更新view会增加犯错的可能性. 如果某一数据在多个地方被渲染, 那么很可能就忘了更新其中的某个view.
• 很容易创建非法状态, 比如两个更新以不期望的方式冲突了. (比如: 一个要更新值, 另一个要移除节点.)
• 维护的复杂度随着需要更新的view个数而增加.

声明式

所以, 在过去的几年里, 业界一直在探索并且开始转向一种声明式的ui模型. 目的就是简化构建和更新ui.

jetpack compose是一个声明式的ui framework. 该技术的原理是从头开始重新生成整个屏幕, 然后仅应用必要的更改. 这种方法避免了手动更新stateful view的复杂度.

在compose的声明式解决方案里, widgets相对来说是stateless的, 不暴露getter/setter.
实际上, widgets根本不是以对象的形式来暴露的.
当更新ui的时候, 实际上是传不同的参数调用了composable方法. 当数据改变时, composable负责把当前的应用状态转化为ui.

2.这个技术的优势和劣势分别是什么, 或者说, 这个技术的trade-off是什么.

compose的优势:

• 目前google投入了大量的资源(学习资源, 社区挑战赛, ide和编译器支持, 推出desktop版本等)来推广compose, 我们有理由相信google官方会继续发力, compose会成为android未来的ui标准开发形式.
• compose的声明式写法和flutter, swiftui, react契合, 在支持多个平台的团队里, 有利于架构思想的统一.
• 声明式ui, 写起来更快, 不容易出错.
• 因为所有的代码都是kotlin写的(真100%kotlin), 利用了kotlin的强类型安全, 编译器会提示很多错误.
• 修复和更新了一些旧的api: (buggy android views: picker, spinner, edittext, 有一些edge cases. 因为要更改旧的总是很难, 不如创建一个新的. )
• 基于组合的composable, 比基于继承的view体系, 更加灵活, 易于复用. 比如可以通过组合来达到复用多个源, 不再受单继承限制.
  以button为例, 在传统的ui里, 它是单继承体系下的一个类: button -> textview -> view.
  而在compose的世界里, 它只是一个@composable的方法, 里面包含了其他composable, surface, row等.
  举例: list->detail两个界面, 可以通过提取方法参数来达到两个界面的composable复用.
• 支持和view-based ui系统的互相调用. 这样有两个优点: 有利于已有项目app的混用和逐步迁移; 当compose满足不了需求的时候可以用传统view作为第二选择.
• 和jetpack系列的其他库都能完美结合. (viewmodel, kotlin flow, coroutines, paging, hilt, navigation...)

劣势:

• 需要用canary版本的android studio, 目前(2021.5)ide还是存在一些问题的.
• gradle也要升级到最新版(7.0.0-alpha15), 不是很稳定, 还有一些问题.
• 版本更新频繁. compose alpha版本的一些api已经变了. -> 但是目前已经beta, 最新的google i/0说7月就会有稳定版发布.
• 相比android view, 社区支持不够多. -> 但是google已经投入了大量的资源来推广, 社区支持正在飞速增长.
• 虽然google封装了material的compose库, 但还是有一部分view控件没有办法提供, 比如webview, mapview等.

3.这个技术使用的场景.

jetpack compose的使用场景是取代原来的android view写法(xml, 在代码里实例化view对象再添加到view hierarchy里等),
jetpack compose用全新的方式来写ui, 即将成为google android标准写法.

注意这里的改变除了ui写法的改变, 还是一种状态管理思想的转变.
声明式, 单向数据流, 单个数据源.
android内部的模式近年来一直追求的无外乎就是数据和view的分离, view的无知与自动更新, 清晰的逻辑管理和分离, 可测试性等等.

除了与view强相关的这一层(viewmodel)外, 其他的业务逻辑, 数据交互等被影响不大, 所以即便app决定逐渐迁移到compose, 也只用管view绘制以及和view相邻的这一层.

4.技术的组成部分和关键点.

jetpack compose的总体特点:

• 声明式ui. f(state)=ui.
• built on kotlin.
• unbundled: 不是和系统绑定的, 而是和jetpack中的库一样, 版本独立, 可以自己更新维护版本, 也保证了多个系统上的行为一致.
• built for interop. 可以和已有view互相调用, 适用于现有项目的逐渐迁移.
• 内置控件和theming, 支持material design.

composable functions

compose的使用方法:
定义一系列的composable functions: 接收数据, 发射ui元素.

@composable
fun greeting(names: string) {
    text("hello $name")
}

composable方法的特点:

• 所有的方法都必须有@composable注解.
• 方法参数是数据.
• 通过调用其他composable方法来发射ui元素.
• 方法不返回值, 因为它们在描述屏幕状态, 而不是构建ui widgets.
• 方法要快, 具有幂等性(调用多少次结果都一样), 没有副作用. (fast, idempotent, and side-effect free.) 这就要求方法不会修改外部属性或者全局变量, 也没有random的调用等.

还有一个小区别就是不同于普通的kotlin方法命名规范, composable方法名的首字母要大写, 因为它此时代表的是一种widget.

recomposition

compose framework会很机智地选出有变化, 需要重新绘制的部分.

在compose中, 如果调用composable function, 传入了新数据, 会使得方法被recomposed: 这个方法发射的widgets会根据需要进行重新绘制.

因为重新绘制整个ui tree会花销比较大, 所以实际上composable function只有input改变的才会被重新绘制, 对于那些参数没有变化的方法和lambda, 其实是skip掉的, 这样才能提高recompose的效率.

所以, 永远不要依赖于执行composable function的side-effects, 因为recomposition有可能会被skip掉.

side-effects包括:

• 更新共享对象.
• 更新viewmodel中的observable.
• 更新shared preferences.

由于composable functions有可能会被逐帧执行(比如动画期间), 所以它应该足够的快, 如果需要耗时的操作, 可以考虑后台的coroutine.

5.技术的底层原理和关键实现.

compose的几个特点:

• composable functions可以以任何顺序执行.
• composable functions可以并行执行.
• recomposition会尽可能地skip多的composable functions. 如果真的需要side-effects, 考虑用callback.
• recomposition是乐观的, 它认为在本次重绘期间不会有新的状态改变, 如果有新的状态改变, 它可能会取消当前绘制, 以新的参数重新开始绘制.
• composable function有可能会被执行得很频繁(比如动画), 所以避免耗时操作.

关于compose的底层原理, 目前还没找到一个官方的文档或者架构图.
因为可能大家都还在学习怎么使用, 这项技术的底层实现细节还没有被热烈讨论起来.
这里有个问题:

从使用者的角度揣测一下compose的原理:
虽然composable使用了注解@composable, 但是却没有添加注解处理器(kapt), 所以并不是依靠注解在编译期生成代码.

在添加依赖的时候需要在build.gradle里添加:

    composeoptions {
        kotlincompilerextensionversion compose_version
    }

所以它和kotlin的编译器有关系.

这个视频: understanding compose (android dev summit '19)在17:18开始讲实现原理.

@composable更像是一个语言的关键字. 可以类比suspend, 有以下几个共同点:

• 改变了方法的类型.
• 强制了方法的调用上下文.

部分更新

用了定制化的kotlin编译器插件, 数据改变时, 受数据影响的composable的方法会被重新调用.

6.已有的实现和它之间的对比.

android view和jetpack compose的对比.

android view和jetpack compose的相似点:

• 都是android ui的写法.

jetpack compose改进了view系统的哪些地方:

• 不再需要担心深层嵌套. compose ui不允许多遍的测量(multi-pass measurement), 改善了效率.

flutter和jetpack compose的对比.

jetpack compose和flutter的相似点:

• 声明式ui, ui = f(state).
• 都有web和desktop版本.
• 官方都提供了一些material的控件和资源, 比如都有个scaffold, 提供脚手架.
• 都可以和原生混用, 虽然程度不一样, compose的混用粒度更细一点.
• 都可以一边改ui一边预览.

jetpack compose比flutter好的地方:

• 基于kotlin, 相比于flutter的dart来说, 对android开发者更友好一些.
• 接着上一点, 因为compose只改了ui, 所以其他部分的代码库仍然是android原生代码的逻辑, 趁手的第三方库比较多. 而flutter, 就得利用其它package来做json解析, 数据库等等.
• flutter的stateful widget改状态必须要在setstate里, 使用上不是很方便, 容易出错.
• jetpack compose的recomposition看上去更智能一些, 完全自动, 不像flutter一样需要开发者自己设置一些flag来表明哪个部分不需要重绘.
• 安装包体积应该有优势? 因为flutter sdk包含了自己的图像引擎, 而compose是没有native层面的东西的.

flutter比jetpack compose好的地方:

• flutter还支持ios.
• flutter相比jetpack compose稍微成熟一些(flutter出来的早一些), 是经过一些app的实际上线验证的.
• flutter是有自己的图形引擎skia的, 绘制会更有效率? (没有验证, 纯猜测)

reference

• thinking in compose
• using jetpack libraries in compose | session -> 这个讲状态管理和其他jetpack库结合的视频很棒.