Open pfan123 opened 4 years ago
在了解 React Native 与小程序前,先来了解一下 Hybrid App。
Hybrid App(混合模式移动应用)是指介于web-app、native-app这两者之间的app,兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。
Native App是一种基于智能手机本地操作系统如 iOS、Android、WP 并使用原生程式编写运行的第三方应用程序,也叫本地app。一般使用的开发语言为JAVA、C++、Objective-C。 Web App 就是运行于网络和标准浏览器上,基于网页技术开发实现特定功能的应用。
以下是与Web App和Native App的对比:
Hybrid App的本质,其实是在原生的 App 中,使用 WebView 作为容器直接承载 Web页面,也有人说成是“套壳”。其中,最核心的点就是 Native端 与 H5端 之间的双向通讯层,其实这里也可以理解为我们需要一套跨语言通讯方案,来完成 Native(Java/Objective-c/...) 与 JavaScript 的通讯。这个方案就是我们所说的JSBridge,而实现的关键便是作为容器的 WebView,一切的原理都是基于 WebView 的机制。
WebView是一个基于webkit引擎、展现web页面的控件。
现在比较流行的混合方案主要有三种,主要是在UI渲染机制上的不同:
以上的三种方案,其实同样都是基于 JSBridge 完成的通讯层,第二三种方案,其实可以看做是在方案一的基础上,继续通过不同的新技术进一步提高了应用的混合程度。
接下来,我们先看一下React Native的方案。
因为React Native的底层为React框架,同样地也体现了虚拟DOM的思想
虚拟DOM具体实现思路: 用 JS 对象模拟 DOM(虚拟DOM) 把此虚拟 DOM 转成真实 DOM 并插入页面中(render) 如果有事件发生修改了虚拟 DOM,比较两棵虚拟 DOM 树的差异,得到差异对象(补丁数组)(diff) 把差异对象(补丁数组)应用到真正的 DOM 树上(patch),优点是能高效的改动 DOM,避免了重新绘制 DOM。
虚拟DOM具体实现思路:
主要是使用 JSCore 实现 JS 和 Object C/Java 交互。大致步骤如下:
JSCore,即JavaScriptCore,JS引擎的核心部分。 iOS使用的是内置的JavaScriptCore,Android使用的是 https://webkit.org 家的jsc.so。
RN 既有 Native 的体验,又能使用前端开发者熟悉的 React 框架,并具有 hybrid 技术的优点,能跨平台开发,能远程更新代码,提高迭代频率和效率。 但还有以下不足:
接下来,我们来看一下小程序的双线程的模式。
小程序的主要开发语言是 JavaScript ,所以通常小程序的开发会被用来同普通的网页开发来做对比。两者有很大的相似性,对于前端开发者而言,从网页开发迁移到小程序的开发成本并不高,但是二者还是有些许区别的。
网页开发渲染线程和脚本线程是互斥的,这也是为什么长时间的脚本运行可能会导致页面失去响应,而在小程序中,二者是分开的,分别运行在不同的线程中。网页开发者可以使用到各种浏览器暴露出来的 DOM API,进行 DOM 选中和操作。
小程序的逻辑层和渲染层是分开的,逻辑层运行在 JSCore 中,并没有一个完整浏览器对象,因而缺少相关的DOM API和BOM API。这一区别导致了前端开发非常熟悉的一些库,例如 jQuery、 Zepto 等,在小程序中是无法运行的。同时 JSCore 的环境同 NodeJS 环境也是不尽相同,所以一些 NPM 的包在小程序中也是无法运行的。
网页开发者需要面对的环境是各式各样的浏览器,PC 端需要面对 IE、Chrome、QQ浏览器等,在移动端需要面对Safari、Chrome以及 iOS、Android 系统中的各式 WebView 。而小程序开发过程中需要面对的是两大操作系统 iOS 和 Android 的微信客户端,以及用于辅助开发的小程序开发者工具,小程序中三大运行环境也是有所区别:
小程序的运行环境分成渲染层和逻辑层,WXML 模板和 WXSS 样式工作在渲染层,JS 脚本工作在逻辑层。小程序的渲染层和逻辑层分别由2个线程管理:渲染层的界面使用了WebView 进行渲染;逻辑层采用JsCore线程运行JS脚本。 一个小程序存在多个界面,所以渲染层存在多个WebView线程。这使得小程序更贴近原生体验,也避免了单个WebView的任务过于繁重。 这两个线程的通信会经由微信客户端(Native)做中转,逻辑层发送网络请求也经由Native转发。
小程序的渲染层和逻辑层分离主要有两个原因:
与RN一样,小程序在页面渲染上也体现了虚拟DOM的思想。
在组件系统方面,小程序的大部分组件由 Exparser 组件框架实现,小部分原生组件由客户端参与组件的渲染,以提供更好的性能。 比如原生组件 map,在实际运行时,
map
Exparser 是微信小程序的组件组织框架,内置在小程序基础库中,为小程序的各种组件提供基础的支持。小程序内的所有组件,包括内置组件和自定义组件,都由 Exparser 组织管理。 Exparser 的主要特点包括以下几点: 基于 Shadow DOM 模型:模型上与 WebComponents 的 ShadowDOM 高度相似,但不依赖浏览器的原生支持,也没有其他依赖库;实现时,还针对性地增加了其他 API 以支持小程序组件编程。 可在纯 JS 环境中运行:这意味着逻辑层也具有一定的组件树组织能力。 高效轻量:性能表现好,在组件实例极多的环境下表现尤其优异,同时代码尺寸也较小。 小程序中,所有节点树相关的操作都依赖于Exparser,包括 WXML 到页面最终节点树的构建、createSelectorQuery 调用和自定义组件特性等。
Exparser 是微信小程序的组件组织框架,内置在小程序基础库中,为小程序的各种组件提供基础的支持。小程序内的所有组件,包括内置组件和自定义组件,都由 Exparser 组织管理。
Exparser 的主要特点包括以下几点:
小程序中,所有节点树相关的操作都依赖于Exparser,包括 WXML 到页面最终节点树的构建、createSelectorQuery 调用和自定义组件特性等。
那么,渲染层与逻辑层是怎么与Native通信的呢? 在视图层与客户端的交互通信(基本上只是原生组件会用到)方面,
在逻辑层与客户端原生通信机制方面,
前面提到渲染层和逻辑层的分离也给在不同的环境下运行提供了可能性。在开发者工具中,逻辑层实际上是使用一个隐藏着的标签来模拟 JSCore。并通过将 JSCore 中不支持的 BOM 对象局部变量化,使得开发者无法在小程序代码中正常使用 BOM,从而避免不必要的错误。 在通讯机制方面,开发者工具底层维护着一个 WebSocket 服务器,用于在 WebView 与开发者工具之间建立可靠的消息通讯链路,使得接口调用,事件通知,数据交换能够正常进行,从而使小程序模拟器成为一个统一的整体。 详细可看官网上的 微信开发者工具
小程序双线程模型中,渲染层和逻辑层分离,具有渲染快、加载快的优点; 但任何数据传递都是线程间的通信,也就是都会有一定的延时。这会使得各部分的运行时序变得复杂一些。详细可以看官网上的 天生的延时
RN 与小程序 都具有 hybrid 技术的优点,兼具 “Native App良好用户交互体验的优势” 和 “Web App跨平台开发的优势”。 从框架来说,都使用 Web 相关技术来编写业务代码;都实现了一套跨语言通讯方案,来完成 Native(Java/Objective-c/…) 端 与 JavaScript (小程序中分为渲染层和逻辑层)的通讯。
从渲染底层来看,小程序使用浏览器内核来渲染界面(小部分原生组件由客户端参与渲染),即界面主要由成熟的 Web 技术渲染,辅之以大量的接口提供丰富的客户端原生能力;而 RN 则是用客户端原生渲染的。
Hybrid App技术解析 – 原理篇
React Native for Android 原理分析与实践:实现原理
【React Native】从源码一步一步解析它的实现原理
小程序开发指南
React Native中文网
浅谈小程序运行机制
小程序架构问题
小程序底层框架
揭秘:支付宝小程序 V8 Worker 技术演进
Hybrid App
在了解 React Native 与小程序前,先来了解一下 Hybrid App。
优势
Hybrid App(混合模式移动应用)是指介于web-app、native-app这两者之间的app,兼具“Native App良好用户交互体验的优势”和“Web App跨平台开发的优势”。
以下是与Web App和Native App的对比:
技术原理
Hybrid App的本质,其实是在原生的 App 中,使用 WebView 作为容器直接承载 Web页面,也有人说成是“套壳”。其中,最核心的点就是 Native端 与 H5端 之间的双向通讯层,其实这里也可以理解为我们需要一套跨语言通讯方案,来完成 Native(Java/Objective-c/...) 与 JavaScript 的通讯。这个方案就是我们所说的JSBridge,而实现的关键便是作为容器的 WebView,一切的原理都是基于 WebView 的机制。
现有方案
现在比较流行的混合方案主要有三种,主要是在UI渲染机制上的不同:
以上的三种方案,其实同样都是基于 JSBridge 完成的通讯层,第二三种方案,其实可以看做是在方案一的基础上,继续通过不同的新技术进一步提高了应用的混合程度。
接下来,我们先看一下React Native的方案。
React Native的底层框架
总体框架
UI渲染
因为React Native的底层为React框架,同样地也体现了虚拟DOM的思想
通信机制
主要是使用 JSCore 实现 JS 和 Object C/Java 交互。大致步骤如下:
小结
RN 既有 Native 的体验,又能使用前端开发者熟悉的 React 框架,并具有 hybrid 技术的优点,能跨平台开发,能远程更新代码,提高迭代频率和效率。 但还有以下不足:
接下来,我们来看一下小程序的双线程的模式。
小程序的底层框架
小程序与普通网页开发的区别
小程序的主要开发语言是 JavaScript ,所以通常小程序的开发会被用来同普通的网页开发来做对比。两者有很大的相似性,对于前端开发者而言,从网页开发迁移到小程序的开发成本并不高,但是二者还是有些许区别的。
网页开发渲染线程和脚本线程是互斥的,这也是为什么长时间的脚本运行可能会导致页面失去响应,而在小程序中,二者是分开的,分别运行在不同的线程中。网页开发者可以使用到各种浏览器暴露出来的 DOM API,进行 DOM 选中和操作。
网页开发者需要面对的环境是各式各样的浏览器,PC 端需要面对 IE、Chrome、QQ浏览器等,在移动端需要面对Safari、Chrome以及 iOS、Android 系统中的各式 WebView 。而小程序开发过程中需要面对的是两大操作系统 iOS 和 Android 的微信客户端,以及用于辅助开发的小程序开发者工具,小程序中三大运行环境也是有所区别:
双线程模型
小程序的运行环境分成渲染层和逻辑层,WXML 模板和 WXSS 样式工作在渲染层,JS 脚本工作在逻辑层。小程序的渲染层和逻辑层分别由2个线程管理:渲染层的界面使用了WebView 进行渲染;逻辑层采用JsCore线程运行JS脚本。 一个小程序存在多个界面,所以渲染层存在多个WebView线程。这使得小程序更贴近原生体验,也避免了单个WebView的任务过于繁重。 这两个线程的通信会经由微信客户端(Native)做中转,逻辑层发送网络请求也经由Native转发。
原因
小程序的渲染层和逻辑层分离主要有两个原因:
UI渲染
与RN一样,小程序在页面渲染上也体现了虚拟DOM的思想。
在组件系统方面,小程序的大部分组件由 Exparser 组件框架实现,小部分原生组件由客户端参与组件的渲染,以提供更好的性能。 比如原生组件
map
,在实际运行时,通信原理
那么,渲染层与逻辑层是怎么与Native通信的呢? 在视图层与客户端的交互通信(基本上只是原生组件会用到)方面,
在逻辑层与客户端原生通信机制方面,
开发者工具
前面提到渲染层和逻辑层的分离也给在不同的环境下运行提供了可能性。在开发者工具中,逻辑层实际上是使用一个隐藏着的标签来模拟 JSCore。并通过将 JSCore 中不支持的 BOM 对象局部变量化,使得开发者无法在小程序代码中正常使用 BOM,从而避免不必要的错误。 在通讯机制方面,开发者工具底层维护着一个 WebSocket 服务器,用于在 WebView 与开发者工具之间建立可靠的消息通讯链路,使得接口调用,事件通知,数据交换能够正常进行,从而使小程序模拟器成为一个统一的整体。 详细可看官网上的 微信开发者工具
小结
小程序双线程模型中,渲染层和逻辑层分离,具有渲染快、加载快的优点; 但任何数据传递都是线程间的通信,也就是都会有一定的延时。这会使得各部分的运行时序变得复杂一些。详细可以看官网上的 天生的延时
总结
共同点
RN 与小程序 都具有 hybrid 技术的优点,兼具 “Native App良好用户交互体验的优势” 和 “Web App跨平台开发的优势”。 从框架来说,都使用 Web 相关技术来编写业务代码;都实现了一套跨语言通讯方案,来完成 Native(Java/Objective-c/…) 端 与 JavaScript (小程序中分为渲染层和逻辑层)的通讯。
不同点
从渲染底层来看,小程序使用浏览器内核来渲染界面(小部分原生组件由客户端参与渲染),即界面主要由成熟的 Web 技术渲染,辅之以大量的接口提供丰富的客户端原生能力;而 RN 则是用客户端原生渲染的。
Other Resources
Hybrid App技术解析 – 原理篇
React Native for Android 原理分析与实践:实现原理
【React Native】从源码一步一步解析它的实现原理
小程序开发指南
React Native中文网
浅谈小程序运行机制
小程序架构问题
小程序底层框架
揭秘:支付宝小程序 V8 Worker 技术演进