【quickhybrid】JS端的项目实现

前言

API实现阶段之JS端的实现，重点描述这个项目的JS端都有些什么内容，是如何实现的。

不一样于通常混合框架的只包含JSBridge部分的前端实现，本框架的前端实现包括JSBridge部分、多平台支持，统一预处理等等。

项目的结构

在最初的版本中，其实整个前端库就只有一个文件，里面只规定着如何实现JSBridge和原生交互部分。可是到最新的版本中，因为功能逐步增长，单一文件难以知足要求和维护，所以重构成了一整个项目。

整个项目基于ES6、Airbnb代码规范，使用gulp + rollup构建，部分重要代码进行了Karma + Mocha单元测试

总体目录结构以下：

quickhybrid
    |- dist             // 发布目录
    |   |- quick.js
    |   |- quick.h5.js
    |- build            // 构建项目的相关代码
    |   |- gulpfile.js
    |   |- rollupbuild.js
    |- src              // 核心源码
    |   |- api          // 各个环境下的api实现 
    |   |   |- h5       // h5下的api
    |   |   |- native   // quick下的api
    |   |- core         // 核心控制
    |   |   |- ...      // 将核心代码切割为多个文件
    |   |- inner        // 内部用到的代码
    |   |- util         // 用到的工具类
    |- test             // 单元测试相关
    |   |- unit         
    |   |   |- karma.xxx.config.js
    |   |- xxx.spec.js
    |   |- ...
复制代码

代码架构

项目代中将核心代码和API实现代码分开，核心代码至关于一个处理引擎，而各个环境下的不一样API实现能够单独挂载（这里是为了方便其它地方组合不一样环境下的API因此才分开的，实际上能够将native和核心代码打包到一块儿）

quick.js
quick.h5.js
quick.native.js
复制代码

这里须要注意，quick.xx环境.js中的代码是基于quick.js核心代码的（譬如里面须要用到一些特色的快速调用底层的方法）

而其中最核心的quick.js代码架构以下

index
    |- os               // 系统判断相关
    |- promise          // promise支持，这里并无从新定义，而是判断环境中是否已经支持来决定是否支持
    |- error            // 统一错误处理
    |- proxy            // API的代理对象，内部对进行统一预处理，如默认参数，promise支持等
    |- jsbridge         // 与native环境下原生交互的桥梁
    |- callinner        // API的默认实现，若是是标准的API，能够不传入runcode，内部默认采用这个实现
    |- defineapi        // API的定义，API多平台支撑的关键，也约定着该如何拓展
    |- callnative       // 定义一个调用通用native环境API的方法，拓展组件API（自定义）时须要这个方法调用
    |- init             // 里面定义config，ready，error的使用
    |- innerUtil        // 给核心文件绑定一些内部工具类，供不一样API实现中使用
复制代码

能够看到，核心代码已经被切割成很小的单元了，虽说最终打包起来总共代码也没有多少，可是为了维护性，简洁性，这种拆分仍是颇有必要的

统一的预处理

在上一篇API多平台的支撑中有提到如何基于Object.defineProperty实现一个支持多平台调用的API，实现起来的API大体是这样子的

Object.defineProperty(apiParent, apiName, {
    configurable: true,
    enumerable: true,
    get: function proxyGetter() {
        // 确保get获得的函数必定是能执行的
        const nameSpaceApi = proxysApis[finalNameSpace];

        // 获得当前是哪个环境，得到对应环境下的代理对象
        return nameSpaceApi[getCurrProxyApiOs(quick.os)] || nameSpaceApi.h5;
    },
    set: function proxySetter() {
        alert('不容许修改quick API');
    },
});

...

quick.extendModule('ui', [{
    namespace: 'alert',
    os: ['h5'],
    defaultParams: {
        message: '',
    },
    runCode(message) {
        alert('h5-' + message);
    },
}]);
复制代码

其中nameSpaceApi.h5的值是api.runCode，也就是说直接执行runCode(...)中的代码

仅仅这样是不够的，咱们须要对调用方法的输入等作统一预处理，所以在这里，咱们基于实际的状况，在此基础上进一步完善，加上统一预处理机制，也就是

const newProxy = new Proxy(api, apiRuncode);

Object.defineProperty(apiParent, apiName, {
    ...
    get: function proxyGetter() {
        ...
        return newProxy.walk();
    }
});
复制代码

咱们将新的运行代码变为一个代理对象Proxy，代理api.runCode，而后在get时返回代理事后的实际方法（.walk()方法表明代理对象内部会进行一次统一的预处理）

代理对象的代码以下

function Proxy(api, callback) {
    this.api = api;
    this.callback = callback;
}

Proxy.prototype.walk = function walk() {
    // 实时获取promise
    const Promise = hybridJs.getPromise();

    // 返回一个闭包函数
    return (...rest) = >{
        let args = rest;

        args[0] = args[0] || {};
        // 默认参数的处理
        if (this.api.defaultParams && (args[0] instanceof Object)) {
            Object.keys(this.api.defaultParams).forEach((item) = >{
                if (args[0][item] === undefined) {
                    args[0][item] = this.api.defaultParams[item];
                }
            });
        }

        // 决定是否使用Promise
        let finallyCallback;

        if (this.callback) {
            // 将this指针修正为proxy内部，方便直接使用一些api关键参数
            finallyCallback = this.callback;
        }

        if (Promise) {
            return finallyCallback && new Promise((resolve, reject) = >{
                // 拓展 args
                args = args.concat([resolve, reject]);
                finallyCallback.apply(this, args);
            });
        }

        return finallyCallback && finallyCallback.apply(this, args);
    };
};
复制代码

