前言

Android Compose作为去年出来的新技术,本来我也没有想着再写一篇关于这方面的文章,但是有不少人问了这个问题。就把这个问题再提出来聊一次。

android componet框架 android compose_UI

Jetpack Compose 简述

android componet框架 android compose_android studio_02

Jetpack Compose是用于构建原生Android UI的现代工具包。 Jetpack Compose使用更少的代码,强大的工具和直观的Kotlin API,简化并加速了Android上的UI开发。这是Android Developers 官网对它的描述。

由于Compose基于Kotlin构建,因此可以与Java编程语言完全互操作,并且可以直接访问所有Android和Jetpack API。因此你可以简单地描述UI的外观,而Compose则负责其余的工作-当状态发生改变时,你的UI将自动更新。

它与现有的UI工具包也是完全兼容的,因此你可以混合原来的View和现在新的View,并且从一开始就使用Material和动画进行设计。

据谷歌官方介绍Jetpack Compose 有以下特点

更少的代码:使用更少的代码实现更多的功能,并且可以避免各种错误,从而使代码简洁且易于维护。

直观的 Kotlin API:只需描述界面,Compose 会负责处理剩余的工作。应用状态变化时,界面会自动更新。

加快应用开发:兼容现有的所有代码,方便随时随地采用。借助实时预览和全面的 Android Studio 支持,实现快速迭代

功能强大:凭借对 Android 平台 API 的直接访问和对于 Material Design、深色主题、动画等的内置支持,创建精美的应用。

Compose的渲染性能到底怎么样?

Compose列表渲染性能分析

关于Compose的列表的性能问题也是老生常谈了,很多人都说Compose的LazyColumn在低端手机上会卡顿,那么我们就来分析比较一下同一个页面用LazyColumn与RecyclerView分别实现,在性能上有什么差距?

首先来看下页面的样式。

android componet框架 android compose_kotlin_03

如上,这个页面整体是一个列表,共有4种类型。

可左右滑动的Banner

包含文字与一张图片的item

包含3张图片的复杂item

作为视频封面的大图item

然后我们用LazyColumn与RecyclerView分别实现以上页面,然后在不同手机上分别测量其快速滑动时的FPS,结果如下:

同时在debug包与release包都进行了以上测试,结果基本一致。可以看出,LazyColumn与RecyclerView在性能上的确有一定差距,尤其在低端手机上,LazyColumn快速滑动时掉帧明显,而RecyclerView则都很流畅。

只能说RecyclerView太强了~

/ Compose粒子动画渲染性能分析 /

除了列表,我们也可以通过粒子动画的方式来测量Compose的性能,通过粒子动画我们可以评估在极端情况下Compose与View的渲染性能。首先来看下粒子动画效果:

android componet框架 android compose_kotlin_04

如上,我们可以在画布上生成随机粒子并且做动画,随着粒子数量的增长,观察应用的FPS,以此评估Compose的渲染性能,我们同时也实现了一个View版本以进行对比,结果如下:

可以看出,随着粒子数从100增长到10000,应用的FPS逐渐降低,在低端手机上尤其明显。而与列表不同的是,Compose与View在粒子动画中的渲染性能几乎一致,可以说是几乎没有区别。

总结

本文主要从FPS的角度分析介绍了Compose的渲染性能,可以看出在画布中随机生成粒子动画时,Compose与View的渲染性能几乎一致。而对于复杂列表,LazyColumn与RecyclerView在性能上有一定差距,在低端手机上尤其明显,在快速滑动时会有明显卡顿。

结合两个实验,看起来应该是LazyColumn组件存在一定性能问题,而Compose本身的渲染性能已经基本与View一致了~

Jetpack Compose VS 传统UI

Jetpack compose 提供了现代化的声明式 Kotlin API,取代 Android 传统的命令式开发 xml 布局,可帮助开发者用更少的代码构建美观、响应迅速的应用程序。

命令式UI特征:

UI是可变的:控件接受命令后通过变化自身刷新UI
UI持有State:控件的变化正是通过改变自身状态实现的

声明式UI特征:

UI不可变 : @Composable函数不返回任何可引用句柄,无法被外界改变。
UI不持有State: @Composable函数无法持有状态的,显示的数据都需要通过参数传入。

随着界面越来越复杂,控件越来越多,各控件 State 难以保持同步,UI显示不一致的Bug频发。而声明式UI与命令式UI的特点截然相反,正好可以弥补命令式的缺陷。

总结

其实一项新的技术点提出来肯定是有这道理的,不然总不能做无用功吧。

你想在Android的路上走的更远,Compose值得学。