Jetpack Compose资源最佳实践：中大型项目资源管理咨询

对于从Android XML转Compose的开发者，核心思路是尽量复用Android原生资源系统的成熟能力，同时结合Compose特性做适度优化，以下是中大型项目的具体实践：

尺寸管理 #

• 优先用dimens.xml + dimensionResource()：原生的多屏幕适配配置（比如sw360dp、w600dp这类文件夹）经过长期验证，能统一全项目的适配逻辑，避免硬编码或单例维护的繁琐。
• 动态尺寸需求用CompositionLocal封装：如果需要随主题、状态变化的尺寸，基于dimensionResource拿到基础值后再做调整，别脱离原生资源体系单独搞一套。
• 绝对禁止硬写数值：比如Modifier.padding(16.dp)这种写法，后期适配不同屏幕时要改遍所有Composable，成本极高。

字符串管理 #

• 必须用strings.xml + stringResource()：原生资源的多语言切换、占位符处理、无障碍支持都是现成的，Compose完全兼容，没必要自己写单例或硬编码文本，否则多语言适配会变成噩梦。
• 复杂文本组合基于原生资源：比如动态拼接内容，先通过stringResource拿到基础文本，再做组合，别直接在Composable里拼硬编码字符串。

颜色管理 #

• 基础色用colors.xml + colorResource()：尤其是需要深色模式适配的颜色，原生的night配置文件夹能自动切换，比自己维护单例主题色可靠得多。
• 主题动态色结合Compose Theme：比如MaterialTheme.colorScheme.primary，但底层的颜色值建议还是从colors.xml读取，保持全项目资源的统一入口。

额外提醒 #

• 资源命名统一：延续XML开发的命名习惯，比如尺寸用spacing_small、size_button，颜色用color_primary，团队协作更顺畅。
• 别过度封装：不要为了“纯Compose”而搞大量单例或CompositionLocal，只有原生资源满足不了动态需求时再考虑扩展。
• 复用原有适配逻辑：之前XML开发时的屏幕适配策略（比如配置文件夹规则）直接沿用，不用重新设计，减少团队学习成本。

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