Android-模块化-面向接口编程，掌握这套精编android高级面试题解析的方法

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

面向接口编程的好处？

灵活性高没有依赖具体的实体，实现层可以任意的更改与切换。在模块化中可以相互依赖service(接口层)或依赖多个。‍

‍在模块化中的使用下面对于接口（interface）或api层统称为service，其含义为服务提供者。

对于，每一个 module 都一个独立的工程结构，每个 module 都有自己的 Service ,来统一暴露当前 module 所拥有能力与向外提供的服务。

对于 module 是在同一个工程里的项目结构，service 可以放到统一的一个 Module 下，我们统称为 Mediator，这样做的目的是为了减少 Module 创建与维护。假设你的工程有20个业务 Module 如果都同时增加一个 service 层就会造成 Module 数量翻一倍。由于这里存入的都一些接口类，也是每个业务 Module 向外提供的服务其体量不会太大，这里并只是一个建议并没有标准的做法。

当然也有更复杂的设计，一个 Module 又分不同的 service 实现如图，这里不在展开细说。

实际工程中使用与设计

在实际项目中有很多项目都同时开发两版本Pad与Phone，有的是两独立的工程，有的是在同一个工程内用 flavor 切换不同的工程，下面我就以通过 flavor 切换的工程结构举例。先看下工程的包的结构图：

可以看到 module 结构是分为三个部分，common, pad, phone, 如果每个service 都独立将增加3倍的 Module 数量。

使用一个 Mediator Module 统一管理这这些 service 就很好控制了 module 数量。

Service 创建

在 module_mediator 业务 module 下 common，pad、pone 下分别创建ICommonService, IService(pad), IService(phone)。ICommonService：公共服务。IService(pad)：pad服务并继承CommonService。IService(phone)：phone服务并继承CommonService。

注：这里为什么不用，PadService与PhoneService，是因为pad与phone版本同时只会存在一个，使用方只需要关心你提供的Service不用在区分版本，而且这里是一个继承关系也可以获取到共用的部分。

Service 实现

依赖 Mediator :

在业务 common\pad\phone module 下分别实现，ICommonService, Service(pad), IService(phone) ，在 common module 创建 CommonServiceImpl 实现 ICommonService，在 pad、phone module 分别创建 ServiceImpl 对应实现 IService 并继承与 CommonServiceImpl。

Service 注册

注册的方式有一般是通过代码用去注册，或通过注解进行注册。可以在 Application 注册也可以在业务 Module 下自己注册，如果使用注解则可以自动注册，具体要看项目怎样实现。例：

解释下 MediatorServiceFacator，它只是一个服务工厂也是一个接口类，作用是负责管理各业务方的 Service 主要功能是注册与获取 Service。上面的代码就是往里注册了一个会员的 Service。

可以看出这个函数只有两个参数，一个是接口class一个是实现类class，第一个参数cls：它会作为 key 来使用，第二个参数implClass：它会作为 value 来使用。

Service 使用

通过 MediatorServiceFacator 懒加载获取service对象，如果业务方没有注册则获取一个空的对象。

注册有 service 没有使用时是不会创建的，如果使用过则会缓存下来，下次调用则直接返回。（第一次是通过反射创建）例：

1. 在 mediator 模块下会员 CommonService 中 定义了一个模糊查询会员的方法。

2. 在会员模块下 common 中实现了该功能。

3. 在会员模块下 pad 中继承了这个实现。

4. 在其他模块 pad 下使用这个功能。

可以看到获取 Service 只要传对应接口就即可，对于使用方是不用关心实现方，在开发过程中只要先定义好接口，合作的同学就可以进入正常开发了。细心的同学可以看出，返回的数据类型也是一个接口类，为什么不直接返回一个普通 java 类呢？主要原因是通过接口方法达到双方 api 约定，例如 getName() :String 方法是通过方法名返回值达到约定效果，这样不依赖具体实现。

从上面的例子可以看出主要分为三个部分：1、定义接口。2、提供方实现接口。3、使用方都通过服务工厂获取服务使用。对于使用者来是很简单的，不需要关心实现，通过接口可以直接获取到实现，并且获取到结果可以直接使用，不需要做序列化处理。

有了路由通信我们为什么还使用面向接口编程？

路由模式虽然很好的解决了耦合的问题，但他的方法调用都是静态的，对于传参与返回值只能是基本类型，如果是对象需要做序列化与反序列化处理，对性能有一定影响。类似在调后台接口一样，同时降低了代码的可读性， 对于 app 而言所有 Module 都是在同一个应用下，没有必要做这些序列化操作。

对于复杂业务不好处理，例如一个业务需要多次通信，路由模式则不好处理，而通过接口通信则可以容易解决。例如：一个读卡的操作，业务方需要对它有开启、关闭、暂停等多个状态的操作。通过接口则可以直接返回一个读卡的 service 控制器， 这样可以直接进行相应的控制操作。

从上面代码中可以看出，上层回调结果的同时并回调了一个控制接口，这样就提供使用方一个反向操作的能力。

三、总结

通过路由通信，可以很好的解决模块间耦合，但拿不到对象无法持续交互，并且需要序列化，而通过接口通信，则很好地解决了这一点，并且代码可读性比较高。而接口通信会有一定的耦合性，也就是依赖了提供方的 service 层相当 api，但对于收益来说还是值得的方式。

在架构模式中，没有最好的模式只有比较合适自己项目的模式，希望大家都可以活学活用，谢谢。

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

《507页Android开发相关源码解析》

因为文件太多，全部展示会影响篇幅，暂时就先列举这些部分截图

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

）**
[外链图片转存中…(img-O09g2TwX-1713227647262)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！