2024年安卓最全Android组件化和插件化，体系面试一般问些什么

题外话

我们见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了7、8年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

注意：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

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

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

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

• 拆成多个 module 开发就是组件化

• 以前的 Android 开发不是现在这样用 gradle 的，用的是 ant，做模块拆分 比较麻烦

• 现在有了 gradle，拆模块非常方便了。不过模块化开发是在 gradle 到来之 前就有了的

说下我的个人观点

这里比较下前端开发

• 前端的组件化和移动开发的组件化其实有类似但也有不同的地方

• 比如前端一个小的UI组件类似Android开发中的自定义UI，可以叫做组件，但是显然在移动开发中我们不会认为是一个组件，

• 在前端中组件的集合叫做组件库或者UI组件库，比如AntD，elementUI等

• 安卓也有UI组件库，比如QMUI等

• Android开发中，我们依赖了很多module，组件和模块我认为可以统一但是也可以细分

• 首先实现方式上他们并没有什么区别，都是通过module依赖实现的

• 如果非要区分，可以通过不同的维度来区分

• 借鉴下前端思想，在前端开发中，component文件夹多用于存放UI组件，所以我现在这样定义

• 我认为组件更偏向的是UI，其内部主要是一些UI组件

• 之所以把UI放在一起，是为了方便开发者查找和使用

• 这样平时积累的UI组件就不必各自为战，也能统一地去管理

• 模块更加偏向的是功能，模块具备了完整的某一块业务流程，目的是为了降低与主工程的耦合，方便调用，也就是解耦，

• 其内部可能是包含网络、图片、异步处理等

• 甚至很多时候，模块也需要能够独立打包

• 我认为模块的粒度是大于组件的，其内部类文件/资源文件的职责和分类也更丰富些（毕竟组件可能只专注于UI），如果非要说某个组件库多少多少代码那我觉得就有些抬杠了

插件化

---

App 的部分功能模块在打包时并不以传统方式打包进 apk 文件中，而是以另一种形 式二次封装进 apk内部，或者放在网络上适时下载，在需要的时候动态对这些功能 模块进行加载，称之为插件化。

这些单独二次封装的功能模块 apk ，就称作「插件」，初始安装的 apk 称作「宿 主」。

插件化是组件化的更进一步推进。

插件化基础：反射

反射基本使用

• 首先在我们的plugin目录下新建一个utils文件夹，里面写一个Utils类

class Utils {

private static final String TAG = “Utils”;

void shout(){

Log.d(TAG, "shout!!! ");

}

}

• 然后在plugin包下新建一个使用它的Activity -> PluginActivity

• 由于Utils的访问权限都是默认的，所以无法在包外去实例它，所以要通过反射

• 对于类的实例化，需要通过构造方法去实例，实例方法要扩大访问权限setAccessible(true)

• 对于方法的调用，需要在获取方法之后并扩大访问权限setAccessible(true)

• 下面是完整代码

public class PluginActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_plugin);

//使用反射

try {

//1.拿到类

Class utilsClass = Class.forName(“com.dsh.txlessons.plugin.utils.Utils”);

//2.拿到第一个构造方法

Constructor utilsConstructor = utilsClass.getDeclaredConstructors()[0];

//3. 扩大访问性 默认default包权限 -> public

utilsConstructor.setAccessible(true);

//4. 创建类实例（通过构造方法实例）

Object utils=utilsConstructor.newInstance();

//5. 获取方法

Method shoutMethod = utilsClass.getDeclaredMethod(“shout”);

//6. 扩大方法访问权限

shoutMethod.setAccessible(true);

//7. 方法执行

shoutMethod.invoke(utils);

} catch (IllegalAccessException e) {

e.printStackTrace();

} catch (InstantiationException e) {

e.printStackTrace();

} catch (NoSuchMethodException e) {

e.printStackTrace();

} catch (InvocationTargetException e) {

e.printStackTrace();

} catch (ClassNotFoundException e) {

e.printStackTrace();

}

}

}

反射的目的

Java 既然提供了可⻅性关键字 public private 等等，用来限制代码之间的可 ⻅性，为什么又要提供反射功能?

• 可⻅性特性的支持不是为了代码不被坏人使用，而是为了程序开发的简洁性。安 全性的话，可⻅性的支持提供的是 Safety 的安全，而不是 Security 的安全。 即，可⻅性的支持让程序更不容易写出 bug，而不是更不容易被人入侵。

• 反射的支持可以让开发者在可⻅性的例外场景中，可以突破可⻅性限制来调用自 己需要的 API。这是基于对开发者「在使用反射时已经足够了解和谨慎」的假设的。

• 所以，可⻅性的支持不是为了防御外来者入侵，因此反射功能的支持并没有什么 不合理。

插件化原理:动态加载

通过自定义 ClassLoader 来加载新的 dex 文件，从而让程序员原本没有的类可以被 使用，这就是插件化的原理。

1. 下面我们改造下代码

• 首先新建一个 module：「phone & Tablet Module」-> pluginapp

• 将app工程下utils文件夹移植到pluginapp工程下

• 改造app下PluginActivity反射代码,修改包名，其他不变

//1.拿到类

Class utilsClass = Class.forName(“com.dsh.pluginapp.utils.Utils”);

• 运行app，GG了，错误如下

Caused by: java.lang.ClassNotFoundException: Didn't find class "com.dsh.pluginapp.utils.Utils" on path: DexPathList[[zip file "/data/app/com.dsh.mydemos-q8nYNkNjIWB0F6mdYX_Gvg==/base.apk"] - 这个错误表示没有找到Utils这个类

2. 重点来了

上面的代码之所以会报错，是因为pluginapp同样是一个App工程，其本身经过打包也是一个apk的存在，所以我们app工程的类加载器是无法加载到pluginapp里面的类(.dex)文件的，所以才会报这样的错误

那么下面要解决的问题就是如何让app程序能够拿到pluginapp程序中的Utils

插件化的解决方案很粗暴，就是把插件工程的文件扔给宿主工程

下面我们实践一下

• 为了能够拿到插件工程中的文件，首先要将插件工程运行过后的apk复制到app工程的assets/apk目录下

• 现在我们拿到了apk，就可以通过DexClassLoader加载apk里面的类了

• 下面是代码，注释很详细

onCreate{

…

//------------------ 插件化使用 ------------------

//1. 将插件apk复制到缓存目录

File apk = new File(getCacheDir()+“plugin.apk”);

try (Source source = Okio.source(getAssets().open(“apk/pluginapp-debug.apk”));

BufferedSink sink = Okio.buffer(Okio.sink(apk))😉{

【附】相关架构及资料

往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。

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

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

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

课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。**

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

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

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