一、应用最广的模式--单例模式
概述：确保一个类只有一个实例，而且自行实例化并向整个系统或应用提供这个实例。
应用场景：确保一个类有且只有一个对象的场景，避免产生多个对象消耗过多的场景，或者某种类型的对象只有应该有且只有一个的情况。
特点：
- 构造函数不对外开放，一般为private；
- 通过一个静态方法或者枚举返回单例类对象；
- 确保单例的对象有且只有一个，尤其是在多线程环境下；
- 确保单例类对象在反序列化时不会重新构建对象。
实现方式：
- 饿汉模式
- 懒汉模式
- Double Check Lock
- 枚举单例
- 静态内部类实现单例
推荐常用的两种方式：
Double Check Lock
这种就是我们代码中常用的啦，双重加锁的同时，用volatile修饰变量
private volatile static Singleton singleton4;
public static Singleton getSingleton4() {
if (singleton4 == null) {
synchronized (Singleton.class) {
if (singleton4 == null) {
singleton4 = new Singleton();
}
}
}
return singleton4;
}
synchronized加锁使得同一时间只有一个线程能进入
外面又加了一层if判断其实就是为了性能，如果不为空就不需要进入下面锁的部分了，直接返回
volatile修饰符为了让singleton4实例在变化后立即写入主存，方便其他线程读取，否则有可能造成空指针，因为new的过程不是一瞬间的，所以有可能在操作过程中，另一个线程读到singleton4还是空的。
优点：线程安全，懒加载，性能也还可以
缺点：有点复杂，可能加载速度不快
静态内部类模式-号称最优雅单例
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getSingleton5() {
return SingletonHolder.INSTANCE;
}
ok，你说只会存在一个实例我是看到了，但是这个为啥就能保证线程安全了呢？
这就要说到类的初始化了，类初始化阶段是类加载过程的最后一步，也是执行类构造器<clinit>()方法的过程。
而虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步。如果有多个线程去同时初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其它线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。
所以，明白了吧，内部类在初始化过程中是线程安全的，所以就能保证这个单例的创建也是线程安全的。
优点：线程安全，懒加载，代码量少，简单易懂
缺点：在调用getSingleton方法不能带上参数进行实例化。如果是要使用Context 的话，可以写一个全局Context 单例 ，这样就可以获取context 了。
二、自由扩建你的项目--建造者模式（Builder模式）
概述：Builder模式是一步一步创建一个复杂对象的创建型模式。它允许用户在不知道内部构建细节的情况下，可以更精细地控制对象的构造流程。该模式是为了将构建复杂对象的过程和它的部件解耦，使得构建过程和部件的表示隔离开来。这个模式的重点是突出构造的过程，可以精细地控制构造流程。
应用场景：
- 初始化一个对象特别复杂，如参数多，且很多参数都具有默认值时。
- 产品类非常复杂，或者产品类中的调用顺序不同产生了不同的效能，这个时候使用建造者模式非常合适；
- 相同的方法，不同的执行顺序，产生不同的事件结果时；
优点：
- 良好的封装性，能够生成多种多样的对象
- 代码简洁易读
实现：参考Android 对话框（AlertDialog.Builder）的创建。
三、工厂方法模式
概述：定义一个用于创建对象的接口，让子类决定实例化哪个类。
应用场景：在任何需要生成复杂对象的地方，都可以使用工厂方法模式。
个人观点：网上有一些描述工厂模式说“用new 就可以完成创建的对象无需使用工厂方法模式”，个人不太认为这句话的描述是对的。例如Android 里面 Executors 里面的DefaultThreadFactory，这个类的实例也是可以直接new出来的，为何设计上还是用了工厂模式呢。对于工厂模式的使用，第一创建的对象可以代入产品的概念，这些产品也可以扩展，且每个产品也是比较复杂的，这种情况下，我认为就可以使用工厂方法模式了。
扩展（简单工厂模式、工厂模式和抽象工厂模式的区别）：
简单工厂模式：只有一个产品和一个工厂。
工厂方法模式：多个产品且每一个产品对应一个工厂。
抽象工厂模式：一系列的产品族，每个产品有一定的共性，每个工厂都对应了这一系列产品的创建，意思是每个工厂会生辰不同类型的产品。
四、观察者模式
概述：观察者模式使用率非常高，几乎没有接触到的项目是不使用的。定义对象间一种一对多的依赖的关系，使得每当一个对象状态改变，则所有依赖于它的对象都会得到通知并通知更新。我们平时所说的回调就是当观察者只有一个的情况。
应用场景：
- 当一个对象的改变需要通知其它对象改变时，而且它不知道具体有多少个对象有待改变时。
- 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。
- 跨系统的消息交换场景，如消息队列、事件总线的处理机制。
五、其他常用设计模式简单介绍
策略模式：
封装不同的算法，算法之间能互相替换。突出策略，主要是针对同一个问题，有多种解决策略。例如要对数组排序，可以选择快速排序，冒泡排序。
状态模式：
根据不同的状态做出不同的行为。突出状态，不同状态下有不同的行为表现。
中介者模式**：
将网状结构转变为星型结构，所有行为都通过中介。用一个中介者对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用，从而使其松散耦合，而且可以独立地改变它们之间的交互。在程序中，如果类的依赖关系过于复杂，呈现网状的结构，可以使用中介者模式对其进行解耦。
组合模式：
将整体与局部（树形结构）进行递归组合，让客户端能够以一种的方式对其进行处理。将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。组合模式有时叫做部分—整体模式，主要是描述部分与整体的关系。组合模式实际上就是个树形结构，一棵树的节点如果没有分支，就是叶子节点;如果存在分支，则是树枝节点。例如Android 里面的View 与 ViewGroup 的嵌套组合就是这种情况。
适配器模式：
将原来不兼容的两个类融合在一起。将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。生活中的手机充电器就是一个适配器的例子，手机一般都是在5V的电压下进行充电，但是外部的电压都是220V，那怎么办，这就需要充电器去适配了，将220V的电压转换为5V。实际开发中，我们常遇到两个类之间的接口不兼容，但是又不想去改动接口，这可以通过适配器模式来解决这个问题。
享元模式：
使用对象池来减少重复对象的创建。享元模式是对象池的一种实现。享元模式用来近可能减少内存使用量，适合用于可能存在大量重复对象的场景，来缓存可共享的对象，达到对象共享，避免创建过多对象的效果。
外观模式：
对外提供一个统一的接口用来访问子系统。外观模式通过一个外观类使得整个系统的结构只有一个统一的高层接口，这样能降低用户的使用成本。通常我们对API进行封装，都会用到外观模式，只是我们可能不知道而已。
参考：一句话总结23种设计模式
