Hermes Android Intl.Collator 已知问题剖析：非稳定排序与 resolvedOptions 键序偏差

• 语言运行时
• 编译器
• 移动开发

本文基于 lib/Platform/Intl/java/com/facebook/hermes/intl/notes.md 中记录的实现者笔记，深入剖析 Hermes 引擎在 Android 平台上实现Intl.Collator时遗留的两个 ECMA-402 规范符合性（spec conformance）问题：Array.sort非稳定导致的ignore-invalid-unicode-ext-values测试失败，以及 Java/C++ 双层哈希容器导致resolvedOptions()返回键序不确定的prototype/order测试失败。读完本文，你将理解 Hermes Intl 的 JNI 分层架构、Intl.Collator的选项解析与 ICU 映射原理，并能据此复现、定位和评估这两个已知缺陷。

Hermes Intl 的 Java/C++ 双层实现架构

在开始分析具体问题之前，有必要先厘清 Hermes Intl 在 Android 上的整体结构。从仓库布局看，Intl 的 Java 层实现位于 lib/Platform/Intl/java/com/facebook/hermes/intl/，其中：

• Collator.java、DateTimeFormat.java、NumberFormat.java分别对应 ECMA-402 的三大核心对象；
• LocaleResolver.java、LocaleMatcher.java、LocaleIdentifier.java负责 locale 解析与匹配；
• PlatformCollatorICU.java/PlatformCollatorAndroid.java是IPlatformCollator接口的两个平台实现，分别面向 Android N（API 24）及以上和更老的系统版本。

而对应的 C++ 层实现位于 lib/VM/JSLib/Intl.cpp。如该文件头部注释所述，这一层"试图避免平台代码错误导致崩溃或抛出 JS 异常，但仍可能产生不符合规范的行为"（// non-compliant behavior... if the platform result doesn't include them, then they will simply not be present）。两个已知问题正是这类"非致命但不符合规范"行为的典型代表。

Collator.java的类注释明确了分工：Java 部分负责 Android Intl.Collator 实现，与 Hermes JavaScript 内部的交互在 C++ 中实现，二者通过 JNI 桥接。@DoNotStrip注解保证混淆时这些入口不会被剥离。

已知问题一：非稳定的 Array.sort 导致测试失败

问题描述

notes.md记录的第一个已知问题是：

"intl402/Collator/ignore-invalid-unicode-ext-values.js"失败，因为Array.sort不是稳定的（not stable）。

复现方法

笔记给出的复现方法非常简洁——反复执行以下语句，观察console.log输出是否出现顺序不一致：

console.log(testArray.sort(new Intl.Collator().compare));

当排序算法不稳定时，对于compare返回 0（即两个元素在 Collator 语义下完全相等）的元素对，其相对顺序可能在不同轮次、不同输入规模下发生改变，从而导致依赖稳定排序的测试断言偶发失败。

源码级根因

从 lib/VM/JSLib/Sorting.cpp 可以看出，Hermes 的数组排序并非稳定排序。其核心算法是quickSort（见quickSort()与doQuickSort()），并辅以insertionSort处理小规模子区间、heapSort作为快速排序退化时的兜底（// Bail to heap sort）。经典快速排序基于交换（_swap），天然不具备稳定性——即使待排序元素在比较器看来完全相等，其原始相对顺序也无法保证保留。

这一点与问题一直接相关：Intl.Collator.prototype.compare是一个合法的 JS 比较器，当被Array.prototype.sort调用时，排序结果是否稳定由引擎的排序算法决定。由于 Hermes 采用基于快速排序的实现，ignore-invalid-unicode-ext-values.js这类依赖"相等元素保持原序"的测试用例就会失败。

已知问题二：resolvedOptions 键序不确定导致测试失败

问题描述

notes.md记录的第二个已知问题是：

规范要求Intl.Collator.prototype.resolvedOptions()返回的对象具有特定的键顺序。但因为我们（Hermes）在 Java 代码中使用JavaHashMap，在 C++ 层使用std::unordered_map，无法产生确定性的键顺序，这导致"intl402/Collator/prototype/order.js"测试失败。

规范要求 vs 实现现实

ECMA-402 规范（https://tc39.es/ecma402/#sec-intl.collator.prototype.resolvedoptions）要求resolvedOptions返回一个普通对象，其属性插入顺序需遵循规范定义的内部槽（internal slots）顺序，例如依次是locale、usage、sensitivity、ignorePunctuation、collation、numeric、caseFirst等。JS 对象属性的枚举顺序由插入顺序决定，因此键的顺序就是规范一致性的一部分。

而 Hermes 的实现中：

• Java 层：LocaleResolver.resolveLocale()使用HashMap组织解析结果（见 LocaleResolver.java 中new HashMap<>()的用法）。HashMap的迭代顺序依赖哈希值与容量，既不反映插入顺序，也无法跨运行保持一致。虽然Collator.resolvedOptions()最终用LinkedHashMap构造返回对象（见 Collator.java），但中间经HashMap传递的数据在取用时的顺序已经不可控。
• C++ 层：lib/VM/JSLib/Intl.cpp 中optionsToJS()接收的参数类型为std::unordered_map<std::u16string, std::u16string>，遍历该容器逐项写入 JS 对象，键顺序完全取决于哈希桶的排列，同样不具备确定性。

两层叠加导致最终 JS 对象Object.keys()的枚举顺序不固定，prototype/order.js这类严格校验键序的符合性测试自然无法通过。

源码佐证：Collator 的完整实现脉络

