Android字符串本地化内部实现机制探究及方案评估需求

现有本地化方案概述 #

我们项目的本地化实现逻辑如下：

• 仅维护一套默认字符串资源文件夹
• 所有多语言字符串存储在数据库中，通过扩展Resources类重写getString()方法实现自定义加载：

@Override
public String getString(int id) throws NotFoundException {
    String value = null;
    try {
        value = getStringFromRepository(id);
        if (value != null) {
            return value;
        }
    } catch (Exception ex) {
        
    }
    return super.getText(id).toString();
}

• 搭配LRU缓存，在应用启动、语言切换时通过后台线程异步从网络同步数据
• 但缓存读取、数据库查询操作均在UI线程执行，引发了ANR问题
• 推测该方案初衷是缩小APK初始安装包体积，而Android官方推荐的标准方案是按语言在res/values-xx目录下存放对应字符串资源

Android 内部字符串资源管理与加载机制 #

1. 编译打包阶段 #

Android构建工具（AGP）会将各语言目录下的字符串资源编译为二进制格式的resources.arsc文件：

• 每个字符串资源会被分配唯一的资源ID，映射关系写入自动生成的R.java类
• 不同语言的同ID字符串会被归类到对应的语言资源组，打包时APK会包含所有配置的语言资源（支持通过App Bundle按需分包）

2. 运行时加载逻辑 #

应用启动时系统会创建Resources实例，关联当前设备的配置（语言、屏幕密度等）：

• 调用getString(int resId)时，Resources会根据当前语言优先级，从resources.arsc的内存映射中快速定位对应字符串：
  • 优先匹配最贴合当前语言的资源组（如系统语言为zh-CN时，先查找values-zh-rCN，无匹配则依次 fallback 到values-zh、默认values目录）
  • 整个查找过程是纯内存级别的索引查询，无磁盘IO或数据库操作，性能开销极低
• 系统会对常用资源进行内存缓存，进一步提升加载速度

3. 语言切换时的资源重载 #

切换语言时，只需创建新的Configuration对象并更新Resources实例，系统会重新加载对应语言的资源组，全程基于内存映射操作，无需额外IO开销

现有方案的问题分析与优化方向 #

核心问题 #

现有方案将缓存读取、数据库查询放在UI线程，即使是本地DB操作也会因磁盘IO阻塞UI（尤其是数据量较大、索引未优化时），直接触发ANR；而Android原生资源加载是纯内存操作，完全规避了这个风险。

优化建议 #

1. 异步化资源查询操作：
   • 重写getString()时，禁止在UI线程执行getStringFromRepository()，改用Coroutine、HandlerThread等异步方式加载，通过回调或LiveData返回结果
   • 预先在后台线程将高频使用的字符串加载到内存缓存，UI线程仅读取缓存，彻底避开DB操作
2. 结合官方方案优化包体积：
   • 采用Android App Bundle（AAB）的按需语言资源下载功能，用户仅下载自身需要的语言资源，既符合官方规范，又能减小初始安装包体积
   • 保留默认语言资源在APK中，其他语言通过按需下载获取，避免完全依赖网络/DB加载
3. 替换自定义Resources扩展逻辑：
   • 放弃扩展Resources类的方案，改用官方标准资源管理方式，仅在需要动态更新的场景（如运营文案）使用网络+缓存的方式补充

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