React Native Android 从学车到补胎和成功发车经历

2401_84544461

于 2024-05-01 05:39:21 发布

阅读量874

点赞数 18

分类专栏：程序员文章标签： react native android react.js

本文链接：https://blog.csdn.net/2401_84544461/article/details/138364110

版权

程序员专栏收录该内容

168 篇文章 0 订阅

订阅专栏

【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

3 React Native 项目踩坑记

========================

关于 React Native 项目开发到集成其实是有很多坑的，网上也有很多文章给出了各种攻略，但我个人还是倾向于 React Native一旦翻车以后尽量使用如下工具进行呼救：

React Native github 开源项目 issues 中搜索你遇到的问题关键词

stackoverflow 中搜索你遇到的问题关键词

到此 RN 翻车踩坑的问题基本上在上面这两个地方都能找到解释的，其他的就需要自己看源码和自己依据自己项目进行总结了，下面总结下我认为我遇到的最坑的 RN 填坑记录。

3-1 最低版本兼容性问题

现有项目的 minSdkVersion=14，而 RN 最低支持 API 16；当遇上这个问题时心里是操蛋的，到底是将现有项目 minSdkVersion 升级到 16 还是保持 minSdkVersion 为 14 呢？其实都是可以的，这个取决于你项目目前在 16 以下用户量有多少的问题，如果不多则可以一劳永逸直接升级到 16，如果多的话则可以让 RN 兼容现有项目 minSdkVersion 编译打包，自己在入口处做好判断即可，支持 RN 的版本走一套，不支持的走另一套（WEB 或者别的 Native）或者压根不显示，顶多就是在 16 以下的用户能正常使用你 App 但是没有 RN 这部分功能而已。具体做法如下：

按照文档 gradle 添加相关 RN 依赖和仓库路径等，然后直接尝试编译一次吧，你会得到类似如下错误：

这里写图片描述

坑爹， RN 最低支持 API 16，我又不想改项目 minSdkVersion，看样子只能是上面说的添加 tools:overrideLibrary=”com.facebook.react” 来绕过了，自己做好判断，具体如下：

//AndroidManifest.xml

//如果有多个库有异常，则逗号分割即可，这样AndroidManifest.xml合并时就忽略了最低版本的限制

3-2 依赖冲突问题

由于原来项目中已经存在许多lib依赖，RN 集成进来以后编译会有依赖冲突，这个其实没啥的，依据报错或者执行 gradlew andDep 查看下哪些需要解除即可，譬如如下：

#$gradlew andDep

…

— com.facebook.react:react-native:0.33.0

±-- LOCAL: infer-annotations-1.5.jar

±-- com.facebook.fresco:imagepipeline-okhttp3:0.11.0

| ±-- com.facebook.fresco:fbcore:0.11.0

| — com.facebook.fresco:imagepipeline:0.11.0

| ±-- com.android.support:support-v4:23.2.1

| | — LOCAL: internal_impl-23.2.1.jar

| ±-- com.facebook.fresco:fbcore:0.11.0

| — com.facebook.fresco:imagepipeline-base:0.11.0

| ±-- com.android.support:support-v4:23.2.1

| | — LOCAL: internal_impl-23.2.1.jar

| — com.facebook.fresco:fbcore:0.11.0

±-- com.facebook.soloader:soloader:0.1.0

±-- org.webkit:android-jsc:r174650

±-- com.facebook.fresco:fresco:0.11.0

| ±-- com.facebook.fresco:drawee:0.11.0

| | ±-- com.android.support:support-v4:23.2.1

| | | — LOCAL: internal_impl-23.2.1.jar

| | — com.facebook.fresco:fbcore:0.11.0

| ±-- com.facebook.fresco:fbcore:0.11.0

| — com.facebook.fresco:imagepipeline:0.11.0

| ±-- com.android.support:support-v4:23.2.1

| | — LOCAL: internal_impl-23.2.1.jar

