Android-模块化-面向接口编程

一、概述

随着业务的发展,工程的逐渐增大与开发人员增多,很多工程都走向了模块化、组件化、插件化道路,来方便大家的合作开发与降低业务之间的耦合度。现在就和大家谈谈模块化的交互问题,首先看下模块化的几个优势。

模块化的优势

  1. 结构清晰:业务独立,代码实现分离,不会搅在一起。
  2. 便于协作:每个开发同学只要自己负责的模块,没有太多的耦合。
  3. 便于维护:各模块管理自己的代码、布局、资源,主工程可以方便添加与移除。

特点:高内聚、低耦合。

常见的模块化实现方式有两种

  1. 业务 Module 都放到同一个工程里。
  2. 每个业务 Module 都是一个独立的工程。

如图:

模块的划分

模块可分为多种类型,一般分为:三方的基础 SDK (网络请求,地图导航,推送等);自己平台的通用功能(网络请求的能力封装、图片加载能力封装、权限设置、UI组件等);业务模块的拆分(登录、交易、会员、硬件等)。

模块间通信

虽然功能已经按模块拆分,但是模块间通信也是多种形势,如果处理不好模块之间耦合严重维护成本增大。常见模块问通信有:直接依赖、事件或广播通信、路由通信、面向接口通信,下面就对比下几种通信优势。

二、实现方案

直接依赖


这种方式实现简单,但是耦合太严重,不方便维护与开发,当工程逐渐增大模块逐渐增多,依赖关系会非常复杂,不推荐这种方式。

事件或广播通信

EventBus: 我们非常熟悉的事件总线型的通信框架,非常灵活,采用注解方式实现,但是难以追溯事件。
广播: 安卓的四大组件之一,在一个模块中发送广播设置数据,在另一个模块中注册广播接收数据,使用广播进行数据传递方式广播相对于其他的方式而言消耗资源较多。

总结: BroadcastReceiver、EventBus,非常灵活,模块之间没有任何的耦合,但是代码的可读性差,难以追溯事件,不是很推荐。

路由通信

模块与模块之间不存在依赖关系,而是各自运作,简单的来说就是映射关系的路由通信,也是目前比较主流的一种方案,比较常用的开源框架是阿里的ARouter。

ARouter典型应用

从外部URL映射到内部页面,以及参数传递与解析跨模块页面跳转,模块间解耦拦截跳转过程处理登陆、埋点等逻辑跨模块API调用,通过控制反转来做组件解耦。

面向接口通信

以上几种方式只是简单的介绍,下面就具体说下通过接口解耦通信的方式,首先先看几个问题。

什么是面向接口编程?

接口大家都很熟悉,这里所说的面向接口编程,并不只是所谓的 java 中的 interface,而是指超类型,可以是接口也可以是抽象类。

面向接口比面向对象编程是更先进一步编程思想,而是附属于面向对象编程的体系,属于其中一部分,它是面向对象编程体系中的思想精髓之一。面向接口编程它的核心思想是将抽象与实现分离,从组件的级别来设计代码,达到高内聚低耦合的目的。面向接口编程方法是,先定义底层接口模块,也就是 通信的协议与功能约定 ,是提供方实现对应的功能与能力。在架构中层次分明,不需要关注具体实现,开发中可以通过接口快速制定协议,与提供能力api,对于上层通过接口显露能力,对于下层只需要依赖接口层相当于依赖api。

面向接口编程的好处?

灵活性高没有依赖具体的实体,实现层可以任意的更改与切换。在模块化中可以相互依赖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,但对于收益来说还是值得的方式。

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


https://mp.weixin.qq.com/s/KvOhI44jc4WRFVpHmJwO8g

Android 深色模式适配原理分析

从Android10(API 29)开始,在原有的主题适配的基础上,Google开始提供了Force Dark机制,在系统底层直接对颜色和图片进行转换处理,原生支持深色模式。深色模式可以节省电量、改善弱势及强光敏感用户的可视性,并能在环境亮度较暗的时候保护视力,更是夜间活跃用户的强烈需求。对深色模式的适配有利于提升用户口碑。

发布于:7天以前  |  101次阅读  |  详细内容 »

百度APP-Android H5首屏优化实践

百度App自2016年上半年尝试Feed流业务形态,至2017年下半年,历经10个版本的迭代,基本完成了产品形态的初步探索。在整个Feed流形态的闭环中,新闻详情页(文中称为落地页)作为重要的组成部分,如果打开页面后,loading时间过长,会严重影响用户体验。因此我们针对落地页这种H5的首屏展现速度进行了长期优化,本文会详细阐述整个优化思路和技术细节

发布于:16天以前  |  144次阅读  |  详细内容 »

Android 10分区存储介绍及百度APP适配实践

Google于 2019年9月3日发布了Android10 release版本,为了更好的保护用户数据并限制设备冗余文件增加,Android 10版本变更了设备外部存储访问方式,外部存储新特性称为分区存储(Scoped Storage), 分区存储遵循以下三个原则对外部存储文件访问方式重新设计,便于用户更好的管理外部存储文件

发布于:17天以前  |  150次阅读  |  详细内容 »

深入探究Android应用启动起点

