导读

如何借助Hybrid方案实现App良好用户交互体验，同时又能使App实现跨平台开发？新浪移动大前端&基础工具平台技术专家李文森将带你了解新浪新闻客户端开发过程中Hybrid技术的使用。

1、新闻客户端发展现状

新浪新闻客户端正处于高速发展的状态，用户总规模持续增长，月活跃用户数环比增长12.2%，高于行业平均水平。用户月日均使用时长较去年同比增长80%。在如此高速发展的背景下，新浪新闻客户端面临着什么样的挑战呢？

第一点快。作为资讯类APP，用户首要需求是及时获取内容，为保证良好的用户体验，需要产品渲染性能进一步提升。

第二点灵活。面对突发事件、新闻本身的灵活性该如何应对，随着用户规模的不断壮大，要求产品迭代速度更加灵活。

第三点轻。新闻类需求目前处于爆发期，因此应用的体积也正逐步增加，这就需要平衡用户需求与应用体积两者之间的关系。

传统Native APP有哪些不足：1、IOS和Android实现两套逻辑，这就需要在两个不同的平台做同一个逻辑业务，导致开发成本增加；2、随着开发的完成，产品最终推向用户，需要不断审核，产品的迭代升级也需要进行审核，发版过程繁琐；3、随着需求越来越大，业务存在一个包内，导致应用体积不断增大；

针对的Native APP的不足，能不能通过一些优化技术、解决方式来弥补它的不足呢？首先想到的就是通过Web应用来弥补Native不足。那Web应用又有哪些优势呢？

首先是Web应用能够实现灵活上线，迭代迅速。再者就是Web应用可以跨平台，实现多端统一。但Web应用也有不足，首先Web需要下载，受制于网络环境的影响。其次Web交互能力不如客户端顺畅。通过结合Web以及Native应用的优势从而完善了新浪移动的Hybrid方案。

2、新浪移动Hybrid方案的技术结构

Hybrid技术是基于Webview的一个混合，Webview为外部内容提供一些原生的浏览运行环境，对于Native方面又是一个原生环境的暴露。在这个体系之下，依据基础层、桥接层、业务层从下自上搭建了一个技术架构。首先是基础层，底层的Android/IOS平台层，向上对外是Native API、Data Channel以及Hardware API；在此之上是中间的桥接层，桥接层包括Webview、Intercepter、JSBridge、SDK、Plugins等，负责桥接基础层与业务层的沟通，在最上面就是Web前端所要接触的业务层，业务层包括H5 Pages、H5 framework、module等，通过前端的一些代码、一些技术去实现一套业务，也通过这层实现多端统一的目的。

从上往下来看，当点击一个事件或者请求的API，需要调用JSBridge做一个代理，请求底层的API的具体事件，最下层系统层会对事件做一个响应。整个过程的重点在JSBridge的实现。JSBridge是Web和原生端沟通的枢纽，通过callHandle调用native以及registHandle监听native时间两种方法。底层业务的实现通过拦截一个URL，对URL进行数据解码，通过直接输入参数直接调取具体API。通过registHandle监听一些客户端为我们发送一些事件，比如点击分享按钮后，客户端需要告诉我这个按钮被点击了，然后对这个按钮做一个响应，通过registHandle事件通道进行事件的订阅与响应。

JSBridge对于前端来说过于底层，这两个方法调用起来比较复杂，需要判断code码、data是否存在，以及Message信息，在此之上进行了封装，形成JS-SDK。SDK能力就是对JSBridge一个封装，对外输出一致性的API。业务人员调用它去关注传输业务，关注返回的结果。未来可以通过JSBridge这一层达到两端API统一的目的，因为它是中间的桥接层，通过这层来做一个Hybrid和外部API的实现，从而达到API在Web和Hybrid的两端统一。

SDK还增加了一个DEBUG功能，在网页开发过程中，如果跟移动端联调，就需要调用Hybrid的环境。为了满足前端自测效果这个需求，之前会在浏览器实现一套一模一样的API Mock，这样可以在脱离Hybrid环境进行自测，在与客户端联调的时候能更快发现问题，从而排查异常行为。

JSBridge还提供了PLUGINS机制，Hybrid功能分为通用型和业务型两种，通用型功能是封装到一个类里面，比如要实现一个Hybrid页面，可能会继承这个类来进行识别化，这个类的对象作为Webview的实例，其中可能会用到一些API特性，这些特性可能是通用的，也可能非常冷门，对于这些冷门特性需要前端开发人员去拓展冷门API，从而减少通用API的初始化性能损耗，可以使拓展API在初始化时不去格外加载。