| ±-- com.facebook.fresco:fbcore:0.11.0

| — com.facebook.fresco:imagepipeline-base:0.11.0

| ±-- com.android.support:support-v4:23.2.1

| | — LOCAL: internal_impl-23.2.1.jar

| — com.facebook.fresco:fbcore:0.11.0

±-- com.android.support:recyclerview-v7:23.0.1

| — com.android.support:support-v4:23.2.1

| — LOCAL: internal_impl-23.2.1.jar

— com.android.support:appcompat-v7:23.0.1

— com.android.support:support-v4:23.2.1

— LOCAL: internal_impl-23.2.1.jar

查看完依赖冲突关系以后在项目中解除即可，如下：

//build.gradle中各种姿势的exclude掉依赖就行了

compile (“com.facebook.react:react-native:+”){ // From node_modules.

exclude module: ‘cglib’ //by artifact name

exclude group: ‘org.jmock’ //by group

exclude group: ‘org.unwanted’, module: ‘iAmBuggy’ //by both name and group

}

当然啦，如果你是修改过 RN 源码工程然后将源码引入的模式，依赖摘除也类似，这都是 Android 开发的必备技术了，不再多提了。不过如果你想裁剪优化 RN 则这里的依赖可以不摘除，直接想办法替换为自己项目共用已有优质 lib 即可，只不过这个过程依据团队规模和投入慎重考虑，因为 RN 版本太快，合并代码很苦逼。

3-3 动态 so 库加载策略问题

现有项目中为了安装包体积和 CPU 兼容性问题，所有 so 动态库都是放在 armeabi 目录下的，没有其他目录，而 RN 却只支持编译如下 so：

//RN 的 Application.mk

APP_ABI := armeabi-v7a x86

APP_PLATFORM := android-9

这他妈就尴尬了，你提供 SDK 竟然不考虑提供完整的 ABI 编译支持。那我只能自己想办法了，首先想到的就是你不提供我就自己编译呗（前提是将 RN 以源码形式集成进项目），于是在 RN 的 Application.mk 的 APP_ABI 多添加了一个armeabi（别问我为何加在这里，后面等我写 RN 编译链分析你就明白了，别问我这是啥语法，这是 Android 开发应该必备的技能，和 RN 无关），在 build.gradle 中也对应只添加过滤 armeabi，然后编译了一把报错了，坑爹啊，依据错误信息一查看发现是有一处 Android.mk 执行时找不到一个文件，具体如下：

//编译报错的Android.mk文件路径

//react-native\ReactAndroid\src\main\jni\third-party\jsc

//Android.mk内容

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE:= jsc

LOCAL_SRC_FILES := jni/$(TARGET_ARCH_ABI)/libjsc.so //编译真实报错地方

LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

include $(PREBUILT_SHARED_LIBRARY)

TARGET_ARCH_ABI 这玩意已经很明显了，做过 Android 都知道，指定是编译 armeabi ABI 时找不到 libjsc.so 文件，那就看看这个 so 是哪儿来的吧，通过 RN 源码自己的 build.gradle 可以看见如下：

// Create Android.mk library module based on so files from mvn + include headers fetched from webkit.org

