Android开发Compose框架使用开篇

手机APP/开发
381
0
0
2023-02-05
android实现轮播图引导页
上一篇
Android autojs随时翻译剪贴板单词实现示例
下一篇
标签   Android
目录
  • Compose的诞生
  • Compose好处
  • Compose 架构
  • @Composable的背后
  • 智能重组真的那么智能吗
  • 最后

Compose的诞生

在2019年的谷歌IO大会上，Compose作为Android新一代UI开发亮相，因为声明式开发越来越流行了，对标IOS开发SwiftUi，Compose的立项也为Android开发新加了声明式ui的开发选项，在2021年7月1.0正式版本的诞生，也意味着Compose即将进入生产环节，国际app巨头Twitter就首当其冲，在新页面上用上了Compose

Compose好处

与传统的xml相比，Compose不仅吸收了其优点，摒弃了糟粕，还具有以下几个优点

声明式

兼容性

跨平台

布局效率

不同于传统的命令式，ui的刷新需要调用者主动调用刷新方法，比如TextView需要特定的setText进行文本变化，而compose在定义好声明状态后，由框架自主调用刷新，减少状态不一致

compose最低兼容到android api 21，不但可以在原来View体系中嫁接使用，也可以在compose中使用原来View体系的xml

跨平台，目前支持macos等多个平台，跨平台由Jetbrain团队在做，compose未来会实现ui多跨平台，同时也搭配逻辑跨平台KMM项目（有关kmm的以后有机会可以再说说，比起说跨平台，更不如说是多平台，因为编译出来的代码是直接符合原平台开发规范的，比如ios编译出来的就是framework），未来实现ui跟逻辑都跨平台也不在遥远

compose 是严格遵循LayoutNode的单次测量，不会出现View的多次测量导致的问题，在ui卡顿或者ui规范上，是非常重要的改进

因为Compose是Android团队与JetBrain在推，国内外的学习热情都挺好，目前国内也有不少大厂进行了尝试阶段，比如字节。

Compose 架构

说了这么多，那么Compose是怎么做到在原有View体系做到兼容并改善的呢？

我们从一个例子出发：

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
             xxx组件
        }
    }
}

我们可以看到，Compose在Activity中，用了setContent方法代替了原有的setContentView方法，那么setContent做了什么呢？

public fun ComponentActivity.setContent(
    parent: CompositionContext? = null,
    content: @Composable () -> Unit
) {
    val existingComposeView = window.decorView
        .findViewById<ViewGroup>(android.R.id.content)
        .getChildAt(0) as? ComposeView
    if (existingComposeView != null) with(existingComposeView) {
        setParentCompositionContext(parent)
        setContent(content)
    } else ComposeView(this).apply {
        // Set content and parent **before** setContentView
        // to have ComposeView create the composition on attach
        setParentCompositionContext(parent)
        setContent(content)
        // Set the view tree owners before setting the content view so that the inflation process
        // and attach listeners will see them already present
        setOwners()
        setContentView(this, DefaultActivityContentLayoutParams)
    }
}

可以看到，android.R.id.content的第一个孩子被替换成了ComposeView，而这个ComposeView，就是Compose环境的提供者，在这里面，Compose将剔除原本View体系的测量逻辑，从而采用自己的测量架构。如下图包饺子架构所示：

值得注意的是ComposeView是继承于AbstractComposeView（他定义了compose环境的规范），还有就是android中是多window架构的，所以针对Dialog这种，也有特别的环境实现类。针对PopupWindow这种共用window的组件，也同样提供了compose环境实现类

可以看到架构图中，AbstractComposeView其实也是继承于ViewGroup的。所以准确来说，Compose并没有完全脱离AndroidView体系，而是在这之上建立起了中间层，这就印证了一句老话，没有什么架构是不能解决的，如果有，那就加个中间层！而这个中间层，提供了全新的设计，从而让android得以脱胎换骨到一个新架构！

@Composable的背后

说到Compose，那么肯定离不开Compsoable的介绍，我们肯定会有一个疑问，为什么一个函数加上了Composable注解，就变成了一个可见的视图了呢？比如

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

我们进行反编译后

