-
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，降低使用者的理解难度。
- 支持开发模式
组件需要预留开发者模式，可以让使用者自行选择开启关闭。
打开开发者模式：组件运行的关键节点需进行日志输出，方便使用者进行调试，可以在运行时抛出异常。
关闭开发者模式：组件不再对外输出Error级别以下的日志，禁止在运行时抛出异常、ANR，如发生异常需要在组件内捕获并通过错误回调或打印Error级别日志等方式告知使用者。
- 可拓展性
部分组件（视具体情况而定，多数为对三方类库的封装组件）应该有一定的拓展性，应支持使用者自定义实现覆盖默认实现。
比如Dialog类库有默认弹窗样式，需要支持使用者自定义弹窗样式而不是只能在默认样式中进行选择，图片加载框架也是相同的逻辑。
开发规范
- 包名规范
为了避免无意中导致的包名冲突问题，约定组件的包名为4级，除去前两级的com.company为固定写法以外，后两级可根据具体的组件功能进行命名，并要求有良好的可读性。
- 资源规范
组件中定义资源文件时，要以组件名称为前缀，避免资源冲突导致的打包问题，需要在gradle文件的android节点下新增如下代码强制进行资源名称前缀检查：
android{
resourcePrefix = “${your_component_name}_”
}
总结
【Android 详细知识点思维脑图（技能树）】
我个人是做Android开发，已经有十来年了，目前在某创业公司任职CTO兼系统架构师。虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。
由于篇幅有限，这里以图片的形式给大家展示一小部分。
详细整理在GitHub可以见；
Android架构视频+BAT面试专题PDF+学习笔记
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
F%91%E4%B8%8D%E4%BC%9A%E8%BF%99%E4%BA%9B%EF%BC%9F%E5%A6%82%E4%BD%95%E9%9D%A2%E8%AF%95%E6%8B%BF%E9%AB%98%E8%96%AA%EF%BC%81.md)**
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
最后，赠与大家一句话，共勉！
