HyBird 混合开发选型

[mishe]

---

Hybrid简史

Hybrid既利用了Native App丰富的设备API（Device API），又能拥有Mobile Web的跨平台、高效开发、快速发布的能力，对于相当庞大的应用场景而言都是适用的。

Hybrid优势在于：

跨平台

• Web内容可以做到开发一次，所有平台生效，诸多产品需要这种能力。

快速发布

• iOS平台，Apple Store平均审核周期1～2周不等，甚至更长，产品的发布周期从2周到1月，这对需要快速发布的产品而言难以接受。
• Android平台，应用商店众多，发布过程烦琐。虽然可以应用内升级，但是带来的问题是新App需要通过应用商店，此外APK体积庞大，2G/3G环境下体验差。

高效开发

• Web开发经过20年的发展，已经将结构（HTML）、表现（CSS）、行为（JavaScript）3部分很好地分离开，在分工协作、开发效率上会具明显优势。

丰富的Device API

• Web（HTML5）强调通用性，受限于标准和浏览器实现，许多有用的系统功能未能得到支持（或部分支持）。而Native最大的优势在于设备API的调用能力，只要桥接Native和Web，Web也就能够拥有这种能力。

Hybrid劣势表现为：

• CPU/GPU密集类应用目前看更适合Native，例如极品飞车这样的游戏。这种劣势是在不断弱化的，正如 “CSS Transform 3D”引入GPU大大缓解了Web动画不流畅的问题。
• 静态资源从服务器端加载导致的UI展示延迟问题。这个问题可以通过Native拦截WebView通信加载已打包的公共库来缓解

Hybrid 开发可选方案

• H5(Vue) + DIY JSBridge
• H5(Vue) + Address
• H5(Vue) + Cordova
• H5(Vue) + Weex
• H5(Vue) + nativescript-vue
• H5(React) + ReactNative
• H5(AngularJS)+ ionic+phonegap
  

由于源码采用了vue，最后2种方案可以不考虑，因此剩下5种可选方案；

DIY JSBridge和Address

DIY JSBridge和Address数据交互原则上对于原生APP端开发的影响不是很太大，都是需要原生APP开发人员编写一些代码给与H5人员来调取，两者之间主要差异在H5端的交互数据的长度不一致上，Address受地址栏长度的限制，因此不能支持大数据的交互，JSBridge可以支持大数据量的交互。

这2种方式的页面呈现基本还是HTML，只不过被app内嵌入webview中，开发效率和代码统一性高度合一，只需一套代码，就可以运行在手机浏览器，微信，淘宝，ios，Android等可以开启webview的任何平台和软件中；

如果采用上面的2者之一的方案，那么最好用原生app端实现如下的功能，那样的话，开发效率和用户体验二者就可以兼得。

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

因H5比较容易被恶意攻击，对于安全性要求比较高的界面，如注册界面、登陆、支付、购物车等界面，会采用Native来取代H5开发，保证数据的安全性，当然降级的方案也有，就是全站采用HTTPS。

导航组件采用Native

页面的页头，页尾，下拉刷新等，可以用原生开发，H5根据页面不同修改数据和状态；
所以打开的界面都是Native的导航组件+webview来组成，这样即使H5加载失败或者太慢用户可以选择直接关闭。

系统级UI组件采用Native

一些通用的UI组件，如alert、toast等将采用Native来实现，这些组件通常功能单一但是通用，适合做成公用组件整合到HybridApi里边

默认界面采用Native

由于H5是在H5容器里进行加载和渲染，所以Native很容易对H5页面的行为进行监控，包括进度条、loading动画、404监控、5xx监控、网络诊断等，并且在H5加载异常时提供默认界面供用户操作，防止APP“假死”。

H5离线访问

顾名思义就是将H5预先放到用户手机，这样访问时就不会再走网络从而做到看起来和Native APP一样的快了。
我们需要解决以下几个问题：

H5应该有线上版本

