Android组件所用设计模式：为何回答MVP/MVC/MVVM被判错误？求正解

兄弟，我太懂你这种被面试官突然打断、说答案错误的懵圈感了！问题出在你混淆了「应用架构模式」和「Android系统组件内部依赖的设计模式」——你说的MVP、MVC、MVVM是我们开发者用来搭建App上层架构的方案，但面试官问的是Android系统自带的组件（比如Activity、BroadcastReceiver、Service这些）内部实现时用到的设计模式，完全是两个范畴！

下面给你梳理Android核心组件常用的设计模式，这才是面试官想要的答案：

• 观察者模式：最典型的就是BroadcastReceiver——系统作为被观察者发送广播，注册的接收器作为观察者接收并处理事件；另外LiveData、ContentObserver也都是基于观察者模式实现的。
• 单例模式：系统级服务比如ActivityManager、NotificationManager，都是通过getSystemService()获取的单例实例；我们自定义的Application子类，通常也会以单例形式存在。
• 工厂模式：系统创建Activity、Fragment实例时，底层用了工厂模式的变种——比如ActivityThread通过反射+类加载器来实例化Activity，不需要我们手动new，这就是工厂模式的核心思想：封装对象创建过程。
• 代理模式：Activity里的Context对象其实是ContextImpl的代理，我们调用的getResources()、startActivity()等方法，底层都是由ContextImpl来具体执行，代理模式在这里实现了接口和具体实现的解耦。
• 适配器模式：RecyclerView.Adapter、ListView.Adapter是最直观的例子，把数据源和UI组件解耦，让任意格式的数据都能适配到列表上；还有IntentFilter也是适配器，用来匹配不同的Intent请求。
• 模板方法模式：Activity的生命周期方法（onCreate、onStart、onResume）就是标准的模板方法——系统定义了生命周期执行的固定流程（模板），我们只需要在子类中重写具体的业务逻辑。
• 命令模式：Intent就是命令的封装，它包含了要执行的操作（比如启动Activity、发送广播），系统根据Intent的内容去执行对应的命令，发送者（比如点击按钮的代码）和执行者（系统组件）完全解耦。

补充一句：有些面试官可能表述不够清晰，把「组件内部的设计模式」说成「组件使用的设计模式」，才导致你误解成了上层架构。下次遇到类似问题，可以先反问一句：“您是指Android系统组件内部实现的设计模式，还是我们开发时基于组件的应用架构模式？”避免踩坑！

内容的提问来源于stack exchange，提问作者grv.takte