浅谈Hybrid技术的设计与实现第三弹——落地篇

2016/10/25 · 基础技术 · Hybrid

原文出处： 叶小钗（@欲苍穹）   

根据之前的介绍，大家对前端与Native的交互应该有一些简单的认识了，很多朋友就会觉得这个交互很简单嘛，其实并不难嘛，事实上单从Native与前端的交互来说就那点东西，真心没有太多可说的，但要真正做一个完整的Hybrid项目却不容易，要考虑的东西就比较多了，单从这个交互协议就有：

① URL Schema

② JavaScriptCore

两种，到底选择哪种方式，每种方式有什么优势，都是我们需要深度挖掘的，而除此之外，一个Hybrid项目还应该具有以下特性：

① 扩展性好——依靠好的约定

② 开发效率高——依赖公共业务

③ 交互体验好——需要解决各种兼容问题

我们在实际工作中如何落地一个Hybrid项目，如何推动一个项目的进行，这是本次我们要讨论的，也希望对各位有用。

文中是我个人的一些开发经验，希望对各位有用，也希望各位多多支持讨论，指出文中不足以及提出您的一些建议。

设计类博客

iOS博客

Android博客

代码地址：

因为IOS不能扫码下载了，大家自己下载下来用模拟器看吧，下面开始今天的内容。

总体概述在第一章，有兴趣大家去看

细节设计在第二章，有兴趣大家去看

本章主要为打补丁

浅谈Hybrid技术的设计与实现

2015/11/05 · 基础技术 · Hybrid

原文出处： 叶小钗（@欲苍穹）   

边界问题

在我们使用Hybrid技术前要注意一个边界问题，什么项目适合Hybrid什么项目不适合，这个要搞清楚，适合Hybrid的项目为：

① 有60%以上的业务为H5

② 对更新（开发效率）有一定要求的APP

不适合使用Hybrid技术的项目有以下特点：

① 只有20%不到的业务使用H5做

② 交互效果要求较高（动画多）

任何技术都有适用的场景，千万不要妄想推翻已有APP的业务用H5去替代，最后会证明那是自讨苦吃，当然如果仅仅想在APP里面嵌入新的实验性业务，这个是没问题的。

前言

随着移动浪潮的兴起，各种APP层出不穷，极速的业务扩展提升了团队对开发效率的要求，这个时候使用IOS&Andriod开发一个APP似乎成本有点过高了，而H5的低成本、高效率、跨平台等特性马上被利用起来形成了一种新的开发模式：Hybrid APP。

作为一种混合开发的模式，Hybrid APP底层依赖于Native提供的容器（UIWebview），上层使用Html&Css&JS做业务开发，底层透明化、上层多多样化，这种场景非常有利于前端介入，非常适合业务快速迭代，于是Hybrid火啦。

本来我觉得这种开发模式既然大家都知道了，那么Hybrid就没有什么探讨的价值了，但令我诧异的是依旧有很多人对Hybrid这种模式感到陌生，这种情况在二线城市很常见，所以我这里尝试从另一个方面向各位介绍Hybrid，期望对各位正确的技术选型有所帮助。

Hybrid发家史

最初携程的应用全部是Native的，H5站点只占其流量很小的一部分，当时Native有200人红红火火，而H5开仅有5人左右在打酱油，后面无线团队来了一个执行力十分强的服务器端出身的leader，他为了了解前端开发，居然亲手使用jQuery Mobile开发了第一版程序，虽然很快方案便被推翻，但是H5团队开始发力，在短时间内已经赶上了Native的业务进度：

突然有一天andriod同事跑过来告诉我们andriod中有一个方法最大树限制，可能一些页面需要我们内嵌H5的页面，于是Native与H5框架团队牵头做了第一个Hybrid项目，携程第一次出现了一套代码兼容三端的情况。这个开发效率杠杠的，团队尝到了甜头，于是乎后续的频道基本都开始了Hybrid开发，到我离开时，整个机制已经十分成熟了，而前端也有几百人了。

场景重现

狼厂有三大大流量APP，手机百度、百度地图、糯米APP，最近接入糯米的时候，发现他们也在做Hybrid平台化相关的推广，将静态资源打包至Native中，Native提供js调用原生应用的能力，从产品化和工程化来说做的很不错，但是有两个瑕疵：

① 资源全部打包至Naive中APP尺寸会增大，就算以增量机制也避免不了APP的膨胀，因为现在接入的频道较少一个频道500K没有感觉，一旦平台化后主APP尺寸会急剧增大

② 糯米前端框架团队封装了Native端的能力，但是没有提供配套的前端框架，这个解决方案是不完整的。很多业务已经有H5站点了，为了接入还得单独开发一套程序；而就算是新业务接入，又会面临嵌入资源必须是静态资源的限制，做出来的项目没有SEO，如果关注SEO的话还是需要再开发，从工程角度来说是有问题的。

