语言运行时编译器移动开发【免费下载链接】hermesA JavaScript engine optimized for running React Native.项目地址https://gitcode.com/gh_mirrors/hermes/hermes点击查看免费下载本文基于 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 NAPI 24及以上和更老的系统版本。而对应的 C 层实现位于 lib/VM/JSLib/Intl.cpp。如该文件头部注释所述这一层试图避免平台代码错误导致崩溃或抛出 JS 异常但仍可能产生不符合规范的行为// non-compliant behavior... if the platform result doesnt 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_mapstd::u16string, std::u16string遍历该容器逐项写入 JS 对象键顺序完全取决于哈希桶的排列同样不具备确定性。两层叠加导致最终 JS 对象Object.keys()的枚举顺序不固定prototype/order.js这类严格校验键序的符合性测试自然无法通过。源码佐证Collator 的完整实现脉络为了让上述两个问题有更扎实的上下文下面结合 Collator.java 梳理Intl.Collator的实现流程。这既帮助理解两个问题的产生场景也展示了 Hermes 在规范细节上的取舍。选项解析initializeCollatorinitializeCollator()大体对应规范算法InitializeCollatorhttps://tc39.es/ecma402/#sec-initializecollator依次处理usagesort或search默认sort见Constants.COLLATOR_USAGE_POSSIBLE_VALUES与Constants.SORTlocaleMatcherlookup或best fit默认best fitnumeric布尔值对应 unicode 扩展键kncaseFirstupper/lower/false对应扩展键kfsensitivitybase/accent/case/variant未指定时按 usage 决定默认值sort 默认为variantsearch 默认为localeignorePunctuation布尔值默认false。类注释还解释了[[RelevantExtensionKeys]]的取舍ECMA-402 规定 Collator 的相关扩展键必须包含co可以包含kf和knICU 的RuleBasedCollator.getKeywords()只原生支持collation映射到cokf/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 thisCASE敏感度因缺少setCaseLevel而无法在旧平台上正确工作见 PlatformCollatorAndroid.java。此外在 Android LAPI 21之前Locale.toLanguageTag不可用getAvailableLocales只能返回{en}。特殊处理search usage 的 hackinitializeCollator中有一段值得注意的hack源码注释原话This is a hacky way to avoid the search collation value from being shown in resolvedOptionsICU 没有公开 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目录层面的失败对普通业务代码的语义影响有限但有以下规避与验证策略依赖稳定排序的业务如果应用依赖比较器相等时保持原序的排序语义例如按多级关键字排序后再次排序在当前 Hermes 版本上应先自行做稳定化处理如携带原始索引作为次级比较键或改用TypedArray之外、由用户层实现的归并排序。相关排序实现可继续参考 lib/VM/JSLib/Sorting.cpp 与 lib/VM/JSLib/Array.cpp。依赖属性顺序的业务不要依赖resolvedOptions()乃至任何由std::unordered_map/HashMap中转构造的 JS 对象的Object.keys()顺序如需确定性应显式按文档中规定的键顺序自行构造对象。相关键序问题在Intl.DateTimeFormat、Intl.NumberFormat的resolvedOptions路径中同样存在参见 lib/VM/JSLib/Intl.cpp 中三处optionsToJS调用。复现与回归观察按笔记给出的语句在 Hermes CLI 或 React Native 的 Hermes 运行时中反复执行排序并比对输出即可复现问题一问题二可用Object.keys(new Intl.Collator().resolvedOptions())多次执行观察键序变化。小结notes.md以极简的篇幅记录了 Hermes Android Intl 实现的两个真实且可复现的符合性缺口非稳定排序的Array.sort叠加 Collator 比较器破坏稳定排序测试以及 JavaHashMap Cstd::unordered_map双层哈希容器导致的resolvedOptions键序不确定。前者根植于 Sorting.cpp 的快速排序算法选型后者根植于 Intl.cpp 与 LocaleResolver.java 的容器选型。理解这两处取舍不仅有助于规避业务层风险也能为评估 Hermes 在 Android 上的 ECMA-402 覆盖度提供准确的坐标参照。赞分享语言运行时编译器移动开发【免费下载链接】hermesA JavaScript engine optimized for running React Native.项目地址https://gitcode.com/gh_mirrors/hermes/hermes点击查看免费下载相关推荐gorush中的切片排序稳定性稳定排序与不稳定排序gorush中的切片排序稳定性稳定排序与不稳定排序 在Golang开发中切片Slice排序是常见操作。排序算法的稳定性直接影响程序结果准确性尤其在多字后端pnpm 确定性修复lockfile tarball URL 与已知 registry 匹配顺序的等长排序问题pnpm 确定性修复lockfile tarball URL 与已知 registry 匹配顺序的等长排序问题 本篇文章以 pnpm 仓库的 changese包管理器开发工具CLIopencodex 非 OpenAI 提供商追赶盘点现状所有权、已知差距与依赖排序路线图opencodex 非 OpenAI 提供商追赶盘点现状所有权、已知差距与依赖排序路线图 本文基于仓库 devlog/_fin/260717_non_open创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
