跨语言通信——起点

现代app一定会涉及到大量的跨语言通信。常见的包括JNI、js bridge等，不常见的有flutter channel、lua binding、python binding等。

框架要素

更泛化一些看，网络请求也是一种跨语言通信，gRPC可以作为一个中立的跨语言通信模板来拆解要素。通信主要是方法调用，方法调用可以分解成方法定义/绑定（gRPC部分）和参数传递（pb部分），做的好的体系会有签名校验，可能是运行时、编译时甚至生成（gRPC）。

方法定义

需要在两个语言定义出相同的方法签名，并且告知框架将二者绑定。绑定核心就是个methodSig->method的大map。
绑定常见的方法有：

• 带方法名的回调：如flutter channel。其实是把核心逻辑直接暴露
• 运行时直接支持：如gRPC生成的代码、jni中的JNIEXPORT也算是。是用诸如生成代码、annotation等语言工具把核心逻辑封装了一层。好一些的会把参数传递也一并封装起来
  当然，也有语言会把二者同时暴露出来，比如flutter及pigeon。

参数传递

参数传递首先是取出各语言支持的类型交集，并定义成一个标准的可跨语言序列化反序列化的类型集合。大部分框架会约束至一个很小的集合：T = primitive|String|List<T>|Map<T, T>，受限于primitive在各个语言中并不一致，通常会缩减至js支持的number|boolean，多数会加入byte的支持，少数会稍微拓展一下number。而高级一些的会提供真正的自定义类型，例如pb。
传递部分有两大类：传值和传引用。传值是必然需要的，序列化方式是核心点，gRPC完全依托pb。传引用则比较复杂，一方面需要一套语言层面的interpo方案（jni、jsi、dart::ffi等）；另一方面因为主要大部分通信的根基都是C/C++，涉及到的语言一般都有较为“现代的”gc体系，传引用的方案中如何设计gc监听，保证C指针不泄露是难点。

校验规则

基于客户端难以hotfix的特点，校验是跨语言框架所必须的。这里面最多的还是走生成代码，包括了pigeon、gRPC、JNI等。如果没有使用这些工具，业界常见方案基本是文档。

总结

本文是跨语言通信方案总结的开篇，大概说明了跨语言通信框架的分析要素：

• 方法定义
• 方法绑定
• 参数类型约束
• 自定义类型方案
• 参数序列化方式
• interop
• gc
• 校验

后续会按照上述要素陆续拆解分析luascriptcore、flutter channel&pigeon、dart::ffi、rn turbomodule、gRPC等跨语言通信框架的源码。