Android中常用的设计模式
一：参考文档
先介绍参考文档（或许我们更容易明白）：另记录本人可参考 QQ15 MobileSafe 两个Demo
- 有哪些在实际 Android 项目中用到的设计模式？
- Android开发中常见的设计模式
- Android中常见的设计模式
- Android设计模式之23种设计模式一览
- Android中常用设计模式
二：然后总结一下
其总结内容多根据参考文献文档而来，还请了解文档内容
（一）什么是设计模式
1. 基本定义：设计模式（Design pattern）是一套被反复使用的代码设计经验的总结。使用设计模式的目的是为了可重用代码让代码更容易被他人理解。设计模式是是软件工程的基石脉络，如大厦的结构一样。
2. Design pattern的四大要素：模式名（Name），问题（Question），解决方案（Solution），效果（Efftive）。
3. OO（面向对象）的六大原则：单一职责原则，开闭原则，里氏替换原则，依赖倒置原则，接口隔离原则，迪米特原则。
单一职责原则：一个类中应该是一组相关性很高的函数，数据的封装。两个完全不一样的功能就不应该放在一个类中。
开闭原则：对修改封闭，对扩展放开。里氏替换原则：抽象和继承；所有引用基类的地方必须能透明的使用其子类的对象。
里氏替换原则：抽象和继承；所有引用基类的地方必须能透明的使用其子类的对象。
依赖倒置原则：抽象不应该依赖细节，细节应该依赖抽象。
接口隔离原则：将大接口改成多个小接口。
迪米特原则：也称为最少知识原则，一个对象应该对另一个对象有最少的了解。
（二）设计模式的分类
设计模式分为三种类型：
（1）创建型模式5种：
单例模式，抽象工厂模式，工厂模式，原型模式，建造者模式。（口诀：单原建造者，东西二厂）
（2）结构型模式7种：
适配器模式，桥接模式，装饰模式，组合模式，外观模式，享元模式，代理模式。（口诀：一器一桥一代理；装饰组合外观）
（3）行为型模式11种：
观察者模式，中介者模式，访问者模式，解释器模式，迭代器模式，备忘录模式，责任链模式，状态模式，策略模式，命令模式，模板模式。（口诀：三者两器、一录一链一模板，状态策略命令）
（三）Android 中的设计模式
（1）单例模式：
简介：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
示例：Android中的系统级服务都是通过容器的单例模式实现方式，以单例形式存在，减少了资源消耗。
比如LayoutInflater Service，将这些服务以键值对的形式存储在一个HashMap容器中，用户使用时只需要根据key来获取到对应的ServiceFetcher，然后通过ServcieFetcher对象的getService函数来获取到具体的服务对象，第一次获取时会调用ServcieFetcher的createService函数创建服务对象，然后将该对象缓存到一个列表中，下次再取时直接从缓存中获取，避免重复创建对象，从而达到单例的效果。
（2）抽象工厂模式：
简介：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
示例：Android底层对MediaPlayer的创建。
MediaPlayerFactory是Android底层为了创建不同的MediaPlayer所定义的一个类。
（3）工厂模式：
简介：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。
示例：BitmapFactory位图工厂，专门用来将指定的图片转换为指定的位图Bitmap。
（4）原型模式：
简介：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
示例：比如我们需要一张Bitmap的几种不同格式：ARGB_8888、RGB_565、ARGB_4444、ALAPHA_8等。那我们就可以先创建一个ARGB_8888的Bitmap作为原型，在它的基础上，通过调用Bitmap.copy(Config)来创建出其它几种格式的Bitmap。另外一个例子就是Java中所有对象都有的一个名字叫clone的方法，已经原型模式的代名词了。在系统中要创建大量的对象，这些对象之间具有几乎完全相同的功能，只是在细节上有一点儿差别。
（5）建造者模式：
简介：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
示例：AlertDialog.Builder ImageLoader的初始配置。
（6）适配器模式：
简介：将一个类的接口转换成客户希望的另外一个接口。
示例：不同的数据提供者使用一个适配器来向一个相同的客户提供服务。ListView或GridView的Adapter。
（7）桥接模式：
简介：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
示例：Window和WindowManager之间的关系。
在FrameWork中Window和PhoneWindow构成窗口的抽象部分，其中Window类为该抽象部分的抽象接口，PhoneWindow为抽象部分具体的实现及扩展。而WindowManager则为实现部分的基类，WindowManagerImpl则为实现部分具体的逻辑实现。
（8）装饰模式：
简介：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
示例：Activity继承自ContextThemeWrapper，ContextThemeWrapper继承自ContextWrapper，ContextWrapper才是继承自Context。ContextWrapper就是我们找的装饰者。
（9）组合模式：
简介：将对象组合成树形结构以表示“部分-整体”的层次结构。
示例：View和ViewGroup的组合
（10）外观模式
简介：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，统一编程接口。
示例：ContextImpl
（11）享元模式：
简介：运用共享技术有效地支持大量细粒度的对象。
示例：Message.obtainMessage通过重用Message对象来避免大量的Message对象被频繁的创建和销毁。
（12）代理模式：
简介：为其他对象提供一个代理以控制对这个对象的访问。
示例：所有的AIDL都一个代理模式的例子。假设一个Activity A去绑定一个Service S，那么A调用S中的每一个方法其实都是通过系统的Binder机制的中转，然后调用S中的对应方法来做到的。Binder机制就起到了代理的作用。
（13）观察者模式：
简介：一个对象发生改变时，所有信赖于它的对象自动做相应改变。
示例：我们可以通过BaseAdapter.registerDataSetObserver和BaseAdapter.unregisterDataSetObserver两方法来向BaseAdater注册、注销一个DataSetObserver。这个过程中，DataSetObserver就是一个观察者，它一旦发现BaseAdapter内部数据有变量，就会通过回调方法DataSetObserver.onChanged和DataSetObserver.onInvalidated来通知DataSetObserver的实现类。事件通知也是观察者模式。
（14）中介者模式：
简介：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
示例：Binder机制。
(15)访问者模式:
简介：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
示例：编译时注解中的ElementVisitor中定义多个Visit接口，每个接口处理一种数据类型，这就是典型的访问者模式，访问者模式正好解决了数据结构和数据操作分离的问题，避免某些操作污染了数据对象类。
（16） 解释器模式：
简介：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
示例：PackageParser这个类对AndroidManifest.xml这个配置文件的解析过程，
（17）迭代器模式
简介：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
示例：在Android中除了各种数据结构体，如List，Map，等包含的迭代器以外，Android源码中也提供了迭代器遍历模式，比如数据库查询使用Cursor，当我们使用SQLiteDataBase的query方法查询数据库时，会返回一个Cursor游标对象，该游标对象实际上就是一个具体的迭代器。
（18）备忘录模式
简介：不需要了解对象的内部结构的情况下备份对象的状态，方便以后恢复。
示例：Activity的onSaveInstanceState和onRestoreInstanceState就是通过Bundle这种序列化的数据结构来存储Activity的状态，至于其中存储的数据结构，这两个方法不用关心。
（19）责任链模式
简介：有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
示例: 责任链模式在Android源码中比较类似的实现莫过于对事件的分发处理，每当用户接触屏幕时候，Android都会将对应的事件包装成一个事件对象从ViewTree的顶部至上而下的分发传递。ViewGroup事件投递的递归调用就类似一条责任链，一旦寻找到责任者，那么就由责任者持有并消费该次事件，具体的体现在View的onTouchEvent方法中的返回值，如果OnTouchEvent返回false，那么意味着当前View不会是该次事件的责任人，将不会对该事件持有。
（20）状态模式：
简介：状态发生改变时，行为改变。
示例：View.onVisibilityChanged方法，就是提供了一个状态模式的实现，允许在View的visibility发生改变时，引发执行onVisibilityChanged方法中的动作。
（21）策略模式
简介：定义了一系列封装了算法、行为的对象，他们可以相互替换。
示例：Java.util.List就是定义了一个增（add）、删（remove）、改（set）、查（indexOf）策略，至于实现这个策略的ArrayList、LinkedList等类，只是在具体实现时采用了不同的算法。但因为它们策略一样，不考虑速度的情况下，使用时完全可以互相替换使用。
（22）命令模式
简介：把请求封装成一个对象发送出去，方便定制、排队、取消。
示例：Handler.post后Handler.handleMessage。
（23）享元模式
简介：运用共享技术有效地支持大量细粒度的对象。
示例：Message.obtainMessage通过重用Message对象来避免大量的Message对象被频繁的创建和销毁。
三：实例
在参考文档中有许多简洁易懂的实例，我就只列举一部分常用的，不一一列举了，具体请参考文档
一：单利模式
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
这样做有以下几个优点
- 对于那些比较耗内存的类，只实例化一次可以大大提高性能，尤其是在移动开发中。
- 保持程序运行的时候该中始终只有一个实例存在内存中
public class singleton{
private volatitle static instance; //使用volatile 表明每次都会去内存中读取最新的值; static 表明生成周期和当前应用一样
public singleton(){
}
public static singleton getInstance(){ //同样使用静态方法获取
if(instance == null){
synchronized (singleton.classs){ //在多线程中获取需要进行同步，或者会导致同步问题
if(instance == null)
instance = new singleton();
}
}
return instance;
}
}要保证单例，需要做一下几步
必须防止外部可以调用构造函数进行实例化，因此构造函数必须私有化。
必须定义一个静态函数获得该单例
单例使用volatile修饰
使用synchronized 进行同步处理，并且双重判断是否为null，我们看到synchronized (Singleton.class)里面又进行了是否为null的判断，这是因为一个线程进入了该代码，如果另一个线程在等待，这时候前一个线程创建了一个实例出来完毕后，另一个线程获得锁进入该同步代码，实例已经存在，没必要再次创建，因此这个判断是否是null还是必须的。
public class BlackDao {
// 单例设计模式：在整个应用程序中，不管什么地方，获得的都是同一个对象实例
private BlackDao(Context ctx){
dbHelper = new BlackNumDbHelper(ctx, "black_num.db", 1);
}
private static BlackDao instance;
public static synchronized BlackDao getInstance(Context ctx){
if(instance == null){
instance = new BlackDao(ctx);
}
return instance;
}
private BlackNumDbHelper dbHelper;
private String table_black_num = "black_num";
其实我们在吐司时也用到了单例：
public class ToastUtils {
private static Toast sToast;//静态的
// sToast 静态的 context.getApplicationContext() 如果直接是context 会造成内存泄漏
public static void showToast(Context context, String msg){
if (sToast==null){//单例的吐司，连续点击会立即显示
sToast = Toast.makeText(context.getApplicationContext(), msg, Toast.LENGTH_SHORT);
}
//如果这个Toast已经在显示了，那么这里会立即修改文本
sToast.setText(msg);
sToast.show();
}
}二：Builder（建造者）模式
当需要创建一个对象需要很多变量组合而成，这个时候可以考虑将这个对象的创建过程和对象的表示分离开来，这样可以很简洁的构建一个复杂的对象。(然而 我们并不懂这句话 没个卵用) 这里我们参考http://www.cnblogs.com/android-blogs/p/5530239.html 下的Builder建造者模式
其实在Android中， Builder模式也是被大量的运用。比如常见的对话框的创建
AlertDialog.Builder builder=new AlertDialog.Builder(this);
AlertDialog dialog=builder.setTitle("标题")
.setIcon(android.R.drawable.ic_dialog_alert)
.setView(R.layout.myview)
.setPositiveButton(R.string.positive, new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
}
})
.setNegativeButton(R.string.negative, new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
}
})
.create();
dialog.show();三：工厂模式
我们创建的activity或者fragment中，定义基类的时候，可以将每个界面不同的地方抽象出来，让真正实现的子类去实现该统一的方法。
例一：QQ15中
基类的方法
public class BaseFragment extends Fragment {
}
在不同的实现子类activity或者fragment中去实现该方法
/**
* 作者： itheima
* 时间：2016-10-17 10:42
* 网址：http://www.itheima.com
* 使用 工厂设计模式 都继承BaseFragment 生产 ...Fragment
*/
public class FragmentFactory {
//使用单例的对象 懒汉式
private static ConversationFragment sConversationFragment;
private static ContactFragment sContactFragment;
private static PluginFragment sPluginFragment;
public static BaseFragment getFragment(int position){
BaseFragment baseFragment = null;
switch (position) {
case 0:
if (sConversationFragment==null){ //懒汉式
sConversationFragment = new ConversationFragment();
}
baseFragment = sConversationFragment;
break;
case 1:
if (sContactFragment==null){
sContactFragment = new ContactFragment();
}
baseFragment = sContactFragment;
break;
case 2:
if (sPluginFragment==null){
sPluginFragment = new PluginFragment();
}
baseFragment = sPluginFragment;
break;
}
return baseFragment;
}
}例二：
基类的方法
public interface IBase {
/**
* 功能描述：给view绑定数据
**/
void onInitView(Bundle savedInstanceState);
/**
* 功能描述：获得布局文件Id
**/
int getLayoutResource();
}
在不同的实现子类activity或者fragment中去实现该方法
public class LoginActivity implements IBaseview{
@Override
public void onInitView(Bundle savedInstanceState) {
//....
}
@Override
public int getLayoutResource() {
return R.layout.activity_login;
}
}。。。。。。。。