单例怎么写？

参考来源：

https://www.jianshu.com/p/a92c0283f243

http://www.cocoachina.com/ios/20171123/21300.html

1.什么是单例模式

简单的来说，一个单例类，在整个程序中只有一个实例，并且提供一个类方法供全局调用，在编译时初始化这个类，然后一直保存在内存中，到程序（APP）退出时由系统自动释放这部分内存。

2.系统为我们提供的单例类有哪些？

UIApplication(应用程序实例类)
NSNotificationCenter(消息中心类)
NSFileManager(文件管理类)
NSUserDefaults(应用程序设置)
NSURLCache(请求缓存类)
NSHTTPCookieStorage(应用程序cookies池)

3.在哪些地方会用到单例模式

一般在我的程序中，经常调用的类，如工具类、公共跳转类等，我都会采用单例模式；

重复初始化单例类会怎样？

请看下面的例子，我在我的工程中，初始化一次UIApplication,

  [[UIApplication alloc]init];

最后运行的结果是，程序直接崩溃，并报了下面的错，

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'There can only be one UIApplication instance.'
 

所以，由此可以确定，一个单例类只能初始化一次。

4.单例类的生命周期

单例实例在存储器的中位置

请看下面的表格展示了程序中中不同的变量在手机存储器中的存储位置；

位置存放的变量
栈 临时变量（由编译器管理自动创建/分配/释放的，栈中的内存被调用时处于存储空间中，调用完毕后由系统系统自动释放内存）
堆 通过alloc、calloc、malloc或new申请内存，由开发者手动在调用之后通过free或delete释放内存。动态内存的生存期可以由我们决定，如果我们不释放内存，程序将在最后才释放掉动态内存，在ARC模式下，由系统自动管理。
全局区域 静态变量（编译时分配，APP结束时由系统释放）
常量 常量（编译时分配，APP结束时由系统释放）
代码区 存放代码

在程序中，一个单例类在程序中只能初始化一次，为了保证在使用中始终都是存在的，所以单例是在存储器的全局区域，在编译时分配内存，只要程序还在运行就会一直占用内存，在APP结束后由系统释放这部分内存内存。

 

5.Objective-C的坑

看起来很完美了。可是Objective-C毕竟是Objective-C。别的语言，诸如C++，java，构造方法可以隐藏。Objective-C中的方法，实际上都是公开的，虽然我们提供了一个方便的工厂方法的访问入口，但是里面的alloc方法依旧是可见的，可以调用到的。也就是说，虽然你给了我一个工厂方法，调皮的小伙伴可能依旧会使用alloc的方式创建对象。这样会导致外面使用的时候，依旧可能创建多个实例。

关于这个事情的处理，可以分为两派。一个是冷酷派，技术上实现无论你怎么调用，我都给你同一个单例对象；一个是温柔派，是从编译器上给调皮的小伙伴提示，你不能这么造对象，温柔的指出有问题，但不强制约束。

1. 冷酷派的实现

冷酷派的实现从OC的对象创建角度出发，就是把创建对象的各种入口给封死了。alloc，copy等等，无论是采用哪种方式创建，我都保证给出的对象是同一个。

由Objective-C的一些特性可以知道，在对象创建的时候，无论是alloc还是new，都会调用到 allocWithZone方法。在通过拷贝的时候创建对象时，会调用到-(id)copyWithZone:(NSZone *)zone，-(id)mutableCopyWithZone:(NSZone *)zone方法。因此，可以重写这些方法，让创建的对象唯一。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
+(id)allocWithZone:(NSZone *)zone{
    return [DJSingleton sharedInstance];
}
+(DJSingleton *) sharedInstance{
    static DJSingleton * s_instance_dj_singleton = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        s_instance_dj_singleton = [[super allocWithZone:nil] init];
    });
    return s_instance_dj_singleton;
}
-(id)copyWithZone:(NSZone *)zone{
    return [DJSingleton sharedInstance];
}
-(id)mutableCopyWithZone:(NSZone *)zone{
    return [DJSingleton sharedInstance];
}

2. 温柔派的实现

温柔派就直接告诉外面，alloc，new，copy，mutableCopy方法不可以直接调用。否则编译不过。

