iOS的单例模式

一、实现

+ (SVProgressHUD*)sharedView {

    static dispatch_once_t once;

    static SVProgressHUD*sharedView;

    dispatch_once(&once,^ { sharedView =[[SVProgressHUD alloc] initWithFrame:[[UIScreenmainScreen] bounds]];});

    return sharedView;

}

dispatch_once_t 变量只是标识_dispatch_once的执行情况，当once已经被使用时，dispatch_once方法将不执行内容；

因为once和sharedView都是静态的，故sharedView方法每次被执行时始终保持上一次结果，故实现单例效果。

 

           1线程安全

           2很好满足静态分析器要求

           3和自动引用计数（ARC）兼容 

           4仅需要少量代码

该方法有很多优势: 

二、单例模式跟全局变量相比的好处

全局变量是最容易引起初学者兴趣的了，在整个项目中，任何一个函数，每一行代码都可以轻易访问所有的全局变量，并且可以不用付出额外的代价，全局变量看起来就像是为懒惰的程序员设计的一条绿色通道，如果不想看到函数因为要与其他模块通信而动辄很多参数，或者像给程序始末的关键信息寻找一个最合适的存储位置，那么全局变量就是很好的解决方案

但是在项目中，全局变量肯定不少，这个时候，使用起来就会比较混乱，这个时候有一种方法就是创建一个类，其中都是可以使用的全局变量，当需要使用时，直接在类中添加就可以了，这个模式还是很好的，但是仍然有很多麻烦事

首先就是变量名的冲突，这个问题会使项目管理的成本大大增加，项目经理必须小心维护变量名规则，必须分析每一个变量的模块，程序。

还有肯定就是耦合度的问题了，这个全局变量大大增加了函数和模块之间的耦合度，访问某个全局变量的多个函数被该变量牢牢结合在一起，无法拆分开来。

还有初始化的顺序，因为全局变量不可能保证相互之间遵循特定的初始化顺序，这个对于类与对象的实例，构造方法的电泳的顺序有时显得非常重要了。

多线程访问也是问题，当多个并发的线程都需要访问某些全局变量的时候，我们必须使用各种同步机制来保护这些变量，防止陷入并发冲突的泥潭。

       单件模式是创建型模式的一种，从一定程度上说，它可以成为全局变量的替代品，它的设计意图是，保证一个类只有一个对象实例，并提供一个访问的方法，这个时候我们可以将数据封装在一个特殊的类中，然后这个类严格管理它的数据的唯一性，不允许程序员随意创建这个类的对象实例（将构造器不公有化就可以了），便可以用它的静态成员函数得到类的唯一对象实例数据。

使用单间类最容易犯的错误就是按照以前的结构化程序设计的思路考虑问题，将全局变量作为模块之间共享数据的一个桥梁，把它们收集起来，放进一个单间类，这肯定是不对的，而应该是从系统中寻找那些类的特性，生存周期较长的类，改成单间类的形式，生存周期短的就封装在一个需要使用的类中，便可以解决这个问题（比如，有一个drawLine的属性，它只要用于类Line中，只要Line类的生存周期结束了，便不再需要，如果将drawLine的属性耦合关系封装在Line内部，就可以解决问题了）