前言
在iOS开发中，懒加载的角色在很多时候至关重要，它可以让我们的代码变得更加优秀。之所以写这篇文章，主要是谈谈个人对懒加载的粗浅理解，如果不对的地方，欢迎各位仁人志士不吝赐教，这里只是抛砖引玉。另外，相信网上也有很多讲述懒加载的各种文章，有的分析也甚是不错。但是技术这种东西，还是需要思想的碰撞，才能折射出更加耀眼的精华。
懒加载的本质
懒加载，亦叫延迟加载，即在第一次需要的时候才去加载，本质上就是对一个实例的getter方法的重写。
懒加载的使用
懒加载的使用也相对简单，我们以例子来说话，为了能够尽量详细点，下面会粘贴全部的代码：
#import "ViewController.h"
@interface ViewController ()
@property (nonatomic, strong) UILabel *label;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self label];
}
- (UILabel *)label {
if (!_label) {
_label = [[UILabel alloc] init];
_label.frame = CGRectMake(64, 64, 300, 50);
_label.backgroundColor = [UIColor cyanColor];
_label.text = @"懒加载就是当需要的时候才去加载";
[self.view addSubview:_label];
}
return _label;
}
@end
上面就是一个懒加载的写法，其它类型大同小异，可举一反三，这里主要以上面例子为准。
首先，我们来分析下，为什么在viewDidLoad方法中调用懒加载是以[self label]的方式来调用，而不是以self.label的方式呢？为了验证是否可以，我们将[self label]改成self.label，Xcode会提示如下
Property access result unused - getters should not be used for side effects
显然，Xcode报了一个warning, 但是我们直接直接运行，忽略这个warning，任何错误都不会产生，视图正常显示在界面上。
原因是，当我们调用懒加载方法时，系统默认其为一个getter方法，而在- (UILabel *)label这个懒加载中，必然要返回一个实例label，所以报警告说获取到的属性结果并未使用，如果我们在调用时并且用一个变量去接收它，那警告自然而然就会消除，如下：
UILabel *receivedLabel = self.label;
NSLog(@"%@",receivedLabel);
但是，根本原因是什么呢？事实上，根本原因是apple期望调用属性使用点语法形式，而调用方法使用方括号[]的形式，而在懒加载中，尽管我们说其本质是重写getter方法，获取的实例类似一个属性，但是实际上它还是一个方法，所以Xcode希望我们以方法的形式去调用懒加载！
当然，有人会说了，如果在懒加载中我没有将其添加到self.view上呢，这样我不就可以使用[self.view addSubview:self.label];点语法来添加了吗？没错，你当然也可以这样写，没有任何问题！只是我们没有必要这样做而已，如果你使用方法的形式去调用，绝对不会出现任何问题。
懒加载的注意点
使用懒加载时，必须注意getter方法嵌套，从而造成死循环，导致程序crash！， 比如，我们写成这样：
- (UILabel *)label {
// 注意这里会造成程序奔溃，getter方法自身嵌套循环，永无休止
if (!self.label) {
_label = [[UILabel alloc] init];
_label.frame = CGRectMake(64, 64, 300, 50);
_label.backgroundColor = [UIColor cyanColor];
_label.text = @"懒加载就是当需要的时候才去加载";
}
return _label;
}
又或者写成
- (UILabel *)label {
if (!_label) {
_label = [[UILabel alloc] init];
_label.frame = CGRectMake(64, 64, 300, 50);
_label.backgroundColor = [UIColor cyanColor];
_label.text = @"懒加载就是当需要的时候才去加载";
}
// 注意这里会造成程序奔溃，getter方法自身嵌套循环，永无休止
return self.label;
}
所以，强烈建议使用懒加载时，懒加载内部的实例变量完全采用下划线的方式去判断及创建！！！
当然，还有另外一种只要你记住, 就随便你怎么写，并且万无一失、永远也不会造成死循环的方法，那就是懒加载的方法名不要和懒加载内部的实例变量同名，这样Xcode就可以准确识别出你调用的是属性还是懒加载方法，比如：
#import "ViewController.h"
@interface ViewController ()
@property (nonatomic, strong) UILabel *label;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self lazyMethod];
}
- (UILabel *)lazyMethod {
if (!self.label) {
_label = [[UILabel alloc] init];
_label.frame = CGRectMake(64, 64, 300, 50);
_label.backgroundColor = [UIColor cyanColor];
_label.text = @"懒加载就是当需要的时候才去加载";
[self.view addSubview:_label];
}
return self.label;
}
@end
我个人认为这才是懒加载的较好的书写方式，一目了然，并且安全可靠。
为什么要使用懒加载？
网上有很多文章论述使用懒加载的观点，我们来看一些常见的那些优点
- 第一，懒加载不必写在viewDidLoad方法里面，每个属性的getter方法中分别负责各自的实例化处理，因此可读性更强、独立性更强
我个人觉得，这只是相对的，所以可读性强也要看你怎么写、写多少，如果我们需要创建 100个视图，如果这100个视图全部使用懒加载的话，优势在哪？所以的可读性更强吗？独立性更强吗？使用懒加载我们都知道，每创建一个懒加载，代码量会多出3-4行，如果我们创建100个视图，那么就多出了300-400行？因此可读性就变得不是那么强的，相反，如果我们直接使用组件化来分开创建视图，然后在viewDidLoad中调用，那样反而清晰明了、可读性才是真的强。当然，如果只是几个视图的情况下，那懒加载的确看起来更加清晰、可读性更强，那么，问题是如果只是简单的几个视图，又何必使用懒加载，优势在哪？
此问题小结：懒加载的可读性强、独立性强并不是绝对的，甚至微乎其微，我个人并觉得这有多大的优势或者说优点。
- 第二，懒加载可以防止实例为nil
这个优势可能是有，但也只是相对的，一般正常情况下，作为一名合格的程序员（也许我并不合格，因为我的代码也曾因未安全检查而奔溃过），都会对所使用的变量做安全检查，就像防止数组越界一样，从而导致程序奔溃！
当然，在懒加载中，因为已经独立地做了安全检查，所以后续使用时不需要再次去繁琐和重复地校验是否为nil，的确也算是一个较好的选择，但是，这点也谈不上多大的优势，只是相对来说做了一个类似全局校验的做法而已。
这算是懒加载的一个相对的优势，但并不是绝对。
- 第三，懒加载节省内存资源
这个在一定程度上是有道理的，当且仅当我们在需要加载的时候才调用懒加载，比如说，在网络请求的时候，我们无法知道请求是否失败，是因为网络失败，还是因为请求的数据为空？没有网络，我们就显示一个网络错误页，而这个网络错误页面我们就可以使用懒加载，因为在一般情况下，网络好的时候，是不存在需要加载这个网络错误页面的，但是也为了以防万一，比如说我们在使用某个app的时候，突然进入电梯或地下室，都有可能导致网络失败的情况；如果网络好的情况下，或许我们请求下来的数据为空，那此时就可以加载一个为空页面，这个页面就可以使用懒加载。
当然，本文中的开头例子是不需要使用懒加载的，因为完全没有必要，懒加载要根据时机、资源需要的时候才去使用懒加载，这样才能节省内存。再比方说，我们需要加载网络请求下来的数据model，但是是分页加载，那这时我们也可以使用懒加载，因为用户上拉加载也许只是看几页就不加载了，或者一些缓存数据的使用等等。
懒加载使用得当的确可以节省内存资源，有一定程度上的性能优化，这也是比较使我信服的优点，此外，我个人觉得也能节省某一阶段的时间，那就是在调用懒加载前，如果后面一直未使用到懒加载，那么就可以节省加载
懒加载的这段时间。
什么时候使用懒加载？
一般情况下，不需要使用懒加载，懒加载未必能增强可读性、独立性，滥用反而让可读性适得其反。简言之，就是在逻辑上，觉得现在不需要加载，而在后面某一时间段内可能会加载，就可以考虑懒加载。
总结
懒加载的优点
相对来说，如果代码量不是很多，可读性略强
相对来说，防止为nil，减少了后续使用时安全检查的后顾之忧
使用适当，可节省内存资源
一定程度上，节省了某一个期间内的时间
使用得当，优化性能，提高用户体验
注意：上述所谓的优点都只是相对来说，并没有绝对，关键还是要看你怎么使用！所以懒加载好与不好，还是在于使用的人是谁。
懒加载的缺点
使用太泛滥，导致可读性变差
使用不得当，可能会造成死循环，导致crash
代码量增多（每增加一个懒加载，代码会平均多出3-4行）
注意： 上述所谓的缺点也只是相对来说，因人而异，毕竟，对于开来说，除懒加载这个技术点之外，任何技术上的或逻辑上的错误，最终的产出都是bug。
