JSPatch 和 React Native 的区别
前言
去年的3月份,很多苹果开发者可能都收到了苹果对于热更新的警告邮件。收到邮件的很可能代码中使用了类似 JSPatch 这样的热修复框架。
同时很多没有使用 JSPatch 等类似框架的开发者可能也收到了这份警告邮件,这很可能是苹果的代码检测机制的误伤。不过这也引起了很多使用 React Native 这类框架的开发者的担忧,是不是说以后也不能使用 React Native 这类框架了?
答案当然是可以继续使用 React Native 了。我这里会详细说明一下为什么,主要从两者的原理和能力来阐述。
JSPatch 的原理
JSPatch 的代码非常精炼。核心文件就两个,一个是 JSPatch.js
,另外一个是 JSEngine.m
。实现主要依赖两个:
- Objective C 语言的动态属性
- JavaScriptCore 通过 JS 调用 Native 的能力
JSPatch 的核心文件也分别对应了这两者。JSEngine.m
主要是定义一套原生接口给 JSPatch.js
使用,这套原生接口使用了 OBjective C 语言的动态能力。JSPatch.js
则是定义了一套 JS 接口给开发者使用,开发者可以基于这套接口写热更新代码。JSPatch.js
定义的这套接口相当于一层 DSL。JSPatch 的 GitHub 上的文档详细介绍了这套 DSL JSPatch-基础用法
结合两者使得 JSPatch 的能力十分强大,可以通过 JS 任意调用原生 API。
React Native 的能力
React Native 是一个非常庞大的项目,我这边暂时还没有去详细阅读过源码。我主要讲一下 React Native 是如何和原生交互的。关于更详细的描述可能查看 官方文档
React Native 主要有两种与原生代码交互的途径。官方文档将其描述成 Native Modules
和 Native UI Components
。
Native Modules
,说明如何将原生的代码(与 UI 无关)暴露给 RN 的 JS 代码Native UI Components
,说明如何将原生的 UI 组件暴露给 RN 的 JS 代码
注意,这两者都需要写原生代码,同时重新打包运行,这样暴露出来接口才能被 JS 代码调用执行。也就是说这里没有热更新。
与原生交互,我们比较关注
- JS 如何调用原生代码并取得返回值
- 原生代码如何调用 JS 代码并获得返回值
对于前者,官方文档已经详细的阐述了。主要是 Callback、Promises。
对于后者,官方文档中说的并不详细,需要将文档中的手段结合起来使用。总的来说比较复杂。
总结一下 RN,本质上来说 RN 是自成一体的,我们只能在 RN 的能力范围内具备热更新能力。RN 的能力主要来自两方面:
- RN 的原生代码库,这套代码库使得我们可以基于此编写 JS 的 UI,进行网络请求以及其他一些原生服务,比如地理位置服务、推送等。这些方面都能进行热更新。RN 的官方文档也几乎全是关于这方面的内容
- 我们自己编写的并暴露给 RN 的原生代码,可以基于此编写相应地 JS 代码,RN 的官方文档详细的描述了这一方面的规范。在我们自己的 RN 原生模块范围内能够进行热更新
总结
通过上面的描述,我们知道了:
- JSPatch 很强大,可以通过 JS 任意调用原生 API。所以 JSPatch 的热更新能力是全面的。
- React Native 也很强大,但是其强大是克制的。其提供的热更新能力基本上只是写界面,编写一些通常的业务逻辑。