除了优化启动性能 ， 团队还将内存占用作为改进React Native应用的重要机会 ， 尤其是在VR方面 。 在Java 引擎的底层控制中 ， 通过压缩位（squeezing bits）和字节实现多轮内存优化：

• 以前 ， 所有Java值都表示64位NaN装箱编码标记值 ， 用来表示64位架构上的浮点双精度值和指针 。 然而 ， 这在实践中是浪费的 ， 因为大多数数字都是小整数 (SMI) ， 并且客户端应用程序的 Java 堆通常不会大于 4GiB 。 为了解决这个问题 ， 我们引入了一种新的 32 位编码 ， 其中 SMI 和指针以 29 位编码（因为指针是 8 字节对齐的 ， 我们可以假设底部 3 位始终为零） ， 其余的 JS 数字是 装在堆上 。 这将 Java 堆大小减少了约 30% 。
• 不同类型的 Java 对象在 Java 堆中表示为不同类型的 GC 管理单元 。 通过积极优化这些单元格头的内存布局 ， 我们能够将内存使用量再减少约 15% 。

团队还决定Hermes不实现即时 (JIT) 编译 ， 对于大多数 React Native 应用程序来说 ， 额外的预热成本、额外的二进制文件和内存占用实际上并不值得 。
多年以来 ， 团队在解释器性能与编译器的优化方面投入了大量精力 ， 也让 Hermes 获得了远超其他引擎的 React Native 工作负载吞吐量优势 。 他们将继续关注广泛存在的性能瓶颈（解释器调度循环、堆栈布局、对象模型、垃圾回收等）以提高吞吐量 。 请大家静待胜利的消息！
在过去两年 ， Hermes团队除了上文描述的内容之外 ， 还在垂直整合领域做了不少尝试 ， 例如Hermes 使用 Chrome DevTools Protocol支持 Chrome 调试器在设备上执行 Java 调试；其次 ， Hermes还就推动整个技术社区生态进行努力；第三 ， Hermes 正在努力扩展到更多新平台 ， 例如在微软 Build 2020 大会上 ， 软件巨头表示相较于原本的 Chakra 引擎 ， Hermes 能够将 React Native for Windows 的内存占用量降低 13% 。 而在最近的一些综合基准测试中 ， 微软发现 Hermes 0.8（包含 Hades 及之前提到的 SMI 与指针压缩优化功能）占用的内存量比其他引擎少 30% 至 40% 。
作者在最后也呼吁广大开发者能够多多支持Hermes社区 ， 让Hermes成为大多数React Native应用程序的正确选择 ， 并分享了Hermes社区的发展路线图 ， 从而最终实现Hermes成为React Native 默认Java引擎这一目标 。

原文：https://reactnative.dev/blog/2021/10/26/toward-hermes-being-the-default

?库克霸气回应：用户想侧载可以买安卓；腾讯员工人均月薪8万；Facebook与微软达成合作 | 极客头条
?CentOS 8 ， 凛冬将至！
?英伟达黄仁勋的元宇宙梦想：虚拟世界将如同互联网站那样不断涌现