为了保证JSBridge的能力以及质量，开发人员提供了一个全面的API文档，文档里面包含45个以上Hybrid常用方法；同时还对JSBridge本身代码层做了完备的单元测试，保证逻辑层百分之百的测试覆盖度。对JSBridge进行封装后，启用数据启动接口，从接口引入JSBridge，然后得到fetch提供的URL，获取需要请求的参数，直到最后获取响应。其中fetch也是调用原生端的实现，相当于继承了原生端一些优化的成果。Hybrid使得应用开发迭代更加灵活，通过native以及Web的结合使得应用开发已经具备了原生的能力，并且拥有灵活上线的特性；对于应用体积，因为我们的逻辑不是在native层实现，所以完全可以在开发之后，通过异步模块的方式再去加载，将业务逻辑转移到前端，控制了发布包体积的问题。

目前Hybrid暂时还没有解决渲染快的问题，Web端除了有一些优势之外，还有一些劣势，会受网络因素的影响，可能导致页面加载不出来或者渲染损耗，需要进一步优化。

3、新浪移动的Hybrid优化方案

传统加载流程的弊端：第一个过程是用户点击各个card后，会进入Webview，Webview去加载URL，此时会有一个加载的loading状态，这个loading状态其实是第一个损耗过程；第二块拿到页面后再去请求服务器端，这也是一个需要等待的过程，这里就是第二块的渲染瓶颈；最后数据以及页面回来之后，才会真正进入渲染步骤，这时页面才会展现在用户面前。这两块就是Hybrid现存的弊端。

针对以上弊端首先通过离线包机制减少Html的下载延时；

再者是通过并行处理方式减少首次请求的加载时长。

除了对Hybrid以上两个弊端进行优化外，还可以通过共享包对Hybrid的公共资源进行优化。

在页面里面通过输入标签的形式直接把URL写上去，这里的URL是与客户端约定的成果，会去走共享包的内容，促使数据拦截机制的实现。解析页面同时，客户端对请求进行拦截，检查离线包的共享包是否有这个内容，如果有的话去反馈该内容，如果没有会进一步穿透http，再去拉这块请求。

在工程化方面提升了开发效率，提供了一套统一的脚手架，通过内置模板帮助业务人员迅速初始化一些项目；对GITLAB CI进行了集成，打包完成后直接推到GITLAB上建一个tag就可以部署到CDN节点上；针对组件提供了组件化支持平台，在打包过程中，通过工具分析页面用到了哪些依赖；Hybrid页面是调用Hybrid的接口，更多地只是在Hybrid环境中运行，在Web端极易出现调用报错等问题，所以通过SDK提供一套Web端JSBridge的模拟实现；最后针对调试环境提供了一套调试入口，Web调试后可以刷新当前页面，更换Webview地址，甚至是一些首次请求参数及log日志的查看功能。

4、Hybrid项目实例及未来展望

在新浪新闻客户端视频模块已经上线的一些Hybrid功能，二楼是新浪新闻客户端内比较重要的入口，在新闻首页下拉会进入二楼页面，这其中有一些动态效果，都是通过前端技术实现的；

精品栏目是第一个Hybrid项目，原来是用Web实现的，这导致精品栏目打开会有白条加载不便，针对这一弊端进行了Hybrid改造，在改造之后上线不到一个月，就接到了商业合作需求；

最后是一个正文，其实早在几年前就用到了Hybrid技术，但由于与端内深度耦合，API针对 View 进行了特殊化定制，不具备通用性，目前也在逐步升级到新的 Hybrid 体系中。

以上三个板块是目前Hybrid的实现和应用，未来会扩大Hybrid增量包的支持，同时会会针对一些页面及新业务，做一些Hybrid的转换；完善发布管理平台，做好Hybrid版本的选择；完善Hybrid的监控系统，利用新浪技术体系的秒开项目，去进行实时的下发，保证Hybrid页面、响应以及下发的流程有一个严格的质量保证。

安卓绿色联盟后续会根据每期技术沙龙议题输出精彩技术干货文章，为未能现场参加技术沙龙的您提供另一个干货学习机会。

微信搜索“安卓绿色联盟”或“AndroidGA”或扫描文末二维码即可关注安卓绿色联盟微信公众号，最新技术沙龙招募、精彩技术干货分享、与专家讲师更多互动等你参与！！！