此处的 Android 文档http://developer.android.com/guide/topics/resources/localization.html说明您可以使用此方法获取当前语言环境：
context.getResources().getConfiguration().locale
似乎 Java 已经以这种方法的形式提供了这些信息：
java.util.Locale.getDefault()
那么，为什么 Android 开发人员要引入另一种获取语言环境的方法呢？上面两行代码在同时运行时会产生不同的结果吗？
我同意它令人困惑，虽然我没有攻击它，也没有捍卫它，但我可以看到它允许你做一些事情。
让我们从头开始。
java.util.Locale.getDefault()由 java 运行时定义。它是电话/设备的语言环境。当没有语言环境时，它是 DateFormats（ISO 日期格式标准、美国格式标准等）、NumberFormats（逗号或小数、3 或 4 分组等）和 CurrenyFormats（它看起来像 $ 还是 CAD）之类的东西的动力给定的。对于这些情况，无论如何最好为这些类型的对象指定区域设置。
context.getResources().getConfiguration().locale是在给定上下文中向当前资源包注册的语言环境。它可以包括所有资源内容将尊重当前上下文/资源对的语言环境值。配置可以有点像设备的当前状态，最好过滤到当前资源。您不一定需要指定任何根据区域设置更改的内容，但这是一个选项。
资源在配置中使用一组鉴别器，如方向、屏幕宽度、语言环境等。因此，在您的应用程序中，您可以通过将语言环境应用程序配置更改为不同的语言环境来允许用另一个资源覆盖当前的 Resources()。例如，您正在为地址进行布局。您可能希望某些字段根据所选国家/地区进行变形。（并不是说对于这样的应用程序来说这是正确的行为，但这是现在最简单的想法）。如果您必须简单地依赖 Locale.getDefault()，那么当您想要执行我刚才描述的操作时，它会导致系统应用程序和状态的一些尴尬重置。
您基本上需要修改整个设备的区域设置（这不一定安全，也不是任何老用户都会喜欢的东西）。即使我们忽略主机 vm 会重复的安全管理器问题；在大多数设备上，为国家/地区套件缓存了很多状态。所以在切换这个值时会有相当大的滞后，可能会有很多不稳定（如果有人能做到的话）。另一种选择是始终为所有内容指定语言环境。你可以看到那会有多烦人。所以它在上下文的配置中。
因此，虽然它很尴尬，但它确实提供了额外的自由度、保护和便利性。大多数情况下它将是 Locale.getDefault()，因为您的应用程序是从一个将基本上下文初始化为 Locale.getDefault() 的进程启动的。一般来说，我会避免过多地使用 Locale.getDefault() 值。在消费者应用程序开发中，没有太多次值得信任。
再次不是基于事实，因为我不是操作系统开发人员，只是主要基于分析系统的优缺点。我认为配置中的语言环境是完全合理的。