开发者文档中提到,Android应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动或热启动。三种启动状态中,冷启动耗时最久,系统和App有较多初始化的工作。如果启动时间过长,可能会导致用户在应用商店打低分,甚至完全弃用app,所以冷启动速度是各个app非常重要的性能指标之一。

发布于:17天以前  |  145次阅读  |  详细内容 »

一文搞懂Android JetPack组件原理之Lifecycle、LiveData、ViewModel与源码分析技巧

Lifecycle、LiveData和ViewModel作为AAC架构的核心,常常被用在Android业务架构中。在京东商城Android应用中,为了事件传递等个性化需求,比如ViewModel间通信、ViewModel访问Activity等等,以及为了架构的扩展性,我们封装了BaseLiveData和BaseViewModel等基础组件,也对Activity、Fragement和ViewHolder进行了封装,以JDLifecycleBaseActivity、LifecycleBaseFragment和LifecycleBaseViewHolder等组件强化了View层功能,构建出了各业务线统一规范架构的基石。

发布于:29天以前  |  160次阅读  |  详细内容 »

Android 记一次解决问题的过程

之前我写过一篇文章,介绍我在GitHub开源的滑动控件 ConsecutiveScroller 是如何实现布局吸顶功能的。有兴趣的朋友可以去看一下:Android滑动布局ConsecutiveScrollerLayout实现布局吸顶功能。

发布于:1月以前  |  231次阅读  |  详细内容 »

Android内存异常机制(用户空间)_NE

常见的Android稳定性异常,有内核异常和Android层异常。内核异常也就是常说的“kernel panic”,简称KE异常;Android层异常又分为java层crash和Native层crash,简称JE、NE异常。 上篇文章介绍了JE异常的抓取机制和处理方式,本文再讲一下NE异常。

发布于:2月以前  |  538次阅读  |  详细内容 »

Android-模块化-面向接口编程

随着业务的发展,工程的逐渐增大与开发人员增多,很多工程都走向了模块化、组件化、插件化道路,来方便大家的合作开发与降低业务之间的耦合度。现在就和大家谈谈模块化的交互问题,首先看下模块化的几个优势。

发布于:2月以前  |  845次阅读  |  详细内容 »

Android SurfaceView 播放gif

Android SurfaceView 是Android系统中的高级组件,它有自己的绘制界面,可以在一个独立的线程进行UI的绘制, 因此不会阻塞主线程,这也是我们使用SuefaceView播放gif图片的原因。

发布于:3月以前  |  638次阅读  |  详细内容 »

Android Studio 生成so文件 及调用

so文件是C、C++的函数库,在Android中 调用这些库,使用的是JNI( Java Native interface) JNI 可以使Java程序调用本地程序或者库(一般是使用C、C++ 或者汇编语言编写)。 这篇文章 会介绍 使用Android Studio 如何生成so文件,及如何使用so

发布于:3月以前  |  846次阅读  |  详细内容 »

Android 保活从入门到放弃:乖乖引导用户加白名单吧(附7大机型加白示例)

IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论,自从Android 8.0后系统大大降低了后台运行应用的保活容忍度(详见《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》),保活从黑科技横行的时代进入了技术蛮荒阶段,真要实现保活,技术难度越来越大。

发布于:3月以前  |  846次阅读  |  详细内容 »

安居客 Android APP 走向平台化 | 开发者说·DTalk

安居客 Android App 距离上次的模块化/组件化重构已经两年多了,重构之后很好的支撑了两年多以来的业务发展。但这个世界总是在向前走的,没有任何一种架构能够一劳永逸的解决所有问题,外部环境的不断变化相应的也要求项目架构做出改变,以此来应对环境变化所带来的挑战。

发布于:3月以前  |  626次阅读  |  详细内容 »

Android View 体系竟然还能这么理解?

很多小伙伴可能在学习view的绘制流程源码的时候有点抓不住重点,所以在分析代码的时候绕来绕去脑袋晕乎乎的。今天我就来给大家化繁为简,只关注它最核心的东西。

发布于:3月以前  |  812次阅读  |  详细内容 »

移动端常见崩溃指标

崩溃分析,是将 Android 和 iOS 平台常见的 APP 崩溃问题进行归类分析,帮助企业根据崩溃指标快速发现、定位问题。

发布于:3月以前  |  833次阅读  |  详细内容 »

最多阅读

简化Android的UI开发 11月以前  |  290815次阅读
Android设计与开发工作流 11月以前  |  2821次阅读
Google Enjarify:可代替dex2jar的dex反编译 1年以前  |  2706次阅读
30分钟搭建一个android的私有Maven仓库 1年以前  |  2473次阅读
Android多渠道打包工具:apptools 1年以前  |  2264次阅读
Google Java编程风格规范(中文版) 1年以前  |  2259次阅读
Android UI基本技术点 1年以前  |  2229次阅读
Android权限 - 第一篇 1年以前  |  2192次阅读
Stetho 1年以前  |  2114次阅读
2015 Google IO带来的新 Android 开发工具 1年以前  |  2008次阅读
你应该知道的布局和属性 1年以前  |  1980次阅读
MVP在Android平台上的应用 1年以前  |  1953次阅读
听FackBook工程师讲*Custom ViewGroups* 1年以前  |  1953次阅读
Gradle小知识#3:任务的顺序 1年以前  |  1927次阅读