作为访问离线资源的降级方案，当本地资源不存在的时候应该走现网去拉取对应资源，保证H5可用。另外就是，对于H5，我们不会把所有页面都使用离线访问，例如活动页面，这类快速上线又快速下线的页面，设计离线访问方式开发周期比较高，也有可能是页面完全是动态的，不同的用户在不同的时间看到的页面不一样，没法落地成静态页面，还有一类就是一些说明类的静态页面，更新频率很小的，也没必要做成离线占用手机存储空间。

开发调试&抓包

为了实现同一资源的线上和离线访问，Native需要对H5的静态资源请求进行拦截判断，将静态资源“映射”到sd卡资源，即实现一个处理H5资源的本地路由。

H5离线动态更新机制

将H5资源放置到本地离线访问，最大的挑战就是本地资源的动态更新如何设计，开发阶段H5代码可以通过手机设置HTTP代理方式直接访问开发机。完成开发之后，将H5代码推送到管理平台进行构建、打包，然后管理平台再通过事先设计好的长连接通道将H5新版本信息推送给客户端，客户端收到更新指令后开始下载新包、对包进行完整性校验、merge回本地对应的包，更新结束。

通常来说，H5资源分为两种，经常更新的业务代码和不经常更新的框架、库代码和公用组件代码，为了实现离线资源的共享，在H5打包时可以采用分包的策略，将公用部分单独打包，在本地也是单独存放。

数据通道

由于界面由H5和Native共同完成，界面上的用户交互埋点数据最好由H5容器统一采集、上报，还有，由页面跳转产生的浏览轨迹（转化漏斗），也由H5容器记录和上报

ajax代理

因ajax受同源策略限制，可以在hybridApi层对ajax进行统一封装，同时兼容H5容器和浏览器runtime，采用更高效的通讯通道加速H5的数据传输

Native对H5的扩展

主要指扩展H5的硬件接口调用能力，比如屏幕旋转、摄像头、麦克风、位置服务等等，将Native的能力通过接口的形式提供给H5。

Cordova、nativeScript-vue、Weex

Cordova、nativeScript-vue、Weex都是需要重新编写代码的，否则无法利用原生的优势和组件，weex有中文文档，Cordova和nativeScript-vue只有英文文档，分别是：

Cordova文档
weex中文文档
nativeScript-vue文档

不推荐使用Cordova

Cordova是PhoneGap贡献给Apache后的开源项目，是从PhoneGap中抽离出的核心代码，是驱动PhoneGap的核心引擎。有点类似Webkit和Google Chrome的关系。
Cordova做的app，在低端Android手机上很难流畅运行，而且没有专业开发工具，语法提示、调试、打包都很麻烦，因此不推荐使用Cordova作为HYbird的开发框架。

Weex

nativeScript-vue和Weex都支持spa，但weex推荐使用多页面，并且vue-router被大大限制了，只能使用编程式导航，不支持，也就是说不能使用多单页的方式来快速切换页面地址，另外weex的调试不方便。

weex的功能和组件

- 跳转链接 A
- 布局 DIV
- 图像 image
- 轮播图 slider
- 表单 input textarea
- 列表 list recycle-list
- 下拉刷新 refresh
- 滚动框 scroller
- 文本内容 text
- 视频播放 video
- 瀑布流布局的组件 waterfall
- 页面容器 web

- js动画 animation
- 剪贴板 clipboard
- 导航 navigator
- 常用弹窗 toast alert confirm prompt
- 日期选择 picker
- 本地存储 storage
- 网络请求 fetch
- websocket
- history
- postMessage

Weex 环境中没有 DOM

DOM（Document Object Model），即文档对象模型，是 HTML 和 XML 文档的编程接口，是 Web 中的概念。Weex 的运行环境以原生应用为主，在 Android 和 iOS 环境中渲染出来的是原生的组件，不是 DOM Element。

不支持 DOM 操作

既然原生环境中不支持 Web API，没有 Element 、Event 、File 等对象，详细列表可以参考 Web APIs on MDN。不支持选中元素，如 document.getElementById 、 document.querySelector 等；当然也不支持基于 DOM API 的程序库（如 jQuery）。

