Android移动应用架构设计

Android 移动应用架构设计

随着新技术的引入，及编写原生Android 代码的技能不断提升，我们开始思索如何去解锁移动应用新架构，也就是Growth 5.0。

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

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

1.业务架构

2.技术远景

3.方案对比

4.架构设计方案

5.持续集成设计

6.测试策略

7.架构实施

即下图：

技术架构设计之路

业务架构

技术是为了解决业务的问题而产生的。

脱离了业务，技术就没有了存在的前提。脱离了业务的架构不叫“架构”，而叫刷流氓，又或者是画大饼。业务由于其本身拥有其特定的技术场景，往往是对技术决策影响最大的部分。

因此，开始之前让我们先了解一些业务，这里以Growth 为例。

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

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

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

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

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

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

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

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

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

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

技术远景

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

在上一节中，我们介绍的是项目的业务远景。而作为一个技术人员，在一个项目里，我们也已经创建自己的技术远景。一来，我们可以创建出可持续演进的架构；二来，可以满足个人的技能需求。以Growth 为例，我的最基本的技术需求是：提升自身的能力。然后才是一个跨平台的技术设施——减少构建时间。

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

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

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

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

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

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

o使用新技术带来成长

o让应用长期可维护

o拥有跨平台的基础设施

o插件化方案

方案对比

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

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

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

PS：NativeScript 在安全性上比React Native 好一点点的原因是，使用NativeScript 的人相对少一点，所以技术成本就高一些。毕竟，macOS 和Android 手机上也是有病毒的。

考虑到我打算结合不同的几个框架，所以这里就不需要选择了。

技术方案

在定下了基本的技术方案后，就差不多是时候进行架构设计了。

现今的很多应用里，也是采用多种技术栈结合的架构，如淘宝的Android 原生+ Weex + WebView，或者支付宝（不确定有没有Weex）。但是，可以肯定的是几乎每个大型应用，都会在应用里嵌入WebView。WebView 毕竟是可以轻松地进行远程动态更新，也需要原生代码那样的后台更新策略。

在Growth 3.0 里，我们选择了使用React Native + WebView 的构建方式，其原因主要是WebView 的生态圈比较成熟，有相当多的功能已经用WebView 实现了。而在新版本的设计中，则系统变得稍微复杂一些：

架构图2

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

Growth 技术方案

原生部分

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

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