Android能否用Firebase Remote Config动态更新strings.xml？求方案与最佳实践

我正在开发一款支持多语言的Android应用，计划用Firebase Remote Config存储JSON格式的翻译内容，想在运行时动态更新类似strings.xml的资源文件。请问能否通过Firebase获取的数据直接在运行时更新strings.xml或同类资源文件？若可行，该如何实现？

另外想了解这个方案是否可取，或者有没有更优的实践方案，能借助Firebase实现Android应用的动态本地化。

已尝试操作 #

• 在Kotlin中创建数据类，用于存储从Firebase Remote Config获取并解析后的本地化字符串
• 尝试通过编程方式在全应用范围内应用这些解析后的字符串，而非依赖传统的strings.xml机制

预期与实际结果 #

• 预期：JSON解析为数据类后，能基于用户语言设置动态更新UI的本地化字符串
• 实际：JSON解析正确且数据类已填充翻译字符串，但无法将这些动态翻译无缝集成到应用各处。核心问题是运行时无法修改strings.xml，导致无法使用Android内置资源系统（R.string）管理本地化

遇到的问题 #

无法与Android原生资源系统集成，没法用getString(R.string.some_string)这类熟悉的机制获取并显示翻译字符串，这限制了方案的可扩展性与可维护性，还偏离了标准Android开发规范。

核心结论：无法直接运行时更新strings.xml #

Android的strings.xml属于编译后的只读资源文件，运行时完全无法修改或替换。系统加载资源依赖编译时生成的R类，没有途径在运行时修改预编译的资源映射，因此直接更新strings.xml的方案从技术上不可行。

可行的替代实现方案 #

如果已经基于Firebase Remote Config完成了JSON解析和数据类存储，可以通过以下方式无缝集成到应用中：

1. 封装全局本地化工具类 #

创建单例工具类统一管理动态翻译，替代原生getString(R.string.*)的调用逻辑：

object LocalizationManager {
    private var currentTranslations: TranslationsDataClass? = null

    // 从Firebase Remote Config解析后初始化/更新翻译数据
    fun updateTranslations(translations: TranslationsDataClass) {
        currentTranslations = translations
    }

    // 获取翻译字符串，优先用动态数据， fallback到原生资源
    fun getString(key: String, context: Context): String {
        return currentTranslations?.getTranslation(key) 
            ?: context.getString(context.resources.getIdentifier(key, "string", context.packageName))
    }
}

使用时将原getString(R.string.some_key)替换为LocalizationManager.getString("some_key", this)即可。

2. 自定义ContextWrapper（深度集成原生资源系统） #

通过自定义ContextWrapper拦截资源获取逻辑，让原生getString(R.string.*)自动优先使用Firebase动态翻译：

class DynamicLocalizationContextWrapper(base: Context) : ContextWrapper(base) {
    override fun getString(resId: Int): String {
        val resName = resources.getResourceEntryName(resId)
        val dynamicString = LocalizationManager.getDynamicString(resName)
        return dynamicString ?: super.getString(resId)
    }

    override fun getString(resId: Int, vararg formatArgs: Any?): String {
        val resName = resources.getResourceEntryName(resId)
        val dynamicString = LocalizationManager.getDynamicString(resName)
        return dynamicString?.let { String.format(it, *formatArgs) } ?: super.getString(resId, *formatArgs)
    }

    companion object {
        fun wrap(context: Context): ContextWrapper {
            return DynamicLocalizationContextWrapper(context)
        }
    }
}

然后在Activity的attachBaseContext方法中替换上下文：

override fun attachBaseContext(newBase: Context) {
    super.attachBaseContext(DynamicLocalizationContextWrapper.wrap(newBase))
}

这种方式无需修改现有代码中的getString调用，即可自动适配动态翻译。

方案评估与更优实践 #

原方案的优缺点 #

• 优点：无需重新打包发布即可更新翻译，适合快速修复翻译错误、新增小语种场景
• 缺点：无法完全替代原生资源系统，处理复数、带占位符的字符串时需额外逻辑，且首次启动可能存在翻译加载延迟

更优实践：原生资源兜底 + Firebase动态补充 #

推荐采用混合方案平衡稳定性与灵活性：

1. 基础翻译放在strings.xml：保证应用在无网络或Firebase加载失败时能正常显示本地化内容
2. Firebase存储增量翻译：仅存储需要动态修改的字符串，减少Remote Config的 payload 大小
3. 结合WorkManager定期同步：避免每次启动都请求Firebase，提升应用性能
4. 兼容复杂格式：在Firebase的JSON中存储符合Android格式的字符串（如%1$s个项目），适配带占位符、复数的场景

其他可选方案 #

如果需要更全面的动态本地化能力，可以考虑用Firebase Cloud Firestore存储翻译内容，配合Room做本地缓存，实现更灵活的版本管理和增量更新，但整体复杂度会高于Remote Config。

内容的提问来源于stack exchange，提问作者SYED MUHAMMAD HARIS