public static final void Greeting(String name, Composer $composer, int $changed) {
    Intrinsics.checkNotNullParameter(name, "name");
    Composer $composer2 = $composer.startRestartGroup(-154424256);
    ComposerKt.sourceInformation($composer2, "C(Greeting)46@1589L27:MainActivity.kt#8m9ksz");
    int $dirty = $changed;
    if (($changed & 14) == 0) {
        $dirty |= $composer2.changed(name) ? 4 : 2;
    }
    if ((($dirty & 11) ^ 2) != 0 || !$composer2.getSkipping()) {
        TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4567String$0$str$arg0$callText$funGreeting() + name + LiveLiterals$MainActivityKt.INSTANCE.m4584String$2$str$arg0$callText$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
    } else {
        $composer2.skipToGroupEnd();
    }
    ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
    if (endRestartGroup == null) {
        return;
    }
    endRestartGroup.updateScope(new MainActivityKt$Greeting$1(name, $changed));
}

可以看到，实际上，编译器为我们的带有@Composable的Greeting方法添加了两个参数，

Composer $composer, int $changed

Composer就是我们真的compose执行时的操作者，changed就是一个参与是否重组的标识之一，这种通过注解在编译时生成对应参数的方案，在Coroutine里面也用到，当然我们也可以通过ASM等方法去编译时判断注解并更改相应的函数方法，只不过这部分由compose编译器帮我们做了。

我们重点关注一下composer.startRestartGroup这个方法

override fun startRestartGroup(key: Int): Composer {
    start(key, null, false, null)
    addRecomposeScope()
    return this
}

可以看到传入了一个key为Int类型的标识，所有Composable函数区域会通过特定key去判断重组的范围以及当前范围是否进行更新（范围就是startRestartGroup - endRestartGroup 之间的状态），当然一个Composable函数里面可能存在多个重组范围，我们还是拿上面的Greeting函数做个例子，不过这次有点变化

@Composable
fun Greeting(name: String) {
    val  state by remember {
        mutableStateOf(true)
    }
    if (state){
        Text(text = "true")
    }else{
        Text(text = "false")
    }
}

此时反编译后就会多一些代码