有限的事件类型

Weex 支持在标签上绑定事件，和在浏览器中的写法一样，但是 Weex 中的事件是由原生组件捕获并触发的，行为和浏览器中有所不同，事件中的属性也和 Web 中有差异。

并不支持 Web 中所有的事件类型，详情请参考《通用事件》。

不区分事件的捕获阶段和冒泡阶段，相当于 DOM 0 级事件。
Weex 环境中没有 BOM
BOM（Browser Object Model），即浏览器对象模型，是浏览器环境为 javascript 提供的接口。Weex 在原生端没有并不基于浏览器运行，不支持浏览器提供的 BOM 接口。

没有 window 、screen 对象

Weex 中并未提供浏览器中的 window 和 screen 对象，不支持使用全局变量。如果是想要获取设备的屏幕或环境信息，可以使用 WXEnvironment 变量。

没有 document 对象

在浏览器中 document 表示了当前活动的文档模型，在 Android 和 iOS 环境中并没有这个对象，也不支持与其相关的 DOM 操作。

没有 history 、location 、navigator 对象

history 保存了当前页面的历史记录，并且提供了前进后退操作。
location 记录了当前页面 URL 相关的信息。
navigator 记录了当前浏览器中的信息。
这些接口与浏览器自身的实现有关，可以控制页面的前进后退并且获取状态信息。虽然在 Android 和 iOS 中也有“历史”和“导航”的概念，但是它是用于多个管理视图之间的跳转的。换句话说，在浏览器中执行“前进”、“后退”仍然会处于同一个页签中，在原生应用中“前进”、“后退”则会真实的跳转到其他页面。

此外 Weex 也提供了 navigator 模块来操作页面的跳转，使用方法参考《navigator 导航控制》。

能够调用移动设备原生 API

在 Weex 中能够调用移动设备原生 API，使用方法是通过注册、调用模块来实现。其中有一些模块是 Weex 内置的，如 clipboard 、 navigator 、storage 。

weex 竟然没有拍照，定位，录音等原生扩展

总体上，weex只能算是一个基础的ui库，需要原生app端配合开发很多的原生应用，完善度上还远远不如微信小程序。

nativeScript-vue

nativeScript-vue目前项目还处于高速发展中，可以紧密的配合VUE开发，而且提供了在线编辑调试和真机预览及联调工具，是目前比较被看好的hybird开发框架，但缺少中文文档。

nativescript的原理和react-native有点相似：提供一个运行环境，提供一个JavaScript引擎，android端是V8引擎，ios端是JavaScriptCore引擎，一个虚拟机上运行JavaScript代码，都可以调用平台api和ui组件。而nativescript更专注于创建一个与平台无关的单一的开发体验，因此nativescript的执行效率上不是很高。

nativeScript-vue的组件及功能

- 字符模板 v-template
- 子组件继承父组件的指令 v-view
- 同样支持vue-router 的$route.push
- 支持vuex
- 支持6种布局功能
- 支持固定导航 actionBar
- loading进度条 activityIndicator
- 按钮 button
- 日期选择 DatePicker
- html解析支持 htmlView（静态）  webView（动态）
- 图片 image
- 标签 label
- select列表 listpicker
- 列表布局 listView
- 任务进度条 progress
- 滚动区域 scrollView
- 搜索条 -searchBar
- 多选项的单选功能 segmentedBar
- 可拖动的进度条 slider
- 开关  switch
- tab功能  tabView、
- 可编辑单行文本替代input textField
- 多行文本textarea textView
- 时间选择期 timepicker
- 各类弹窗对话框 alert confirm prompt

总结

hybird 快速开发可以选择DIY jsbridge的方式

追求用户体验的话，可以选择weex和nativeScript

weex对比nactiveScript优势：

优势：有比较好的体验优化。
劣势：没有很好的调试工具来支持业务的快速开发和调试。