2024年安卓最新Android 组件化面试必备(1)，面试被逆袭的可能性大吗

最后

**一个零基础的新人，我认为坚持是最最重要的。**我的很多朋友都找我来学习过，我也很用心的教他们，可是不到一个月就坚持不下来了。我认为他们坚持不下来有两点主要原因：

他们打算入行不是因为兴趣，而是因为所谓的IT行业工资高，或者说完全对未来没有任何规划。

刚开始学的时候确实很枯燥，这确实对你是个考验，所以说坚持下来也很不容易，但是如果你有兴趣就不会认为这是累，不会认为这很枯燥，总之还是贵在坚持。

技术提升遇到瓶颈了？缺高级Android进阶视频学习提升自己吗？还有大量大厂面试题为你面试做准备！

提升自己去挑战一下BAT面试难关吧

对于很多Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些知识图谱希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

不论遇到什么困难，都不应该成为我们放弃的理由！

如果有什么疑问的可以直接私我，我尽自己最大力量帮助你！

最后祝各位新人都能坚持下来，学有所成。

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

需要这份系统化学习资料的朋友，可以戳这里获取

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

将会破坏：组件的 可替代性、可重用性、组件间耦合度

因为framework是基础模块嘛，所有business模块都依赖的模块，如此，不管你的business1模块是否依赖business2模块的对外接口，都会存在这一层依赖。

模块间的代码边界出现一些劣化。缺少了编译上的隔离。许多模块将会变得不够“独立”了。

可替代性、可重用性 越来越弱，想要替换或者复用某个business组件将变得越来越难。

将会导致，我们很难知道，哪些business对哪些business 接口有依赖。

同时，framework模块随着功能迭代，会不断膨胀。

这就是，中心化的问题。

于是我们很自然的想到了一个解决方案：

实现了另一种接口暴露的形式——“.api化”。

将 business模块 对外提供的接口单独抽到 business-api 模块中。其他依赖他的模块只需要依赖他的business-api即可。

这个方案如何实践下去呢？

微信的api化方案

微信团队出了一个很巧妙的方案，这个方案对android的组件化开发，产生了非常深远的影响。

后面很多做组件化开发的团队，在解决中心化问题基本都会用到类似的方案。

mp.weixin.qq.com/s/6Q818XA5F…

以下为，微信官方博客的原文引用：

使用方式和思路都很简单。对于java文件，将工程里想要暴露出去的接口类后缀名从“.java”改成“.api”，就可以了。

而且并不只是java文件，其他文件如果也想暴露，在文件名后增加".api”，也一样可以。

当然，要让工程支持这样的方式，gradle文件肯定会有一点改变。

它的实现原理也相当简单：自动生成一个“SDK”工程，拷贝.api后缀文件到工程中就行了，后面其他工程依赖编译的只是这个生成的工程。简单好用。

api方案有点类似于android的AIDL的思路。

微信API方案的变种

gradle 根据src/api文件来，自动生成{moduleName}-api模块。

如果，src/api文件不存在，将不会自动生成 {moduleName}-api 模块。

通过API模块来解决代码中心化问题带来的好处：

1. 让各个business的之间的依赖明确

2. 让business对外提供的接口明确。

从而加强了模块的：可替代性。

只要两个business对外提供的API一致，就可以相互替换。

3、单独编译、测试 business的单个模块

模块变多了，项目变大了，整个项目的编译速度变慢了。

业内有两种常用做法。

• 方案一：动态配置 build.gradle。

只要让单个的组建能编译成APP就能单独测试。

• 方案二：多壳APP

方案来自，在聚美优品。

这里需要注意：假如，Demo1是business1的壳APP。那么Demo1还需要依赖哪些businessXXX呢？

刚好，前面做的api化，能排上用场。

business1依赖的businessXXX-api模块对应的businessXXX模块，Demo1也需要依赖。

为甚？因为，business1依赖的businessXXX-api模块，意味着，business1需要依赖 businessXXX提供的功能，比如要跳转到businessXXX的activity？或者，要获取businessXXX的对象。

4、模块变多了，gradle代码同比增长，gradle 代码复用

• 版本号统一管理，依赖的统一管理

• 方案一：Extra properties

在项目跟目录的build.gradle文件中配置Extra属性

如此可以实现统一管理版本号，和依赖。

但是，但是，但是，这个方案存在明显的缺陷。

• 不支持，自动补全

