彻底理解 Android 架构，移动应用开发就业工资

不知道还有没有印象上文提到了架构 “形式必须服从功能” 当然这不是权威的定义，可以作为参考。我们先不管是形式服从功能还是功能服从形式，可以结构化思维理解下这句话，架构大致可分为：形式、功能所以我们依次按照此两点进行搭建 wanAndroid 项目。

3.1 架构 - 形式

从形式本身而言包括两部分。一是事物外在的形状，二是内在的结构、组合方式。实际上，这两者为同一。内容如何内在组合，对外就自然有某种表现的形状。

我们打开项目的第一眼接触到和看到的就是我们项目的目录结构，更清晰更简洁的目录结构可以使我们更快的上手项目。这里主要分为两部分核心模块、业务功能模块：

核心模块主要有以下职责：

• Dagger 依赖注入处理。

• 扩展功能：各种 utils。

• 基础层的抽象：BaseActivity、BaseViewModel 等

• 第三库处理、网络异常处理等

业务功能模块主要有以下好处：

• 高内聚性

• 清晰的功能结构

• 模块化

• 功能隔离并封装

在主 APP 下进行了 core、features 的划分，业务模块并没有按照模块化的形式进行多 moudle 拆分而是聚合在 features 下，以包的形式进行了聚合，这样做的好处如下：

• 更快的编译速度

• 减少 maven 库的依赖冲突

• 通用功能的重用性

• 包的内聚力

可以看到我们并没有采用按照业务 module 进行模块化划分，因为我之前接触过一个项目拆分了 40 多个 module 可想而知项目一旦庞大起来坏处也就是暴露出来：

• 编译一次项目高达 7/8 分钟，编译速度优化可以看我之前的文章[（编译速度优化）](

)

• 项目中的 moudle 依赖纵横交错

当然我并不反对多 module 模块化的存在，因为任何模式都有利有弊，这取决于当前的项目的业务来抉择使用那种形式。此外项目中全部采用 kotlin 编写：

• build.gradle.kts .kts 也是官方推崇的可以使 gradle 更加简化

• buildSrc来处理 gradle 依赖

3.2 架构 - 功能

在玩 Android 中的业务点功能点主要有文章、项目获取，而这些功能点大部分都离不开网络请求和回调处理。这里不再描述 MVC、MVP、MVVM 的区别和如何选择，但是我可以说明一点是任何架构模式都没有最好、最优，只有最适合当前业务的才是好架构。现在 google 官方推崇的架构主要是 MVVM 所有我们主要说下 MVVM。更详细的可以查看官网文档 [应用架构指南](

)：

MVVM 架构模式满足上文我们描述符合的架构设计的目的，同时也准守了官方给定的架构原则，架构原则大致有两点如下。可能光看这两个定义可能不太容易理解。所有我们用结构化思维的方式理解下，关注点分离就是将复杂问题做合理的分解，再研究分解的侧面，最后合成整体的解决方案。因此我们在 Activity 或 Fragment 不应该做业务逻辑而是把功能点拆分成需要最小的最优解，最后合并成整体方案。比如 mvvm 我们衍生出 ViewModel、LiveData、Model 等。

1. 关注点分离 Activity 或 Fragment 中的代码应是处理界面和操作系统交互的逻辑应使这些类尽可能保持精简，这样可以避免许多与生命周期相关的问题。

2. 通过模型驱动界面 模型是负责处理应用数据的组件。它们独立于应用中的 View 对象和应用组件，因此不受应用的生命周期以及相关的关注点的影响

MVVM 中每个组件仅依赖于其下一级的组件如：activity-->viewMoudle-->Repository。这时候你可能有疑惑，如果是单向依赖那网络请求的回调怎么处理？这里引出一个概念 “响应式编程” 结合 liveData 做处理其内部是观察者模式，并且关联视图的声明周期如：Activity、Fragment 或 Service。使用 LiveData 的好处如下：

1. 不会发生内存泄漏 观察者会绑定到 Lifecycle 对象，并在其关联的生命周期遭到销毁后进行自我清理。

2. 不会因 Activity 停止而导致崩溃 如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。

3. 不再需要手动处理生命周期 界面组件只是观察相关数据，不会停止或恢复观察。LiveData 将自动管理所有这些操作，因为它在观察时可以感知相关的生命周期状态变化。

3.3 UseCase

UseCase 是 Clean 架构中的一个概念，其中主要用于 UI 和数据层的连接同时也会进行 IO 的切换，这里可以看到本项目抛弃了 Rxjava 因为他完全可以用 Kotlin 来替代。

abstract class UseCase<out Type, in Params> where Type : Any {

abstract suspend fun run(params: Params): Either<Failure, Type>{

operator fun invoke(params: Params, onResult: (Either<Failure, Type>) -> Unit = {}) {val job = GlobalScope.async(Dispatchers.IO) { run(params) }GlobalScope.launch(Dispatchers.Main) { onResult(job.await()) }}

class None}

3.4 一个完整网络请求流程

• View：一个网络请求的发送并订阅，处理 UI 数据。

• ViewModel：为 View(Activity/Fragment) 提供数据，并处理业务逻辑。

• LiveData：具有生命周期可观察的数据存储器类，LiveData 存储在 ViewModel 中

• UseCases：用于连接 ViewModel 和 Model，并更新 LiveData。

• Model：可以从网络、数据库或其他 API 获取数据四、总结

我们可以体会到从架构理论定义到实践的过程相信你有了自己的理解和见解，但这只是一种实现方式，如果在满足架构设计目的和架构原则的情况下你有更好的实践方式或者有任何和架构项目的疑问点都可迎在评论区或者 [Github 中留言讨论](

)。这里我也有个疑问点就你认同形式必需服从功能？欢迎留下你的见解。后续本项目将持续更新，并完善 wanAndorid 的所有功能。还会用 23 种设计模式在项目中实践，彻底理解设计模式在业务场景中的

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

使用，欢迎持续关注。当其他的平台如后端、前端架构的搭建都是殊途同归的。但是我还是有几点建议：

• 业务决定架构

• 不要过度设计