【讨论】js.browser.dweb 升级内核引擎

[Gaubee]

该提案主要目的是解决当下IOS平台上，js-process与native的通讯性能低下的问题。

可选技术方案：

• javascriptCode
  • 优点：高性能？

    这是我自己自以为是的觉得，但是我和chatgpt一再确认过，它觉得即便有jit加速，在移动端也不如quickjs快。这点需要具体的测试才能有结论

  • 优点：支持wasm
  • 优点：开箱即用，体积小
  • 缺点：不支持esmodule
  • 缺点：ios-only

    在 android 上使用 javascriptEngine； 在 desktop/jxbrowser 上没有开箱即用的类似功能 但目前在 android 和 desktop/jxbrowser 上，因为底层的支持良好，所以性能问题不大，不大需要考虑迁移。 但是要考虑一致性的问题，因此以下基于quickjs的方案可能是更好？

• quickjs
  • 优点：跨平台一致性
  • 优点：一流的esmodule支持
  • 优点：一流的异步支持（Kotlin Coroutines）
  • 缺点：性能一般？

    存疑，待验证

[kingsword09]

如果还要加上HarmonyOS的话，这两个方案好像也只能考虑 quickjs 了吧。 HarmonyOS好像也是用的iOS 那套使用postMessage的方式来通讯

[Gaubee]

如果还要加上HarmonyOS的话，这两个方案好像也只能考虑 quickjs 了吧。 HarmonyOS好像也是用的iOS 那套使用postMessage的方式来通讯

HarmonyOS 的 WebView 有 WebMessagePort。那就意味着能跟 web-worker 直接通讯，所以性能也能跟 android 是同个级别的。

[Gaubee]

使用非webview引擎的话，需要额外开发一个调试器或者适配标准调试协议。 quickjs的话，应该有人给它做了调试能力吧？

[kingsword09]

使用非webview引擎的话，需要额外开发一个调试器或者适配标准调试协议。 quickjs的话，应该有人给它做了调试能力吧？

是不是可以使用 Meta 开发的 flipper

[kingsword09]

之前说过的那个 webf 他们好像使用的微软的 DAP 来做的：Debugger Design，里面用了这个vscode-js-debug

[kingsword09]

这个升级是不是还是没法改变iOS只能使用 webkit.messageHandlers 来传递 js -> native 消息，如果是这样，好像iOS效率还是很难提升

[Gaubee]

这个升级是不是还是没法改变iOS只能使用 webkit.messageHandlers 来传递 js -> native 消息，如果是这样，好像iOS效率还是很难提升

用quickjs可以解决这个问题呀。

我刚才试用了 quickjs-kt ，感觉不大好用，它暴露出来的接口不完善，只能满足一些简单的需求，或者需要有一些妥协。

比方说我想在 Set.prototype 上扩展原生对象，quickjs-c 是可以有原生的接口做到的：在native侧有对应的 JSObject 可以直接操作属性。 但是在 quickjs-kt 上，只能先定义一个全局函数，然后通过js代码来讲这个函数绑定到 JSObject上。而且这个函数的参数和返回值都是有限制的，因为它的互操作性是依靠序列化反序列化，会有大量的性能损失。

所以可能得用rust库来解决需求，比如 rquickjs 但是我们还未用rust库与kotlin之间做非常频繁的互操作、内存交换，不确定会有什么问题。

[kingsword09]

这些绑定的quickjs都不是最新的了，现在最新的quickjs仓库地址

[kingsword09]

没看到有rust相关的绑定来绑定这个最新的quickjs，基本上大家绑定的都还是原先的那个，这个新的是quickjs的重新出发，看readme说会合并这两个

[Gaubee]

所以对于quickjs，我们直接面向c来做编程可能是最好的？（理论上可以用上ziglang ）

[kingsword09]

所以对于quickjs，我们直接面向c来做编程可能是最好的？（理论上可以用上ziglang ）

如果是在kotlin中使用，还有一种以前用过的方案，但是应该是要写一些C的代码，就是cklib，可以用于kotlin native，jvm Target的就要使用jni了吧，或者使用JDK17开始实验性支持，23稳定的FFM的方式