• 不支持Find Usages，查找所有应用的地方

• 使用时，不支持点击跳转

严重影响开发体验。

• 方案二：buildSrc

• 支持，自动补全

• 支持，Find Usages

• 支持，点击跳转

• 更完美的语法高亮

• gradle文件复用

版本和依赖做到了统一管理，但是每个module都有各自的build.gradle，重复的build.gradle代码依然没有复用。

我们可以通过apply from:"xxx.gradle"的方式来复用gradle代码。

如下图

如上，我们可以在base.gradle中为每一个项目添加配置统一的编译逻辑，如：kotlin的支持，java版本的修改，maven库上场的逻辑等等

5、模块间：string、drawable、value、layout等，资源名冲突问题

如何防止资源名冲突？

比如businessA 和 businessB都在drawable目录下，都有一张同名的图片。

这两张图片只有一张会被打包到apk中，被使用。

这样就容易出现混乱。

这个问题比较好解决。让每个模块的资源名固定一个前缀。只要模块之间的前缀不一样就不会冲突。

gradle的resourcePrefix配置，刚好符合我们的需求。

如下配置，如果module中存在资源不以app_开头，**lint走查会报warnning。**注意不会编译失败。

android {

resourcePrefix ‘app_’

}

如下截图的warning：

6、由于多module分层的项目结构，导致 R.class 冗余

可以通过booster的资源内联工具解决，R类的冗余。

详细可以自己查看booster官网，booster是didi开源的一个插件。booster.johnsonlee.io/feature/shr…

7、模块间，公共资源string、drawable、layout等如何共享？

没有找到很好的解决方案。

每个方案都有缺陷

比如说，business1和business2都要用到同一张图片。

那么这张图片该放到哪里呢？

• 1、把他放到api模块里来共享

资源这种，并非功能依赖，放到api模块也不太合适。

因为这样可能造成business1和business2模块原本没有关联也没有依赖；

但因为共用同一个资源，却导致存在了依赖。

• 2、在business1和business2中都放一个图片

如此会增大包体

• 3、在business1和business2中都放文件名同名的图片，让编译时资源合并的时候只使用同一张图片。

如此一来，放开各个模块资源命名，也容易导致开发时发生冲突。

自定义lint规则，让存在common和{moduleName}两种前缀？

• 4、将这张图片下沉到base层，如：framework模块，或者，单开一个lib-resource

如此一来，将会出现资源中心化问题。

上面的方法多少都有些缺陷，大叔还没有找到一个优雅的方式。如果你有什么好想法，一定要留言告诉大叔，大叔在此谢过你了。

8、各个business 模块 之间能不能有直接依赖？

千万不能这么操作。

假如：在 business/setting 中直接在gradle配置中依赖，business:account。

那么编译上的代码隔离就彻底被毁。就跟不要谈组件的可重用性、可替代性了。

implementation project(“:business:account”)

9、Application生命周期如何派发

各个组件如何获得Application.attach()、Application.onCreate()、Application.onTerminate()等的回调。

未完待续

10、组件生命周期管理

未完待续，待大叔踩过坑，实现了，再来写。

11、组件实现热插拔

未完待续，待大叔踩过坑，实现了，再来写。

12、等等，未完待续

待大叔继续探索

三、升华

最后我们再回到，组件化本身上来。

组件化开发不仅仅是一种多module分层的项目结构；他不仅仅是一种架构；他更是一种架构思想，一种追求模块复用精神。

有人说小项目没有必要做组件化开发。大叔不这么认为，小项目依然适合做组件化，除非你们团队只有一个项目，并且项目几乎不需要迭代。组件跨项目的复用也是一件让人十分兴奋的优势。

前几年听烂了的技术中台，跟组件化的架构也不谋而合。

最后

---

小编在网上收集了一些 Android 开发相关的学习文档、面试题、Android 核心笔记等等文档，希望能帮助到大家学习提升，如有需要参考的可以直接去我 CodeChina地址：https://codechina.csdn.net/u012165769/Android-T3 访问查阅。

最后

今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。

最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

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

需要这份系统化学习资料的朋友，可以戳这里获取

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

pJxcsLB-1715774779339)]

【延伸Android必备知识点】

[外链图片转存中…(img-wFeR8GSH-1715774779340)]

【Android部分高级架构视频学习资源】

**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

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

需要这份系统化学习资料的朋友，可以戳这里获取

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