task prepareJSC(dependsOn: downloadJSCHeaders) << {

copy {

from zipTree(configurations.compile.fileCollection { dep -> dep.name == ‘android-jsc’ }.singleFile)

from {downloadJSCHeaders.dest}

from ‘src/main/jni/third-party/jsc/Android.mk’

include ‘jni/**/.so’, '.h’, ‘Android.mk’

filesMatching(‘*.h’, { fname -> fname.path = “JavaScriptCore/${fname.path}”})

into “$thirdPartyNdkDir/jsc”;

}

dependencies {

…

compile ‘org.webkit:android-jsc:r174650’

…

}

这脚本已经告诉你 libjsc.so 是来自 org.webkit:android-jsc:r174650 这个依赖的，坑爹啊，上 maven 去下了一个解压 aar 包打开 libs 目录才惊讶的发现妹的 android-jsc 这货没提供 armeabi ABI 的 libjsc.so，怪不得会报错，也是由此猜想到 RN 为毛作为一个 SDK 不遵守 SDK so 提供的基础准则，估计是它用了 jsc，jsc也没有 armeabi ABI 的原因（这个初步是判断是这样的，至于 android-jsc 这个 lib 能不能自己下源码编译 armeabi 的 so还没研究。。。。。时间有限，啥时候闲了一定要下一份源码编译一下），所以这条路就这么浪费了我接近一个小时的时间，然后还是暂时失败了。

这时候不得不重新换个思路了，想了想还是在这一版先放弃 x86 吧（第一版接入就完美几乎不可能），但是放弃 x86 以后 armeabi-v7a 与现有 armeabi 的目录在加载 so 时还是存在问题啊，就是那个坑爹的策略问题，所以直接暴力测试了一下，修改编译脚本，armeabi-v7a 编译好以后剪切到 armeabi 下再打包（为了简单测试，你还可以直接解压现有 apk 中 armeabi-v7a 目录的文件复制到 armeabi 下打包测试，最后再修改脚本），然后通过 Build 辅助类进行架构判断。此坑暂时 mark，T_T，过几天有时间了要仔细搞下这个 so 兼容性问题。

3-4 RN 模块拖垮现有项目问题

接入 RN 前后对比了一下内存开销，确实大了不少，加之 RN 官方自己 ListView 的性能问题没有很好的解决，所以从各方面来说都有点不太放心，于是采取了多进程的方式，让 RN 模块运行在独立进程中，这样的话就能避免很多尴尬。

不过多进程方式还是建议不要通过使用 Application 注册配合 ReactActivity 方式，推荐高内聚的模块化方式，也就是自己 Activity implements DefaultHardwareBackBtnHandler，自己 setContentView 一个 ReactRootView 的方式。至于怎么多进程我想不用说了吧，做安卓的自己看着办。

3-5 RN 集成后热更新核心思路

RN 自身是不具备热更新全套机制的，尤其是比较老的低版本 RN 想要热更新是很费劲的，要做很多事情才能支持 JS 和图片resource 的热更新；但是比较新版本的 RN 不存在这个问题了，因为有 PR 已经重新搞了 JS 和 resource 加载这块逻辑，所以热更新变得容易了很多，不过新版本中却又搞出了一个新的致命坑，下面第6点详细说明，这里还是探讨热更新。其实简单的热更新说白了就是一个典型的CS流程，客户端发起请求查询更新，依据返回 JSON 决定是否去 CDN 下载新包，然后客户端在指定新包路径 load 启动即可，大体如下流程：

这里写图片描述

其实你所看到的市面上的各种 RN 热更新框架无非都是这个主线，只是更加健壮和高效而已，譬如 CodePush 实质就是这么回事，但是我们不想受限服务器类型、也不想使用他人服务器，所以有必要自己搞一套热更新。出于商业项目问题，这里接下来只提供如何快速搞一个简单的热更新框架，其他细节需要自己完善，具体做法如下：

1、在现有代码中进行如下代码修改来支持热更新。

//在 RN ReactInstanceManager构造中通过setJSBundleFile方法设置外部热更新文件保存路径

mReactInstanceManager = ReactInstanceManager.builder()

…

.setJSBundleFile(RNHotUpdateAndroid.getJSBundleFile(this))

…

.build();

紧接着创建一个RNHotUpdateAndroid.java的类，实现如下：

public class RNHotUpdateAndroid {

//上面setJSBundleFile方法设置的路径来自此处

public static String getJSBundleFile(Context context) {

//首先判断外部指定路径下是否存在新下载的bundle文件

String bundleFile = FileUpdateManager.getExtraJSBundleFile(context);

if (FileUtils.exists(bundleFile)) {

//存在更新文件则直接将外部路径设置给ReactInstanceManager，也即RN使用热更新文件加载启动

return bundleFile;

}

//不存在更新文件则使用原来打包的assets路径

bundleFile = FileUpdateManager.getInnerJSBundleFile();

return bundleFile;

}

再看下FileUpdateManager.java的实现，如下：

public class FileUpdateManager {

public static final String BUNDLE_FILE_NAME = “index.android.bundle”;

public static final String BUNDLE_EXTRA_DIR = “RNHotUpdate”;

public static final String ASSETS_BUNDLE_PREFIX = “assets://”;

public static String getExtraHotUpdatePath(Context context) {

return context.getApplicationContext().getFilesDir().getAbsolutePath() + File.separator + BUNDLE_EXTRA_DIR;

}

public static String getExtraJSBundleFile(Context context) {

return getExtraHotUpdatePath(context)+ File.separator + BUNDLE_FILE_NAME;

}

public static String getInnerJSBundleFile() {

return ASSETS_BUNDLE_PREFIX + BUNDLE_FILE_NAME;

}

到此具备 JS 和 res 图片资源的热更新超级基础版可以算 OK 了，就是判断有没有更新文件存在，有就在启动时使用更新文件的路径，没有就使用原来 assets 的路径，简单吧，至于为毛这么设置就能热更新了后面文章我会详细介绍，现在先记得就行，饥渴的话可以自己去翻下源码就明白了。

2、本地随便搭建一个服务器，各种集成环境也可以，方便接下来的测试。

3、准备更新包，记得不要和打入assets的一样，免得看不出明显效果，随便改个字体大小、颜色啥的，然后进行官方打包命令操作：

//$OUTPUT_PATH为你指定的一个输出路径

react-native bundle --platform android --dev false --entry-file index.android.js --bundle-output $OUTPUT_PATH/index.android.bundle --assets-dest $OUTPUT_PATH

此时会在 $OUTPUT_PATH 路径下看到如下输出：

这里写图片描述

将这些文件选中压缩成 update.zip 的压缩包，如下：

这里写图片描述

如上两步除过 index.android.bundle.meta 文件可以不要以外，剩下无论是文件夹还是文件名都不要修改，千万不要修改，压缩到根目录，至此一个更新包就做好了（差分包那些自己实现，这里是最简单的热更新实现）。

4、上面热更新超级简单版机制和更新包zip文件都已经有了，接下来就得找个合适时机去向服务端请求查询是否有更新、获取更新链接进行下载解压了；这里就是你需要依据自己项目情况实现的细节了，譬如渠道控制、版本控制等等一堆匹配校验，我们都略掉吧，重点看下怎么更新成功，那就暴力点，假设有更新（直接从指定路径拉取zip包吧），所以局部代码如下：

public class RequestManager {

//第二步让你搭建的服务器，把第三步做好的更新包扔到如下路径即可（是不是很暴力很直接！！！）。

public static final String HOT_UPDATE_URL = “http://10.20.185.22/rn_hot_update/test_cdn/update.zip”;

private Context mContext;

public RequestManager(Context context) {

this.mContext = context.getApplicationContext();

}

public void start() {

//开启线程后台下载更新包解压等操作（仅仅为Demo，不具备实用价值！！！！！）

new Thread(new Runnable() {

@Override

public void run() {

OutputStream output = null;

File zipDownloadFile = null;

try {

Log.i(“YYYY”, “----------bundle download start”);

URL url = new URL(HOT_UPDATE_URL);

HttpURLConnection urlConn = (HttpURLConnection) url.openConnection();

InputStream input = urlConn.getInputStream();

File dir = new File(FileUpdateManager.getExtraHotUpdatePath(mContext));

if(!dir.exists()) {

dir.mkdirs();

}

//创建一个临时zip文件

zipDownloadFile = new File(FileUpdateManager.getExtraHotUpdatePath(mContext) + File.separator + “template”);

if(!zipDownloadFile.exists()){

zipDownloadFile.createNewFile();

}

output = new FileOutputStream(zipDownloadFile);

byte buffer [] = new byte[1024];

int inputSize = -1;

long totalSize = 0;

byte[] header = new byte[4];

while((inputSize = input.read(buffer)) != -1) {

if (totalSize < 4) {

for (int index=0; index<inputSize; index++) {

int headerOffset = (int)(totalSize) + index;

if (headerOffset >= 4) {

break;

}

header[headerOffset] = buffer[index];

}

totalSize += inputSize;

output.write(buffer, 0, inputSize);

}

output.flush();

//判断下的是不是一个zip，其实应该还有md5等各种校验的，这只是个Demo！！！！

boolean isRealZipFile = ByteBuffer.wrap(header).getInt() == 0x504B0304;

if (isRealZipFile) {

//解压文件到热更新目录供使用（仅仅是Demo，实际要考虑版本回退问题）

FileUtils.unzipFile(zipDownloadFile, FileUpdateManager.getExtraHotUpdatePath(mContext));

Log.i(“YYYY”, “----------bundle download and unzip OK”);

} else {

Log.i(“YYYY”, “----------bundle download, but not a zip file!”);

}

} catch (Exception e) {

Log.i(“YYYY”, “----------bundle download error”);

e.printStackTrace();

} finally{

//删掉下载解压后的zip文件

try{

if (zipDownloadFile != null) zipDownloadFile.delete();

if (output != null) output.close();

}

catch(Exception e){

e.printStackTrace();

}

}).start();

}

好了，在你合适的地方（譬如 RN Activity 启动后 onCreate 最后）进行如下调用：

new RequestManager(this).start();

至此一个从服务器下载更新包解压和再次进入界面展示热更新资源的超级简单热更新 JS 与 image 资源的方案就落地了。TT，其实远远不止这些，这只是给大家提供个思路，里面很多细节需要考虑的，版本回退、校验、查询、兼容性、容错、差分包等等，商业原因就不细细说明了，相信有了这个主要的核心思路，那些拓展完善大家都能做好的，而且是量身定做的。

怎么样，看似很神奇的 RN 热更新 JS 和资源本质核心就这么回事。但是一直不明白为啥很多群里和论坛到处求助如何更新 RN 的 image 资源，我想说的是，如何更新自己去看代码啊，从代码找突破口啊！

3-6 RN 集成后 release 版本中可能存在的一个小概率崩溃

有了上面那些经历， React Native 基本就算 OK 了，但是无意间和同事讨论发现一个崩溃，追踪了一把才发现是个天坑（其实这个坑在 RN 低版本是不存在，后来的新版本不清楚为毛要这么干，不知道是不是失误）；上面 release 版本的更新拽回来的 bundle 文件如果是一个人为搞错的文件打包成 zip 发布的话就会复现（这种 bundle 文件搞错，譬如有个 txt 文件，只是名字取成了 bundle 等，md5 校验也无力回天），虽然这种傻逼的做法不多，但是容错机制不能没有啊，不能让它在可预见的情况下崩溃啊，万一运营发版本傻逼了咋搞。

下面来看下比较新的 RN 版本 XReactInstanceManagerImpl.java 中 ReactContextInitAsyncTask 内部类的这个坑，具体先看下 RN 里 ReactContextInitAsyncTask 内部类的 doInBackground 方法，如下：

@Override

protected Result doInBackground(ReactContextInitParams… params) {

…

try {

JavaScriptExecutor jsExecutor = params[0].getJsExecutorFactory().create();

return Result.of(createReactContext(jsExecutor, params[0].getJsBundleLoader()));

} catch (Exception e) {

// Pass exception to onPostExecute() so it can be handled on the main thread

return Result.of(e);

}

看看 createReactContext 方法吧，如下：