但从产品可接入度与产品化来说，糯米Hybrid化的大方向是很乐观的，也确实取得了一些成绩，在短时间就有很多频道接入了，随着推广进行，明年可能会形成一个大型的Hybrid平台。但是因为我也经历过推广框架，当听到他们忽悠我说性能会提高70%，与Native体验基本一致时，不知为何我居然笑了……

总结

如果读了上面几个故事你依旧不知道为何要使用Hybrid技术的话，我这里再做一个总结吧：

JavaScript

Hybrid开发效率高、跨平台、底层本 Hybrid从业务开发上讲，没有版本问题，有BUG能及时修复

Hybrid是有缺点的，Hybrid体验就肯定比不上Native，所以使用有其场景，但是对于需要快速试错、快速占领市场的团队来说，Hybrid一定是不二的选择，团队生存下来后还是需要做体验更好的原生APP。

好了，上面扯了那么多没用的东西，今天的目的其实是为大家介绍Hybrid的一些设计知识，如果你认真阅读此文，可能在以下方面对你有所帮助：

① Hybrid中Native与前端各自的工作是什么

② Hybrid的交互接口如何设计

③ Hybrid的Header如何设计

④ Hybrid的如何设计目录结构以及增量机制如何实现

⑤ 资源缓存策略，白屏问题……

文中是我个人的一些开发经验，希望对各位有用，也希望各位多多支持讨论，指出文中不足威尼斯澳门在线 ，以及提出您的一些建议。

然后文中Andriod相关代码由我的同事明月提供，这里特别感谢明月同学对我的支持，这里扫描二维码可以下载APP进行测试：

Andriod APP二维码：

代码地址：

交互约定

根据之前的学习，我们知道与Native交互有两种交互：

① URL Schema

② JavaScriptCore

而两种方式在使用上各有利弊，首先来说URL Schema是比较稳定而成熟的，如果使用上文中提到的“ajax”交互方式，会比较灵活；而从设计的角度来说JavaScriptCore似乎更加合理，但是我们在实际使用中却发现，注入的时机得不到保障。

iOS同事在实体JavaScriptCore注入时，我们的原意是在webview载入前就注入所有的Native能力，而实际情况是页面js已经执行完了才被注入，这里会导致Hybrid交互失效，如果你看到某个Hybrid平台，突然header显示不正确了，就可能是这个问题导致，所以JavaScriptCore就被我们弃用了。

JavaScript

JavaScriptCore可能导致的问题： ① 注入时机不唯一（也许是BUG） ② 刷新页面的时候，JavaScriptCore的注入在不同机型表现不一致，有些就根本不注入了，所以全部hybrid交互失效

如果非要使用JavaScriptCore，为了解决这一问题，我们做了一个兼容，用URL Schema的方式，在页面逻辑载入之初执行一个命令，将native的一些方式重新载入，比如：

JavaScript

_.requestHybrid({ tagname: 'injection' });

这个能解决一些问题，但是有些初始化就马上要用到的方法可能就无力了，比如：

① 想要获取native给予的地理信息

② 想要获取native给予的用户信息（直接以变量的方式获取）

作为生产来讲，我们还是求稳，所以最终选择了URL Schema。

明白了基本的边界问题，选取了底层的交互方式，就可以开始进行初步的Hybrid设计了，但是这离一个可用于生产，可离落地的Hybrid方案还比较远。

Native与前端分工

在做Hybrid架构设计之前需要分清Native与前端的界限，首先Native提供的是一宿主环境，要合理的利用Native提供的能力，要实现通用的Hybrid平台架构，站在前端视角，我认为需要考虑以下核心设计问题。

交互设计

Hybrid架构设计第一个要考虑的问题是如何设计与前端的交互，如果这块设计的不好会对后续开发、前端框架维护造成深远的影响，并且这种影响往往是不可逆的，所以这里需要前端与Native好好配合，提供通用的接口，比如：

① NativeUI组件，header组件、消息类组件

② 通讯录、系统、设备信息读取接口

③ H5与Native的互相跳转，比如H5如何跳到一个Native页面，H5如何新开Webview做动画跳到另一个H5页面

资源访问机制

Native首先需要考虑如何访问H5资源，做到既能以file的方式访问Native内部资源，又能使用url的方式访问线上资源；需要提供前端资源增量替换机制，以摆脱APP迭代发版问题，避免用户升级APP。这里就会涉及到静态资源在APP中的存放策略，更新策略的设计，复杂的话还会涉及到服务器端的支持。

账号信息设计

账号系统是重要并且无法避免的，Native需要设计良好安全的身份验证机制，保证这块对业务开发者足够透明，打通账户信息。

Hybrid开发调试

功能设计完并不是结束，Native与前端需要商量出一套可开发调试的模型，不然很多业务开发的工作将难以继续，这个很多文章已经接受过了，本文不赘述。

