彻底理解Android架构

2024-02-06 02:02:44 阅读 0

前言

我利用本文的理论知识和架构原理实践了一个项目。它们全部被写入并丢弃，因为它们可以被完全替换。本项目整理了业界知名的架构文章和一些项目，帮助你彻底理解架构。未来，这个项目将会持续更新，完善所有功能。您还将使用23种设计模式在项目中进行实践，深入了解设计模式在业务场景中的使用。欢迎继续关注。

1.什么是架构 1.1 架构简介

建筑到底是什么？如何更好地理解架构。我们知道，汉字博大精深。可以说，从字的构成就可以明白其中的含义。建筑也不例外。 “建筑”由“框架”和“结构”组成。

框架：建造、竖立、支撑。简称：整体结构：人类居住的房屋、木、砖、瓦结构。简称：构件

整体结构和组件的组合形成了架构。以架构为例，一个APP通常是由类组成的。这些类如何组合以及它们之间如何交互是影响APP本身的关键点。如果细分的话，可以分为类、接口（连接器）和任务流。所谓类是构成架构的核心“砖块”，接口则是这些类之间的通信路径、通信机制以及通信的预期结果。任务流描述了系统如何使用类和接口来完成某个需求，例如网络请求。上面对建筑的介绍提到了房屋、木材和砖块。可见，建筑与建筑物是相互关联的。

1.2 架构

软件架构的概念在20世纪60年代就已经被设计出来，直到20世纪90年代软件架构的概念才开始流行。计算机的历史始于 20 世纪 50 年代，与建筑的历史相比非常短暂。建筑工程始于石器时代。人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计主要包括两点，一是建筑风格，二是建筑模式。独特的建筑风格和适当选择的建筑模式可以使其成为独一无二的建筑。

下图是玛雅古建筑： - 伊察，有九个巨大的石阶叠起，九十一级台阶（象征着四个季节的天数）遥遥无期，塔顶的神庙高耸入云进入天空。所有的数字都像日历一样严谨，风格浑厚。很难想象这是一座石器时代的建筑。

安卓框架模式_框架中用到的模式_android常见设计模式和框架

英国首相温斯顿·丘吉尔说过，我们建造建筑物，建筑物建造我们。英国下议院会议厅狭窄，无法让所有下议院议员面朝同一方向就座。相反，他们必须坐在两侧。丘吉尔认为，议员坐下时，自然会选择政治观点相同的人同时就座，这就是英国政党制度的起源。

2. 架构设计目的

框架中用到的模式_android常见设计模式和框架_安卓框架模式

几乎所有的软件设计概念都可以在浩瀚的建筑史上找到。很多人认为“形式必须服从功能”（你同意这个观点吗？在评论区留下你的看法）。好的设计兼具形式和功能。比如我们北京大兴国际机场，以航站楼为核心，向四面八方延伸。从空中俯瞰，犹如一只展翅欲飞的凤凰。以航站楼核心区为中心，向东北、东南、中南、西南延伸。五条走廊向西北、西北五个方向延伸，通向北京大兴国际机场飞行区。这种从中心向四面八方延伸的设计，使得从航站楼中心到最远登机口的距离仅约600米，旅客步行最多仅需8分钟。

建筑的设计都有一定的目的，软件架构设计也是如此。软件架构的目的大致可分为可扩展性、可定制性、可扩展性、可维护性：

1.可扩展性：即使用户的UV/PV数量快速增加，APP也必须能够保持软件的合理性能。只有这样，我们才能在需求从0到1的快速迭代中安心。

2、可定制：同一个软件系统可能针对不同、多样化的用户群体，需要根据不同的用户群体和市场需求进行定制。例如，APP中的某些功能仅对特定用户可用。

3.可扩展性：当新技术出现时，软件系统应该允许使用新技术来扩展现有系统的功能和性能。

4、可维护性：软件系统的维护包括两个方面，一是修复现有的bug，二是向现有系统开发新的迭代需求。易于维护的系统可以有效减少人力和物力。

3.练习一个APP：玩

