Android 设计模式之(一)单例，代理，外观模式

单例模式

这个就不说了，分为懒汉式单例 饿汉式单例实现
参考我之前的Java 懒汉式单例 饿汉式单例

需要注意的地方，千万注意OOM，尽量使用getApplicationContext，而不是context，不要引用view

代理模式

模式介绍 ##

代理模式是对象的结构模式。代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。
就是一个人或者机构代表另一个人或者机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。

我们知道Activity实际上可以看做是Proxy类，代理的实际对象是ContextImpl，Activity的很多方法实际上执行的是ContextImpl的方法

//Activity间接继承自ContextWrapper类
public class ContextWrapper extends Context {
    Context mBase;
    public ContextWrapper(Context base) {
        mBase = base;
    }
    protected void attachBaseContext(Context base) {
        if (mBase != null) {
            throw new IllegalStateException("Base context already set");
        }
        mBase = base;
    }
    @Override
    public Resources getResources(){
        return mBase.getResources();
    }
    @Override
    public Looper getMainLooper() {
        return mBase.getMainLooper();
    }
    @Override
    public Context getApplicationContext() {
        return mBase.getApplicationContext();
    }
    ............
}

ActivityThread中初始化Activity的时候

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent)
Context appContext = createBaseContextForActivity(r, activity);
activity.attach(appContext, this, getInstrumentation(), r.token,
   r.ident, app, r.intent, r.activityInfo, title, r.parent,
   r.embeddedID, r.lastNonConfigurationInstances, config,
   r.voiceInteractor); //attach方法内部调用attachBaseContext(context);
class ContextImpl extends Context{
    ..........
    @Override
    public AssetManager getAssets() {
        return getResources().getAssets();
    }
    @Override
    public Resources getResources() {
        return mResources;
    }
    ........
}

此时ContextWrapper看做是一个proxy类，实际上也充当客户类，代理的实际对象是ContextImpl，两者都继承子Context类。除了这个地方，Android系统中还有很多地方使用了这种模式，比如 还有代理模式在Binder中的使用.
比如在Activity中使用getResource().getString(R.String.**),实际上执行的是ContextImpl中的方法

实际上代理也分静态代理跟动态代理，上面介绍的其实是静态代理了，两者的区别就是静态代理，proxy类在编译期间就生成了，但是动态代理，proxy类在运行过程才生成，主要通过InvocationHandler接口实现，动态代理原理，参考这里 公共技术点之Java动态代理

优点与缺点

优点
* 给对象增加了本地化的扩展性，增加了存取操作控制
缺点
* 会产生多余的代理类

外观模式

模式介绍 ##

外观模式(也成为门面模式)要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。它提供一个高层次的接口，使得子系统更易于使用。
Client : 客户端程序。
Facade : 对外的统一入口,即外观对象。
SubSystemA : 子系统A。
SubSystemB : 子系统B。
SubSystemC : 子系统C。
SubSystemD : 子系统D。
外观模式非常的简单，只是封装了子系统的操作，并且暴露接口让用户使用，避免了用户需要与多个子系统进行交互，降低了系统的耦合度、复杂度。如果没有外观模式的封装，那么用户就必须知道各个子系统的相关细节，子系统之间的交互必然造成纠缠不清的关系，影响系统的稳定性、复杂度。

其实在ContextImpl

class ContextImpl extends Context{
    @Override
    public void startActivity(Intent intent, Bundle options) {
        ..........
        mMainThread.getInstrumentation().execStartActivity(
            getOuterContext(), mMainThread.getApplicationThread(), null,
            (Activity)null, intent, -1, options);
        ..........
    }
    private ComponentName startServiceCommon(Intent service, UserHandle user) {
            ..........
            ComponentName cn = ActivityManagerNative.getDefault().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), user.getIdentifier()); //ActivityManagerNative子系统
            ..........
    }
    @Override
    public String getPackageName() {
        if (mPackageInfo != null) {
            return mPackageInfo.getPackageName(); //PMS子系统
        }
        .........
    }
}

在这里可以看到，ContextImpl内部有很多xxxManager类的对象，也就是我们上文所说的各种子系统的角色,ContextImpl可以看作是Facade对象，而实际调用的Activity和Service可以看作是客户端对象。ContextImpl内部封装了一些系统级别的操作，有的子系统功能虽然没有实现，但是也提供了访问该子系统的接口，比如获取ActivityManager的getActivityManager方法。

优点与缺点

优点
- 使用方便，使用外观模式客户端完全不需要知道子系统的实现过程；
- 降低客户端与子系统的耦合；
- 更好的划分访问层次；
缺点
- 减少了可变性和灵活性；
- 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”；

此时要注意区分代理模式和外观模式的区别！！！！！！Activity/ContextImpl/Context这些类的设计其实既实用了代理模式也使用了外观模式，同时这些类都充当多个角色，比如Activity既充当proxy类又充当client类角色