至于Native还会关注的一些通讯设计、并发设计、异常处理、日志监控以及安全模块因为不是我涉及的领域便不予关注了（事实上是想关注不得其门），而前端要做的事情就是封装Native提供的各种能力，整体架构是这样的：

真实业务开发时，Native除了会关注登录模块之外还会封装支付等重要模块，这里视业务而定。

账号体系

一般来说，一个公司的账号体系健壮灵活程度会很大程度反映出这个研发团队的整体实力：

① 统一的鉴权认证

② 短信服务图形验证码的处理

③ 子系统的权限设计、公共的用户信息导出

④ 第三方接入方案

⑤ 接入文档输出

⑥ ……

这个技术方案，有没有是一回事（说明没思维），有几套是一回事（说明比较乱，技术不统一），对外的一套做到了什么程度又是一回事，当然这个不是我们讨论的重点，而账号体系也是Hybrid设计中不可或缺的一环。

账号体系涉及了接口权限控制、资源访问控制，现在有一种方案是，前端代码不做接口鉴权，账号一块的工作全部放到native端。

Hybrid交互设计

Hybrid的交互无非是Native调用前端页面的JS方法，或者前端页面通过JS调用Native提供的接口，两者交互的桥梁皆Webview：

app自身可以自定义url schema，并且把自定义的url注册在调度中心， 例如

• ctrip://wireless 打开携程App
• weixin:// 打开微信

我们JS与Native通信一般就是创建这类URL被Native捕获处理，后续也出现了其它前端调用Native的方式，但可以做底层封装使其透明化，所以重点以及是如何进行前端与Native的交互设计。

native代理请求

在H5想要做某一块老的App业务，这个APP80%以上的业务都是Native做的，这类APP在接口方面就没有考虑过H5的感受，会要求很多信息如：

① 设备号

② 地理信息

③ 网络情况

④ 系统版本

有很多H5拿不到或者不容易拿到的公共信息，因为H5做的往往是一些比较小的业务，像什么个人主页之类的不重要的业务，Server端可能不愿意提供额外的接口适配，而使用额外的接口还有可能打破他们统一的某些规则；加之native对接口有自己的一套公共处理逻辑，所以便出了Native代理H5发请求的方案，公共参数会由Native自动带上。

JavaScript

//暂时只关注hybrid调试,后续得关注三端匹配 _.requestHybrid({ tagname: 'apppost', param: { url: this.url, param: params }, callback: function (data) { scope.baseDataValidate(data, onComplete, onError); } });

这种方案有一些好处，接口统一，前端也不需要关注接口权限验证，但是这个会带给前端噩梦！

前端相对于native一个很大的优点，就是调试灵活，这种代理请求的方式，会限制请求只能在APP容器中生效，对前端调试造成了很大的痛苦

从真实的生产效果来说，也是很影响效率的，容易导致后续前端再也不愿意做那个APP的业务了，所以使用要慎重……

JS to Native

Native在每个版本会提供一些API，前端会有一个对应的框架团队对其进行封装，释放业务接口。比如糯米对外的接口是这样的：

JavaScript

BNJS.http.get()；//向业务服务器拿请求据【1.0】 1.3版本接口有扩展 BNJS.http.post()；//向业务服务器提交数据【1.0】 BNJS.http.sign()；//计算签名【1.0】 BNJS.http.getNA()；//向NA服务器拿请求据【1.0】 1.3版本接口有扩展 BNJS.http.postNA()；//向NA服务器提交数据【1.0】 BNJS.http.getCatgData()；//从Native本地获取筛选数据【1.1】

JavaScript

BNJSReady(function(){ BNJS.http.post({ url : '', params : { msg : '测试post', contact : '18721687903' }, onSuccess : function(res){ alert('发送post请求成功！'); }, onFail : function(res){ alert('发送post请求失败！'); } }); });

前端框架定义了一个全局变量BNJS作为Native与前端交互的对象，只要引入了糯米提供的这个JS库，并且在糯米封装的Webview容器中，前端便获得了调用Native的能力，我揣测糯米这种设计是因为这样便于第三方团队的接入使用，手机百度有一款轻应用框架也走的这种路线：

JavaScript

clouda.mbaas.account //释放了clouda全局变量

这样做有一个前提是，Native本身已经十分稳定了，很少新增功能了，否则在直连情况下就会面临一个尴尬，因为web站点永远保持最新的，就会在一些低版本容器中调用了没有提供的Native能力而报错。

注入cookie

前端比较通用的权限标志还是用cookie做的，所以Hybrid比较成熟的方案仍旧是注入cookie，这里的一个前提就是native&H5有一套统一的账号体系（统一的权限校验系统）。

因为H5使用的webview可以有独立的登录态，如果不加限制太过混乱难以维护，比如：

我们在qq浏览器中打开携程的网站，携程站内第三方登录可以唤起qq，然后登录成功；完了qq浏览器本来也有一个登录态，发现却没有登录，点击一键登录的时候再次唤起了qq登录。

