Web Renderer

Web Renderer方案从实现的方案、机制和各种处理事件响应的逻辑与顺序都与终端保持高度一致性。使得Web-Renderer能够直接使用Hippy基于Native方案构建的jsbundle.js产物，在高度保持与终端侧渲染效果一致的情况下，使得复用JS层代码变的可能和简单。

原理解析

Hippy2.0方案

上面第一章图是当前hippy的架构图，里面比较细节的展示了js、c++、native的各自组成内容。然后第二张图是在前端的角度，做了一些简化和抽象后的架构图。

JS运行环境

当前hippy2.0的方案下，JS相关的代码一般由两部分组成，一部分是业务也就是平时大家写的，还有一部分是hippy-react和hippy-vue，这里面是对hippy终端提供的基础功能、协议的封装。而除开这两部分内容还有一部分内容是js逻辑是在c++里面的，在js引擎创建的时候会注入进去。这块代码主要是用来进行js运行环境的提供，如一些环境变量、全局的api（settimeout）等以支持UI框架的运行。

桥的实现

这里的js-bridge用以将js产生的数据和调用序列化后传递给终端。

调用解析/调用分发

终端在接受到js侧传递过来的数据时，需要进行解析然后分发给对应的处理对象进行处理。

组件/模块/事件的实现

是调用分发的承接者，如：调用解析到要创建一个组件，则就会将这个调用分发到组件这里然后创建出一个组件出来。

基于中间层的实现

在前面的内容，我们提到了hippy2.0方案中的几个关键的内容，其中在“桥的实现”和“调用解析分发”那里平凡提到了js侧产生的数据，接下来将详细讲述一些这些数据是什么、能干些什么。

上图是hippy终端方案交互层的抽象，现在的hippy2.0的方案中js引擎运转后会输出一些列的数据，其中包了ui指令（用来创建组件、更新组件、删除组件）、模块的功能调用、组件的api调用等。终端在接收和处理各种指令后，也会向js引擎派发事件、js侧的api调用、callback。

我们在这里将这块用来交互的内容称为中间层，这块中间层的内容是由hippy方案这么多年演进并且稳定下来的。是标准化的、平台无关的。这块中间层的内容，终端有一套完整的解析和处理逻辑，也正是因为这套逻辑才能构建出ui并且产生正确的交互。理论上来说只要能够完成对中间层内容的正确解析和实现，就能够实现与终端一直的渲染效果。

接下来看两个交互数据的例子：

createNode
{
    "id": 64,
    "pId": 20,
    "index": 0,
    "name": "View",
    "props": {
        "onLayout": true,
        "style": {
            "flex": 1
        },
    },
    "tagName": "View"
}

这是一个创建组件的指令，

creatNode指明是要进行ui创建
id代表终端和Web用来对这个ui的唯一标识
pId代表这个节点创建后将要被插入到哪个父节点下
index代表了插入到父节点下的第几个位置
name代表了创建的是一个什么类型的组件
props是对这个组件的哪些属性进行设置已经参数是什么

receiveUIComponentEvent
[
    287,
    "onPageSelected",
    {
        "position": 0
    }
]

这是一个终端对前端的ui事件指令，在数组中

第一个数字代表了这个ui事件要分发给id为287的这个组件，
第二个参数onPageSelected标识这次分发的事件的名称，
第三个参数代表这个事件携带的参数。

通过上面的内容可以看出正式通过js和终端不断的交互,然后解析这些交互内容并且分发到实现对象上，来构造ui，响应用户的操作。所以Web场景下，也需要完成对这些内容的解析和实现，这样才能从机制、流程和功能甚至是异常情况都达到与终端的一致性。从而实现比较平滑的进行渲染层切换，开发者在不同渲染层的成本也会更低更低。而Web-Renderer正是在浏览器上完成了这一系列的标准内容解析和功能提供，让Web-Renderer可以使用相同的构建产物，并且表现上高度一致

基于中间层实现，Native VS Web 流程对比

在基于中间层这个技术关键点完成Web-Renderer方案后，可以看到与Native方案的对比，Web-Renderer使用与其相同的构建产物，一致的渲染流程。而不同的是最后落地到的UI和功能上，一个是落地到浏览器提供的上面，一个是落地到 Android/iOS提供的上面。

5.0 KiB Raw Permalink Blame History