单例模式

Android设计模式之单例模式
单例设计模式可以说是应用程序中应用最广的模式之一，在应用单例模式时，单例对象的类必须保证只有一个实例存在，而且可以自行实例化并向整个系统提供这个实例。一般在不能自由构造对象的情况下，就会使用单例设计模式，例如创建一个对象需要消耗资源过多，还有访问IO和数据库等资源等情况。

1.面向对象的六大原则

设计模式本身并不复杂，但学习设计模式是程序员自我修炼、提升实力过程中必不可少的一环，首先我们从面向对象的六大原则说起，面向对象的六大原则有：

1）单一职责原则，一个类中，应该是一组组相关性很高的函数、数据的封装；
2）开闭灵活，软件中的对象应该对于扩展是开放的，而对于修改是封闭的；
3）里氏替换原则，所有能引用基类的地方必须透明地使用其子类的对象；
4）依赖倒置原则，指代了一种特殊的解耦形式，高层模块不应该依赖底层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象；
5）接口隔离原则，客户端不应该依赖它不需要的接口；
6）迪米特原则（最少知识原则），一个对象应该对其他对象有最少的了解。

在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用能够拥抱变化。意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合的系统架构。遵循面向对象六大原则就是我们走向灵活软件之路的第一步。

2.单例模式的优缺点

• 单例模式
  优点 在内存中只有一个实例，减少了内存开支和性能开销；可以避免对同一资源文件的同时写操作；可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。
  缺点 一般没有接口，扩展困难；单例模式如果持有 Context，很容易引发内存泄漏，此时需要注意传递给单例对象的 Context 最好是 Application Context。
  3.单例模式的UML类图
  

4.单例模式的几种实现方式

1.饿汉式

public class Singleton { /* 单例模式(饿汉式) */
private static final Singleton instance = new Singleton(); // 句柄 private Singleton() { }
return instance; }
}
2.懒汉式

优点是单例只有在使用时才会被实例化；缺点是第一次加载反应稍慢，每次调用
getInstance() 都进行同步，造成不必要的同步开销，一般不建议使用。
public class Singleton { /* 单例模式(懒汉式) */
private static Singleton instance; // 句柄
private Singleton() { }
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
}

3.DCL方式

