大众汽车网站建设,常州市建设银行网站,徐州市专业做网站的公司,建设科技期刊官网作者#xff1a;古哥E下 如果一直关注 Compose 的发展的话#xff0c;可以明显感受到 2022 年和 2023 年的 Compose 使用讨论的声音已经完全不一样了, 2022 年还多是观望#xff0c;2023 年就有很多团队开始采纳 Compose 来进行开发了。不过也有很多同学接触了下 Compose古哥E下 如果一直关注 Compose 的发展的话可以明显感受到 2022 年和 2023 年的 Compose 使用讨论的声音已经完全不一样了, 2022 年还多是观望2023 年就有很多团队开始采纳 Compose 来进行开发了。不过也有很多同学接触了下 Compose然后就放弃了。要么使用起来贼特么不顺手要么就是感觉性能不行卡。其实问题只是大家的思维没有转换过来还不会写 Compose。
为何要选择 Compose
很多 Android 开发都会问View 已经这么成熟了为何我要引入 Compose
历史也总是惊人的相似React 横空出世时很多前端同学也会问jQuery 已经如此强大了为何要引入 JSX、Virtual DOM
争论总是无效的时间会慢慢证明谁才会成为真正的主宰。
现在的前端同学可能连 jQuery 是什么都不知道了。其作为曾经前端的主宰何其强大却也经受不住来自 React 的降维打击。回看这端历史那我们选择 Compose 就显得很自然了。
另一个大趋势是 Kotlin 跨平台的逐渐兴起与成熟也会推动 Compose 成为 Fultter 之外的选择而且可以不用学习那除了写 Flutter 就完全没用的 Dart 语言。
但是我也不推荐大家随随便便就把 Compose 接入的项目中。因为国内的开发现状就是那样迭代速度要求快但是也要追求稳定。而接入 Compose 到使用 Compose 快速迭代也是有一个痛苦的过程的搞不好就要背锅现在这环境背锅可能就代表被裁了。
所以目前 Compose 依旧只能作为简历亮点而非必备点。可是如果你不学万一被要求是必备点那该怎么办
所以即使你不喜欢 Compose 这一套那为了饭碗该掌握的还是得掌握毕竟市场饱和我们是被挑选的哪一方。
Compose 的思想
声明式 UI
Compose 的思想与 React、View、Fultter、SwiftUI 都是一脉相传那就是数据驱动 UI 与 声明式 UI。以前的 View 体系我们称它为命令 UI。
命令式 UI 是我们拿到 View 的句柄然后通过执行命令主动更新它的的颜色、文字等等 声明式 UI 则是我们构建一个状态机描述各个状态下 UI 是个什么样子的。
那些写 Compose 怎么都不顺手的童鞋就是总想拿 View 的句柄但又拿不到所以就很痛苦但如果转换到状态机的思维上去定义各种情景的状态那写起来就非常舒服了。
Compose 从 View 体系进化的点就是它贴近于真实的 UI 世界。因为每个界面就是一个复杂的状态机以往我们命令式的操作我们依旧要定义一套状态系统某种状态更新为某种 UI有时候处理得不好还会出现状态错乱的问题。 Compose 则强制我们要思考 UI 的状态机该是怎样子的。
Virtual DOM
在 Compose 的世界中是没有介绍 Virtual DOM 这一概念的但我觉得理解 Virtual DOM 能够帮助我们更好的理解 Compose。 Virtual DOM 的诞生一个原因是因为 DOM/View 节点实在是太重了所以我们不能在数据变更时删除这个节点再重新创建我们也不没有办法通过 diff 的方式去追踪到底发生了哪些变更。但大佬们的思维就比较活跃因为开发过程中关注的一个 DOM/ View 的属性是很少的所以就创造了一个轻量级的数据结构来表示一个 DOM/View 节点由于数据结构比较轻量那么销毁创建就可以随意点。每次更新状态我可以用新状态去创造一个新的 Virtual DOM Tree 然后与旧的 Virtual DOM Tree 进行 diff然后将 diff 的结果更新到 DOM / View 上去 React Native 就是把前端的 DOM 变成移动端的 View因而开启了 UI 跨平台动态化的大门。
那这和 Compose 有什么关系呢我们可以认为Compose 的函数让我们来生成 Virtual DOM 树Compose 内部叫 SlotTable框架用了全新的内部结构来代表 DOM 节点。每次我们状态的变更就会触发 Composable 函数重新执行以生成新的 Virtual DOM这个过程叫做 Recomposition。
所以重点来了发生状态更新后框架会首先去重新生成 Virtual DOM 树交给底层去比对变更最终渲染输出。如果我们频繁的变更状态那就会频繁的触发 Recomposition如果每次还是重新生成一个巨大的 Virtual DOM 树那框架内部的 diff 就会非常耗时那么性能问题随之就来了这是很多同学用 Compose 写出的代码卡顿的原因。
Compose 性能最佳实践
如果我们有了 Virtual DOM 这一层认识那么就能够想到该怎样去保持 Compose 的高性能了那就是
1.减少 Composable 函数自身的计算 2.减小状态变更的频次 3.减小状态变更的造成 Recomposition 的范围以减小 diff 更新量 4.减小 Recomposition 时的变更量以减小 diff 更新量
减少 Composable 函数自身的计算
这个很好理解如果 Recomposition 发生了那么整个函数就会重新执行如果有复杂的计算逻辑那就会造成函数本身的消耗很大而解决措施也简单就是通过 remember 缓存计算结果
Composable
func Test(){val ret remember(arg1, arg2) { // 通过参数判断是否要重新计算// 复杂的计算逻辑}
}减少状态变更的频次
这个主要是减少无效的状态变更如果有多个状态其每个状态下的执行结果是一样的那这些状态间的变更就没有意义了应该统一成唯一的状态。
其实官方在 mutableStateOf 的入参 policy 上已经定制了几种判断状态值是否变更的策略
StructuralEqualityPolicy: 通过值判等的来看其是否发生变更ReferentialEqualityPolicy: 必须是同一个对象才算未发生变更NeverEqualPolicy : 总是触发状态变更
默认为 StructuralEqualityPolicy也符合一般情况的要求。
除此之外我们减小状态变更频率的手段就是 derivedStateOf。 它的用途主要是我们就是将多个状态值收归为统一的状态值 例如
1.列表是否滚动到了顶部我们拿到的 scorllY 是很频繁变更的值但我们关注的只是 scorllY 0 2.根据内容为空判定发送按钮是否可点击我们关注的是 input.isNotBlank() 3.多个输入的联合校验 4…
我们以发送按钮为例
Composable
func Test(){val input remember {mutabtleStateOf()}val canSend remember {derivedStateOf { input.value.isNotBlank() }}// 使用 canSendSendButton(canSend)// 其它很多代码
}这样子我们可以多次更新 input 的值但是只有当 canSend 发生变更时才会触发 Test 的 Recomposition。
减小状态变更的造成 Recomposition 的范围
Recomposition 是以函数为作用范围的所以某个状态触发了 Recomposition那么这个函数就会重新执行一次。但需要注意的是不是状态定义的函数执行Recomposition而是状态读取的函数会触发 Recomposition。
还是以上面的输入的例子为例。 如果我在 Test 函数执行期内读取了 input.value 那么 input 变更时就会触发 Test 函数的重组。注意的是函数执行期内读取而不是函数代码里写了 input.value。上面 canSend 的 derivedStateOf 虽然也有调用 input.value但因为它是以 lambda 的形式存在不是会在执行 Test 函数时就执行所以不会因为 input.value 变更就造成 Test 的 Recomposition。
但如果我在函数体内使用 input.value例如
Composable
func Test(){val input remember {mutabtleStateOf()}val canSend remember {derivedStateOf { input.value.isNotBlank() }}Text(input.value)SendButton(canSend)OtherCode(arg1, arg2)OtherCode1(arg1, arg2)
}那就会因为 input 的变更而造成 Test 的重组 canSend 使用 derivedStateOf 也就是做无用功了。更严重的是可能有很多其它与 input 无关的代码也会再次执行。
所以我们需要把状态变更触发 Recomposition 的代码用一个子组件来承载
Composable
func InputText(input: () - String){Text(input())
}Composable
func Test(){val input remember {mutabtleStateOf()}val canSend remember {derivedStateOf { input.value.isNotBlank() }}InputText {input.value}SendButton(canSend)OtherCode(arg1, arg2)OtherCode1(arg1, arg2)
}我们重新创建了一个 InputText 函数然后通过 lambda 的形式传递 input因而现在 input 变更造成的 Recomposition 就局限于 InputText 了而其它的无关代码就不会被执行这样范围就大大缩减了。
减小 Recomposition 时的变更量
加入我们的函数 Recomposition 的范围已经没办法缩减了例如上面 canSend 变更触发 Test 的 Recomposition这造成 OtherCode 组件的重新执行好像无法避免了。其实官方也想到了这种情况所以它框架还会判断 OtherCode 的参数是否发生了变更依此来判断 OtherCode 函数是否需要重新执行。如果参数没有变更那么就可以开心的跳过它那么 Recomposition 的变更量就大幅减小了。
那么怎么判断参数没有发生变更呢如果是基础类型和data class 等的数据结果还好可以通过值判等的形式看其是否变更。但如果是列表或者自定义的数据结构就麻烦了。 因为框架无法知道其内部是否发生了变更。
以 a: List 为例虽然重组时我拿到的是同一个对象 a, 但其实现类可能是 ArraryList, 并且可能调用 add/remove 等方法变更了数据结构。所以在保证正确性优先的情况下框架只得重新调用整个函数。
Composable
fun SubTest(a: ListString){//...
}Composable
fun Test(){val input remember {mutabtleStateOf()}val a remember {mutableStateOf(ArrayListString())}// 因为读取了 input.value 所以每次 input 变更都会早成 Test 的 RecompositionTest(input.value)// 而因为 a 是个 List所以每次 SubTest 也会执行 RecompositionSubTest(a)
}那要怎么规避这个问题呢 那就是使用 kotlinx-collections-immutable 提供的 ImmutableList 等数据结构如此就可以帮助框架正确的判断数据是否发生了变更。
Composable
fun SubTest(a: PersistentListString){//...
}Composable
fun Test(){val input remember {mutabtleStateOf()}val a remember {mutableStateOf(persistentListOfString())}// 因为读取了 input.value 所以每次 input 变更都会早成 Test 的 RecompositionTest(input.value)// 而因为 a 是个 List所以每次 SubTest 也会执行 RecompositionSubTest(a)
}而如果是我们自己定义的数据结构如果是非 data class那就要我们主动加上 Stable 注解告诉框架这个数据结构是不会发生变更或者其变更我们都会用状态机去处理的。特别需要注意的是使用 java 作为实体类而给 compose 使用的情况那就是非常不友好了。
对于列表而言我们往往需要用 for 循环或者 LazyColumn 之类的方式使用:
Composable
fun SubTest(list: PersistentListItemData){for(item in list){Item(item)}
}这个写法如果 list 不会变更那也没什么问题可是如果列表发生了变更例如原本是 12345, 我删了一项变成 1345。
那么在 Recomposition 的时候框架在比对变更时发现从第二项开始就全不同了那么剩下的 Item 就得全部重新重组一次了这也是非常耗费性能的所以框架提供了 key 的功能通过它框架可以检测列表的 Item 移动的情况。
Composable
fun SubTest(list: PersistentListItemData){for(item in list){key(item.id){Item(item)} }
}不过需要注意的是 key 需要具有唯一性。 LazyColumn 的 item 也有 key 的功能其作用类似其还有 contentType 的传参其作用和 RecyclerView 的多 itemType 类似也是一个可以使用的优化措施。
最后
Compose 业务上能做的优化大体上就是这些了。总之我们就是我们要保持组件的颗粒度尽可能的小容易变动的要独立出来非常稳定的也要独立出来尽量使用 Immutable 的数据结构。 如此之后 Compose 的流畅度还是非常不错的。
如果还觉得卡那多半是因为你使用的是 Debug 包Compose 会在 Debug 包加很多调试信息会很影响其流畅度的。切换到 Release 包可能丝滑感就出来了。 为了帮助大家更好的熟知Jetpack Compose 这一套体系的知识点这里记录比较全比较细致的《Jetpack 入门到精通》(内含Compose) 学习笔记 对Jetpose Compose这块感兴趣的小伙伴可以参考学习下……
Jetpack 全家桶Compose
Jetpack 部分
Jetpack之LifecycleJetpack之ViewModelJetpack之DataBindingJetpack之NavigationJetpack之LiveData Compose 部分 1.Jetpack Compose入门详解 2.Compose学习笔记 3.Compose 动画使用详解
