android 单例工具类,Android常见设计模式三：单例模式

对于开发人员来说，设计模式有时候就是一道坎，但是设计模式又非常有用，过了这道坎，它可以让你水平提高一个档次。而在android开发中，必要的了解一些设计模式又是必须的，因为设计模式在Android源码中，可以说是无处不在。对于想系统的学习设计模式的同学，这里推荐一本书，《大话设计模式》。

Android常用设计模式系列：

单例模式

单列模式是非常常见的设计模式之一，写个笔记，记录一下我的学习过程和心得。

首先了解一些单例模式的定义。

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

这样做有以下几个优点

对于那些比较耗内存的类，只实例化一次可以大大提高性能，尤其是在移动开发中。

保持程序运行的时候该中始终只有一个实例存在内存中

由单例的定义，可以分析出，实现一个单例，有以下几个要点

构造函数必须私有化，防止外部调用构造函数进行实例。

提供静态函数获得该单例。

单例主要有两种种实现方式，懒汉模式和饿汉模式。

懒汉模式：

在类加载时，不创建实例，因此类加载速度快，但运行时获取对象的速度慢，代码如下

public class Singleton {

private static volatile Singleton instance = null;

private Singleton(){

}

public static Singleton getInstance() {

if (instance == null) {

synchronized (Singleton.class) {

if (instance == null) {

instance = new Singleton();

}

}

}

return instance;

}

}

懒汉模式实现要点

单例使用volatile修饰。

单例实例化时，要用synchronized 进行同步处理。

双重null判断

饿汉模式：

在类加载时就完成了初始化，所以类加载较慢，但获取对象的速度快，代码如下

public class Singleton {

private static Singleton instance = new Singleton();

private Singleton(){

}

public static Singleton getInstance() {

return instance;

}

}

两种实现模式各有优缺点，综合来说，个人比较偏向于懒汉模式。

并发测试

至于单例的并发测试，可以使用CountDownLatch，使用await()等待锁释放，使用countDown()释放锁从而达到并发的效果。可以见下面的代码

public static void main(String[] args) {

final CountDownLatch latch = new CountDownLatch(1);

int threadCount = 1000;

for (int i = 0; i < threadCount; i++) {

new Thread() {

@Override

public void run() {

try {

latch.await();

} catch (InterruptedException e) {

e.printStackTrace();

}

System.out.println(Singleton.getInstance().hashCode());

}

}.start();

}

latch.countDown();

}

看看打印出来的hashCode会不会出现不一样即可，理论上是全部都一样的。

应用广泛

在Android开发中，很多地方用到了单例。

比如大名鼎鼎的 Android-Universal-Image-Loader中的单例

private volatile static ImageLoader instance;

/** Returns singleton class instance */

public static ImageLoader getInstance() {

if (instance == null) {

synchronized (ImageLoader.class) {

if (instance == null) {

instance = new ImageLoader();

}

}

}

return instance;

}

而Android 源码中单例也是非常的多，如InputMethodManager 中的单例

static InputMethodManager sInstance;

public static InputMethodManager getInstance() {

synchronized (InputMethodManager.class) {

if (sInstance == null) {

IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);

IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);

sInstance = new InputMethodManager(service, Looper.getMainLooper());

}

return sInstance;

}

}

AccessibilityManager 中的单例

private static AccessibilityManager sInstance;

public static AccessibilityManager getInstance(Context context) {

synchronized (sInstanceSync) {

if (sInstance == null) {

final int userId;

if (Binder.getCallingUid() == Process.SYSTEM_UID

|| context.checkCallingOrSelfPermission(

Manifest.permission.INTERACT_ACROSS_USERS)

== PackageManager.PERMISSION_GRANTED

|| context.checkCallingOrSelfPermission(

Manifest.permission.INTERACT_ACROSS_USERS_FULL)

== PackageManager.PERMISSION_GRANTED) {

userId = UserHandle.USER_CURRENT;

} else {

userId = UserHandle.myUserId();

}

IBinder iBinder = ServiceManager.getService(Context.ACCESSIBILITY_SERVICE);

IAccessibilityManager service = IAccessibilityManager.Stub.asInterface(iBinder);

sInstance = new AccessibilityManager(context, service, userId);

}

}

return sInstance;

}

总结

总结一下单例模式的优缺点

优点

1.在单例模式中，活动的单例只有一个实例，对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化，确保所有的对象都访问一个实例

2.单例模式具有一定的伸缩性，类自己来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。

3.提供了对唯一实例的受控访问。

4.由于在系统内存中只存在一个对象，因此可以 节约系统资源，当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。

5.避免对共享资源的多重占用。

缺点

1.不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。

2.由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。

3.单例类的职责过重，在一定程度上违背了“单一职责原则”。

4.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。

适用场景：

单例模式只允许创建一个对象，因此节省内存，加快对象访问速度，因此对象需要被公用的场合适合使用，如多个模块使用同一个数据源连接对象等等。如：

需要频繁实例化然后销毁的对象。

创建对象时耗时过多或者耗资源过多，但又经常用到的对象。

有状态的工具类对象。

频繁访问数据库或文件的对象。