前言
很多人面试之前，可能没有在互联网公司工作过或者说工作过但年头较短，不知道互联网公司技术面试都会问哪些问题？ 再加上可能自己准备也不充分，去面试没几个回合就被面试官几个问题打蒙了，最后以惨败收场。
下述是我整理的android面试题汇总，由于篇幅原因，在这只把热点技术部分的题目列举出来，后续还会更新其余面试题内容，大家可以关注一下我，及时知晓我更新的知识点，同时这份面试集锦的整理也花费了我很多时间！
1.组件化（1）概念：
组件化：是将一个app分成多个module，每个module都是一个组件，也可以是一个基础库供组件依赖，开发中可以单独调试部分组件，组件中不需要相互依赖但是可以相互调用，最终发布的时候所有组件以lib的形式被主app工程依赖打包成一个apk。
（2）由来：app版本迭代，新功能不断增加，业务变得复杂，维护成本高业务耦合度高，代码臃肿，团队内部多人协作开发困难android编译代码卡顿，单一工程下代码耦合严重，修改一处需要重新编译打包，耗时耗力。方便单元测试，单独改一个业务模块，不需要着重关注其他模块。（3）优势：组件化将通用模块独立出来，统一管理，以提高复用，将页面拆分为粒度更小的组件，组件内部出了包含ui实现，还可以包含数据层和逻辑层每个组件度可以独立编译、加快编译速度、独立打包。每个工程内部的修改，不会影响其他工程。业务库工程可以快速拆分出来，集成到其他app中。迭代频繁的业务模块采用组件方式，业务线研发可以互不干扰、提升协作效率，并控制产品质量，加强稳定性。并行开发，团队成员只关注自己的开发的小模块，降低耦合性，后期维护方便等。（4）考虑问题：模式切换：如何使得app在单独调试跟整体调试自由切换
组件化后的每一个业务的module都可以是一个单独的app（ismodulerun=false）， release 包的时候各个业务module作为lib依赖，这里完全由一个变量控制，在根项目 gradle.properties里面ismodulerun=true。ismodulerun状态不同，加载application和androidmanifest都不一样，以此来区分是独立的apk还是lib。
在build.grade里面配置：
资源冲突
当我们创建了多个module的时候，如何解决相同资源文件名合并的冲突，业务module和basemodule资源文件名称重复会产生冲突，解决方案在于：
每个 module 都有 app_name，为了不让资源名重名，在每个组件的 build.gradle 中增加 resourceprefix “xxx_强行检查资源名称前缀。固定每个组件的资源前缀。但是 resourceprefix 这个值只能限定 xml 里面的资源，并不能限定图片资源。
依赖关系
多个module之间如何引用一些共同的library以及工具类
组件通信
组件化之后，module之间是相互隔离的，如何进行ui跳转以及方法调用，具体可以使用阿里巴巴arouter或者美团的wmrouter等路由框架。
各业务module之前不需要任何依赖可以通过路由跳转，完美解决业务之间耦合。
入口参数
我们知道组件之间是有联系的，所以在单独调试的时候如何拿到其它的module传递过来的参数
application
当组件单独运行的时候，每个module自成一个apk，那么就意味着会有多个application，很显然我们不愿意重复写这么多代码，所以我们只需要定义一个baseapplication即可，其它的application直接继承此baseapplication就ok了，baseapplication里面还可定义公用的参数。
2.插件化（1）概述
提到插件化，就不得不提起方法数超过65535的问题，我们可以通过dex分包来解决，同时也可以通过使用插件化开发来解决。插件化的概念就是由宿主app去加载以及运行插件app。
（2优点）
在一个大的项目里面，为了明确的分工，往往不同的团队负责不同的插件app，这样分工更加明确。各个模块封装成不同的插件apk，不同模块可以单独编译，提高了开发效率。 解决了上述的方法数超过限制的问题。可以通过上线新的插件来解决线上的bug，达到“热修复”的效果。 减小了宿主apk的体积。
（3缺点）
插件化开发的app不能在google play上线，也就是没有海外市场。