共计 14610 个字符,预计需要花费 37 分钟才能阅读完成。
前言
React Native 作为一款跨端框架,有一个最让人头疼的问题,那就是 版本更新。尤其是遇到大版本更新,JavaScript、iOS 和 Android 三端的配置构建文件都有十分大的变动,有时候三者的配置文件又相互耦合在一起,往往牵一发而动全身。
本文假设 React Native 降级的主导者是 前端 同学,比拟相熟 javaScript 为主的一套前端构建流程。如果有条件,降级时强烈建议拉上 iOS 和 Android 开发,对于一些琐碎的降级细节,当面沟通远比搜索引擎高效。
提醒:因为每次批改和新增内容都会暗藏文章从新审核,倡议浏览博客原文获得最佳浏览体验
???? 浏览博客原文
感觉文章对你有用的话肯定要记得 点赞 哦 ????,谢谢你,这对我来说真的很重要!
一、磨刀不误砍柴工
这部分常识我认为是最重要的,毕竟 版本更新是永恒的,操作流程却是不变的。
具体介绍各端构建工具前,咱们抛开各种技术细节,从整个我的项目的生命周期登程,看看大部分产品是怎么做技术布局的:
- 产品晚期 :架构都比较简单,整个我的项目拿个 配置文件 做配置就好了,配置文件越简略越好,xml、json 就被拿进去用了
- 产品发展期 :须要配置的中央变多了,这时候 多加几个配置项多加几个参数,尽管有些繁琐,但动态的配置文件还够用
- 产品成熟期 :人员扩增代码收缩,动态的配置文件齐全不够用了,为了达到动静配置的目标,往往会引入一门 脚本语言 或借鉴一套 DSL 来治理相干配置
产品早期:一把火烧了重整旗鼓(记得删掉)
理清一个技术产品的生命周期后,你就会对日常开发中配置文件有了整体的认知:那些又臭又长的配置项,乌七八糟的兼容写法,毫无美感的 DSL,最神奇的是这些七拼八凑的货色还能把我的项目跑起来,Build 胜利的那一刻你肯定会对这种人类奇观收回由衷的钦佩之情——原来这就叫业余啊!
收一收磅礴的情绪,牢记下面的领导教训,咱们上面开始探讨技术细节。
1.【Web 前端】我的项目配置
前端工程化始终是前端外面的热点,尽管始终很热,然而具体实现还是一团糟。集体认为起因次要有两点,一个是前端构建从无到有,相对而言基础薄弱;一个是社区推动,百花齐放的同时又没有统一标准。就拿当初前端的次要配置文件来说:
- 用
package.json
治理 npm 包 - 用 npm script 实现流程治理,有时候还要把相干脚本塞到
package.json
里 - 用 eslint 进行编码标准,有时候还要写个
.eslintrc.js
- 用 babel 解决语法兼容,有时候还要写个
babel.config.js
- 用 webpack 进行我的项目构建和打包公布
- ……
下面只是列出了几个支流配置,不出意外的话,当初你的我的项目里曾经有 5 个 配置文件 了,在 JavaScript 这个前端万能 脚本语言 的粘合下,这些配置文件还能够 相互援用相互耦合,复杂度搞成这样,开发体验还没有 iOS Android 的一半好。
如果你认为我只是单纯的批评前端那你就了解错了,我想表白的是,这么简单的配置都能搞定,iOS Android 的我的项目配置还不是 手到擒来?
2.【iOS】我的项目配置
iOS 我的项目次要有两个点:project.pbxproj 和 CocoaPods。这两块儿的常识理解后,降级 RN 就齐全不虚了。
1⃣️ project.pbxproj 与 Xcode
project.pbxproj
就是一个 iOS 我的项目的 配置文件,从数据结构特点上有些像 JSON,年龄能够追溯到 NeXT,可读性根本为 0,每次 git 合并都是纯黑的噩梦。不信你瞅瞅下图,这是给人看的吗。
可读性这么差的货色能传下来,其实全靠 XCode 这个 IDE 给它续命。咱们每次在 XCode 里批改的配置,例如 Build Settings
等选项,最初都会反映到 project.pbxproj
这个配置文件上,也算是一种另类 DSL 了。
project.pbxproj
相干的常识我举荐上面几篇文章,浏览后会让你对 iOS 编译打包流程有个更深的理解:
- iOS 开发 xcode 中的 project.pbxproj — 深刻分析:介绍了
project.pbxproj
文件的一些特点 - Xcode 工程文件 project.pbxproj 小结:看完后会对 XCode 配置和
project.pbxproj
文件的对应关系有着更粗浅的理解 - Xcode – Target , PROJECT 区别:介绍了 Xcode 中各个配置项是什么意思
- XCode Build 过程
2⃣️ CocoaPods
CocoaPods 是一个负责管理 iOS 我的项目中第三方开源库的工具,目前支流 iOS 工程都是用 CocoaPods 治理第三方库的。
React Native 在 0.60 里终于用上了 CocoaPods,和 iOS 社区各自为政了起来。这样做的益处就是后续保护和迭代的压力会小很多,鬼晓得我以前降级各种 iOS SDK 的日子是怎么熬过来的。
绝对 project.pbxproj
,CocoaPods 无疑简略了不少,写配置脚本的 Ruby 语言也比拟清新,Podfile 的可读性要高很多。
platform :ios, '9.0'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
target '项目名称' do
pod 'React', :path => '../node_modules/react-native/'
pod 'React-Core', :path => '../node_modules/react-native/React'
use_native_modules!
end
CocoaPods 的学习材料能够参考下文,不够的话自行搜寻即可:
CocoaPods 应用教程
3.【Android】我的项目配置
Android 的我的项目配置次要是由 gradle 文件管制的,gradle 文件又由 Groovy 这门 JVM 系的脚本语言书写。到这里思路就很显著了,咱们只有理解一些 Groovy 的语法和 gradle 的写法,就能读懂和批改 Android 的配置文件了。在这里我举荐一些相干教程,读完后就会有个大抵的理解:
- Groovy 脚本根底全攻略
- Gradle 脚本根底全攻略
- Gradle 提醒与窍门
学习了根底的语法后,再回到 Android 工程上来。Android 的我的项目配置次要由 3 个文件管制,降级时抵触较多的也是这 3 个文件:
settings.gradle
:用来批示 Gradle 在构建利用时应将哪些模块蕴含在内build.gradle
:定义实用于我的项目中所有模块的构建配置app/build.gradle
:定义 App 的构建配置
集体认为 Android 的 Gradle 配置还是比拟容易入门的,因为 gradle 文件有个益处,能够 随便的增加正文。大家能够花点儿工夫把每个配置项都加上正文,这样在降级改变过程中就不容易发怵。
4.RN 官网降级助手
React Native 官网在 2019 年 7 月 0.60 大版本更新时,推出了 Upgrade Helper 这个 Diff 小工具。通过这个工具咱们能够不便的看出版本更新时各个配置脚本的改变,十分的不便。
二、降级流程
RN 版本升级时,我的降级流程个别是这样的:
- 通顺的网络环境,能够自在拜访 Google 那种
- 查看官网博客,获取版本更新的次要内容
- 浏览 RN GitHub 上的 CHANGELOG,获取版本更新的具体改变,适配 API 变更
- 浏览第三方依赖的
README.md
文件,是否须要同步降级 - 应用 Upgrade Helper 做版本 Diff,并浏览 upgrading-react-native 的相干博文,批改我的项目配置文件与配置脚本
- 删除 node_modules 与缓存,从新 Build 我的项目,如果 Build 失败,依据报错信息搜寻 or 询问 Native 开发同学
- 回归测试
在更新过程中,集体倡议 git commit 操作要尽量原子化,不便后续复盘和回滚,小心驶得万年船。
在我理论降级中,因为 React Native 0.59 到 0.60 有十分大的变动,并且业务较为简单,降级 0.60 花了两个星期的工夫:iOS 一周,Android 一周;0.61 和 0.62 的降级就比较简单了,大略一两个小时就能够降级好。
三、React Native 0.60 降级
2019 年 7 月 3 日 Facebook 官网公布了 React Native 0.60,这是一次十分大的版本更新,尽管没有增加新的性能,然而在底层上做了很多优化,向支流配置靠齐:
- 移除 WebView 等组件交给 react-native-community 社区保护
- 利用 CocoaPods 治理 iOS 的第三方依赖,向 iOS 支流配置靠齐
- Android 迁徙到 AndroidX,不便后续的降级与更新
- React Native 的一些第三方包会主动链接,不再须要手动应用
react-native link *
了
0.60 降级时肯定要有急躁,不可能一次性胜利的,倡议参考 Upgrade Helper 和 Upgrade to React Native 0.60 这篇博文,我会对文中没有阐明的中央进行补充。
降级前先确保相干第三方包曾经是最新版本。
1.React Native
JavaScript 这里相对来说好降级一些,毕竟是前端程序员的主场。依据 Diff 差别降级版本号后,还须要留神以下几点:
1⃣️ 局部 RN 内置组件交给社区保护
NetInfo、WebView 和 Geolocation 从 React Native 中移除,交给 react-native-community 社区保护。所以咱们须要批改 import
时的门路。
Slider、AsyncStorage、CameraRoll、Clipboard 等组件也有移除打算,这次降级也能够顺便迁徙一下。
值得注意的是,react-native-webview 在一次更新中为了响应 App Store 政策,曾经移除了 UIWebView,只反对 WKWebView。如果你做过挪动端的适配,你必定明确 WKWebview 对 cookie 反对不太敌对,这里须要重点回归测试一下;另外一点是如果 RN 和 H5 网页是通过 postMessage
的形式交互,相干 API 也有一些不兼容更新,这里须要重点适配一下,具体细节能够看文档。
2⃣️ SwipeableFlatList 移除
SwipeableFlatList 是 React Native 在 0.5X 某个版本提供的 侧滑删除列表组件,尽管始终没有官网文档中放进去,然而社区上曾经有很多人在应用了。可能对这个组件的实现不太称心,官网在 0.60 里删除了这个组件。为了不让我的项目报错,咱们可能须要把 SwipeableFlatList 相干的源码拿进去本人手动保护一下,有人把相干代码提出来保护了一个 npm 包——react-native-swipeable-lists,大家能够引入临时适度一下。
2.iOS
0.60 版本的 React Native 反对 CocoaPods,2020 年了,RN 终于反对 CocoaPods 了,没有 CocoaPods 的时代,为了应用一些 iOS 第三方库,咱们必须手动把库文件拖到主工程里,降级和保护十分不不便。因为 0.61 版本 CocoaPods 是惟一可选包治理计划,所以强烈建议间接降级应用。
1⃣️ 迁徙到 CocoaPods & Autolinking 反对
迁徙 CocoaPods 前,先在 CLI 里输出一下命令 unlink Native Modules:
react-native unlink
unlink 后就要迁徙到 CocoaPods 了。迁徙前确保 Ruby 和 CocoaPods 曾经装置胜利,具体的装置过程不是本文重点就不开展了,没有装置的同学自行 Google 搜寻。
咱们在 ios 目录里新建一个文件 Podfile
,在外面输出以下代码:
platform :ios, '9.0'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
target '项目名称' do
pod 'React', :path => '../node_modules/react-native/'
pod 'React-Core', :path => '../node_modules/react-native/React'
pod 'React-DevSupport', :path => '../node_modules/react-native/React'
pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS'
pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation'
pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob'
pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image'
pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS'
pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network'
pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings'
pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text'
pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration'
pod 'React-RCTWebSocket', :path => '../node_modules/react-native/Libraries/WebSocket'
pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact'
pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi'
pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor'
pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector'
pod 'yoga', :path => '../node_modules/react-native/ReactCommon/yoga'
pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
target '项目名称 Tests' do
inherit! :search_paths
# Pods for testing
end
use_native_modules!
end
下面这段代码,pod
结尾的都是从 node_modules
目录导入 react-native
相干的官网代码。上面两行代码是实现 autolink 的性能:
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
target '项目名称' do
...
use_native_modules!
end
Podfile
配置好后,就在 ios 文件夹下运行 pod install
,装置相干依赖。
装置胜利后会生成一个 xcworkspace 空间,这时候你须要退出以后的 xcodeproj 我的项目,关上 xcworkspace。
在 xcworkspace 里,首先有两个顶层文件夹,一个是你的 xcodeproj 我的项目,一个是 Pods 文件夹(左图):前者蕴含着你的业务代码,后者管理者装置的第三方库文件。这时候须要手动把 你的我的项目 /Libraries
目录下的 *.xcodeproj
文件手动删除(右图红框 ➊),因为他们曾经存在于 Pods 文件夹里了(右图红框 ➋)。
2⃣️ 批改 Header Search Path
上一步批改了 React Native 我的项目的援用形式,但还有一个问题,那就是寻址的头文件门路并没有批改过去,咱们能够察看上面两张图:
- 原来的 Header Search Path 指向的是
$(SRCROOT)/../node_modules/*
- 应用 CocoaPods 后门路产生了变动,变成了
$(PODS_CONFIGURATION_BUILD_DIR)/*
过后这个变动卡了我一天,而且这个变动是在 project.pbxproj
中的,十分难以浏览就疏忽掉了。起初通过新建一个 RN 新我的项目发现了问题。解决办法是删除原来的 Header Search Path 内容,手动把新的门路增加进去。
下面两步做完后能够尝试 build 一下我的项目,大概率你会发现还是 build 不起来。因为谬误起因千奇百怪我也无奈一一笼罩,这里还是问 Google 比拟不便。
3⃣️ 新增 Start Packager 脚本
到这一步假如你曾经 Build 起来 iOS 我的项目了,这时候你会发现一个问题,之前 iOS build 胜利后,会主动启动一个 node 服务器编译 javascript 文件,更新后并没有主动启动 node 服务器,须要咱们手动 npm run start
启动 node 服务器,十分的不不便。
问题出在哪里呢?起因是在原来的构建形式里,Libraries 下的 React.xcodeproj
有个 Start Packager 脚本,这个脚本会在我的项目 build 胜利后主动启动一个 node 服务器:
迁徙到 Pods 后,这个脚本就没有了,须要咱们在主工程里手动增加一下。增加形式也很简略,我在下图也标注好了,点击我的项目文件夹,在 TARGETS
的 Build Phases
里点击 ➕,再点击 New Run Script Phase
新增一个脚本区域,而后把上面的代码填写进去:
export RCT_METRO_PORT="${RCT_METRO_PORT:=8081}"
echo "export RCT_METRO_PORT=${RCT_METRO_PORT}" > "${SRCROOT}/../node_modules/react-native/scripts/.packager.env"
if [-z "${RCT_NO_LAUNCH_PACKAGER+xxx}" ] ; then
if nc -w 5 -z localhost ${RCT_METRO_PORT} ; then
if ! curl -s "http://localhost:${RCT_METRO_PORT}/status" | grep -q "packager-status:running" ; then
echo "Port ${RCT_METRO_PORT} already in use, packager is either not running or not running correctly"
exit 2
fi
else
open "$SRCROOT/../node_modules/react-native/scripts/launchPackager.command" || echo "Can't start packager automatically"
fi
fi
这个 Start Packager 脚本的地位也有些考究,最好放在 Check Pods Manifest.lock
和 Compile Sources
之间,要不然启动 node 服务器时会导致报错。
4⃣️ 新增 LaunchScreen.storyboard
随着 iPhone 产品线的增多,iPhone 手机的尺寸也多了起来,原来一个尺寸配一个 LaunchImage
的形式逐步变的不再实用,这时候 官网倡议用 LaunchScreen.storyboard
来制作启动屏,并且要求 2021 年所有 APP 都得改为此计划。
具体的配置网上有很多教程了,大家搜寻参考配置就好。我集体参考了以下教程:
- iOS 开发时如何应用 Launch Screen Storyboard
- 通过 LaunchScreen.storyboard 来为 RN 利用增加启动屏
- iOS 13 应用 LaunchScreen.storyboard 适配各尺寸启动图
5⃣️ 批改 xcodebuild 脚本
如果我的项目之前有配置过主动打包脚本,因为这次降级迁徙到 workspace,所以也得对原来的打包脚本做一些批改:
xcodebuild archive -project 项目名称.xcodeproj
⬇️
xcodebuild archive -workspace 项目名称.xcworkspace
对于 xcodebuild 能够参考这两篇文章:
- 应用 xcodebuild 命令进行自动化打包
- Xcodebuild 从入门到精通
3.Android
0.60 的 Android 更新次要是 3 点:
- React Native 我的项目降级到 AndroidX
- React Native 第三方依赖反对 autolink
- 反对 Hermes,一个 Facebook 开源的 Javascript 引擎
降级前先须要降级 Gradle 和 Groovy 的版本。具体细节参考 Upgrade Helper。
1⃣️ 降级到 AndroidX
AndroidX 的推动次要是 Google 官网受够了 Android 目前凌乱不堪的 android.support
,用一个对立的 androidx
来代替。降级跟着 Android 官网文档走就行,我次要参考了以下文档:
- 总是听到有人说 AndroidX,到底什么是 AndroidX?
- AndroidX 概览
- 迁徙到 AndroidX
- Android AndroidX 的迁徙
迁徙工作次要是批改 import
门路,工作量可能有些大,但心理累赘较小,实质上就是改了个名字,问题不大。
2⃣️ Autolinking 反对
Autolinking 性能集成前先试试运行 react-native unlink
,看看能不能主动勾销链接。如果勾销失败,就要本人手动删除旧的 link 代码,退出新的 Autolinking 代码。上面我以 react-native-svg 这个第三方库为例进行阐明:
1. 查看 android/settings.gradle
,删除旧的 include
配置,退出上面新的代码:
rootProject.name = '你的我的项目'
- include ':react-native-svg'
- project(':react-native-svg').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-svg/android')
+ apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
include ':app'
2. 查看 android/app/build.gradle
,删除旧的配置,文件的最初一行退出一行配置:
dependencies {- implementation project(':react-native-svg')
}
+ apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)
3. 查看 MainApplication.java
,删除旧的援用:
- @Override
- protected List<ReactPackage> getPackages() {
- return Arrays.<ReactPackage>asList(- new MainReactPackage(),
- new SvgPackage()
- );
+ @SuppressWarnings("UnnecessaryLocalVariable")
+ List<ReactPackage> packages = new PackageList(this).getPackages();
+ return packages;
- }
值得注意的是,咱们业务中很有可能会本人封装一些 Native Module,通过下面的批改后,导入 Native Module 的形式也要做相应的批改,这里能够参考官网文档 Android Register the Module:
+ import com.your-app-name.CustomToastPackage; // <-- Add this line with your package name.
protected List<ReactPackage> getPackages() {@SuppressWarnings("UnnecessaryLocalVariable")
List<ReactPackage> packages = new PackageList(this).getPackages();
+ packages.add(new CustomToastPackage()); // <-- Add this line with your package name.
return packages;
}
3⃣️ Hermes 反对
Hermes 是一个 Facebook 开源的 Javascript 引擎,和当初的 JSC 相比,在包体积和启动速度上有所优化。社区上曾经有很多介绍 Hermes 的文章了,我找了几篇比拟好的,如果对 Hermes 感兴趣能够移步查看。
- 携程对 RN 新一代 JS 引擎 Hermes 的调研
- React Native 公布新一代 JS 引擎 Hermes
- Hermes Engine 初探
Hermes 的相干个性不是本文重点,所以就不多介绍了。
Android 想要应用 Hermes 的话,必须得应用版本号大于 0.60.4 的 React Native,并且要对 android/app/build.gradle
做一些批改:
project.ext.react = [
- entryFile: "index.js"
+ entryFile: "index.js",
+ enableHermes: false, // clean and rebuild if changing
]
- def useIntlJsc = false
+ def jscFlavor = 'org.webkit:android-jsc:+'
dependencies {- if (useIntlJsc) {
- implementation 'org.webkit:android-jsc-intl:+'
- } else {
- implementation 'org.webkit:android-jsc:+'
- }
+ if (enableHermes) {
+ def hermesPath = "../../node_modules/hermesvm/android/";
+ debugImplementation files(hermesPath + "hermes-debug.aar")
+ releaseImplementation files(hermesPath + "hermes-release.aar")
+ } else {
+ implementation jscFlavor
+ }
}
下面只列出了次要变更,如果不想用 Hermes,能够齐全不做更改;如果想要尝试一下,最好还是依据 Upgrade Helper 列出的具体变更进行批改,而后浏览 React Native 官网的 Using Hermes 进行配置与调试。
四、React Native 0.61 降级
React Native 0.61 最次要的更新就是 Fast Refresh 的引入了,这个性能大大晋升了开发体验。
Fast Refresh 的退出有两个益处,第一个是把 live reloading 和 hot reloading 两个性能合二为一并做了性能增强;第二个终于反对 Hooks 热更新了。尽管 0.59.10 曾经反对 hooks,然而过后的函数式组件不反对热更新,开发体验过于差劲。降级到 React Native 0.61 后就能够应用了。
整体来说 0.61 的更新很小,一两个小时就能够实现降级。降级前倡议参考 Upgrade Helper 和 Upgrade to React Native 0.61 这篇博文,我会对文中没有阐明的中央进行补充。
1.React Native
JavaScript 这里次要是一些 API 的变动和降级,跟着报错信息批改就好,难度并不大。
1⃣️ React 降级到 16.9
React 降级到 16.9 后,componentWillMount
等 API 废除,必须迁徙到 UNSAFE_componentWillMount
等带有 UNSAFE_
前缀的 API。
主工程里这些 API 比拟容易重构和替换,麻烦的是一些很久没有保护的第三方 JS 包,这时候须要本人手动 Fork 一份代码保护,或者替换同性能的正在保护的第三方包,这个属于技术债,只能一点一点克服。
2⃣️ 援用门路改变
更新后有些办法和组件的援用门路产生了变更,须要咱们适配一下:
1.ErrorUtils
默认绑定到 global 上,不须要 import ErrorUtils from ErrorUtils
导入了
2.RCTNetworking
援用门路产生扭转,须要批改为:
const RCTNetworking = require('react-native/Libraries/Network/RCTNetworking');
3.Dimensions
导入形式也产生了扭转,须要批改:
import Dimensions from 'Dimensions';
⬇️
import {Dimensions} from 'react-native';
2.iOS
0.61 之后,React Native iOS 端只反对通过 Cocoapods Link 了,如果 0.60 曾经降级到 Cocoapods 了,那么这次的 iOS 降级将会十分快,只须要改变 Podfile 中一些库的导入门路就能够了。
具体的差别可见 Upgrade Helper,非常简单,比对批改后从新 pod install
就能够了。
3.Android
0.61 的 Android 降级也比较简单,降级了 Gradle 版本,批改了 Hermes 的援用门路,跟着 Upgrade Helper 的 Diff 顺次批改就可。
五、React Native 0.62 降级
React Native 0.62 也是增强了开发者体验,RN 我的项目默认引入了 Flipper 这个 Facebook 制作的挪动端调试工具,反对了 React DevTools v4,谬误提醒能够抉择新的 LogBox,比原来的谬误提醒更加敌对从而更容易定位问题。
除了开发体验的增强,这次更新还反对了 Dark Mode 模式,RN 之后就能够做暗黑模式的适配了。
整体来说 0.62 的更新也很小,一两个小时就能够实现降级。降级前倡议参考 Upgrade Helper 和 Upgrade to React Native 0.62 这篇博文,我会对文中没有阐明的中央进行补充。
1.React Native
1⃣️ useNativeDriver 显式指定
React Native 之前应用 Animated
API 时,useNativeDriver
默认值为 false,也就是说默认都是 JS 线程绘制动画。版本升级后须要显式指定 useNativeDriver
的值。我认为这个更新的意义在于每次应用 Animated
时,强制开发者思考能不能让动画在 Native 线程运行,优化动画体验。
2⃣️ LogBox 开启
LogBox 这个性能在 0.62 里是默认敞开的,0.63 版本默认开启。0.62 里开启形式比拟 Hack,须要按以下步骤操作:
1. 我的项目根目录新建一个 before.js
,而后外面只写一行代码:
require('react-native').unstable_enableLogBox();
2. 在 JS 所有文件的入口文件 index.js
的第一行里导入这个文件:
import './before';
下面两步 必须严格执行,不然的话会有红屏报错。
2.iOS
1⃣️ CocoaPods 更新
Cocoapods 在这个版本里也有些改变,除去 Flipper 相干的 pod,改变十分小,依据 Upgrade Helper 中的 Diff 差别批改就好。
2⃣️ Swift 反对
0.62 降级须要批改一些 Swift 相干的配置,具体降级流程可见 React Native 0.62 upgrade (Xcode)
3.Android
0.61 的 Android 降级也比较简单,降级了 Gradle 版本,除去 Flipper 相干的更新,改变十分小,跟着 Upgrade Helper 的 Diff 顺次批改就可。
4.Flipper
0.62 之后,Flipper 在 RN 的我的项目里是默认增加的,能够不便的查看 Layout、network 和 log 等信息。
旧我的项目降级时,Flipper 其实是可选的,装置有些挫折,上手体验了一下感觉如下(版本为 0.52.1):
- 把 React Native 的
console.log
信息和 Native 的 log 信息和在一个利用里,比拟不便查看 - 能够查看 Native Layout 布局,并且内置了
React DevTools v4
,两者比对能够不便查看布局 - Network 能够不便查看网络信息,这个始终是 RN 调试的一个痛点
- 能够疾速的截屏录屏,有助于和 UED 沟通
- 反对自定义插件
下面都是长处,毛病还是有不少的,上面我说说我用下来感觉到的有余:
- network 对 UTF-8 反对不太好。Flipper 对编码没有解决好,导致中文显示乱码,我曾经给官网提了 issues,然而始终没有理我
- network 图片解析也有问题,被解析为乱码的文本
- log 模块的数据都是字符串,即便你 log 的是 object,它也只是展现
JSON.stringify
后的数据
下面就是我的应用体验,要不要在我的项目中应用,我感觉大家还是亲自体验一下比拟好。
如果要在我的项目中集成 Flipper,依据 Upgrade Helper 进行集成就好,难度不是很大。
后记
下面就是 React Native 版本升级指南的内容了,本降级教程会继续更新,为了获得最佳体验能够查看浏览博客原文。
感觉文章对你有用的话肯定要记得 点赞 哦 ????,谢谢你,这对我来说真的很重要!
更多优良文章举荐:
- React Native 性能优化指南从渲染层的角度剖析了 RN 性能优化的 6 个点,并以图文模式解说了 FlatList 的实现原理
- 一篇介绍了 webpack 中最易混同的 5 个知识点,掘金快 800 赞了,一文讲清楚 Webpack 中那些 长得像却意义不同的概念
- 一篇具体介绍了 webpack dll 是个什么货色,并且给出了 2 条最佳实际,解脱繁琐的 dll 配置