剖析RN与小程序的底层实现
# RN框架
# 框架
- js层
该层提供了各种供开发者使用的组件以及一些工具库(事件分发等)。 - C++层
主要处理java/OC与js的通信(JSBridge)以及执行JavaScript(JS脚本引擎)。 - Native层(Object C/Java层)
主要包括UI渲染器、网络通信等工具库。根据不同操作系统有不同的实现。
# UI
基于react框架(虚拟dom)
- 首先Js层通过jsx编写的Virtual Dom来构建Component
- Native层将其转成真实DOM插入到原生 App 的页面中。
- 当有变更,通过diff算法生成差异对象
- 最终由 Native层将差异对象应用到原生App的页面元素上。
# 通信
基于JSCore实现js与java/oc交互
- 把JSX代码解析成javaScript代码
- 读取JS文件,并利用利用JS脚本引擎执行
- 返回一个数组,数组中会描述OC/Java对象,描述对象属性和所需要执行的方法,这样就能让这个对象设置属性,并且调用方法。
# 优缺点
优势
- 原生渲染->native体验
- react方便前端开发
- hybrid技术跨平台开发,成本及难度低于原生
- 热更新方便迭代
劣势
- 支持的样式是 CSS 的子集,会满足不了 Web 开发者日渐增长的需求;
- 现有能力下还存在的一些不稳定问题,比如性能、Bug等。
- 把渲染工作全都交由客户端原生渲染,会有更接近原生的体验,但实际上一些简单的界面元素使用 Web 技术渲染完全能胜任
# 小程序底层框架
# 双线程架构
- 渲染层使用WebView渲染WXML+WXSS
- 逻辑层使用JsCore执行js脚本
- webview线程隔离,一个界面一个webview线程
- 线程通信经由微信native
- 逻辑层网络请求经由微信native转发
# 原因
- UI渲染跟 JavaScript 的脚本执行分别在两个线程,从而避免一些逻辑任务抢占UI渲染的资源。
- 为了解决管控与安全问题,提供一个沙箱环境来运行开发者的JavaScript 代码(逻辑层),从而阻止开发者使用一些浏览器提供的,诸如跳转页面、操作DOM、动态执行脚本的开放性接口。
- 渲染层和逻辑层的分离也给在不同的环境下(小程序与小程序开发者工具)运行提供了可能性
# UI
页面渲染
1.在渲染层,宿主环境会把WXML可以先转成JS对象,然后再渲染出真正的Dom树。
2.在逻辑层发生数据变更的时候,需要通过宿主环境提供的setData方法把数据从逻辑层传递到渲染层
3.对比前后差异,把差异应用在原来的Dom树上,渲染出正确的UI界面
组件系统
Exparser组件框架+原生组件
原生组件渲染时
1.渲染层webview创建组件,插入到DOM树中后计算布局(位置与宽高)
2.通过通信机制通知Native,Native会根据布局插入一块原生区域并渲染
3.当webview得知位置或宽高发生变化时,通知Native做相应的调整
# 通信
视图层<->客户端(大部分原生组件涉及)
- iOS 利用WKWebView 的提供 messageHandlers 特性
- 安卓则是往 WebView 的 window 对象注入一个原生方法,最终会封装成 WeiXinJSBridge 这样一个兼容层
逻辑层<->客户端
- iOS平台可以往JavaScripCore框架注入一个全局的原生方法
- 安卓方面则是跟渲染层一致的
# 开发者工具
- 开发者工具中,逻辑层实际上是使用一个隐藏着的标签来模拟JSCore的。并通过将JSCore中不支持的BOM对象局部变量化,使得开发者无法在小程序代码中正常使用BOM,从而避免不必要的错误
- 开发者工具底层维护着一个WebSocket服务器,用于在WebView与开发者工具之间建立可靠的消息通讯链路,使得接口调用,事件通知,数据交换能够正常进行,从而使小程序模拟器成为一个统一的整体
# 优缺点
优势:渲染层和逻辑层分离->渲染快、加载快
劣势:线程通信延时,setData没有diff操作,频繁操作会有明显性能问题
# 总结
# 相同点
- 都具有hybrid技术的优点
- 接近原生的体验
- 跨平台开发
- 使用Web 相关技术框架来编写业务代码
- 各自实现了跨语言通讯方案完成Native(Java/Objective-c/…)端与JavaScript(小程序中为渲染层和逻辑层)的通讯
# 不同点
渲染
- 小程序使用浏览器内核来渲染界面(小部分原生组件由客户端参与渲染),界面主要由成熟的Web技术渲染,辅之大量的接口提供丰富的客户端原生能力
- RN是客户端原生渲染