一段时间前，@s1341 将 Frida 移植到了 QNX；就在几周前， 他在嵌入式 ARM 设备上使用 Frida 时遇到了内存占用问题。这正值他贡献将 Frida 移植到 linux-arm 的 pull request 之后。我们开始意识到，可能该引入一个新的 JavaScript 运行时了，并一致认为 Duktape 非常符合我们的需求。

该运行时现已落地，所有测试均已通过；在测量带空 onEnter/onLeave 回调的 被钩住函数调用开销时，它甚至击败了 V8 运行时。下面是一个直观对比：

…/interceptor_on_enter_performance: V8 min=2 max=31 avg=2 OK
…/interceptor_on_enter_performance: DUK min=1 max=2 avg=1 OK

（数值单位为微秒，在运行 OS X 10.11.2 的 4 GHz i7 上测得。）

不管怎样，即使这一对比并不完全公平——我们在新运行时里使用了一些巧妙的回收和写时复制技巧， 而 V8 运行时还没有——这个新运行时已经相当令人印象深刻。它还让我们能在非常微型的设备上运行； 对大多数 Frida 用户而言，像 V8 这样由 JIT 驱动的怪兽与纯解释器之间的性能差异，可能并不真的重要。

因此从此版本开始，我们也在所有预构建二进制文件中包含这个全新运行时，让你可以尝试并告诉我们使用效果。 它只增加几百 KB 的体积，与 V8 为每个架构切片增加的 6 MB 相比微不足道。 请通过向 CLI 工具传入 --disable-jit，或在首次调用 session.create_script() 前调用 session.disable_jit() 来试用它。

考虑到这个新运行时还解决了一些需要在 JavaScriptCore 运行时中投入大量工作才能修复的问题， 例如忽略来自后台线程的调用并避免污染应用的堆，我们决定放弃该运行时，并在 V8 目前无法运行的操作系统上， 例如 iOS 9，切换到基于 Duktape 的新运行时。我们会在运行时进行特性检测，所以你仍可在 iOS 8 上像以前一样使用 V8—— 除非你按前面所说显式使用 --disable-jit。

最后，以下是变更摘要：

6.1.0：

• core：用基于 Duktape 的后继者替换 JavaScriptCore 运行时
• core：添加 disable_jit()，让用户可以试用新 Duktape 引擎
• core：修复 Linux 上注入进程时的崩溃，该进程中 pthread_create 从未被调用/绑定
• core：添加对 linux-armhf（例如 Raspberry Pi）的支持
• python：向 Session 添加 disable_jit()
• node：向 Session 添加 disableJit()
• CLI 工具：添加 –disable-jit 开关
• frida-repl：升级到最新 prompt-toolkit
• frida-trace：修复尝试跟踪部分解析的导入时的崩溃
• frida-trace：生成的处理器使用 ES5，以兼容 Duktape

6.1.1：

• core：修复 Duktape 运行时中的同步逻辑和错误处理问题

6.1.2：

• core：修复导致注入时崩溃的 Android 回归
• core：修复 Python 3.x 构建回归
• clr：向 Session 添加 DisableJit()

6.1.3：

• core：为 iOS frida-helper 授予 Preferences 应用拥有的所有 entitlement，使系统会话脚本可读写系统配置
• core：为支持临时目录/文件上的 AppContainer ACL 而做出变更
• node：修复 pid 检查，使其允许附加到系统会话

6.1.4：

• core：为 iOS 上的控制台二进制文件实现 spawn()
• core：改进对钩挂低层 OS API 的支持
• core：修复 mapper 问题，该问题阻止我们注入到尚未加载 frida-agent 依赖库的 Mac 进程
• core：让替换后的函数也可以使用 InvocationContext

6.1.5：

• core：在 frida-load 生成的脚本中添加对生成器函数的支持
• frida-repl：修复导致挂起的竞态条件
• frida-repl：修复退出时的伪错误消息

尽情享用！