当然，qq作为一个浏览器容器，不应该关注业务的登录，他这样做是没问题的，但是我们自己的一个H5子应用如果登录了的话，便希望将这个登录态同步到native，这里如果native去监控cookie的变化就太复杂了，通用的方案是：

Hybrid APP中，所有的登录走Native提供的登录框

每次打开webview native便将当前登录信息写入cookie中，由此前端就具有登录态了，登录框的唤起在接口处统一处理：

JavaScript

/* 无论成功与否皆会关闭登录框 参数包括： success 登录成功的回调 error 登录失败的回调 url 如果没有设置success，或者success执行后没有返回true，则默认跳往此url */ HybridUI.Login = function (opts) { }; //=> requestHybrid({ tagname: 'login', param: { success: function () { }, error: function () { }, url: '...' } }); //与登录接口一致，参数一致 HybridUI.logout = function () { };

API式交互

手白、糯米底层如何做我们无从得知，但我们发现调用Native API接口的方式和我们使用AJAX调用服务器端提供的接口是及其相似的：

这里类似的微薄开放平台的接口是这样定义的：

粉丝服务（新手接入指南）

读取接口

接收消息

接收用户私信、关注、取消关注、@等消息接口

写入接口

发送消息

向用户回复私信消息接口

生成带参数的二维码

生成带参数的二维码接口

我们要做的就是通过一种方式创建ajax请求即可：

JavaScript

所以我在实际设计Hybrid交互模型时，是以接口为单位进行设计的，比如获取通讯录的总体交互是：

账号切换&注销

账户注销本没有什么注意点，但是因为H5 push了一个个webview页面，这个重新登录后这些页面怎么处理是个问题。

我们这边设计的是一旦重新登录或者注销账户，所有的webview都会被pop掉，然后再新开一个页面，就不会存在一些页面展示怪异的问题了。

格式约定

交互的第一步是设计数据格式，这里分为请求数据格式与响应数据格式，参考ajax的请求模型大概是：

$.ajax(options) ⇒ XMLHttpRequest type (默认值："GET") HTTP的请求方法(“GET”, “POST”, or other)。 url (默认值：当前url) 请求的url地址。 data (默认值：none) 请求中包含的数据，对于GET请求来说，这是包含查询字符串的url地址，如果是包含的是object的话，$.param会将其转化成string。

所以我这边与Native约定的请求模型是：

JavaScript

