日常装机软件

系统工具类:

Chrome App:

背景

以下分析 React Native 版本均为 0.59.10

RN 实现 Fragment 加载因为想将其放置于首页，当放置在首页时就必须考虑其加载速度、so Crash、native module 及 js Crash 后如何显示等问题。对于容器化则是需要将现有 natvie 功能规范化后向上提供，还有 Android 和 iOS 双端开放能力的统一，方便上层业务调用。

容器化

RN 容器架构图

背景

React Native 版本迭代速度相对较快，所以在使用过程中就会遇到升级问题。我们也遇到了这个问题，但是由于我们的业务形态导致升级后还必须兼容低版本的 React Native 前端代码，所以就不能使用官方提供的方案。

方案

对于 React Native Android 代码升级，最简单的就是将所有源码覆盖，然而事情并没有想的这么简单。

ReactView 相对是所有 RN 创建出的 View 统称

背景

在开发过程中遇到个比较特别的需求，在现有的 RN 源码不改动的情况下，以竖屏的方式在横屏的 Activity 上显示 RN 页面。
听起来比较绕其实效果很简单，如下图

1
2
3
4
5
6
7
8
9
10
11
12
13
14

 _____________________________________________
|             |                 |             |
|             |                 |             |
|             |                 |             |
|             |                 |             |
|             |                 |             |
|    Empty    |    Activity     |    Empty    |
|             |      View       |             |
|             |                 |             |
|             |                 |             |
|             |                 |             |
|             |                 |             |
|_____________|_________________|_____________|
                      平板

如果是纯原生开发的页面，我们最简单的方式就是修改 RootView 的宽高或者 Window 的 宽高。但是经过尝试当我们改变宽高后 RN 页面里的 View 并未随着改变，还是按照横屏模式下屏幕的宽高显示。

遇到这种问题肯定是 RN 源码有自身的逻辑，所以需要撸一遍源码才能搞清楚是哪里有了和我们预想的差异。

Jcenter 是目前最大的 maven 源，通过 AS 创建的项目自身就使用 Jcenter，当我们想上传自己的 aar 至 jcenter 时都会选择官方提供的插件，它可以很方便的将我们的产物上传至 jcenter，然后在产物的详情页里点击 Add to jcenter 就可以提交审核到公共源里。

需求

由于项目开源需要将某些产物从私有 maven 发布到 jcenter，但是如果依赖插件打包就有太多的组件要打包历史版本，显然看起来时不可行的，所需要研究怎样把私有 maven 的产物发布到 jcenter。

前言

在混合开发时经常需要调用 Native 方法获取资源，此时需要以 NativeMoudle 的方式供前端调用。当继承ReactContextBaseJavaModule时可以重写的方法只有 onCatalystInstanceDestroy() 可以看出来是容器销毁时会调用的方法，但是其他的生命周期都没有相关方法。通过查询api发现LifecycleEventListener·这个listener可以监听主要的生命周期如onHostResume() onHostPause() onHostDestroy()通过这几个方法可以监听页面的生命周期，方便释放资源。

问题

但是有个很特殊的场景就是从锁屏界面调用 ReactNative 界面，这时 ReactNative 界面会在调用onResume()后直接调用onPause(),这个是由于系统机制决定的，无法更改这个逻辑。由于快速进入 pause 状态导致 NativeMoudle 的onHostResume()没有调用，造成无法触发这个方法里的逻辑。

分析

那这样的生命周期是从哪里开始调用，以什么方式开始调用呢。下面做个简单的分析。
当看到onHostResume时一定会发现和Activity的生命周期很相似，所有当需要从 Activity 中入手查看。本文忽略ReactFragment相关内容。

背景

我们业务的 SDK 包含 ReactNative 方案,所以必须依赖 React Native 的 AAR，但是最近对接的客户有自己依赖的版本，和我们使用的版本不同，所以需要我们的 React Native 代码运行在他们使用的版本上。

问题

当 React Native 版本和 Native 版本不一致时，会弹出红框提示

解决方法

根据提示在源码里搜索发现，来自于Libraries/Core/ReactNativeVersionCheck.js这个文件里，根据文件注释可以看出是专门做版本校验

Java 开发中使用最多的构建工具就是 Maven，Android 的 Gradle 构建工具使用的版本仓库也是 Maven，对于使用脚本打包出产物上传至远程仓库的方式已经很熟悉，但是有时候需要从 Maven 下载产物或者直接上传产物。如果每次都在 Maven 的服务端页面操作就很麻烦。所以如果使用脚本就很方便。

译文

你是否知道可以指定使用某个依赖或者某个版本的依赖的原因.
是的,在API和DOCS中

{% note info %}
void because?(@Nullable String reason)

Sets the reason why this dependency should be used.
Since:
4.6
{% endnote %}

需求

现在 Android 10 早已经发布,当 targetVersion 为29时必须使用 AndroidX 并且现在新建项目时已经必须勾选 AndriodX 选项了,所以需要开始迁移工作了,有些三方库也只提供 AndroidX 版本,我们遇到 QQ 音乐和 GoogleMap 的 SDK 就只提供 AndroidX 版本.如果对于单个工程而言只需要 Refactor->Migrate to AndroiX 即可以完成自动迁移,但是对于有更多项目而言使用这样的方式虽然可以完成迁移,但是太过于繁琐,也不好统一 AndroidX 库的版本.为了方便整个团队项目进行迁移,所以使用脚本进行迁移会方便很多.

解决方案

整个流程很简单

1. checkout 新分支
2. 升级新 gradle 版本
3. 升级 gradle tool 版本
4. gradle.properties 添加 AndroidX 支持
5. 替换工程里所有 support 包名
6. 替换工程里所有 support 依赖
7. 添加混淆文件

梳理完成流程,就可以动手迁移了.需要注意 AndroidX 必须使用 gradle tool 3.2 版本以上,为了保证兼容性,工程当前最好使用 supprot 28 的依赖.