从2008年9月23日发布 Android 1.0开始到现在的 Android 12，它已经历十三个年头，在这过程中经历了层层的升级改变……
随着 Android 版本的不断更新升级和用户对 APP 产品需求技术越来越高，相对的各大公司对 Android 开发者们设置的招聘门槛也越来越高。
至于如何去看一个开发者水平的高低，一般看面试官会怎么问，会问那些部分的技术内容？
一般公司对于一些刚入行的新手要求不会太高，但基本要懂得的技术还要懂的，不会太深入的去问。
而对于在 Android 开发行业有三五年经验的人，就不会这么简单的问了。会根据他们做过和设计到的一些项目进行询问。
因为在这个行业有太多挂着3-5年工作经验的“新手”，如果不深入的问，就很容易让他们拿着高工的薪资，且没有得到应该有的技术支持。
他们一般是如何开发的呢？
项目架构毫无章法，毫无设计模式，不追求极致的性能体验，总计就是东西做出来就行
想要评判技术水平的高低，可以用代码的好与坏来进行衡量。但在开发眼里，写好项目码第一步就是需要选择好的架构设计。
在 Android 开发行业中比较受欢迎的架构模式那肯定是组件化开发了。为啥？
- 对于初级进阶中高级的开发者来说，组件化是必备的。
- 对应大厂的项目中，组件化也是必备的。
- 对应大型项目中维护角度来说，组件化仍是必备的。
- 对应团队开发来说，组件化还是必备的。
- 对应提升开发效率来说，组件化依然是必备的。
为什么要选组件化开发？
首先说优势：
Android APP组件化架构的目标是：告别结构臃肿，让哥哥业务变得相对独立，业务组件在组件模式下可以独立开发，而在集成模式下又可以变成“app壳工程”中，组成一个完整功能的APP；
从组件化工程模型中可以看到，业务组件之间是独立的，没有关联的，这些业务组件在集成模式下是一个个library，被app壳工程所依赖，组成一个具有完整业务功能的APP应用，但是在组件开发模式下，业务组件又变成了一个个application，它们可以独立开发和调试，由于在组件开发模式下，业务组件们的代码量相比于完整的项目差了很远，因此在运行时可以显著减少编译时间。
组件化项目架构详解
-
集成模式: 所有的业务组件被“app壳工程”依赖，组成一个完整的APP；
-
组件模式: 可以独立开发业务组件，每一个业务组件就是一个APP；
-
app壳工程: 负责管理各个业务组件，和打包apk，没有具体的业务功能；
-
业务组件: 根据公司具体业务而独立形成一个个的工程；
-
Main组件:属于业务组件，指定APP启动页面、主界面 ；
-
Common组件: 也就是功能组件(component_base 模块)，支撑业务组件的基础，提供多数业务组件需要的功能，例如提供网络请求功能；
-
component_data组件: 存放与项目相关的公共数据,例如bean的基类,IntentKV存数据的键值对等.
-
SDK组件: 集成微信,支付宝支付,分享,推送等常用的第三方框架.
项目中实践
当你用组件化开发接触到大型项目时，你就会发现组件化开发的优点。如果你没有用组件开发进行时，你会发现一下问题：
- 编译时间长，每次改一个参数都需要编译整个项目
- 项目耦合太严重，每次复用一个功能都要Copy很多的关联类
- 团队开发不方便，不能很好的分工合作
根据上面的问题，你会发现组件化已成为每个Android开发必须掌握的一项技能，它能够让大家开发项目变得更方便，让大家的功能复用变得简单(因为在组件化项目中，每个功能彼此之间是没有关联的）：
从上图中我们会发现，在组件化架构的项目中，我们的每个业务逻辑模块从传统的用包名来划分升级到了用模块来划分，这样的好处在于，当在新项目中要用到一个之前项目的某一个功能的时候，如果两个项目都是组件化架构，那我直接复制过来就可以使用，不需要解耦合。
而且大家会发现，每个模块都是可以独立运行的Application，这样设计优势在于每个模块都能够独立的测试，能够提高我们的编译速度。再站在团队开发的角度来说，每个小项目组负责一个模块的功能，互不干扰，何乐而不为呢？
为了方便大家能够更好的掌握组件化开发，小编自行整理了一些 Android组件相关学习文档和Android 开发其他相关的学习文档、面试题、Android 核心笔记等等文档，希望能帮助到大家学习提升，如有需要参考的可以直接去我 GitHub地址访问查阅。