requestHybrid({ //创建一个新的webview对话框窗口 tagname: 'hybridapi', //请求参数，会被Native使用 param: {}, //Native处理成功后回调前端的方法 callback: function (data) { } });

这个方法执行会形成一个URL，比如：

hybridschema://hybridapi?callback=hybrid_1446276509894¶m=%7B%22data1%22%3A1%2C%22data2%22%3A2%7D

这里提一点，APP安装后会在手机上注册一个schema，比如淘宝是taobao://，Native会有一个进程监控Webview发出的所有schema://请求，然后分发到“控制器”hybridapi处理程序，Native控制器处理时会需要param提供的参数（encode过），处理结束后将携带数据获取Webview window对象中的callback（hybrid_1446276509894）调用之

数据返回的格式约定是：

JavaScript

{ data: {}, errno: 0, msg: "success" }

真实的数据在data对象中，如果errno不为0的话，便需要提示msg，这里举个例子如果错误码1代表该接口需要升级app才能使用的话：

JavaScript

{ data: {}, errno: 1, msg: "APP版本过低，请升级APP版本" }

代码实现

这里给一个简单的代码实现，真实代码在APP中会有所变化：

JavaScript

window.Hybrid = window.Hybrid || {}; var bridgePostMsg = function (url) { if ($.os.ios) { window.location = url; } else { var ifr = $('<iframe style="display: none;" src="' + url + '"/>'); $('body').append(ifr); setTimeout(function () { ifr.remove(); }, 1000) } }; var _getHybridUrl = function (params) { var k, paramStr = '', url = 'scheme://'; url += params.tagname + '?t=' + new Date().getTime(); //时间戳，防止url不起效 if (params.callback) { url += '&callback=' + params.callback; delete params.callback; } if (params.param) { paramStr = typeof params.param == 'object' ? JSON.stringify(params.param) : params.param; url += '¶m=' + encodeURIComponent(paramStr); } return url; }; var requestHybrid = function (params) { //生成唯一执行函数，执行后销毁 var tt = (new Date().getTime()); var t = 'hybrid_' + tt; var tmpFn; //处理有回调的情况 if (params.callback) { tmpFn = params.callback; params.callback = t; window.Hybrid[t] = function (data) { tmpFn(data); delete window.Hybrid[t]; } } bridgePostMsg(_getHybridUrl(params)); }; //获取版本信息，约定APP的navigator.userAgent版本包含版本信息：scheme/xx.xx.xx var getHybridInfo = function () { var platform_version = {}; var na = navigator.userAgent; var info = na.match(/scheme/d.d.d/); if (info && info[0]) { info = info[0].split('/'); if (info && info.length == 2) { platform_version.platform = info[0]; platform_version.version = info[1]; } } return platform_version; };

因为Native对于H5来是底层，框架&底层一般来说是不会关注业务实现的，所以真实业务中Native调用H5场景较少，这里不予关注了。

公共业务的设计-体系化

在Hybrid架构中（其实就算在传统的业务中也是），会存在很多公共业务，这部分公共业务很多是H5做的（比如注册、地址维护、反馈等，登录是native化了的公共业务），我们一个Hybrid架构要真正的效率高，就得把各种公共业务做好了，不然单是H5做业务，效率未必会真的比Native高多少。

底层框架完善并且统一后，便可以以规范的力量限制各业务开发，在统一的框架下开发出来的公共业务会大大的提升整体工作效率，这里以注册为例，一个公共页面一般来说得设计成这个样子：

公共业务代码，应该可以让人在URL参数上对页面进行一定定制化，这里URL参数一般要独特一些，一面被覆盖，这个设计适用于native页面

URL中会包含以下参数：

① _hashead 是否有head，默认true

② _hasback 是否包含回退按钮，默认true

③ _backtxt 回退按钮的文案，默认没有，这个时候显示为回退图标

④ _title 标题

⑤ _btntxt 按钮的文案

⑥ _backurl 回退按钮点击时候的跳转，默认为空则执行history.back

⑦ _successurl 点击按钮回调成功时候的跳转，必须

只要公共页面设计为这个样子，就能满足多数业务了，在底层做一些适配，可以很轻易的一套代码同时用于native与H5，这里再举个例子：

如果我们要点击成功后去到一个native页面，如果按照我们之前的设计，我们每个Native页面皆已经URL化了的话，我们完全可以以这种方向跳转：

JavaScript

requestHybrid({ tagname: 'forward', param: { topage: 'nativeUrl', type: 'native' } });

这个命令会生成一个这样的url的链接：

_successurl == hybrid://forward?param=%7B%22topage%22%3A%22nativeUrl%22%2C%22type%22%3A%22native%22%7D

完了，在点击回调时要执行一个H5的URL跳转：

JavaScript

window.location = _successurl

而根据我们之前的hybrid规范约定，这种请求会被native拦截，于是就跳到了我们想要的native页面，整个这一套东西就是我们所谓的体系化：

常用交互API

良好的交互设计是成功的第一步，在真实业务开发中有一些API一定会用到。

离线更新

根据之前的约定，Native中如果存在静态资源，也是按频道划分的：

JavaScript

webapp //根目录 ├─flight ├─hotel //酒店频道 │ │ index.html //业务入口html资源，如果不是单页应用会有多个入口 │ │ main.js //业务所有js资源打包 │ │ │ └─static //静态样式资源 │ ├─css │ ├─hybrid //存储业务定制化类Native Header图标 │ └─images ├─libs │ libs.js //框架所有js资源打包 │ └─static //框架静态资源样式文件 ├─css └─images

我们这里制定一个规则，native会过滤某一个规则的请求，检查本地是否有该文件，如果本地有那么就直接读取本地，比如说，我们会将这个类型的请求映射到本地：

JavaScript

//===>> file ===> flight/static/hybrid/icon-search.png

这样在浏览器中便继续读取线上文件，在native中，如果有本地资源，便读取本地资源：

但是我们在真实使用场景中却遇到了一些麻烦。

跳转

跳转是Hybrid必用API之一，对前端来说有以下跳转：

① 页面内跳转，与Hybrid无关

② H5跳转Native界面

③ H5新开Webview跳转H5页面，一般为做页面动画切换

如果要使用动画，按业务来说有向前与向后两种，forward&back，所以约定如下，首先是H5跳Native某一个页面

JavaScript

//H5跳Native页面 //=>baidubus://forward?t=1446297487682¶m=%7B%22topage%22%3A%22home%22%2C%22type%22%3A%22h2n%22%2C%22data2%22%3A2%7D requestHybrid({ tagname: 'forward', param: { //要去到的页面 topage: 'home', //跳转方式，H5跳Native type: 'native', //其它参数 data2: 2 } });

比如携程H5页面要去到酒店Native某一个页面可以这样：

JavaScript

//=>schema://forward?t=1446297653344¶m=%7B%22topage%22%3A%22hotel%2Fdetail%20%20%22%2C%22type%22%3A%22h2n%22%2C%22id%22%3A20151031%7D requestHybrid({ tagname: 'forward', param: { //要去到的页面 topage: 'hotel/detail', //跳转方式，H5跳Native type: 'native', //其它参数 id: 20151031 } });

比如H5新开Webview的方式跳转H5页面便可以这样：

JavaScript

requestHybrid({ tagname: 'forward', param: { //要去到的页面，首先找到hotel频道，然后定位到detail模块 topage: 'hotel/detail ', //跳转方式，H5新开Webview跳转，最后装载H5页面 type: 'webview', //其它参数 id: 20151031 } });

back与forward一致，我们甚至会有animattype参数决定切换页面时的动画效果，真实使用时可能会封装全局方法略去tagname的细节，这时就和糯米对外释放的接口差不多了。

增量的粒度

其实，我们最开始做增量设计的时候就考虑了很多问题，但是真实业务的时候往往因为时间的压迫，做出来的东西就会很简陋，这个只能慢慢迭代，而我们所有的缓存都会考虑两个问题：

① 如何存储&读取缓存

② 如何更新缓存

浏览器的缓存读取更新是比较单纯的：

浏览器只需要自己能读到最新的缓存即可

而APP的话，会存在最新发布的APP希望读到离线包，而老APP不希望读到增量包的情况（老的APP下载下来增量包压根不支持），更加复杂的情况是想对某个版本做定向修复，那么就需要定向发增量包了，这让情况变得复杂，而复杂即错误，我们往往可以以简单的约定，解决复杂的场景。

思考以下场景：

我们的APP要发一个新的版本了，我们把最初一版的静态资源给打了进去，完了审核中的时候，我们老版本APP突然有一个临时需求要上线，我知道这听起来很有一些扯淡，但这种扯淡的事情却真实的发生了，这个时候我们如果打了增量包的话，那么最新的APP在审核期间也会拉到这次代码，但也许这不是我们所期望的，于是有了以下与native的约定：

Native请求增量更新的时候带上版本号，并且强迫约定iOS与Android的大版本号一致，比如iOS为2.1.0Android这个版本修复BUG可以是2.1.1但不能是2.2.0

然后在服务器端配置一个较为复杂的版本映射表：

JavaScript

## 附录一 // 每个app所需的项目配置 const APP_CONFIG = [ 'surgery' => [ // 包名 'channel' => 'd2d', // 主项目频道名 'dependencies' => ['blade', 'static', 'user'], // 依赖的频道 'version' => [ // 各个版本对应的增量包范围，取范围内版本号最大的增量包 '2.0.x' => ['gte' => '1.0.0', 'lt' => '1.1.0'], '2.2.x' => ['gte' => '1.1.0', 'lt' => '1.2.0'] ], 'version_i' => [ // ios需特殊配置的某版本 ], 'version_a' => [ // Android需特殊配置的某版本 ] ] ];

这里解决了APP版本的读取限制，完了我们便需要关心增量的到达率与更新率，我们也会担心我们的APP读到错误的文件。

Header 组件的设计

最初我其实是抵制使用Native提供的UI组件的，尤其是Header，因为平台化后，Native每次改动都很慎重并且响应很慢，但是出于两点核心因素考虑，我基本放弃了抵抗：

① 其它主流容器都是这么做的，比如微信、手机百度、携程

② 没有header一旦网络出错出现白屏，APP将陷入假死状态，这是不可接受的，而一般的解决方案都太业务了

PS：Native吊起Native时，如果300ms没有响应需要出loading组件，避免白屏

因为H5站点本来就有Header组件，站在前端框架层来说，需要确保业务的代码是一致的，所有的差异需要在框架层做到透明化，简单来说Header的设计需要遵循：

① H5 header组件与Native提供的header组件使用调用层接口一致

② 前端框架层根据环境判断选择应该使用H5的header组件抑或Native的header组件

一般来说header组件需要完成以下功能：

① header左侧与右侧可配置，显示为文字或者图标（这里要求header实现主流图标，并且也可由业务控制图标），并需要控制其点击回调

② header的title可设置为单标题或者主标题、子标题类型，并且可配置lefticon与righticon（icon居中）

③ 满足一些特殊配置，比如标签类header

所以，站在前端业务方来说，header的使用方式为（其中tagname是不允许重复的）：

JavaScript

//Native以及前端框架会对特殊tagname的标识做默认回调，如果未注册callback，或者点击回调callback无返回则执行默认方法 // back前端默认执行History.back，如果不可后退则回到指定URL，Native如果检测到不可后退则返回Naive大首页 // home前端默认返回指定URL，Native默认返回大首页 this.header.set({ left: [ { //如果出现value字段，则默认不使用icon tagname: 'back', value: '回退', //如果设置了lefticon或者righticon，则显示icon //native会提供常用图标icon映射，如果找不到，便会去当前业务频道专用目录获取图标 lefticon: 'back', callback: function () { } } ], right: [ { //默认icon为tagname，这里为icon tagname: 'search', callback: function () { } }, //自定义图标 { tagname: 'me', //会去hotel频道存储静态header图标资源目录搜寻该图标，没有便使用默认图标 icon: 'hotel/me.png', callback: function () { } } ], title: 'title', //显示主标题，子标题的场景 title: ['title', 'subtitle'], //定制化title title: { value: 'title', //标题右边图标 righticon: 'down', //也可以设置lefticon //标题类型，默认为空，设置的话需要特殊处理 //type: 'tabs', //点击标题时的回调，默认为空 callback: function () { } } });

因为Header左边一般来说只有一个按钮，所以其对象可以使用这种形式：

JavaScript

this.header.set({ back: function () { }, title: '' }); //语法糖=> this.header.set({ left: [{ tagname: 'back', callback: function(){} }], title: '', });

为完成Native端的实现，这里会新增两个接口，向Native注册事件，以及注销事件：

JavaScript

var registerHybridCallback = function (ns, name, callback) { if(!window.Hybrid[ns]) window.Hybrid[ns] = {}; window.Hybrid[ns][name] = callback; }; var unRegisterHybridCallback = function (ns) { if(!window.Hybrid[ns]) return; delete window.Hybrid[ns]; };

Native Header组件的实现：

JavaScript

define([], function () { 'use strict'; return _.inherit({ propertys: function () { this.left = []; this.right = []; this.title = {}; this.view = null; this.hybridEventFlag = 'Header_Event'; }, //全部更新 set: function (opts) { if (!opts) return; var left = []; var right = []; var title = {}; var tmp = {}; //语法糖适配 if (opts.back) { tmp = { tagname: 'back' }; if (typeof opts.back == 'string') tmp.value = opts.back; else if (typeof opts.back == 'function') tmp.callback = opts.back; else if (typeof opts.back == 'object') _.extend(tmp, opts.back); left.push(tmp); } else { if (opts.left) left = opts.left; } //右边按钮必须保持数据一致性 if (typeof opts.right == 'object' && opts.right.length) right = opts.right if (typeof opts.title == 'string') { title.title = opts.title; } else if (_.isArray(opts.title) && opts.title.length > 1) { title.title = opts.title[0]; title.subtitle = opts.title[1]; } else if (typeof opts.title == 'object') { _.extend(title, opts.title); } this.left = left; this.right = right; this.title = title; this.view = opts.view; this.registerEvents(); _.requestHybrid({ tagname: 'updateheader', param: { left: this.left, right: this.right, title: this.title } }); }, //注册事件，将事件存于本地 registerEvents: function () { _.unRegisterHybridCallback(this.hybridEventFlag); this._addEvent(this.left); this._addEvent(this.right); this._addEvent(this.title); }, _addEvent: function (data) { if (!_.isArray(data)) data = [data]; var i, len, tmp, fn, tagname; var t = 'header_' + (new Date().getTime()); for (i = 0, len = data.length; i < len; i++) { tmp = data[i]; tagname = tmp.tagname || ''; if (tmp.callback) { fn = $.proxy(tmp.callback, this.view); tmp.callback = t; _.registerHeaderCallback(this.hybridEventFlag, t + '_' + tagname, fn); } } }, //显示header show: function () { _.requestHybrid({ tagname: 'showheader' }); }, //隐藏header hide: function () { _.requestHybrid({ tagname: 'hideheader', param: { animate: true } }); }, //只更新title，不重置事件，不对header其它地方造成变化，仅仅最简单的header能如此操作 update: function (title) { _.requestHybrid({ tagname: 'updateheadertitle', param: { title: 'aaaaa' } }); }, initialize: function () { this.propertys(); } }); }); Native Header组件的封装

更新率

我们有时候想要的是一旦增量包发布，用户拿着手机就马上能看到最新的内容了，而这样需要app调用增量包的频率增高，所以我们是设置每30分钟检查一次更新。

请求类

虽然get类请求可以用jsonp的方式绕过跨域问题，但是post请求却是真正的拦路虎，为了安全性服务器设置cors会仅仅针对几个域名，Hybrid内嵌静态资源是通过file的方式读取，这种场景使用cors就不好使了，所以每个请求需要经过Native做一层代理发出去。

这个使用场景与Header组件一致，前端框架层必须做到对业务透明化，业务事实上不必关心这个请求是由浏览器发出还是由Native发出：

JavaScript

HybridGet = function (url, param, callback) { }; HybridPost = function (url, param, callback) { };

真实的业务场景，会将之封装到数据请求模块，在底层做适配，在H5站点下使用ajax请求，在Native内嵌时使用代理发出，与Native的约定为：

JavaScript

requestHybrid({ tagname: 'ajax', param: { url: 'hotel/detail', param: {}, //默认为get type: 'post' }, //响应后的回调 callback: function (data) { } });

正确读取

这里可能有点杞人忧天，因为Native程序不是自己手把手开发的，总是担心APP在正在拉取增量包时，或者正在解压时，读取了静态文件，这样会不会读取错误呢，后面想了想，便继续采用了之前的md5打包的方式，将落地的html中需要的文件打包为md5引用，如果落地页下载下来后，读不到本地文件就自己会去拉取线上资源咯。

常用NativeUI组件

最后，Native会提供几个常用的Native级别的UI，比如loading加载层，比如toast消息框：

JavaScript

var HybridUI = {}; HybridUI.showLoading(); //=> requestHybrid({ tagname: 'showLoading' }); HybridUI.showToast({ title: '111', //几秒后自动关闭提示框，-1需要点击才会关闭 hidesec: 3, //弹出层关闭时的回调 callback: function () { } }); //=> requestHybrid({ tagname: 'showToast', param: { title: '111', hidesec: 3, callback: function () { } } });

Native UI与前端UI不容易打通，所以在真实业务开发过程中，一般只会使用几个关键的Native UI。

调试

一个Hybrid项目，要最大限度的符合前端的开发习惯，并且要提供可调试方案

我们之前说过直接将所有请求用native发出有一个最大的问题就是调试不方便，而正确的hybrid的开发应该是有70%以上的时间，纯业务开发者不需要关心native联调，当所有业务开发结束后再内嵌简单调一下即可。

因为调试时候需要读取测试环境资源，需要server端qa接口有个全局开关，关闭所有的增量读取

关于代理调试的方法已经很多人介绍过了，我这里不再多说，说一些native中的调试方案吧，其实很多人都知道。

账号系统的设计

根据上面的设计，我们约定在Hybrid中请求有两种发出方式：

① 如果是webview访问线上站点的话，直接使用传统ajax发出

② 如果是file的形式读取Native本地资源的话，请求由Native代理发出

因为静态html资源没有鉴权的问题，真正的权限验证需要请求服务器api响应通过错误码才能获得，这是动态语言与静态语言做入口页面的一个很大的区别。

以网页的方式访问，账号登录与否由是否带有秘钥cookie决定（这时并不能保证秘钥的有效性），因为Native不关注业务实现，而每次载入都有可能是登录成功跳回来的结果，所以每次载入后都需要关注秘钥cookie变化，以做到登录态数据一致性。

以file的方式访问内嵌资源的话，因为API请求控制方为Native，所以鉴权的工作完全由Native完成，接口访问如果没有登录便弹出Native级别登录框引导登录即可，每次访问webview将账号信息种入到webview中，这里有个矛盾点是Native种入webview的时机，因为有可能是网页注销的情况，所以这里的逻辑是：

① webview载入结束

② Native检测webview是否包含账号cookie信息

③ 如果不包含则种入cookie，如果包含则检测与Native账号信息是否相同，不同则替换自身

④ 如果检测到跳到了注销账户的页面，则需要清理自身账号信息

如果登录不统一会就会出现上述复杂的逻辑，所以真实情况下我们会对登录接口收口。

简单化账号接口

平台层面觉得上述操作过于复杂，便强制要求在Hybrid容器中只能使用Native接口进行登录和登出，前端框架在底层做适配，保证上层业务的透明，这样情况会简单很多：

① 使用Native代理做请求接口，如果没有登录直接Native层唤起登录框

② 直连方式使用ajax请求接口，如果没有登录则在底层唤起登录框（需要前端框架支持）

简单的登录登出接口实现：

JavaScript

/* 无论成功与否皆会关闭登录框 参数包括： success 登录成功的回调 error 登录失败的回调 url 如果没有设置success，或者success执行后没有返回true，则默认跳往此url */ HybridUI.Login = function (opts) { }; //=> requestHybrid({ tagname: 'login', param: { success: function () { }, error: function () { }, url: '...' } }); //与登录接口一致，参数一致 HybridUI.logout = function () { };

账号信息获取

在实际的业务开发中，判断用户是否登录、获取用户基本信息的需求比比皆是，所以这里必须保证Hybrid开发模式与H5开发模式保持统一，否则需要在业务代码中做很多无谓的判断，我们在前端框架会封装一个User模块，主要接口包括：

JavaScript

1 var User = {}; 2 User.isLogin = function () { }; 3 User.getInfo = function () { };

这个代码的底层实现分为前端实现，Native实现，首先是前端的做法是：

当前端页面载入后，会做一次异步请求，请求用户相关数据，如果是登录状态便能获取数据存于localstorage中，这里一定不能存取敏感信息

前端使用localstorage的话需要考虑极端情况下使用内存变量的方式替换localstorage的实现，否则会出现不可使用的情况，而后续的访问皆是使用localstorage中的数据做判断依据，以下情况需要清理localstorage的账号数据：

① 系统登出

② 访问接口提示需要登录

③ 调用登录接口

这种模式多用于单页应用，非单页应用一般会在每次刷新页面先清空账号信息再异步拉取，但是如果当前页面马上就需要判断用户登录数据的话，便不可靠了;处于Hybrid容器中时，因为Native本身就保存了用户信息，封装的接口直接由Native获取即可，这块比较靠谱。

本文由澳门在线威尼斯官方发布于威尼斯澳门在线,转载请注明出处：浅谈Hybrid技术的设计与实现第三弹，浅谈Hybrid技

关键词：