compose使用及优缺点思考

相信大部分安卓开发都经常听到compose，真正项目中使用的还是比较少。最近刚好看了下2年前的compose学习时demo，也简单的介绍下我理解的compose

简单使用

compose是组合式的UI框架，在fragment中使用如下：

override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {
        load()
        return ComposeView(requireContext()).apply {
            setContent {
                val listState = rememberLazyListState()
                LazyColumn(
                    contentPadding = PaddingValues(
                        start = 16.dp,
                        end = 16.dp,
                        bottom = 10.dp,
                        top = 10.dp
                    ),
                    state = listState
                ) {
                    items(contentlist) {
                        setSection(it)
                    }
                }

                LoadMoreListHandler(listState = listState) {
                    load()
                }
            }
        }
    }

其中填充item的代码

@Composable
fun setSection(item: TitleComposableModel) {
    Box(modifier = Modifier) {
        Text(
            text = item.title,
            color = Color.Black,
            fontSize = 25.sp,
            modifier = Modifier.align(Alignment.BottomStart).padding(15.dp)
        )
    }
    val pxValue = with(LocalDensity.current) { 1.dp.toPx() }

    Spacer(
        Modifier
            .background(Color.Gray)
            .fillMaxWidth()
            .height((1/pxValue).dp)
    )
}

简单解释下，compose直接返回的是ComposeView, 调用setContent传入一个@composeble的对象，替代原来的 setContentView(layout), LazyColumn就是替换recycleView的，回想之前使用recycleView时，借用kotlin的语法也要写一堆代码，不同type时候还要写多个if else 在compose 组件里面就这样就实现了(if else也能通过SPI：service provider interface 技术优化掉, 保证开闭原则)，每个item的填充直接把属性写到compose控件上

这跟flutter使用dart的写法差不多啊，也和前端的开发差不多！

甚至连脚手架Scaffold都直接搬过来了！😂

@ExperimentalMaterialApi
@ExperimentalPagerApi
@Composable
fun MainScreen() {
    val navController = rememberNavController()
    Scaffold(
        topBar = { TopBar() },
        bottomBar = { BottomNavigationBar(navController) }
    ) {
        Navigation(navController = navController)
    }
}

compose原理

数据驱动根据接口数据转换为对应model刷新UI

`compose为啥可以随便嵌套不卡`

传统的布局
布局文件的界面层级要尽量地少,因为层级的增加各种 Layout 的重复测量,会大幅拖慢界面的加载.
比如下面布局

<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="320dp"
        android:layout_height="48dp" />

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

LinearLayout 就会先以 0 为强制宽度测量matchparent的子 View，并正常地测量剩下的其他子 View，然后再用其他子 View 里最宽的那个的宽度，二次测量这些 match_parent 的子 View，最终得出它的尺寸，并把这个宽度作为自己最终的宽度，这也是我们自定义布局时候发现onMeasure为啥会执行多次的原因

随着层级的递增，测量的次数会不断快速增加，

`Compose 是禁止二次测量`

Compose 禁用了二次测量，但加入了一个新东西：Intrinsic Measurement 固有测量

`Compose 允许父组件在对子组件进行测量之前，先测量一下子组件的「固有尺寸」，简单地说就是「你内部内容的最大或者最小尺寸是多少」。这是一种粗略的测量，虽说没有真正的「二次测量」模式那么自由，但功能并不弱，因为各种 Layout 里的重复测量，其实本来就是先进行这种「粗略测量」再进行最终的「正式测量」的`

测量是很轻的，并不是因为它量得快，而是因为它在机制上不会像传统的二次测量那样，让组件的测量时间随着层级的加深而不断加倍

比如我们在compose里面嵌套5层box

按照传统View的思维，当前content(R.id.content(FrameLayout)->)布局中存在5层嵌套,这是极不可取的一种做法。但是现在是Compose，最终的绘制R.id.content 上挂载composeView,可以理解为支持compose的一个自定义view，上面再放了AndroidComposeView,再把compose的组件都渲染到这个view上。总共两层！

LayoutNodeWrapper链构建

不同的text button都会转换为LayoutNode，给Layout的设置的modifier会以LayoutNodeWrapper链的形式存储在LayoutNode中，然后后续做相应变换

compose @composeable (组合视图注解 compose平台语言来处理更新) 反编译修饰的方法还有个co mposer 参数到每个被注解修饰的方法上 composer composition 首次加载的view对象

compose总结

优点
1.更简洁的代码就能实现UI功能，不用再写XML布局文件，不再采用传统的继承View/Viewgroup,毕竟View的代码都3W多行框架非常重，也体现了"组合优于继承"。
2.对比传统的布局文件，嵌套层级对性能影响大大减少。对于使用databingding项目代码也不用布局里面去处理，开发更高效
3.compose支持现有项目中混合使用，还能嵌套使用甚至页面一块区域使用。

缺点
1.API 熟悉还是有一定成本，尤其是没做过flutter、前端开发的同学
2.只能用在安卓端，目前整体市面上商用的公司还不算多
3.图片的支持不支持webp图片
4.2024年使用AS的预览功能感觉比较卡对比前端的Vue flutter热更新还是差点
5.在传统的 Android 开发中，开发者可以通过重写生命周期方法来管理界面的状态要使用 Compose 提供的状态管理机制来管理界面的状态

是否要深入研究compose以及商用？

未来的趋势大前端，所有端最好用一套代码，现在市面已经有很多了，uniapp,kuickly等等。
要看公司实际需求和规划，如果公司历史负债多，强行迁移成本会比较大，如果是一些新的项目组内开发也都愿意，就可以使用。
商用与否，也得看实际情况，虽然compose确实在布局性能上有很大优势，但是在一些求稳的业务上，可以选一些边缘的页面混合使用。比如我们在区块链的项目关于部分和一些个人信息的场景有使用了。