从源码中能够看到，这个代理对象统一预处理了两件事情：

• 1.对于合法的输入参数，进行默认参数的匹配

• 2.若是环境中支持Promise，那么返回Promise对象而且参数的最后加上resolve，reject

并且，后续若是有新的统一预处理（调用API前的预处理），只需在这个代理对象的这个方法中增长便可

JSBridge解析规则

前面的文章中有提到JSBridge的实现，但那时其实更多的是关注原理层面，那么实际上，定义的交互解析规则是什么样的呢？以下

// 以ui.toast实际调用的示例
// `${CUSTOM_PROTOCOL_SCHEME}://${module}:${callbackId}/${method}?${params}`
const uri = 'QuickHybridJSBridge://ui:9527/toast?{"message":"hello"}';

if (os.quick) {
    // 依赖于os判断
    if (os.ios) {
        // ios采用
        window.webkit.messageHandlers.WKWebViewJavascriptBridge.postMessage(uri);
    } else {
        window.top.prompt(uri, '');
    }
} else {
    // 浏览器
    warn(`浏览器中jsbridge无效, 对应scheme: ${uri}`);
}
复制代码

原生容器中接收到对于的uri后反解析便可知道调用了些什么，上述中：

• QuickHybridJSBridge是本框架交互的scheme标识

• module和method分别表明API的模块名和方法名

• params是对于方法传递的额外参数，原生容器会解析成JSONObject

• callbackId是本次API调用在H5端的回调id，原生容器执行完后，通知H5时会传递回调id，而后H5端找到对应的回调函数并执行

为何要用uri的方式，由于这种方式能够兼容之前的scheme方式，若是方案切换，变更代价下（自己就是这样升级上来的，因此没有替换的必要）

UA约定

混合开发容器中，须要有一个UA标识位来判断当前系统。

这里Android和iOS原生容器统一在webview中加上以下UA标识（也就是说，若是容器UA中有这个标识位，就表明是quick环境-这也是os判断的实现原理）

String ua = webview.getSettings().getUserAgentString();

ua += " QuickHybridJs/" + getVersion();

// 设置浏览器UA,JS端经过UA判断是否属于quick环境
webview.getSettings().setUserAgentString(ua);
复制代码

// 获取默认UA
NSString *defaultUA = [[UIWebView new] stringByEvaluatingJavaScriptFromString:@"navigator.userAgent"];
        
NSString *version = [[NSBundle mainBundle].infoDictionary objectForKey:@"CFBundleShortVersionString"];
        
NSString *customerUA = [defaultUA stringByAppendingString:[NSString stringWithFormat:@" QuickHybridJs/%@", version]];
        
[[NSUserDefaults standardUserDefaults] registerDefaults:@{@"UserAgent":customerUA}];
        
复制代码

如上述代码中分别在Android和iOS容器的UA中添加关键性的标识位。

API内部作了些什么

API内部只作与自己功能逻辑相关的操做，这里有几个示例

quick.extendModule('ui', [{
    namespace: 'toast',
    os: ['h5'],
    defaultParams: {
        message: '',
    },
    runCode(...rest) {
        // 兼容字符串形式
        const args = innerUtil.compatibleStringParamsToObject.call(this, rest, 'message', );
        const options = args[0];
        const resolve = args[1];
        
        // 实际的toast实现
        toast(options);
        options.success && options.success();
        resolve && resolve();
    },
}, ...]);
复制代码

quick.extendModule('ui', [{
    namespace: 'toast',
    os: ['quick'],
    defaultParams: {
        message: '',
    },
    runCode(...rest) {
        // 兼容字符串形式
        const args = innerUtil.compatibleStringParamsToObject.call(this, rest, 'message');

        quick.callInner.apply(this, args);
    },
}, ...]);
复制代码

以上是toast功能在h5和quick环境下的实现，其中，在quick环境下惟一作的就是兼容了一个字符串形式的调用，在h5环境下则是彻底的实现了h5下对应的功能（promise也需自行兼容）

为何h5中更复杂？由于quick环境中，只须要拼凑成一个JSBridge命令发送给原生便可，具体功能由原生实现，而h5的实现是须要本身彻底实现的。

另外，其实在quick环境中，上述还不是最少的代码（上述加了一个兼容调用功能，因此多了几行），最少代码以下

quick.extendModule('ui', [{
    namespace: 'confirm',
    os: ['quick'],
    defaultParams: {
        title: '',
        message: '',
        buttonLabels: ['取消', '肯定'],
    },
}, ...]);
复制代码

能够看到，只要是符合标准的API定义，在quick环境下的实现只须要定义些默认参数就能够了，其它的框架自动帮助实现了（一样promise的实现也在内部默认处理掉了）

这样以来，就算是标准quick环境下的API数量多，实际上增长的代码也并很少。

关于代码规范与单元测试

项目中采用的Airbnb代码规范并非100%契合原版，而是基于项目的状况定制了下，可是整体上95%以上是符合的

还有一块就是单元测试，这是很容易忽视的一块，可是也挺难作好的。这个项目中，基于Karma + Mocha进行单元测试，并且并非测试驱动，而是在肯定好内容后，对核心部分的代码都进行单测。 内部对于API的调用基本都是靠JS来模拟，对于一些特殊的方法，还需Object.defineProperty(window.navigator, name, prop)来改变window自己的属性来模拟。 本项目中的核心代码已经达到了100%的代码覆盖率。

具体的代码这里不赘述，能够参考源码

返回根目录

• 【quickhybrid】如何实现一个Hybrid框架

源码

github上这个框架的实现

quickhybrid/quickhybrid