javascript-native调用实现
在现在流行的多元框架中，最常见的就是JavaScript的应用了。这里就来分析下react-native的实现。
react-native并不是只有一种实现。因为他不仅仅支持JavaScriptCore来实现交互，也考虑到了某些场景下需要使用WebView来实现，同时也有很多debug工具，需要将JavaScript的执行环境转移到浏览器。大概的结构如下：
------------------------------
| native |
------------------------------
|
bridge
ⅴ
|------------------------------|
| Executor |
|------------------------------|
| JSContext | WebView | Chrome |
|------------------------------|
其中执行器部分（Executor）可随意替换为不同实现。这里我们来分析下JSContext中的实现。
Module
要实现react-native这样大型的框架，javascript就不能被散乱的放置，那么就必须进行分模块。调用模块时需要使用CommonJS或者ES6的方式。
var module = require('module')
import * as module from 'module'
同时也需要考虑到如此多的模块，一次性载入所带来的性能损耗，就必须采用惰性加载的方式。
队列
和其他项目的实现方式类似，react-native依然使用了message queue来实现通信，而不是JavaScriptCore自带的绑定功能，这是为了兼容上面说的多Executor。
与其他方案不太相同的是，react-native在module，module-method和callback都使用了id: number来取代名字，个人猜测可能是为了性能考虑。
那么我们就JSContext这种情况来说下整个通信实现的过程。
实现
这里使用console来作为例子，这里使用JavaScriptCore的c接口是为了和react-native保持一致，同时忽略了内存问题。
模块表
观察发送给JSContext的数据发现会有很多类似这样的JSON数据：
[
"WebSocketModule",
null,
["connect","send","sendBinary","ping","close","addListener","removeListeners"]
]
可以看出来，[0]表示的是module名字，而[2]表示的是module的方法，正式这一份表，才对应了javascript和native双方的indexId，所有的通信都是对应于这一份表来进行的。
所以双方都会有一份自己维护的模块，而js的模块表我们这里定义为
// id => module 这是native调用js module时，传递的是id
var nativeModuleByIds = {}
// name => module 这是js调用js module时，传递的是name
var nativeModules = {}
载入模块
在javascript端，如果需要载入模块，那么我们会使用
var console = require('console')
那么在JSContext还没有console模块的情况下如何进行初始化呢？这里就需要一个NativeRequire，来载入native模块，结合上面的模块配置表，require的实现如下：
var NativeRequire
function require(moduleName) {
if (nativeModules[moduleName]) {
return nativeModules[moduleName]
}
return NativeRequire(moduleName)
}
NativeRequire
在初始化JSContext时，我们就需要为通信做好连接的准备，直接注入3个方法。(这里react-native其实还有另外一个方式触发require，通过nativeModuleProxy对象的getProperty来触发，这里讨论最原始的require方式)
JSClassDefinition definition = kJSClassDefinitionEmpty;
JSClassRef global = JSClassCreate(&definition);
g_ctx = JSGlobalContextCreate(global);
JSObjectRef globalObj = JSContextGetGlobalObject(g_ctx);
{
JSStringRef name = JSStringCreateWithCFString(CFSTR("NativeRequire"));
JSObjectRef obj = JSObjectMakeFunctionWithCallback(g_ctx, name, NativeRequire);
JSObjectSetProperty(g_ctx, globalObj, name, obj, kJSPropertyAttributeNone, nil);
}
{
JSStringRef name = JSStringCreateWithCFString(CFSTR("NativeFlushQueueSync"));
JSObjectRef obj = JSObjectMakeFunctionWithCallback(g_ctx, name, NativeFlushQueueSync);
JSObjectSetProperty(g_ctx, globalObj, name, obj, kJSPropertyAttributeNone, nil);
}
{
JSStringRef name = JSStringCreateWithCFString(CFSTR("NativeFlushQueueAsync"));
JSObjectRef obj = JSObjectMakeFunctionWithCallback(g_ctx, name, NativeFlushQueueAsync);
JSObjectSetProperty(g_ctx, globalObj, name, obj, kJSPropertyAttributeNone, nil);
}
关于NativeFlushQueueSync和NativeFlushQueueAsync到下面再解释。
这里native的模块表就不实现了，直接使用["console", null, ["log", "getName"], [1]]。
JSValueRef NativeRequire (
JSContextRef ctx,
JSObjectRef function,
JSObjectRef thisObject,
size_t argumentCount,
const JSValueRef arguments[],
JSValueRef *exception) {
if (argumentCount == 1) {
JSValueRef jsModuleName = arguments[0];
if (JSValueIsString(g_ctx, jsModuleName)) {
char buffer[128] = {0};
JSStringGetUTF8CString(JSValueToStringCopy(g_ctx, jsModuleName, nil), buffer, 128);
// 0. 当js调用"NativeRequire('console')"的时候
// 1. 我们会在本地的模块表里根据名字去查找
// 这里就简单的strcmp来表示
if (strcmp(buffer, "console") == 0) {
CFStringRef config = CFSTR("[\"console\", null, [\"log\", \"getName\"], [1]]");
// 2. 构造js对应的模块表，这里的顺序必须和native是一一对应的
// [ moduleName, constants, methods, async indexes ]
JSValueRef jsonConfig = JSValueMakeFromJSONString(g_ctx, JSStringCreateWithCFString(config));
JSObjectRef global = JSContextGetGlobalObject(g_ctx);
JSValueRef genNativeModules = JSObjectGetProperty(g_ctx, global, JSStringCreateWithCFString(CFSTR("genNativeModules")), nil);
JSValueRef args[] = {JSValueMakeNumber(g_ctx, ConsoleModuleId), jsonConfig};
// call JS => genNativeModules(moduleId, config)
// 3. 调用js，初始化native模块，将函数表中的string转换为function实现
// 这里接下节
JSValueRef module = JSObjectCallAsFunction(g_ctx, JSValueToObject(g_ctx, genNativeModules, nil), global, 2, args, nil);
return module;
}
}
}
return JSValueMakeNull(g_ctx);
}
这里会同步调用初始化模块方法，并且将模块返回给JSContext。
但是可以发现模块表中的方法都是string，也就是方法名，我们如何去使用console.log()这样的方法呢？这里就需要中间的初始化模块这个作用了。
初始化模块
回到上节的第三步，此时native传给js一个模块表，让js去构造这个模块。让我们回到js：
function genNativeModules(moduleId, config) {
let [name, constants, methods, asyncs] = config
let module = {}
// 这里将所有的方法名都转换为function
methods.forEach(function(method, methodId) {
module[method] = function (args) {
// call native flush
}
}, this);
nativeModules[name] = module
nativeModuleByIds[moduleId] = module
return module
}
这样便把string转换为function了，可以像正常的js方法那样使用了。
到这里注册js模块已经完成，下面来说说调用的过程。
同步方法的调用
同步方法的调用对于JSContext来说会简单很多，而对于很多基于webview的实现来说就会麻烦一些，因为参数不能直接编码在url中，最后我们来讨论下这个问题。
上节说到将方法名转换为function，那么function具体实现是怎么样的呢？
首先来看看同步方法的实现：
module[method] = function (args) {
return NativeFlushQueueSync(moduleId, methodId, ...args)
}
这里的NativeFlushQueueSync方法就是一开始我们注入的方法，作用是执行对应模块的对应方法。
JSValueRef NativeFlushQueueSync (
JSContextRef ctx,
JSObjectRef function,
JSObjectRef thisObject,
size_t argumentCount,
const JSValueRef arguments[],
JSValueRef *exception) {
if (argumentCount == 3) {
// 这里通过查找native的模块表，查找到对应的方法，并执行
if (JSValueIsNumber(g_ctx, arguments[0]) && JSValueIsNumber(g_ctx, arguments[1])) {
if (JSValueToNumber(g_ctx, arguments[0], nil) == ConsoleModuleId) {
if (JSValueToNumber(g_ctx, arguments[1], nil) == 0) {
// call Native <= console.log
if (JSValueIsString(g_ctx, arguments[2])) {
// console.log转换为NSLog
NSString *str = (__bridge NSString *)JSStringCopyCFString(NULL, JSValueToStringCopy(g_ctx, arguments[2], nil));
NSLog(@"%@", str);
}
}
}
}
}
return JSValueMakeNull(g_ctx);
}
然而react-native并没有完全严格上的同步执行方法。因为很多调用UI层的功能必须在主线程上，而JSContext是在自己的线程中执行，所以如果需要严格的同步执行，需要阻塞JS线程。而几乎所有功能都是不需要执行结果的（return void），所以只要触发native去执行该方法就行了，无需等待执行完再返回。而需要有返回值的接口都被设计成异步的了。
异步回调
说到异步回调，大家用的方案好像都是一样的，那就是callbackId。
var messageQueue = {}
var messageQueueId = 0
function JsMessageQueueAdd(args) {
messageQueueId ++
messageQueue[messageQueueId] = args
return messageQueueId
}
function JsMessageQueueFlush(queueId, args) {
let callback = messageQueue[queueId]
if (callback && typeof(callback) === 'function') {
callback(args)
}
}
创建异步module方法的方式会有点不一样：
module[method] = function (args) {
let queueId = JsMessageQueueAdd(args)
NativeFlushQueueAsync(moduleId, methodId, queueId)
}
然后来看看native的实现：
JSValueRef NativeFlushQueueAsync (
JSContextRef ctx,
JSObjectRef function,
JSObjectRef thisObject,
size_t argumentCount,
const JSValueRef arguments[],
JSValueRef *exception) {
if (argumentCount == 3) {
if (JSValueIsNumber(g_ctx, arguments[0]) && JSValueIsNumber(g_ctx, arguments[1])) {
if (JSValueToNumber(g_ctx, arguments[0], nil) == ConsoleModuleId) {
if (JSValueToNumber(g_ctx, arguments[1], nil) == 1) {
// call Native <= console.getName
JSValueRef queueId = arguments[2];
NSInteger queueIdCopy = JSValueToNumber(g_ctx, queueId, nil);
dispatch_async(dispatch_get_main_queue(), ^{
JSObjectRef global = JSContextGetGlobalObject(g_ctx);
JSValueRef flush = JSObjectGetProperty(g_ctx, global, JSStringCreateWithCFString(CFSTR("JsMessageQueueFlush")), nil);
JSValueRef args[] = {
JSValueMakeNumber(g_ctx, queueIdCopy), // callback queueId
JSValueMakeString(g_ctx, JSStringCreateWithCFString(CFSTR("My iPhone")))
};
// call JS => JsMessageQueueFlush(queueId, args)
JSObjectCallAsFunction(g_ctx, JSValueToObject(g_ctx, flush, nil), nil, 2, args, nil);
});
}
}
}
}
return JSValueMakeNull(g_ctx);
}
可以看到和同步方式的区别是就是回调会缓存在队列里。
应用
var console = require('console')
console.log('Hello Javascript!')
console.getName(function (name) {
console.log(`Hello ${name}`)
})
// output:
Hello Javascript!
Hello My iPhone
装饰
实际情况不会这么简单，js也不会直接使用native提供的模块的，一般会包装一层。比如像这样
var nativeLog = NativeRequire('NSLog')
var console = {
log: (args) => NSLog(args),
info: (args) => NSLog('[INFO]', ...args),
error: (args) => NSLog('[ERROR]', ...args)
}
export default console
实际
真实情况不会像上面那么简单，需要考虑到多线程，每个module的运行线程，js消息队列等保证js的安全顺序执行。
WebView
其他项目的方案也是类似的，但也有少许的不同。
比如NativeRequire，在Web里面除了通过iframe来实现，还可以通过script标签来导入模块文件。
var script = document.createElement('script')
script.setAttribute('src', 'file://module.js')
document.head.appendChild(script)
同时由于web通过url传递参数的限制，所以web的参数传递是通过native去主动拉取的。大概的流程如下：
[web] call native --> push <call info> --(iframe url)-->
[native] get <call info> --(executeJs)-->
[web] pop <call info> -->
[native] call ***
同时很多方案，会使用名字来传递模块和方法，这样做最简单也最直接。但是如果存在频繁交互的过程可能会降低性能。
最后
总的来说，javascript-native交互还是挺简单的，只要在初始的设计上比较符合现在与未来的发展，还是可以做到很灵活的。至于使用哪种方案，做到什么样的程度，可以依据自身的需求来判断。
