客户端Hybrid架构设计之——WebView方案的实现

一、 引言

Hybrid App（混合模式移动应用）是指介于web-app、native-app这两者之间的app，兼具“Native App良好交互体验的优势”和“Web App跨平台开发的优势”。

当前Hybrid技术也分了几个门派，其中主流的两派——

• 一派是采用ReactNative或者weex之类的框架来实现，通俗点说就是程序员用js写代码，然后框架负责把js代码翻译成原生代码，最后呈现出原生页面；

• 另外一派是采用WebView组件，程序员写的是纯粹的h5代码，最后也是通过原生端的WebView组件来加载渲染，和WebApp的区别就是，WebApp整个app是一个web容器，各种页面跳转包括效果实现都是在这个容器中通过H5技术实现。
  而Hybrid-WebView的实现方案中，每个页面都是一个独立的WebView容器，页面之间的跳转，一些特殊效果，特殊组件的实现，都是通过H5发消息来调取原生功能实现的。

本文主要探讨后一种方案在Android客户端的实现，当然整体的思路在iOS端也是通用的，ReactNative的方案会在稍后送上。

二、Hybrid-WebView方案的优劣势

优势

• 各平台统一使用H5页面，减少了开发工作量
• H5页面可以动态更新，功能迭代包括处理bug都更灵活

劣势

• H5页面的部分用户体验不如native
• H5也需适配各平台机型
• 原生端基础框架搭建费时费力，有时一些特殊功能需要ios、Android、H5三方联合开发，增加了沟通协调成本

三、关键实现

• JsBridge
  作为H5和native的沟通桥梁，H5通过JsBridge调用native功能，native通过JsBridge回传信息给H5

• Route模块
  路由模块用以实现原生页面与H5页面的自由跳转，页面与页面之间做到尽量解耦

• Handlers
  部分功能（相机、Dialog、下拉刷新、Toolbar等）使用native代码实现，实现相应的Handler供H5调用

• 本地缓存模块
  h5页面的资源如果全部从网络加载，势必会大大拖慢页面的加载速度，破坏用户体验，于是很直觉的实现方案就是把h5需要的一些资源打包到本地，当h5页面需要时，直接从本地获取，这样就可以实现h5页面秒开的性能。

• HybridFragment
  作为项目中承载Hybrid功能的组件，之所以选用Fragment而非Activity，是为了更方便复用。

• WebView
  由于Android4.4及之后的系统版本才开始采用chromium作为WebView的内核，而更早之前的系统采用的是WebKit内核，对HTML5,CSS3,Javascript等的新特性支持较差，所以我们采用腾讯X5的方案来取代原生WebView。
  腾讯X5方案的优势在于，可以从手机本身安装的微信、qq等腾讯客户端中直接获取X5浏览器内核，而不用在我们的app中预置或者重新下载一个完整的浏览器内核，那通常要几十m那么大。
  当然这是1，2年前的不得已为之，随着目前主流手机的系统版本都已经在5.0以上，直接使用系统WebView也是可以接受的方案了。

四、JsBridge实现细节

H5传递数据给Android

H5调用iframe.src = ‘传递内容’，Android的WebViewClient就可以通过shouldOverrideUrlLoading获取到‘传递内容’。

Android传递数据给H5的三种交互方案

1. WebView的addJavaScriptInterface
   Java中编写特别的类与接口供WebView直接调用，在SDK17以上可以给接口@JavascriptInterface注释来保证安全性，但在17以下版本风险太大，估不适用这种方式。
2. SDK19以上可以使用webView.evaluateJavascript方法
3. 通过webView.loadUrl("javascript:" + script);

考虑到兼容性，采用方案3

关于JsBridge更具体的信息，可以参考https://github.com/fangj/WebViewJavascriptBridge的代码

五、Route模块实现

基本功能

• 无论是在原生页面，还是h5页面，可以通过通用的方法，来跳往另一个页面
• 具体跳往哪个页面可以通过远端动态调整，这样在某个页面有问题时，可以跳往另一个没有错误的页面，甚至跳往一个新写的一样功能的H5页面来临时解决bug。

实现原理

• 在客户端本地维护一张路由表，表内内容是一组KV，key值代表页面代号，value代表具体的页面，如果value值是abc://协议，则是一个原生页面，http://协议，则是一个h5页面
  举例
  g_product_detail: abc://g_product_detail
  g_product_detail: http://abc.com/productdetail.html
  同样的key前者跳的是本地页面（客户端本地会维护abc协议之后的key值和具体的Activity类的关联关系），后者跳的是h5页面

• 定期从服务器接口检查、更新路由表，服务器会通过具体的用户、平台、版本号、环境等来返回相应的路由表，这就实现了远端的控制。

• 少数页面需要跳转前置逻辑的，通过RouteJumpHandler拦截路由跳转做特殊处理

六、本地缓存

基本功能

• 拦截h5调用资源的请求，并用本地资源去替换
• 本地缓存更新功能

实现原理

• 使用WebResourceReponse shouldInterceptRequest()方法，拦截webview对各资源的请求，根据后缀名和MINIType筛选出可能可以替换的资源，并去本地资源包中寻找资源，如发现，则生成WebResourceReponse直接返回，如找不到资源，则仍然按正常流程获取。
  需拦截的文件类型
  .js application/x-javascript
  .css text/css
  .jpg image/jpeg
  .jpeg image/jpeg
  .png image/png
  .gif image/gif
  .svg text/xml
  .ttf application/octet-stream
  .woff application/octet-stream
  .woff2 application/octet-stream
  .eot application/octet-stream
  .html text/html

• apk打包时预置一个缓存包，并定期利用差分更新技术，来检查更新本地的缓存包，差分更新技术的具体细节在讲ReactNative方案的实现时再谈

至此整个Hybrid（WebView）框架基本搭建完毕，当然随着业务的开展，可能还需要添加一些特定的Handler，这里就不赘述了。

从我们项目的实际应用情况来说，效果还是显而易见的。公司的产品和运营需求可以更快速的落地了，大多数的业务BUG也不用通过发版来解决，客户端团队也从业务代码中摆脱了出来，开始专心研究优化原生的底层框架，让客户端变得更加稳健、安全。可以说这次架构的转变是一次非常成功的尝试。