为了让上述两个问题有更扎实的上下文，下面结合 Collator.java 梳理Intl.Collator的实现流程。这既帮助理解两个问题的产生场景，也展示了 Hermes 在规范细节上的取舍。

选项解析：initializeCollator

initializeCollator()大体对应规范算法InitializeCollator（https://tc39.es/ecma402/#sec-initializecollator），依次处理：

• usage（"sort"或"search"，默认"sort"，见Constants.COLLATOR_USAGE_POSSIBLE_VALUES与Constants.SORT）；
• localeMatcher（"lookup"或"best fit"，默认"best fit"）；
• numeric（布尔值，对应 unicode 扩展键kn）；
• caseFirst（"upper"/"lower"/"false"，对应扩展键kf）；
• sensitivity（base/accent/case/variant，未指定时按 usage 决定默认值：sort 默认为variant，search 默认为locale）；
• ignorePunctuation（布尔值，默认false）。

类注释还解释了[[RelevantExtensionKeys]]的取舍：ECMA-402 规定 Collator 的相关扩展键必须包含"co"，可以包含"kf"和"kn"；ICU 的RuleBasedCollator.getKeywords()只原生支持collation（映射到co），kf/kn只能通过setNumericCollation、setUpperCaseFirst等方法模拟，因此实现最终固定["co", "kf", "kn"]。

平台分派：N 及以上走 ICU

构造函数中按系统版本分派平台实现：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) { mPlatformCollatorObject = new PlatformCollatorICU(); } else { mPlatformCollatorObject = new PlatformCollatorAndroid(); }

• Android N 及以上：PlatformCollatorICU基于android.icu.text.RuleBasedCollator，按规范要求强制开启CANONICAL_DECOMPOSITION归一化；sensitivity通过setStrength与setCaseLevel组合实现（例如CASE敏感度 =PRIMARY强度 + 大小写层级）；caseFirst通过setUpperCaseFirst/setLowerCaseFirst实现；ignorePunctuation通过setAlternateHandlingShifted(true)实现。这些映射逻辑都在 PlatformCollatorICU.java 中。
• 更老的系统：PlatformCollatorAndroid基于java.text.RuleBasedCollator，能力受限——setIgnorePunctuation、setNumericAttribute、setCaseFirstAttribute均为空实现（直接return this），CASE敏感度因缺少setCaseLevel而"无法在旧平台上正确工作"（见 PlatformCollatorAndroid.java）。此外，在 Android L（API 21）之前Locale.toLanguageTag不可用，getAvailableLocales只能返回{"en"}。

特殊处理：search usage 的 hack

initializeCollator中有一段值得注意的"hack"（源码注释原话：This is a hacky way to avoid the "search" collation value from being shown in "resolvedOptions"）：ICU 没有公开 API 指定 search 排序规则，因此当usage === "search"时，实现通过向 locale id 追加-co-searchunicode 扩展来间接达成——而这在 ECMA-402 规范中是明确禁止的做法。为保证resolvedOptions()不泄露该内部扩展，代码单独维护了mResolvedLocaleObjectForResolvedOptions这个"展示用"的 locale 对象。

规范细节的额外努力

即使存在上述已知问题，实现中仍有一些"尽力贴近规范"的细节，例如resolvedOptions()里将-kn-true规范化为-kn（源码注释：An example of going extra mile to adhere to spec!!），因为布尔扩展键的规范形式是省略-true后缀。这些细节也说明：键序问题并非设计疏忽，而是哈希容器这一实现选择的直接代价。

已知问题的规避策略与验证思路

这两个问题均属于 ECMA-402 符合性测试（test262的intl402目录）层面的失败，对普通业务代码的语义影响有限，但有以下规避与验证策略：

1. 依赖稳定排序的业务：如果应用依赖"比较器相等时保持原序"的排序语义（例如按多级关键字排序后再次排序），在当前 Hermes 版本上应先自行做稳定化处理（如携带原始索引作为次级比较键），或改用TypedArray之外、由用户层实现的归并排序。相关排序实现可继续参考 lib/VM/JSLib/Sorting.cpp 与 lib/VM/JSLib/Array.cpp。
2. 依赖属性顺序的业务：不要依赖resolvedOptions()（乃至任何由std::unordered_map/HashMap中转构造的 JS 对象）的Object.keys()顺序；如需确定性，应显式按文档中规定的键顺序自行构造对象。相关键序问题在Intl.DateTimeFormat、Intl.NumberFormat的resolvedOptions路径中同样存在（参见 lib/VM/JSLib/Intl.cpp 中三处optionsToJS调用）。
3. 复现与回归观察：按笔记给出的语句在 Hermes CLI 或 React Native 的 Hermes 运行时中反复执行排序并比对输出即可复现问题一；问题二可用Object.keys(new Intl.Collator().resolvedOptions())多次执行观察键序变化。

小结

notes.md以极简的篇幅记录了 Hermes Android Intl 实现的两个真实且可复现的符合性缺口：非稳定排序的Array.sort叠加 Collator 比较器破坏稳定排序测试，以及 JavaHashMap+ C++std::unordered_map双层哈希容器导致的resolvedOptions键序不确定。前者根植于 Sorting.cpp 的快速排序算法选型，后者根植于 Intl.cpp 与 LocaleResolver.java 的容器选型。理解这两处取舍，不仅有助于规避业务层风险，也能为评估 Hermes 在 Android 上的 ECMA-402 覆盖度提供准确的坐标参照。

• 语言运行时
• 编译器
• 移动开发