【架构拾集】： Android 移动应用架构设计

在这一个多月里，我工作在一个采用插件化的原生 Android 应用项目上。随着新技术的引入，及编写原生 Android 代码的技能不断提升，我开始思索如何去解锁移动应用新架构。对，我就是在说 Growth 5.0。

两星期前，我尝试使用了 Kotlin + React Native + Dore + WebView 搭建了一个简单的 Android 移动应用模板。为了尝试解决 Growth 3.0+ 出现的一系列问题：启动速度慢、架构复杂等等的问题。

PS：作为 Architecture 练习计划的一部分，我将采用规范一些的叙述方式来展开。

1. 业务架构

2. 技术远景

3. 方案对比

4. 架构设计方案

5. 持续集成设计

6. 测试策略

7. 架构实施

即下图：

从设计上来说，它拥有更好的扩展性，毕竟在安全上也更容易操作。然而，从技术栈上来说，它变得更加复杂。

Growth 技术方案

原生部分

系统在底层将采用原生的代码作为基础框架，而不再是 React Native 作为基础。再考虑到项目上正在实施的 Android 插件化方案，我打算在 Android 的 Native 部分使用 RePlugin 来引入一些更灵活的地特性。因此，从架构上来说，能满足个人的成长需求了。

毕竟原生 Android 有些架构还是相当有意思的：

在这里，引用《全栈应用开发：精益实践》对于测试金字塔的分析：

从图中我们可以发现：单元测试应该要是最多的，也是最底层的。其次才是服务测试，最后才是 UI 测试。大量的单元测试可以保证我们的基础函数是正常、正确工作的。而服务测试则是一门很有学问的测试，不仅仅只在测试我们自己提供的服务，也会测试我们依赖第三方提供的服务。在测试第三方提供的服务时，这就会变成一件有意思的事了。除此还有对功能和 UI 的测试，写这些测试可以减轻测试人员的工作量——毕竟这些工作量转向了开发人员来完成。

而如果是架构混搭的应用来说，其的测试成本相当的大。因为要测试的部分是 3 + 1，即：

• 原生部分，采用原先代码的测试策略，如 JUnit

• React Native 部分，继续之前的  测试渲染、  和  测试业务逻辑

• WebView 部分，采用框架本身推荐的框架

• 组合部分，对于这部分来说，UI 上的测试会更加可靠，如在 Growth 3.0 中采用的  就是一个不错的选择。

架构实施

最后，让我们来看看我在两个星期前，搭的一个架子，用于作技术验证功能。一共由三部分组件：

• 使用 Kotlin 编写的原生代码

• 使用 React Native 编写的 Fragment

• 使用 Ionic 编写的 WebView 应用

接下来看两个简单的代码示例：

创建 React Native 的 Fragement

如下是一个使用 React Native 编写的 Fragement 示例，它可以直接在原生的 Activity 上使用：

除了将 React Native 切分成不同的几个子模块。对于一个 React Native 应用来说，它可以注册多个 Component

这样一来说，可以在一个 React Native 应用里被原生部分多次调用不同的组件。

简单的 WebView

对于那些不需要原生组件的组件来说，可以直接由原生应用来对 WebView 处理。从逻辑上来说，这样的性能会更好一些：

对，就是这么简单。

结论

So，尝试去做这样的设计吧。