Android 中用到设计模式的例子
AlertDialog、Notification 源码中使用了 Bulider（建造者）模式完成参数的初始化
在 AlertDialog 的 Builder 模式中并没有看到 Direcotr 角色的出现，其实在很多场景中，Android 并没有完全按照 GOF 的经典设计模式来实现，而是做了一些修改，使得这个模式更易于使用。这个的 AlertDialog.Builder 同时扮演了上下文中提到的 builder、ConcreteBuilder、Director 的角色，简化了 Builder 模式的设计。
当模块比较稳定，不存在一些变化时，可以在经典模式实现的基础上做出一些精简，而不是照搬 GOF 上的经典实现，更不要生搬硬套，使程序失去架构之美。
定义
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不 同的表示。即将配置从目标类中隔离出来，避免过多的 setter 方法。
优点
- 良好的封装性，使用建造者模式可以使客户端不必知道产品内部组成的细节。
- 建造者独立，容易扩展。
缺点
- 会产生多余的 Builder 对象以及 Director 对象，消耗内存。
日常开发的 BaseActivity 抽象工厂模式
定义
为创建一组相关或者是相互依赖的对象提供一个接口，而不需要指定它们的具体类。
主题切换的应用
比如我们的应用中有两套主题，分别为亮色主题 LightTheme 和暗色主题DarkTheme，这两种主题我们可以通过一个抽象的类或接口来定义，而在对应主题下我们又有各类不同的 UI 元素，比如 Button、TextView、Dialog、ActionBar等，这些 UI 元素都会分别对应不同的主题，这些 UI 元素我们也可以通过抽象的类或接口定义，抽象的主题、具体的主题、抽象的 UI 元素和具体的 UI 元素之间的关系就是抽象工厂模式最好的体现。
优点
- 分离接口与实现，面向接口编程，使其从具体的产品实现中解耦，同时基 于接口与实现的分离，使抽象该工厂方法模式在切换产品类时更加灵活、 容易。
缺点
- 类文件的爆炸性增加。
- 新的产品类不易扩展。
Okhttp 内部使用了责任链模式来完成每个 Interceptor 拦截器的调用
定义
使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的 耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
ViewGroup 事件传递的递归调用就类似一条责任链，一旦其寻找到责任者，那么将由责任者持有并消费掉该次事件，具体体现在 View 的 onTouchEvent 方法中返回值的设置，如果 onTouchEvent 返回 false，那么意味着当前 View 不会是该次事件的责任人，将不会对其持有；如果为 true 则相反，此时 View 会持有该事件并不再向下传递。
优点
- 将请求者和处理者关系解耦，提供代码的灵活性。
缺点
- 对链中请求处理者的遍历中，如果处理者太多，那么遍历必定会影响性能，特别 是在一些递归调用中，要慎重。
RxJava 的观察者模式
定义
定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
ListView/RecyclerView 的 Adapter 的 notifyDataSetChanged 方法、广播、事件总线机制。
观察者模式主要的作用就是对象解耦，将观察者与被观察者完全隔离，只依赖于 Observer 和 Observable 抽象。
优点
- 观察者和被观察者之间是抽象耦合，应对业务变化。
- 增强系统灵活性、可扩展性。
缺点
- 在 Java 中消息的通知默认是顺序执行，一个观察者卡顿，会影响整体的执行效率，在这种情况下，一般考虑采用异步的方式。
AIDL 代理模式
定义
为其他对象提供一种代理以控制对这个对象的访问。
静态代理：代码运行前代理类的 class 编译文件就已经存在。
动态代理：通过反射动态地生成代理者的对象。代理谁将会在执行阶段决定。将原来代理类所做的工作由 InvocationHandler 来处理。
使用场景
- 当无法或不想直接访问某个对象或访问某个对象存在困难时可以通过一 个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理 对象需要实现相同的接口。
缺点
- 对类的增加
ListView/RecyclerView/GridView 的适配器模式
适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接 口不匹配而无法在一起工作的两个类能够在一起工作。
使用场景
- 接口不兼容。
- 想要建立一个可以重复使用的类。
- 需要一个统一的输出接口，而输入端的类型不可预知。
优点
- 更好的复用性：复用现有的功能。
- 更好的扩展性：扩展现有的功能。
缺点
- 过多地使用适配器，会让系统非常零乱，不易于整体把握。例如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果出现太多这种情况，无异于一场灾难。
Context/ContextImpl 外观模式
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式 提供一个高层次的接口，使得子系统更易于使用。
使用场景
- 为一个复杂子系统提供一个简单接口。
优点
- 对客户程序隐藏子系统细节，因而减少了客户对于子系统的耦合，能够拥 抱变化。
- 外观类对子系统的接口封装，使得系统更易用使用。
缺点
- 外观类接口膨胀。
- 外观类没有遵循开闭原则，当业务出现变更时，可能需要直接修改外观类。
