【架构拾集】： 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 为例。

Growth 的价值定位是：带你成为顶尖开发者。

复杂一点的说明就是：Growth 提供 编程学习服务 使用 Web开发路线 帮助 新手 Web 程序员 解决 Web 学习路径问题。

让我们来看一下，更复杂一些的说明（电梯演讲）：

对于	缺少 Web 体系经验的程序员
他们有	书籍、在线教程、论坛、技术问答、练习项目
我们的产品	编程学习软件 Growth
是一个	移动应用
它可以	涵盖Web开发的流程及技术栈，Web开发的学习路线、成长衡量等各方面。
但他不同于	segmentfault、知乎
它的优势是	拥有完整的 Web 开发流程（知识图谱）、配套完整的电子书、提供练习及学习工具。

在原有的业务架构下，我们拥有 Growth、探索、社区、练习四个核心业务，以及用户中心的功能。

• Growth（首页），即带有详细介绍的 Web 应用的生命周期，能帮助开发者理解 Web 应用的构建流程。

• 探索，以辅助开发者了解 Web 应用方方面面的知识，如常用工具、练手项目、技能测验、读书路线等等。

• 练习，通过这些练习项目，来帮助开发者更好的掌握知识。

• 社区，一个简易的论坛。

• 用户中心，一些用户的收藏数据、应用相关的设置等等。

这就是业务上的主要架构，接下来让我们看看技术上的事务。

技术远景

远景，即想象中未来的远大景象。技术远景，即想象中未来的技术方面的远大景象。

在上一节中，我们介绍的是项目的业务远景。而作为一个技术人员，在一个项目里，我们也已经创建自己的技术远景。一来，我们可以创建出可持续演进的架构；二来，可以满足个人的技能需求。

以 Growth 为例，我的最基本的技术需求是：提升自身的能力。然后才是一个跨平台的技术设施——减少构建时间。

从 Growth 1.0、Growth 2.0 采用的 Ionic，到 Growth 3.0 采用的 React Native，它都优先采用新的技术来帮助自己成长，并使用了跨平台的移动应用开发框架。而这几个不同的版本里，也拥有其对应的不同技术问题

• Growth 1.0 主要是 Angular 1.x 的跳崖式升级，使之变成不可维护的系统。

• Growth 2.0 则是 Angular 2.x 那庞大的构建体积，带来了启动时间慢的问题。

• Growth 3.0 则是，React Native 生成的 index.android.bundle 文件有 3.1M，这个体积相当的大，以至于即使在高通的骁龙 835 处理器上，也需要 4~5 秒的打开时间。

而在 Growth 5.0 的设计构架里，考虑到 React Native 本身的不加密，其对于应用来说，存在一些安全的风险。我决定引入 Native 的计划，来从架构上说明，这个系统在某种程度上也是可以加密的。

因此，对于我而言，从技术上的期望就是：

• 使用新技术带来成长

• 让应用长期可维护

• 拥有跨平台的基础设施

• 插件化方案

方案对比

对于普通的应用来说，其需要从不同的方案中选择一个合适的方案。其选择的核心，取决于项目所依赖的关键点。如在 Growth 有两个关键点：代码复用程度、应用性能。

这个时候就需要罗列出不同系统的优缺点，并从中选择合适自己的一部分。

如下数据（纯属个人使用体验总结，没有任何的数据基础）：

	原 生	React Native	NativeScript	混合应用
开发效率	2	4	3	5
跨平台程度	0