【讨论】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的方式

[kingsword09]

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

说什么来什么，有deno的人在绑定了 quickjs-ng-rs

[kingsword09]

或者有没有可能用 react native 的 js engine hermes
hermes examples
支持不使用任何框架，而且可以跨平台

[Gaubee]

或者有没有可能用 react native 的 js engine hermes hermes examples 爱马仕的例子 支持不使用任何框架，而且可以跨平台

这种不够存粹，就像v8，它跟chromium会有耦合，同样的，这种不存粹的也会导致和react-native-runtime也有一定耦合。
所以不在考虑范围内

[kingsword09]

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

说什么来什么，有deno的人在绑定了 quickjs-ng-rs

找到一个 rust ffi 绑定 quickjs_rusty

[Gaubee]

有没有可能，我们自己将quickjs迁移到kotlin。这可能是2～4人月的工作量？
以及这个路径的优势劣势也是值得考虑的问题。

[kingsword09]

有没有可能，我们自己将quickjs迁移到kotlin。这可能是2～4人月的工作量？ 以及这个路径的优势劣势也是值得考虑的问题。

如果是自己迁移的话，这里面是不是要涉及到很多C语言和JNI绑定之类的，我们好像没什么经验，而且后期维护的话也是需要考虑的问题

[Gaubee]

有没有可能，我们自己将quickjs迁移到kotlin。这可能是2～4人月的工作量？ 以及这个路径的优势劣势也是值得考虑的问题。

如果是自己迁移的话，这里面是不是要涉及到很多C语言和JNI绑定之类的，我们好像没什么经验，而且后期维护的话也是需要考虑的问题

自己迁移就不用考虑C和JNI的绑定了呀，就是用存粹的kotlin进行重写

[Gaubee]

我做了初步的调研，有几个关键技术点：

1. js-Number 和 Kotlin 的 Double 是同一个标准（好像也是同一个精度），可以直接使用
2. quickjs 的字节码能力是依托于 c 语言的内存特性，这部分在 kotlin 中不可能实现，可以直接砍掉
3. quickjs 的内存管理可以直接使用 kotlin 的 runtime 来做，因此也可以直接砍掉
4. Atomics 的实现上，quickjs 使用的是 c 的 stdatomic，在 kotlin 中，需要用 kotlinx.atomicfu 来模拟实现 SharedArrayBuffer 和 Atomcis 接口，也就是用 mutex-lock 来实现对 SharedArrayBuffer 的操作。
5. js 的 FinalizationRegistry 实现会比较麻烦，JVM 上需要用 ReferenceQueue 来实现，IOS 上需要用 deinit 函数来实现
6. js 的 Regexp，可以直接使用 kotlin 的 Regex 来实现，因为 Quickjs 也是自己实现的功能子集，也不完善，这部分只能说尽量通过 test262 即可
7. js 的 bigint，quickjs 的 bigfloat，可以用 kotlin-multiplatform-bignum

QuickJS 源码有 55000 行左右，我们需要进行移植的主要代码部分是 JsParser（18438L~19287L），其它都可以自己写。
起点函数是： js_parse_program

参考源码：quickjs-ng/quickjs#c53a0a

[kingsword09]

有没有可能，我们自己将quickjs迁移到kotlin。这可能是2～4人月的工作量？ 以及这个路径的优势劣势也是值得考虑的问题。

如果是自己迁移的话，这里面是不是要涉及到很多C语言和JNI绑定之类的，我们好像没什么经验，而且后期维护的话也是需要考虑的问题

自己迁移就不用考虑C和JNI的绑定了呀，就是用存粹的kotlin进行重写

我以为是自己绑定到kotlin，原来是用kotlin翻译过来😂

[kingsword09]

5. js 的 FinalizationRegistry 实现会比较麻烦，JVM 上需要用 ReferenceQueue 来实现，IOS 上需要用 deinit 函数来实现

react native 的 js runtime hermes的FinalizationRegistry也还没实现

[Gaubee]

react native 的 js runtime hermes的FinalizationRegistry也还没实现

在jrpc中，这个功能有一定的意义，长远来说，如果未来要在云上运行，如果基于kotlin-native的js-runtime性能足够好（理论上可以编译成kotlin代码），那么就有实现的意义