Hermes源码分析（二）——解析字节码

Posted 2023-02-15

参考技术A

前面一节 讲到字节码序列化为二进制是有固定的格式的，这里我们分析一下源码里面是怎么处理的

这里可以看到首先写入的是魔数，他的值为

对应的二进制见下图，注意是小端字节序

第二项是字节码的版本，笔者的版本是74，也即 上图中的4a00 0000
第三项是源码的hash，这里采用的是SHA1算法，生成的哈希值是160位，因此占用了20个字节

第四项是文件长度，这个字段是32位的，也就是下图中的为0aa030，转换成十进制就是696368，实际文件大小也是这么多

后面的字段类似，就不一一分析了，头部所有字段的类型都可以在 BytecodeFileHeader.h 中看到，Hermes按照既定的内存布局把字段写入后再序列化，就得到了我们看到的字节码文件。

这里写入的数据很多，以函数头的写入为例，我们调用了visitFunctionHeader方法，并通过byteCodeModule拿到函数的签名，将其写入函数表（存疑，在实际的文件中并没有看到这一部分）。注意这些数据必须按顺序写入，因为读出的时候也是按对应顺序来的。

我们知道react-native 在加载字节码的时候需要调用hermes的preparejavascript方法， 那这个方法做了些什么事呢？

这里做了两件事情：
1. 判断是否是字节码，如果是则调用createBCProviderFromBuffer，否则调用createBCProviderFromSrc，我们这里只关注createBCProviderFromBuffer
2.通过BCProviderFromBuffer的构造方法得到文件头和函数头的信息（populateFromBuffer方法），下面是这个方法的实现。

BytecodeFileFields的populateFromBuffer方法也是一个模版方法，注意这里调用populateFromBuffer方法的是一个 ConstBytecodeFileFields对象，他代表的是不可变的字节码字段。

细心的读者会发现这里也有visitFunctionHeaders方法， 这里主要为了复用visitBytecodeSegmentsInOrder的逻辑，把populator当作一个visitor来按顺序读取buffer的内容，并提前加载到BytecodeFileFields里面，以减少后面执行字节码时解析的时间。

Hermes引擎在读取了字节码之后会通过解析BytecodeFileHeader这个结构体中的字段来获取一些关键信息，例如bundle是否是字节码格式，是否包含了函数，字节码的版本是否匹配等。注意这里我们只是解析了头部，没有解析整个字节码，后面执行字节码时才会解析剩余的部分。

evaluatePreparedJavaScript这个方法，主要是调用了HermesRuntime的 runBytecode方法，这里hermesPrep时上一步解析头部时获取的BCProviderFromBuffer实例。

runBytecode这个方法比较长，主要做了几件事情：

这里说明一下，Domain是用于垃圾回收的运行时模块的代理， Domain被创建时是空的，并跟随着运行时模块进行传播， 在运行时模块的整个生命周期内都一直存在。在某个Domain下创建的所有函数都会保持着对这个Domain的强引用。当Domain被回收的时候，这个Domain下的所有函数都不能使用。

未完待续。。。