对于上面对架构的介绍，相信已经从陌生走向熟悉了。但最重要的是练习。伟大的毛主席曾经说过，要想知道梨子的味道，就要亲自尝一尝。因此，我们借用开放的API简单实现了一个APP，总结了上述架构的要点。主要功能点如下：

不知道大家是否还有上述架构“形式服从功能”的印象。当然，这并不是一个权威的定义，可以作为参考。无论形式追随功能还是功能追随形式，我们都可以用结构化思维来理解这句话。架构大致可以分为：形式和功能，所以我们依次按照这两点来构建项目。

3.1 架构-形式

表格本身由两部分组成。一是事物的外部形状，二是事物的内部结构和组合。事实上，两者是一回事。内容内部如何组合，外部自然会有一定的表现形式。

框架中用到的模式_android常见设计模式和框架_安卓框架模式

当我们打开项目时，我们首先遇到并看到的就是项目的目录结构。更清晰、更简洁的目录结构可以帮助我们更快的开始项目。主要分为核心模块和业务功能模块两部分：

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

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

主APP分为核心和. 业务模块不是以模块化的形式拆分成多个部分，而是以包的形式聚合在主APP下。这样做的好处如下：

可以看到我们并没有按照业务采取模块化划分，因为我之前参与过一个项目，拆分了40多个人。可以想象，一旦项目变大，弊端就会暴露出来：

当然，我并不反对多模块化的存在，因为任何模式都有优点和缺点，要根据当前项目的业务来决定采用哪种形式。此外，所有项目都是使用以下内容编写的：

3.2 架构-功能

游戏中的业务点和功能主要包括文章和项目获取，而这些功能点大多都离不开网络请求和回调处理。这里我不再描述MVC、MVP和MVVM之间的区别以及如何选择它们，但我可以解释一下，不存在最好或最优的架构模型。只有最适合当前业务的架构才是好的架构。目前官方推荐的架构主要是MVVM，所以我们主要讲MVVM。更多详情可以查看官网文档应用架构指南：

android常见设计模式和框架_框架中用到的模式_安卓框架模式

MVVM架构模式满足了上述架构设计的目的，同时也遵循官方给出的架构原则。架构原理大致如下。仅看这两个定义可能不太容易理解。我们通过结构化思维了解到的就是，关注点分离就是将复杂的问题合理分解，然后研究分解的各个方面，最后综合出整体的解决方案。因此，我们应该或者不应该做业务逻辑，而是将功能点拆分成需求最低的最优解决方案，最后合并成整体解决方案。比如我们推导出mvvm、、Model等等。

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

模型驱动接口模型是负责处理应用程序数据的组件。它们独立于应用程序中的视图对象和应用程序组件，因此不受应用程序生命周期和相关关注点的影响。

MVVM中的每个组件仅依赖于其下级组件，例如：-->-->。这时候你可能会想，如果是单向依赖的话，网络请求的回调怎么处理呢？这就引入了一个“反应式编程”的概念，它与观察者模式以及关联视图的声明周期如：、or相结合。使用的好处如下：

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

不会因停止而崩溃如果观察者的生命周期处于非活动状态（例如在返回堆栈上），它将不会收到任何事件。

不再需要手动处理生命周期。接口组件只需观察相关数据，无需停止或恢复观察。所有这些操作都是自动管理的，因为它在观察到相关生命周期状态变化时会意识到。

3.3

是Clean架构中的一个概念，主要用于UI和数据层的连接，也用于IO的切换。这里可以看到这个项目已经放弃了它，因为它可以完全被替换。

abstract class UseCase where Type : Any {
  abstract suspend fun run(params: Params): Either{
  operator fun invoke(params: Params, onResult: (Either) -> Unit = {}) {
      val job = GlobalScope.async(Dispatchers.IO) { run(params) }
      GlobalScope.launch(Dispatchers.Main) { onResult(job.await()) }
  }
  class None
}
复制代码
复制代码

3.4 一个完整的网络请求流程

框架中用到的模式_安卓框架模式_android常见设计模式和框架