关于android app架构的一点思考

Posted 2023-03-28 pureChilder

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于android app架构的一点思考相关的知识，希望对你有一定的参考价值。

关于android app架构的一点思考

关于架构，我们首先要明白的点就是为什么要进行架构设计？
对程序进行架构设计的原因，对于大企业归根到底是为了提高生产力。通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题，而且也方便项目的管理和维护。
但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。

例子，一个Android应用中，关于Activity，就没有必要做Mvp，或者MVVM的设计，因为没有业务要求，也没有网络请求

但是当你开发的App最终代码量应该在10W行以上，本地需要进行复杂操作，同时也需要考虑到与其余的Android开发者以及后台开发人员之间的同步配合，那就需要在架构上进行一些思考。框架最终要实现的目的无非就是增强项目代码的可读性，维护性和方便测试。
安卓开始之初，业务层项目框架搭建从最初的mvc，到mvp，再到mvvm，再到mvvm的演化mvi，基本的思想都是是相同的，最本质的概念就是 Activity 里做的事情太多了，所以要把 Activity 中与 UI 无关的部分抽离出来，交给别人做。这个 “别人” 在 MVP 里叫作 Presenter，在 MVVM 里叫作 ViewModel。而不论是 MVP 中的约定接口，还是 ViewModel 里的观察者模式，这些都是实现上的细节而已。
而不管是MVC，MVP，MVVM，MVI他们的侧重点是数据从获取到展示的代码逻辑，所要解决的核心问题是数据和界面之间如何更好联系的问题，它的侧重点是界面和数据。

MVI
与前者的主要区别不在于强调严格的单向数据流，而在于从命令式的开发模式，转变为响应式的开发模式。我们并不是说越新潮，越复杂的架构就是最好的，只有合适的架构才是最好的。但是不可否认，从 React 到 Flutter，从 MVI 到 Compose，响应式编程似乎有一统天下的趋势。未来会怎么样，让我们拭目以待。

模块化，组件化、插件化在架构层面的侧重点是业务功能拆分，其中模块化是将应用按功能拆分不同组件或者模块，组件化可以让模块独立运行，不再相互依赖，组件可以依赖同一套libray，组件化最大的好处是有利于团队开发，在团队开发中不需要等待别人的代码，自己可以进行独立测试，写库的写库，写模块的写模块，互不干涉，在android中一个组件对应着一个module，组件化还有一个好处就是可以提高编译效率。在大型项目中使用组件化是必要的，然而在一些独立开发的小型项目中使用组件化反而得不偿失，因为组件化多少会带来代码和配置增多。插件化核心在于动态加载模块，在庞大的工程中，可以按需下载功能包，它不是官方支持的，是一种取巧的技术，在国内盛行，因为android的开源，framework层代码对程序员透明，插件化是android开发者解决一个又一个的问题后诞生的，首先解决的是加载dex文件，android PathClassLoader就能解决，其次是资源文件的加载(res、assets、so) AssetsManager能解决，在资源加载的过程中还要考虑资源id重复或者找不到的问题，再次要解决activity清单文件注册问题，在分析framework后可以采用hook，也就是在调用ams时和ams返回后两个地方进行移花接木，插件化解决了初安装包体太大的问题，按需加载也解决了功能动态下发的问题，但是维护性很高，比如每个android新版本都要做兼容，甚至完全要看谷歌让不让用。
组件化和插件化都是业务架构范畴，是考虑如何拆分以及更好的拆分业务才是核心。

附送一张我自己实现的架构设计：

详细设计：

具体到Store Module,Main Module,Mine Module模块之间的调用通过依赖该模块的export Module

如Mine Module中吊起Store Module，Mine Module依赖 Store Module Export模块即可

关于架构设计的一点思考

概述

从产品经理撰写出产品需求文档（包括产品原型、功能描述等），到研发编程实现，中间有巨大的鸿沟。越复杂的业务需求，这条鸿沟就越大。一般而言，我们至少还要有两个步骤：业务分析与架构设计。

业务分析是针对业务领域的建模，解决的问题是业务上如何实现，产出是分析模型。架构设计是针对技术领域的设计，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构，当然相应的也需要更新文档。

设计方法

架构设计不一定要深入到具体的实现细节，但是应该尽量全面的考虑系统的各个方面。关键是要对项目风险有比较大的把握，这样才能避免开发过程出现不可控的问题。具体设计需要多详细，是需要设计者自己去把握度的。

对于暂时无法确定的内容，应该在文档中注明，在开发过程早期进行试验和验证。如果对项目比较关键，可以考虑先行开发原型来进行验证。

架构设计常见的是4+1视图，即逻辑视图、开发视图、过程视图、物理视图，再加上场景。另外一种我更喜欢的是6步法设计方法。

关于架构设计的一点思考

1、确定整体架构

首先需要在整体上考虑系统的位置和职责：

确定系统在整个上下文中的位置，与其他系统的关联。
确定系统自身以及各个外部系统的职责。

整体架构对应的就是情景视图。这一步将系统看作一个黑盒，确认系统自己的范围和职责，相关的外部系统的职责，以及他们之间的关联。

例如，抢票酱小程序的整体架构大概是这样的。

关于架构设计的一点思考

2、设计功能模块

其次需要确定系统内部的功能模块及其职责：

确定系统的模块划分。
确定每个模块的职责以及模块间的关联。

功能模块对应的就是功能视图。这一步需要明确系统的内部结构。内部模块划分主要有基于业务功能的划分，以及基于实现层次的划分，稍复杂的系统可能会两者都有。基于业务功能的划分方式主要是功能树。

关于架构设计的一点思考

功能模块内部职责及模块之间的关系（接口定义）可以使用UML的组件图表示。

关于架构设计的一点思考

3、考虑设计模块

由于在抢票过程中，有很多状态，比如抢票中、提交中、已取消、待支付、已完成、已过期、休息中等等。因此，可以考虑使用状态机模式。

关于架构设计的一点思考另外，一个余票查询线程（根据出发车站、到达车站、出发日期查询）查到的结果可以供多个用户订单使用，所以，可以使用观察者模式设计余票查询。

4、设计外部接口

一般外部接口是通过HTTP 请求和 JSON 格式进行传输的，但也有可能会有其他的接口形式，例如消息队列、TCP、UDP、WebSocket等。设计阶段，API 文档可以通过 Markdown 文档记录，开发完成后可以独立维护，或者使用 Swagger 和代码一起维护。

接口设计需要注意几点：

接口的设计应该以系统提供的领域资源或服务为基础，同时考虑调用方的需求。
接口的粒度很重要，太细则调用方很不方便需要多次调用，太粗则无法灵活的满足各种需求，需要仔细权衡。
接口的设计也需要从调用方的角度考虑如何进行调用。必要的话可以画流程图、时序图、状态图详细说明调用顺序即状态转换等。
接口的文档一定要清楚的说明调用接口的方法、前置条件，参数作用、不同条件的处理、返回接口等。

下面是设计阶段用Markdown编写的判断用户是否登录的接口文档，可以作为参考。

简要描述：

检查用户是否登陆，在提交订单/候补订单前总是要先这样判断一下

请求URL：

https://kyfw.12306.cn/otn/login/checkUser

请求方式：

参数：

参数名	必选	类型	说明	示例
_json_att	是	string	是一个空字符串	""

返回示例

{
"validateMessagesShowId": "_validatorMessage",
"status": true,
"httpstatus": 200,
"data": {
"flag": true
},
"messages": [],
"validateMessages": {}
}

备注