public static final void Greeting(String name, Composer $composer, int $changed) {
    Object value$iv$iv;
    Intrinsics.checkNotNullParameter(name, "name");
    Composer $composer2 = $composer.startRestartGroup(-154424404);
    ComposerKt.sourceInformation($composer2, "C(Greeting)43@1455L45:MainActivity.kt#8m9ksz");
    if (($changed & 1) == 0 && $composer2.getSkipping()) {
        $composer2.skipToGroupEnd();
    } else {
        $composer2.startReplaceableGroup(-492369756);
        ComposerKt.sourceInformation($composer2, "C(remember):Composables.kt#9igjgp");
        Object it$iv$iv = $composer2.rememberedValue();
        if (it$iv$iv == Composer.Companion.getEmpty()) {
            value$iv$iv = SnapshotStateKt__SnapshotStateKt.mutableStateOf$default(Boolean.valueOf(LiveLiterals$MainActivityKt.INSTANCE.m4554x2b38c863()), null, 2, null);
            $composer2.updateRememberedValue(value$iv$iv);
        } else {
            value$iv$iv = it$iv$iv;
        }
        $composer2.endReplaceableGroup();
        MutableState state$delegate = (MutableState) value$iv$iv;
        // 关注这里
        if (m4607Greeting$lambda1(state$delegate)) {
            $composer2.startReplaceableGroup(-154424297);
            ComposerKt.sourceInformation($composer2, "47@1525L19");
            TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4597String$arg0$callText$branch$if$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
            $composer2.endReplaceableGroup();
        } else {
            $composer2.startReplaceableGroup(-154424258);
            ComposerKt.sourceInformation($composer2, "49@1564L20");
            TextKt.m1219TextfLXpl1I(LiveLiterals$MainActivityKt.INSTANCE.m4598String$arg0$callText$else$if$funGreeting(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
            $composer2.endReplaceableGroup();
        }
    }
    ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
    if (endRestartGroup == null) {
        return;
    }
    endRestartGroup.updateScope(new MainActivityKt$Greeting$1(name, $changed));
}

可以看到，我们状态state变量改变的时候，compose会在if里面生成先startReplaceableGroup，代表着这个范围是可以被替换的，也就是说当if成立的时候会生成一个composition节点，此时如果state变成了false，那么这个if里面的范围group就会被移除，此时父group（即在之前调用startgroup的范围）以替换的方式载入新的else，子group，这就是startReplaceableGroup的含义。

总之，我们可以注意到，key就是一个非常关键的点，就是让我们compose识别到哪些范围能够进行重组，哪些不能！在if else语句中，如果我们依赖一个state，就会在相应的if语句里面插入一个新的子范围group，这就是compose架构中的的智能重组！

智能重组真的那么智能吗

上面我们提到了智能重组的这个概念，那么智能重组真的如字面所说，那么“智能”吗？我们很容易想到，既然compose能在if else这种有作用域的关键字上加上子group，如果是list这种呢？存在着循环语句的条件呢？就算在循环语句里面加上子group，并不能满足我们想要的需求呀！举个🌰

@Composable
fun CustomList(list: List<CustromData>) {
   Column {
       for (item in list){
           CustromView(item)
       }
   }
}

我们想要for循环里面的list，如果list改变了数据，我们希望compose只重组改变部分的数据，而不是全部list里面的CustromView，那么compose能做到吗？compose：老子不干了！ 是的！做不到！因为已经生成的CustromView的key只能依靠着当前的数据决定了，比如list的index，如果下次index更改，那么key就会因为index的不一致，导致了list中每一个生成的CustromView再次重组

CustomList部分反编译代码

ColumnScopeInstance columnScopeInstance = ColumnScopeInstance.INSTANCE;
int $changed2 = ((0 >> 6) & 112) | 6;
// 只加了一个startReplaceableGroup
$composer2.startReplaceableGroup(-1487261693);
ComposerKt.sourceInformation($composer2, "C*52@1739L17:MainActivity.kt#8m9ksz");
if ((($changed2 & 81) ^ 16) != 0 || !$composer2.getSkipping()) {
   Iterator<CustromData> it = list.iterator();
      // 循环没办法加入子group
      while (it.hasNext()) {
          Iterator<CustromData> it2 = it;
          CustromData item = it.next();
          CustromView(item, $composer2, 0);
          $changed$iv = $changed$iv;
          it = it2;
      }
} else {
    $composer2.skipToGroupEnd();
}
$composer2.endReplaceableGroup();
public static final void CustromView(CustromData data, Composer $composer, int $changed) {
    Intrinsics.checkNotNullParameter(data, "data");
    Composer $composer2 = $composer.startRestartGroup(-201540877);
    ComposerKt.sourceInformation($composer2, "C(CustromView)59@1825L23:MainActivity.kt#8m9ksz");
    int $dirty = $changed;
    if (($changed &amp; 14) == 0) {
        $dirty |= $composer2.changed(data) ? 4 : 2;
    }
    if ((($dirty &amp; 11) ^ 2) != 0 || !$composer2.getSkipping()) {
        TextKt.m1219TextfLXpl1I(data.getTest2(), null, 0L, 0L, null, null, null, 0L, null, null, 0L, 0, false, 0, null, null, $composer2, 0, 0, 65534);
    } else {
        $composer2.skipToGroupEnd();
    }
    ScopeUpdateScope endRestartGroup = $composer2.endRestartGroup();
    if (endRestartGroup == null) {
        return;
    }
    endRestartGroup.updateScope(new MainActivityKt$CustromView$1(data, $changed));
}

所以一旦出现增删改查list的情况，那么不好意思，compose也就只能把group里面的list再重组一次，如图：

这也是为什么list系列的compose函数，比如LazyRow等会被诟病为有性能问题。那么compose就没有相关解决方法吗？嗯！官方肯定准备了，就是我们可以主动设置当前composable函数的key！从而避免额外的重组！

@Composable
inline fun <T> key(
    @Suppress("UNUSED_PARAMETER")
    vararg keys: Any?,
    block: @Composable () -> T
) = block()

回到我们自定义的list，就可以这样使用

for (item in list){
    key(keys = arrayOf(item.test) ) {
        CustromView(item)
    }
}

当然，我们的LazyList系列也可以直接指定，在item函数及其他items函数中直接使用

interface LazyListScope {
fun item(key: Any? = null, content: @Composable LazyItemScope.() -> Unit)
...
android实现轮播图引导页
上一篇
Android autojs随时翻译剪贴板单词实现示例
下一篇