我报名了Goldstone Project Phase 1 Challenge——瓜分100,000奖池，这是我的第一篇文章， 点击查看活动详情
背景
在android开发中，无论是基于xml开发还是compose的view系统，开发性能和页面性能也深深影响着我们的app。在 xml 开发中，我们可以使用 Layout Inspector（AS 工具选项）进行 UI 界面级别。视图是用来检查我们的ui等级是否合理，页面绘制是否有问题。虽然有这么好的工具，但是Layout Inspector在普通机型上用起来不是那么方便，而且总是存在性能问题（虽然我开发的是m1芯片的mac，但是运行起来也很困难，哭！）尽管 compose 以高性能和高效率被开发者所接受，但这种高效率并不总是那么“值得信赖”，因为 智能重组 也是有限的，这部分内容可以在 神奇的作曲-开场白 有介绍！所以要判断我们的compose性能好坏，是的，官方也提供了相关的检测方法！ 解释 Compose 编译器指标
使用编译器指标
为了检测compose-compiler的性能，compose官方发布了一个检测插件，可以在我们的build.gradle中直接添加如下代码
启动
可以在终端直接执行以下命令来开启compose编译检测
.gradlew -Pandroidx.enableComposeCompilerMetrics= true :compose :runtime :runtime :compileKotlin
生成报告
.gradlew -Pandroidx.enableComposeCompilerReports= true :compose :runtime :runtime :compileKotlin
复制代码
可以配置其他gradle模块
编译科特林 {
freeCompilerArgs += listOf(
“-P”，
“插件：androidx.compose.compiler.plugins.kotlin:metricsDestination=<directory> "
)
}
复制代码 编译科特林 {
freeCompilerArgs += listOf(
“-P”，
“插件：androidx.compose.compiler.plugins.kotlin:metricsDestination=<directory> "
)
}
复制代码
目录表示我们要生成的报告的路径。当然，上述方法不方便我们启用检测。比如我们想配置发布包不检测、debug检测或者其他包检测的时候，就不是那么方便了。 ，所以这里有一个很好的写法，可以直接在根目录build.gradle配置
子项目{
任务 .withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile) .configureEach {
kotlinOptions {
如果（project.findProperty（“myapp.enableComposeCompilerReports”）==“真”）{
freeCompilerArgs += [ "-P" , "plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=" + project.buildDir.absolutePath + "/compose_metrics" ]
freeCompilerArgs += [ "-P" , "plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination=" + project.buildDir.absolutePath + "/compose_metrics" ]
}
}
}
}
复制代码
上面的配置配置了一个交换机。如果要开启检测，只需要将属性myapp.enableComposeCompilerReports设置为true即可，例如如下
./gradlew assembleRelease -Pmyapp.enableComposeCompilerReports=true
复制代码
生成的compose性能报告如下
生成文件解析
- app_release-classes ：当前扫描类的状态
- app_release-composables.csv csv格式文件，这里我们不关注
- app_release-composables.txt 当前如此可组合的功能信息
- app_release-module.json 当前compose输出中的具体信息统计为json格式
相关数据应该很容易理解，这里不再赘述。值得注意的是，我们可以看到在上面的compose函数中，有一些函数被标记为 可重启 ，有些是 可跳过的 ，有的两者都有，有的只有 可重启 ， 这是什么意思？
可重启 : Composable，表示compose中的函数是否可以参与重组。目前，几乎所有这些都应该是 @可组合 修改后的功能可以参与重组。
可跳过的 : 可以跳过重组，是什么意思？在我们的 compose 函数中，不需要每次都进行重组。当本次compose函数没有变化时，会跳过重组（key相同，内容没有变化时），我们可以反编译compose函数，查看相关函数（编译时生成）
$composer2.skipToGroupEnd();
复制代码
这是跳过重组！这里有 可重启 为了形成差异，并非所有可组合函数都可以生成方法以在编译时跳过重组。我们用下面的对比例子来说明：
没有可跳过的修饰符
类测试数据2 {
变种文字 = ""
}
复制代码 @可组合
有趣的测试1（数据：TestData2）{
文本（文本 = 数据。文本）
}
复制代码
这时候函数没有用skipable修改，因为依赖TestData2中的text属性是可变的
反编译后：
带有可跳过的装饰
相反，当我们使用不可变数据类时，我们可以生成可跳过的可组合函数
数据类 TestData (val text: String )
复制代码 @可组合
有趣的测试（数据：TestData）{
文本（文本 = 数据。文本）
}
复制代码
反编译后：
在这里，我们做一个小结论。如果想让可组合函数具有跳过重组的能力，那么它所依赖的外部属性必须是 all 稳定的 是的，常见的（Boolean、Int、Long、String、Float、Double、函数类型等）是稳定的，一些默认的不稳定的，比如接口等类，如果我们想提高重组的性能，我们可以使用@Stable 装饰，告诉 compose 编译器生成跳过重组的逻辑！
一个小坑
不过值得注意的是，列表类型，即使我们用@Stable装饰它，仍然被认为是 不稳定 依赖的可组合函数仍然不可跳过（没有可跳过）
@可组合
@稳定的
有趣的测试3（数据：列表<TestData>）{
数据.forEach {
文本（文本 = 它。文本）
}
}
复制代码
总结
至此，我们应该可以使用 compiler-metrics 来检测我们的 compose 项目了！找到我们需要优化的点非常重要！
最后，作者有话要说：神奇的compose系列文章其实更侧重于实用技巧和底层分析，可能会干扰对compose不太了解的朋友阅读，不过没关系！尽管继续！附上compose官方链接
developer.android.google.cn/jetpack/and…
版权声明：本文为博主原创文章，遵循CC 4.0 BY-SA版权协议。转载请附上原文出处链接和本声明。
这篇文章的链接： https://homecpp.art/4404/6437/0955
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/12308/08250412
标签：compose,函数,Compose,代码,Magical,复制,监控,文本,我们 From： https://www.cnblogs.com/amboke/p/16654814.html