关于Android架构，你是否还在生搬硬套？，浅谈Android消息机制原理

最新推荐文章于 2024-09-17 21:04:05 发布

2401_84002630

最新推荐文章于 2024-09-17 21:04:05 发布

阅读量916

点赞数 20

分类专栏： 2024年程序员学习文章标签： android 架构

本文链接：https://blog.csdn.net/2401_84002630/article/details/137189643

版权

2024年程序员学习专栏收录该内容

210 篇文章 0 订阅

订阅专栏

1.3 Android如何做分层处理？
1.4 Data Mapper或许是解药
1.5 无处安放的业务逻辑
2. 合理分层是给数据驱动UI 做铺垫
2.1 什么是控制反转？
2.2 什么是数据驱动UI？
2.3 为什么说数据驱动UI底层思想是控制反转？
2.4 为什么引入Diff？
3. 为什么我建议使用函数式编程
3.1 什么是函数式编程？
3.2 Android视图开发可以借鉴函数式编程思想

1. 模块化的意义何在？

1.1 基本概念以及底层思想

所有的模块化都是为了满足单一设计原则 (字面意思理解即可)，一个函数或者一个类再或者一个模块，职责越单一复用性就越强，同时能够间接降低耦合性

在软件工程的背景下，改动就会有出错的可能，不要说"我注意一点就不会出错"这种话，因为人不是机器。我们能做的就是尽可能让模块更加单一，职责越单一影响到外层模块的可能性就越小，这样出错的概率也就越低。

所以模块化核心思想即：单一设计原则

1.2 我们要基于哪些特性去做模块化划分？

做模块化处理的时候尽量基于两种特性进行功能特性、业务特性

功能特性

网络、图片加载等等都可称之为功能特性。比如网络：我们可以将网络框架的集成、封装等等写到同一个模块(module、package等)当中，这样可以增强可读性(同一目录一目了然)、降低误操作概率，方便于维护也更加安全。同时也可将模块托管至远程如maven库，可供多个项目使用，进一步提升复用性

业务特性

业务特性字面意思理解即可，就是我们常常编写的业务，需要以业务的特性进行模块划分

为什么说`业务特性`优先级要高于`功能特性`？

举个例子如下图：

相信很多人见过或者正在使用这种分包方式，在业务层把所有的Adapter、Presenter、Activity等等都放在对应的包中，这种方式合理吗？先说答案不合理，首先这已经是在业务层，我们做的所有事情其实都在为业务层服务，所以业务的优先级应该是最高的，我们应当优先根据业务特性将对应的类放入到同一个包中。

功能模块核心是功能，应当以功能进行模块划分。业务模块核心是业务，应当优先以业务进行模块划分，其次再以功能进行模块划分。

1.3 Android如何做分层处理？

前端开发其实就是做数据搬运，再展示到视图中。数据与视图是两个不同的概念，为了提高复用性以及可维护性，我们应当根据单一设计原则我们应当将二者进行分层处理，所以无论是MVC、MVP还是MVVM最核心的点都是将数据与视图进行分层。

绊脚石：

通常来讲，我们通过网络请求拿到数据结构都是后端定义的，这也就意味着视图层不得不直接使用后端定义的字段，一旦后端进行业务调整会迫使我们前端从数据层-->视图层都会进行对应的改动，如下伪代码所示：

//原始逻辑

数据层

Model{

title

}

UI层

View{

textView = model.title

}

//后端调整后

数据层

Model{

title

prefix

}

UI层

View{

textView = model.prefix + model.title

}

复制代码

起初我们的textView显示的是model中的title，但后端调整后我们需要在model中加一个prefix字段，同时textView显示内容也要做一次字符串拼接。视图层因为数据层的改动而被动做了修改。既然做了分层我们想要的肯定是视图、数据互不干扰，如何解决？往下看…

1.4 Data Mapper或许是解药

Data Mapper是后端常用的一个概念，一般情况下他们是不会直接使用数据库里面的字段，而是加一个Data Mapper(数据映射)将数据库表转按需换成Java Bean,这样做的好处也很明显，表结构甭管怎么折腾都不会影响到业务层代码。

对于前端我觉得可以适当引入Data Mapper，将后端数据转换成本地模型，本地模型只与设计图对应，将后端业务与视图完全隔离。这也就解决了 1.3 面临的问题，具体方式如下：

数据层

Model{

title

prefix

}

本地模型(与设计图一一对应)

LocalModel{

//将后端模型转换为本地模型

title = model.prefix + model.title

}

UI层

View{

textView = localModel.title

}

复制代码

LocalModel相当于一个中间层，通过适配器模式将数据层与视图层做隔离。

前端引入Data Mapper后可以脱离后端进行开发，只要需求明确就可以做视图层的开发，完全不需要担心后端返回什么结构、字段。并且这种做法是一劳永逸的，比如后端需要对某些字段做调整，我们可以不暇思索直奔数据层，涉及到的调整100%不会影响到视图层

注意点：

当下有一部分公司为了将前后端分离更彻底，由前端开发人员提供Java Bean(相当于LocalModel)的结构，好处也很明显，更多的业务内聚到后端，很大程度提升了业务的灵活性，毕竟App发一次版成本还是比较大的。面对这种情况我们其实没必要再编写Data Mapper。所以任何架构设计都要结合实际情况，适合自己的才是最好的。

1.5 无处安放的业务逻辑

关于业务逻辑其实是一个很笼统的概念，甚至可以将任意一行代码称之为业务逻辑，如此宽泛的概念我们该如何去理解？我先大致将它分为两个方面：

界面交互逻辑：视图层的交互逻辑，比如手势控制、吸顶悬浮等等都是根据业务需要实现的，所以严格来说这部分也属于业务逻辑。但这部分业务逻辑一般在视图层实现。

数据逻辑：这部分是大家常说的业务逻辑，属于强业务逻辑，比如根据不同用户类型获取不同数据、展示不同界面，加上Data Mapper一系列操作其实就是给后端兜底，帮他们补全剩余逻辑而已。为了方便大家理解下文我将数据逻辑统称为业务逻辑。

前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。最重要的一点这些业务很难编写单元测试用例。

关于业务逻辑我建议单独写一个use case处理。

use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。这样就解决了ViewModel/Presenter臃肿的问题，同时更方便编写测试用例。

注意点：

好的设计都是特定场景解决特定问题，过度设计不仅解决不了任何问题反而会增加开发成本。以我目前经验来看Android开发至少一半的场景都很简单：请求-->拿数据-->渲染视图最多再加个Data Mapper，流程很单一并且后期改动的可能也不太大，这种情况就没必要写一个use case，Data Mapper扔到数据层即可。

2. 合理分层是给数据驱动UI 做铺垫