1
2
3
4
+(instancetype) alloc __attribute__((unavailable("call sharedInstance instead")));
+(instancetype) new __attribute__((unavailable("call sharedInstance instead")));
-(instancetype) copy __attribute__((unavailable("call sharedInstance instead")));
-(instancetype) mutableCopy __attribute__((unavailable("call sharedInstance instead")));

我个人的话比较喜欢采用温柔派的实现。不需要这么多复杂的实现。也让使用方有比较明确的概念这个是个单例，不要调皮。对于一般的业务场景是足够了的。

6.可不可以再方便点？

可以。

大神们把单例模式的各种套路封装成了宏。这样使用的时候，就不需要每个类都手动写一遍里面的重复代码了。省去了敲代码的时间。

以温柔派的为例，大概是这样子的。

1
2
3
4
5
6
7
8
9
10
11
12
13
#define DJ_SINGLETON_DEF(_type_) + (_type_ *)sharedInstance;\
+(instancetype) alloc __attribute__((unavailable("call sharedInstance instead")));\
+(instancetype) new __attribute__((unavailable("call sharedInstance instead")));\
-(instancetype) copy __attribute__((unavailable("call sharedInstance instead")));\
-(instancetype) mutableCopy __attribute__((unavailable("call sharedInstance instead")));\
#define DJ_SINGLETON_IMP(_type_) + (_type_ *)sharedInstance{\
static _type_ *theSharedInstance = nil;\
static dispatch_once_t onceToken;\
dispatch_once(&onceToken, ^{\
theSharedInstance = [[super alloc] init];\
});\
return theSharedInstance;\
}

那么，在定义和实现的时候就很简单了：

1
2
3
4
5
6
@interface DJSingleton : NSObject
    DJ_SINGLETON_DEF(DJSingleton);
@end
@implementation DJSingleton
    DJ_SINGLETON_IMP(DJSingleton);
@end

 

7.单例模式潜在的问题

1. 内存问题

单例模式实际上延长了对象的生命周期。那么就存在内存问题。因为这个对象在程序的整个生命都存在。所以当这个单例比较大的时候，总是hold住那么多内存，就需要考虑这件事了。另外，可能单例本身并不大，但是它如果强引用了另外的比较大的对象，也算是一个问题。别的对象因为单例对象不释放而不释放。

当然这个问题也有一定的办法。比如对于一些可以重新加载的对象，在需要的时候加载，用完之后，单例对象就不再强引用，从而把原先hold住的对象释放掉。下次需要再加载回来。

2. 循环依赖问题

在开发过程中，单例对象可能有一些属性，一般会放在init的时候创建和初始化。这样，比如如果单例A的m属性依赖于单例B，单例B的属性n依赖于单例A，初始化的时候就会出现死循环依赖。死在dispatch_once里。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
@interface DJSingletonA : NSObject
    DJ_SINGLETON_DEF(DJSingletonA);
@end
@interface DJSingletonB : NSObject
    DJ_SINGLETON_DEF(DJSingletonB);
@end
@interface DJSingletonA()
@property(nonatomic, strong) id someObj;
@end
@implementation DJSingletonA
DJ_SINGLETON_IMP(DJSingletonA);
-(id)init{
    if (self = [super init]) {
        _someObj = [DJSingletonB sharedInstance];
    }
    return self;
}
@end
@interface DJSingletonB()
@property(nonatomic, strong) id someObj;
@end
@implementation DJSingletonB
DJ_SINGLETON_IMP(DJSingletonB);
-(id)init{
    if (self = [super init]) {
        _someObj = [DJSingletonA sharedInstance];
    }
    return self;
}
@end
//---------------------------------------
DJSingletonA * s1 = [DJSingletonA sharedInstance];

2.png

死亡现场

对于这种情况，最好的设计是在单例设计的时候，初始化的内容不要依赖于其他对象。如果实在要依赖，就不要让它形成环。实在会形成环或者无法控制，就采用异步初始化的方式。先过去，内容以后再填。内部需要做个标识，标识这个单例在造出来之后，不能立刻使用或者完整使用。

 

 

 

T

posted @ 2019-03-22 11:55  yuhui.Mr  阅读(520)  评论(0)    收藏  举报