Double Check Lock 实现单例，优点是既能够在需要时才初始化单例，又能够保证线程安全，且单例对象初始化后调用 getInstance() 不进行同步锁；缺点是第一次加载反应稍慢。
public class Singleton {
/* 单例模式(DCL方式) */
private volatile static Singleton instance = null; // 句柄

private Singleton() {}public static Singleton getInstance() {    if (instance == null) { // 避免不必要的同步        if (instance == null) {        }    }}

}

4.静态内部类方式——推荐使用

第一次加载不会初始化 Singleton，只有在第一次调用 Singleton 的 getInstance() 才会初始化，第一次调用会导致虚拟机加载 SingletonHolder 类，这种方式不仅能够确保线程安全，也能够保证单例对象的唯一性，同时也延迟了单例的实例化，推荐使用。

public class Singleton { /* 单例模式(静态内部类的方式) */
private Singleton() { }
public static Singleton getInstance() {
return SingletonHolder.instance;
}
private static class SingletonHolder {
private static final Singleton instance = new Singleton();
}
}

5.使用容器实现单例模式

在初始，将多种单例类型注入到一个统一的管理类中，在使用时根据 key 获取对象对应类型的对象。可管理多种类型的单例，并且在使用时可以通过统一的接口进行获取操作，降低了耦合度。
public class SingletonManager { /* 单例模式(使用容器实现单例模式) */
private static Map String, Object> objMap = new HashMap >();
private SingletonManager() { }
public static void registerInstance(String key, Object instance) {
if (objMap.containsKey(key)) {
objMap.put(key, instance); }
}
public static Object getInstance(String key) {
return objMap.get(key);
}
}

不管以何种形式实现单例模式，它们的核心原理都是将构造函数私有化，并且通过静态方法获取一个唯一的实例，在这个获取的过程中必须保证线程安全、防止反序列化导致重新生成实例对象等问题，选择何种取决于项目本身，并发环境是否复杂、单例对象等资源消耗等。

序列化：将一个对象的实例写到磁盘，然后再读回来，从而获得一个实例。

5.Android系统源代码中的应用情景

在Android系统中，我们经常通过 Context 获取系统级别的服务，如 WindowsManagerService、ActivityManagerService 等，更常用的是 LayoutInflater 的类：

LayoutInflater.from(context).inflate(layoutid, null);
这些服务会在合适的时候以单例的形式注册在系统中，在我们需要的时候就通过 getSystemService(String name) 获取。

我们可以看一下 LayoutInflater.from(context) 的实现：

/* Obtains the LayoutInflater from the given context. */public static LayoutInflater from(Context context) { LayoutInflater LayoutInflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE); if (LayoutInflater == null) { throw new AssertionError(“LayoutInflater not found.”); } return LayoutInflater; }
我们跟踪到 Context 类，发现 Context 是抽象类：

public abstract class Context { }
Context 的总个数 = Activity 个数 + Service 个数 + 1。

一个 Activity 的入口是 ActivityThread 的 main 函数，在 main 函数中创建一个新的 ActivityThread 对象（Framework层），并且启动消息循环（UI线程），创建新的 Activity、新的 Context 对象，然后将该 Context 对象传递给 Activity。并且我们可以通过 分析 ActivityThread 源代码知道，Context 的实现类是 ContextImpl（Framework层）:

class ContextImpl extends Context { // 代码省略 // 服务提取器 ServiceFetcher 通过 getService 获取服务对象 static class ServiceFetcher { int mContextCacheIndex = -1; // 获取系统服务 public Object getService(ContextImpl ctx) { ArrayList Object> cache = ctx.mServiceCache; Object service; synchronized (cache) { if (cache.size() == 0) { for (int i = 0; i sNextPerContextServiceCacheIndex; i++) { cache.add(null); } } else { // 从缓存中获取 Service 对象 service = cache.get(mContextCacheIndex); if (service != null) { return service; } } service = createService(ctx); cache.set(mContextCacheIndex, service); return service; } } // 子类覆写该方法用以创建服务对象 public Object createService(ContextImpl ctx) { throw new RuntimeException(“Not implemented”); } } // 1.Service 容器 private static final HashMap String, ServiceFetcher> SYSTEM_SERVICE_MAP = new HashMap >(); private static int sNextPerContextServiceCacheIndex = 0; // 2.注册服务器 private static void registerService(String serviceName, ServiceFetcher fetcher) { if (!(fetcher instanceof StaticServiceFetcher)) { fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++; } SYSTEM_SERVICE_MAP.put(serviceName, fetcher); } // 3.静态语句块，第一次加载该类时执行，只执行一次，保证实例的唯一性 static { // 代码省略 // 注册LayoutInflater service registerService(LAYOUT_INFLATER_SERVICE, new ServiceFetcher() { public Object createService(ContextImpl ctx) { return PolicyManager.makeNewLayoutInflater(ctx.getOuterContext()); } }); // 代码省略 } public Object getSystemService(String name) { // 根据 name 来获取服务 ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name); return fetcher == null ? null :fetcher.getService(this); } // 代码省略}
分析可以看出，在虚拟机第一次加载该类时会注册各种 ServiceFetcher，其中就包含了 LayoutInflater Service，将这些服务以键值对的形式存储在一个 HashMap 中，使用时只需要根据 key 获取 对应的 ServiceFetcher，然后通过 ServiceFetcher 对象的 getService() 方法获取具体服务对象。首次调用 ServiceFetcher 的 createService() 创建服务对象并将其缓存进一个列表中，下次直接从缓存中获取，避免重复创造对象，从而达到单例效果。系统核心服务以单例形式存在，减少了资源消耗。