长期维护视角下：无需本地化时是否仍需使用strings.xml？

嘿，结合你提到的「不做本地化、几乎无字符串重复、核心关注长期可读性与可维护性」的场景，咱们来拆解下这两种写法的优劣：

先看两种写法的本质 #

• 写法一：textView.setText(context.getString(R.string.string, arg));
  这是Android官方推荐的字符串资源管理方式，把文本内容集中放在strings.xml里，通过资源ID引用。它的底层其实也是调用String.format完成占位符替换，性能上和写法二没有差别。

• 写法二：textView.setText(String.format("string %s", arg));
  属于将字符串硬编码到代码中，直接在代码里完成格式化，好处是看代码时能一眼看到显示的具体文本。

结合你的场景分析 #

既然你明确说永远不会本地化，且几乎没有字符串重复，那核心就落在「长期可读性和可维护性」上：

• 如果你的项目极小，且完全确定这些文本永远不会修改，写法二的直观性可能会让代码看起来更简洁。
• 但从长期维护的角度，我更推荐写法一：
  1. 集中管理更可控：哪怕现在不本地化，哪天产品突然要求修改文本内容（比如把"string"改成"content"），写法一只需要在strings.xml里改一行，不用在整个代码库中搜索所有硬编码的地方，避免漏改。
  2. 可读性更清晰：资源文件里可以给字符串加注释，说明这个文本的使用场景（比如<!-- 详情页的内容标题前缀 -->），而硬编码在代码里的字符串，时间久了可能会让人疑惑这个文本是用在什么地方的。
  3. 符合团队协作规范：哪怕你现在是单人开发，以后如果有新人加入，Android资源管理的方式是行业通用的最佳实践，新人能更快上手，不用适应自定义的硬编码风格。

最终结论 #

如果你的项目没有极端特殊的限制，优先选择写法一——它在可维护性上的优势，远大于写法二那点直观性带来的便利，尤其对于需要长期维护的应用来说，这种集中管理的方式能减少很多潜在的麻烦。

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