Hybrid APP架构设计思路

Posted 2020-08-19 xhmj12

原文：Hybrid APP架构设计思路

关于Hybrid模式开发app的好处，网络上已有很多文章阐述了，这里不展开。

本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考。

通讯

作为一种跨语言开发模式，通讯层是Hybrid架构首先应该考虑和设计的，往后所有的逻辑都是基于通讯层展开。

Native（以android为例）和H5通讯，基本原理：

•                               Android调用H5：通过webview类的loadUrl方法可以直接执行js代码，类似浏览器地址栏输入一段js一样的效果

webview.loadUrl("javascript: alert('hello world')");

•                               H5调用Android：webview可以拦截H5发起的任意url请求，webview通过约定的规则对拦截到的url进行处理（消费），即可实现H5调用Android

•                                      var ifm = document.createElement('iframe');

ifm.src = 'jsbridge://namespace.method?[...args]';

JSBridge即我们通常说的桥协议，基本的通讯原理很简单，接下来就是桥协议具体实现。

P.S：注册私有协议的做法很常见，我们经常遇到的在网页里拉起一个系统app就是采用私有协议实现的。app在安装完成之后会注册私有协议到OS，浏览器发现自身不能识别的协议（http、https、file等）时，会将链接抛给OS，OS会寻找可识别此协议的app并用该app处理链接。比如在网页里以itunes://开头的链接是Apple Store的私有协议，点击后可以启动Apple Store并且跳转到相应的界面。国内软件开发商也经常这么做，比如支付宝的私有协议alipay://，腾讯的tencent://等等。

桥协议的具体实现

由于JavaScript语言自身的特殊性（单进程），为了不阻塞主进程并且保证H5调用的有序性，与Native通讯时对于需要获取结果的接口（GET类），采用类似于JSONP的设计理念:

类比HTTP的request和response对象，调用方会将调用的api、参数、以及请求签名（由调用方生成）带上传给被调用方，被调用方处理完之后会吧结果以及请求签名回传调用方，调用方再根据请求签名找到本次请求对应的回调函数并执行，至此完成了一次通讯闭环。

H5调用Native（以Android为例）示意图：

Native（以Android为例）调用H5示意图：

基于桥协议的api设计（HybridApi）

jsbridge作为一种通用私有协议，一般会在团队级或者公司级产品进行共享，所以需要和业务层进行解耦，将jsbridge的内部细节进行封装，对外暴露平台级的API。

以下是笔者剥离公司业务代码后抽象出的一份HybridApi js部分的实现，项目地址：

hybrid-js

另外，对于Native提供的各种接口，也可以简单封装下，使之更贴近前端工程师的使用习惯：

// /lib/jsbridge/core.js

function assignAPI(name, callback) {

    var names = name.split(/\\./);

    var ns = names.shift();

 

    var fnName = names.pop();

    var root = createNamespace(JSBridge[ns], names);

 

    if(fnName) root[fnName] = callback || function() {};

}

增加api：

// /lib/jsbridge/api.js

var assign = require('./core.js').assignAPI;

...

assign('util.compassImage', function(path, callback, quality, width, height) {

    JSBridge.invokeApp('os.getInfo', {

        path: path,

        quality: quality || 80,

        width: width || 'auto',

        height: height || 'auto',

        callback: callback

    });

});

H5上层应用调用：

// h5/music/index.js

JSBridge.util.compassImage('http://cdn.foo.com/images/bar.png', function(r){

    console.log(r.value); // => base64 data

});

界面与交互（Native与H5职责划分）

本质上，Native和H5都能完成界面开发。几乎所有hybrid的开发模式都会碰到同样的一个问题：哪些由Native负责哪些由H5负责？

这个回到原始的问题上来：我们为什么要采用hybrid模式开发？简而言之就是同时利用H5的跨平台、快速迭代能力以及Native的流畅性、系统API调用能力。

根据这个原则，为了充分利用二者的优势，应该尽可能地将app内容使用H5来呈现，而对于js语言本身的缺陷，应该使用Native语言来弥补，如转场动画、多线程作业（密集型任务）、IO性能等。即总的原则是H5提供内容，Native提供容器，在有可能的条件下对Android原生webview进行优化和改造（参考阿里Hybrid容器的JSM），提升H5的渲染效率。

但是，在实际的项目中，将整个app所有界面都使用H5来开发也有不妥之处，根据经验，以下情形还是使用Native界面为好：

关键界面、交互性强的的界面使用Native

因H5比较容易被恶意攻击，对于安全性要求比较高的界面，如注册界面、登陆、支付等界面，会采用Nati