Android模块化设计之组件开发规范

规范本身就是开发人员之间的约定，没有最权威的，只有最适合的。

版本规范

为保证组件在各个项目中的兼容性问题，约定组件开发版本如下：

• AndroidSdk版本

• minSdkVersion：21

• targetSdkVersion：28

• 语言环境

• 开发语言：Kotlin

• Kotlin版本：1.4.x

• JDK版本：1.8

• 其他建议版本

• AndroidStuido：4.2

• gradle tools：4.1.x

• gradle：6.7.x

组件命名规范

根据组件的功能不同，约定组件分为三个类型：

• 基础组件

为项目提供与业务无关基础支持的组件库，如提供MVVM架构的_lib_basic_，提供依赖注入的_lib_basic_koin_，这类组件统一命名方式为lib_basic_xxx。这些基础组件也可以被工具组件和业务组件依赖，而不仅仅是只被项目依赖。

• 工具组件

对项目中常用的业务无关功能封装的组件库，如Dialog弹窗，相册选择等，这类组件统一命名方式为lib_util_xxx。

• 业务组件

在某个项目的需求中出现的在其他项目中可能也会用到的功能的封装，比如A业务员版中扫描拍照在A商业版中也有用到，于是单独封装为一个业务组件进行管理，这类组件统一命名方式为lib_tool_xxx。

• GroupId

所有组件统一GroupId为com.company.android，方便在Maven仓库中进行索引和管理。

• 版本号

对于迭代的版本号，不做强制性的要求，只需合理进行升级即可，但以下情况需特殊注意：

1、对于上传的开发版本，需要在版本中进行体现，如1.1.0-dev02，与正式版本做区分，在项目中验证无风险后，合并到主迭代版本中。

2、对于紧急修复A项目中的问题而临时发版的，需要在版本中进行体现，如1.1.0-hotfix-A，此次修改在其他使用的项目中验证无风险后，合并到主迭代版本中。

开发原则

• 开闭原则

在组件升级时，应对新增开放，对修改关闭，即做加法不做减法，目的是为了保证对项目中调用老版本API的兼容问题。对于不再建议使用的API，应使用 @Deprecated注解进行标注，并新增建议使用的API进行代替，而不是直接删除旧API。在完成多个稳定版本的迭代之后，可以所有组件使用者讨论删除旧版API的事宜。

• 向下兼容原则

所有组件的版本迭代必须向下兼容，即1.2.0版本须兼容1.1.0，在使用者升级版本之后，无需修改业务层代码。

如果因组件前期设计不合理导致升级必须修改业务代码时，组件开发者需要与所有组件使用者商讨技术实现方案，看能否以最小的改动完成组件的升级，并在组件功能开发完毕后，以书面形式告知使用者并提供完整的升级文档。

• 三方隔离原则

我们在封装组件的时候，难免会使用到第三方依赖，为了避免更换三方依赖或依赖升级造成的影响，需要对三方依赖库进行二次封装，避免直接使用。比如我们要使用glide框架加载图片，可以创建一个代理类对glide的功能进行代理，在业务代码中使用代理类进行操作而不是直接调用glide，这样我们将来替换glide框架时，能最小的改动业务代码。

当然，并不是所有的三方库都通过代理模式进行隔离，比如retrofit、RxJava等，毕竟我们的隔离原则是为了以后更简单的迭代而不是自寻烦恼。

• 最少依赖原则

为了减少项目中依赖的类库，在组件封装中遇到如下情况，应对组件进行拆分工作：

现封装一图片加载类库lib_util_imageloader，对Glide和Picasso进行了二次封装，由于两个类库提供了类似的功能，在项目中只需要使用一套就能满足业务需求，没有必要把两个图片加载框架都进行依赖，所以应该对lib_util_imageloader进行拆分为如下结构：

lib_util_imageloader_core：图片加载核心库，把加载图片的方法抽象为接口，面向项目，不做具体的实现。

lib_util_imageloader_glide：对glide进行二次封装，实现core中的接口。

lib_util_imageloader_picasso：对picasso进行二次封装，实现core中的接口。

在项目使用图片加载库时，除了必须要依赖的core外，只需要从glide和picasso中挑选一个即可，这样就不会把用不到的类库也打包到项目中去了。

这样的做法还有一个好处，就是容易拓展。如果我想要使用Fresco,只需要再新增一个lib_util_imageloader_fresco，并实现core的接口即可，在切换组件时，只需要改变gradle文件中的依赖，无需变更业务代码，因为业务代码都是基于core组件的。

• 最少可见原则

组件应该尽可能少的对外暴露类、接口、方法等。可以通过外观模式对使用者统一提供API，降低使用者的理解难度。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

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

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

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

总结

【Android 详细知识点思维脑图（技能树）】

我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

详细整理在GitHub可以见；

Android架构视频+BAT面试专题PDF+学习笔记

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

-1710569458316)]

详细整理在GitHub可以见；

Android架构视频+BAT面试专题PDF+学习笔记

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

最后，赠与大家一句话，共勉！