Android开发中为什么推荐将文本内容放入strings资源文件中？

优先使用@string引用字符串资源的写法，不建议直接硬编码文本，具体解答如下：

两种写法对比 #

推荐写法 #

<TextView
    android:id="@+id/textView"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/my_text_in_strings" />

不推荐的硬编码写法 #

<TextView
    android:id="@+id/textView"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="My Text" />

推荐使用字符串资源的核心原因 #

• 多语言适配成本极低：所有文本统一存放，需要做多语言适配时只需新增对应语言的strings.xml文件，系统会自动根据用户设备的系统语言加载对应文本，无需修改布局或业务代码
• 统一维护效率更高：相同文案如果在多处使用，只需修改strings.xml中的一处即可全局生效，避免硬编码需要逐处查找修改的问题，也不会出现不同页面同含义文案不一致的问题
• 支持复杂文本处理：可以轻松实现带占位符的动态文本（比如欢迎回来，%s运行时替换用户名）、特殊字符、格式化文本，硬编码实现这类需求会非常繁琐甚至报错

是否属于必须遵守的规范 #

不属于Android系统层面的强制要求，硬编码文本的代码可以正常编译运行。但这是Google官方明确推荐的Android开发最佳实践，也是绝大多数互联网公司Android开发团队的强制准入规范。另外Android Studio自带的Lint检查会对硬编码文本给出Hardcoded string "Repeat", should use @string resource的警告，不少团队的CI/CD流程会把这类Lint警告设为合并卡点，不符合规范的代码无法提交上线。

对运行性能的影响 #

使用字符串资源对应用运行性能的影响极小，几乎可以忽略不计。Android系统对资源加载做了高度优化，加载strings资源的耗时和硬编码的差异几乎感知不到。对比硬编码带来的适配、维护成本上升问题，这点可以忽略的性能差异完全不值得在意。

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