评论

小程序架构设计(二)

这篇文章会接着讲小程序架构设计的历史

接着上篇文章《小程序架构设计(一)》

前边我们说到采用Web+离线包的方式可以解决很多问题,但是遗留了一个安全问题有待解决。

经过了一番讨论,我们决定把开发者的JS逻辑代码放到单独的线程去运行,因为不在Webview线程里,所以这个环境没有Webview任何接口,自然的开发者就没法直接操作Dom,也就没法动态去更改界面,“管控”的问题得以解决。

还存在一个问题:开发者没法操作Dom,如果用户交互需要界面变化的话,开发者就没办法动态变化界面了。所以我们要找到一个办法:不直接操作Dom也能做到界面更新。

其实Facebook早有方案解决这个问题,就是上篇文章提到的React。React引入了Virtual Dom的概念(后文简称VD),业务侧只需要改变数据即可引起界面变化,相关原理后边再写篇文章来分享。

至此小程序双线程的模型就定下来了:渲染层(Webview)+逻辑层(JSCore)

其中渲染层用了Webview进行渲染,开发者的JS逻辑运行在一个独立的JSCore线程。

渲染层提供了带有数据绑定语法的WXML,逻辑层提供了setData等等API,开发者需要进行界面变化时,只需要通过setData把变化的数据传进去,小程序框架就会进行Dom Diff等流程最后把正确的结果更新在Dom树上。

可以看到在开发者的逻辑下层,还需要有一层小程序框架的支持(数据通信、API、VD算法等等),我们把它称为基础库。

我们在两个线程各自注入了一份基础库,渲染层的基础库含有VD的处理以及底层组件系统的机制,对上层提供一些内置组件,例如video、image等等。逻辑层的基础库主要会提供给上层一些API,例如大家经常用到的wx.login、wx.getSystemInfo等等。

解决了渲染问题,我们还要看一下用户在和界面交互时的问题。

用户在屏幕点击某个按钮,开发者的逻辑层要处理一些事情,然后再通过setData引起界面变化,整个过程需要四次通信。对于一些强交互(例如拖动视频进度条)的场景,这样的处理流程会导致用户的操作很卡。

对于这种强交互的场景,我们引入了原生组件,这样用户和原生组件的交互可以节省两次通信。

正如上图所示,原生组件和Webview不是在同一层级进行渲染,原生组件其实是叠在Webview之上,想必大家都遇到过这个问题,video、input、map等等原生组件总是盖在其他组件之上,这就是这个设计带来的问题。

我们也很重视这个问题,经过了一段时间的努力,我们攻克了这个难题,把原生组件渲染到Webview里,从而实现同层渲染。目前video组件已经完成同层渲染的全量发布,详细可以看我们之前的公告:同层渲染公测

为了让开发者可以更好的开发小程序,我们在后来还引入了自定义组件和插件的概念,我们后续会有相关的文章再介绍这两块的设计,希望大家关注我们社区的文章板块。

以上就是小程序架构设计的历史。

最后一次编辑于  2019-02-27  
点赞 25
收藏
评论

11 个评论

  • 后米米米米
    后米米米米
    2019-02-28

    所以,原生组件是同层渲染,但是可以直接和逻辑层直接通信?

    2019-02-28
    赞同
    回复 2

正在加载...

登录 后发表内容