为什么Jetpack Compose仍推荐使用XML字符串资源而非Kotlin常量？

虽然Jetpack Compose摒弃了XML布局，但XML资源体系（字符串、dp/sp值等）的优势是Kotlin常量方案替代不了的，具体原因如下：

一、XML资源的不可替代优势 #

• 原生多语言适配：XML字符串资源支持按语言目录（如values-zh、values-en）自动切换，系统会根据设备语言环境自动加载对应资源，完全无需手动编写语言判断逻辑。用object Strings的话，你得自己实现语言检测、字符串映射，代码冗余且容易出错。
• 系统级动态适配：dp/sp尺寸资源能自动适配不同屏幕密度、系统字体缩放设置。比如用户调大系统字体时，sp值会同步缩放，XML资源会自动处理；而object Sp里的固定数值无法响应这种变化，会导致文字显示不全或布局错乱。
• 主题与富文本支持：XML字符串可以直接使用<b>``<i>等富文本标签，还能通过?attr/xxx引用主题属性，实现样式统一。Kotlin常量很难优雅实现这些功能，要么硬编码富文本，要么额外写大量样式逻辑。
• IDE工具链加持：Android Studio对XML资源提供预览、语法检查、自动提取硬编码内容等功能，能大幅降低出错概率；而Kotlin常量没有这些IDE级别的辅助，拼写错误或遗漏很难被及时发现。

二、Kotlin object常量方案的核心问题 #

• 无法响应动态变化：常量是编译期固定值，不能随系统语言、字体缩放、主题切换等场景动态更新。比如用户中途切换语言，object Strings里的字符串不会自动刷新，必须重启App才能生效。
• 多语言维护成本极高：每新增一种语言，就得手动维护对应的object或映射表，随着语言种类增多，代码会变得臃肿不堪，后期维护难度陡增。
• 缺乏上下文感知能力：带占位符的字符串（如"Hello, %s"）需要结合上下文才能正确格式化，Kotlin常量无法直接处理这类动态场景，得额外编写格式化逻辑，增加代码复杂度。

内容的提问来源于stack exchange，提问作者tariqebadi