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 有些架构还是相当有意思的：原生Android 架构React NativeReact Native 从代码上的变化比较大，架构设计上从代码上切分出几个不同的页面。

它可能可以在某种程度上Bundle 文件过大，带来的加载速度慢的问题。

因而，在某种程度上，可能带来更快的启动速度。

WebView总体上来说，WebView 变化不会太大。

除了，可能从React Native 的WebView 迁移到原生部分的WebView 之外。

持续集成设计之前我们提到持续集成的时候，多数是指持续集成的实施。

而今天我们谈到持续集成的时候，则是在讨论如何去设计。

代码策略首先，就是代码策略，即代码管理策略。

代码管理，指的就是决定采用哪种git 工作流。

会影响到代码管理的因素有：o上线功能。

如某次发布要上线哪些功能，肯定会影响到正常的开发流程。

o代码集成。

当我们采用模块化、插件化来设计系统架构时，就需要将几个不同的的项目集成到一起。

o代码合并。

在有的项目里，人们会使用PR 来提交代码，有的则是直接在master 上提交，也有的采用feature branch。

o分支策略。

什么时候，决定拉出新的分支？o修复bug。

当我们拉到一条新的分支时，我们要怎么去应对一个bug 的出现呢？对于Growth 而言，则仍然是master 分支，采用多个GitHub 项目的集成方式。

工具箱作为一个有经验的程序员，我们应该在设计的初期考虑到我们所需要的工具：o基础设施，诸如React Native 需要的Node.js、Android 及Java 需要的构建工具Gradleo文档工具，诸如架构决策记录工具ADR，o开发工具，编写Android 应用需要的Android Studio、编写React Native 的Intellij IDEAo依赖库，这些工具是我们o持续集成，在持续集成上可以采用Travis CIo应用发布，APP 仍然使用GitHub 和 来进行测试版发布。

至于后台API，是否从GitHub、Coding 上迁出，仍然有待商榷。

这些也仍是我们在设计架构的过程中，需要考虑的一些因素。

测试策略一般情况下，我们要会采用测试金字塔：测试金字塔在这里，引用《全栈应用开发：精益实践》对于测试金字塔的分析：从图中我们可以发现：单元测试应该要是最多的，也是最底层的。

其次才是服务测试，最后才是UI 测试。

大量的单元测试可以保证我们的基础函数是正常、正确工作的。

而服务测试则是一门很有学问的测试，不仅仅只在测试我们自己提供的服务，也会测试我们依赖第三方提供的服务。

在测试第三方提供的服务时，这就会变成一件有意思的事了。

除此还有对功能和UI 的测试，写这些测试可以减轻测试人员的工作量——毕竟这些工作量转向了开发人员来完成。

而如果是架构混搭的应用来说，其的测试成本相当的大。

因为要测试的部分是3 + 1，即：o原生部分，采用原先代码的测试策略，如JUnito React Native 部分，继续之前的 react-test-renderer 测试渲染、 jest 和 chai 测试业务逻辑o WebView 部分，采用框架本身推荐的框架o组合部分，对于这部分来说，UI 上的测试会更加可靠，如在Growth 3.0 中采用的 appium 就是一个不错的选择。

架构实施最后，让我们来看看我在两个星期前，搭的一个架子，用于作技术验证功能。

一共由三部分组件：o使用Kotlin 编写的原生代码o使用React Native 编写的Fragmento使用Ionic 编写的WebView 应用接下来看两个简单的代码示例：创建React Native 的Fragement如下是一个使用React Native 编写的Fragement 示例，它可以直接在原生的Activity 上使用：1.class ArcheReactFragment : ReactFragment() {2. override val mainComponentName: String3. get() = "RNArche"4.5. private var mReactRootView: ReactRootView? = null6. private var mReactInstanceManager: ReactInstanceManager? = null7.8. @Nullable9. override fun onCreateView(inflater: LayoutInflater?, group: ViewGroup?,savedInstanceState: Bundle?): ReactRootView? {10. mReactRootView = ReactRootView(activity)11. mReactInstanceManager = ReactInstanceManager.builder()12. .setApplication(activity.application)13. .setBundleAssetName("index.android.bundle")14. .setJSMainModulePath("index")15. .addPackage(MainReactPackage())16. .setUseDeveloperSupport(BuildConfig.DEBUG)17. .setInitialLifecycleState(LifecycleState.RESUMED)18. .build()19. mReactRootView!!.startReactApplication(mReactInstanceManager,"RNArche", null)20. return mReactRootView21. }22.}除了将React Native 切分成不同的几个子模块。