前言
最近做了一波性能优化，发现项目中有一部分控制器的 view 在没有展示给用户之前就已经加载到内存中了，这其实是一种浪费，而且不符合懒加载的原则。
那什么情况会导致控制器的 view 过早加载？应该如何避免这种情况呢？今天就来聊聊这个话题。
UIViewController 生命周期
UIViewController 是 iOS 开发的基本组件。为了了解上边提到的提前加载控制器，我们需要了解视图控制器的生命周期。
正常的生命周期调用顺序是：
-
init() --- 初始化视图控制器
-
loadView() --- View 被创建并加载到内存中
-
viewDidLoad() --- 加载 View 后调用
-
viewWillAppear(_:) --- 在控制器出现之前调用
-
viewDidAppear(_:) --- 在控制器出现之后调用
-
viewWillDisappear(_:) --- 在控制器消失之前调用
-
viewDidDisappear(_:) --- 在控制器消失之后调用
-
deinit() --- 在控制器销毁之后调用
发现过早加载的问题
这里需要重点说一下 loadView 方法和 viewDidLoad 方法。
当控制器调用 init() 创建之后，其 View 默认的值是 nil，当你第一次调用 view 的时候(即self.view) view 才会创建，这是控制器创建 view 的原理。
view 的创建是通过调用 loadView 方法进行的，loadView 调用完成之后紧接着就会调用 viewDidLoad 方法，而我们大部分的初始逻辑是写在 viewDidLoad 里的。
此时，如果并不需要展示 view，就会导致一些额外的内存占用。
如何避免这种问题
经过我个人项目的经验和问题排查，大概有以下几种情况会导致这种问题，需要在开发中尽量避免。
1、控制器尽量在需要的时候才加载
比如常见的多 tab 切换页面，每个 tab 都是一个控制器，这时候有一种做法是把所有 tab 的控制器都创建出来，等到某个 tab 的时候直接把创建好的拿来用。
从内存最小化的原则上来看，这种方式并不合理，控制器尽量是懒加载的，即在切到某个 tab 的时候再创建。
2、避免在 init 方法中直接调用 view 属性
从控制器 init() 方法内访问 self.view 绝对是一个错误，因为它会过早调用 loadView() 和 viewDidLoad()。一方面，不是所有调用 init 之后就会展示，另一方面这种情况往往会加重主线程的负担，因为 viewDidLoad() 中会有比较多的逻辑。
3、创建控制器之后不要立即调用 view 属性
有些时候的确可能提前创建控制器，比如使用 UITabBarController 控件，就需要提前把 TabBar 上的控制器都创建出来，但是创建完成之后，不要在切过去之前调用控制器的 view 属性，否则还是会提前创建 view，导致性能下降。
利用全局断点发现问题
特别是大项目，这种问题很难被发现，一个一个排查又不太现实，利用全局断点可以帮助我们快速发现这个问题。
首先选中 Xcode 左侧菜单栏的断点 Tab（快捷键 command + 8 ），然后点击左下角加号按钮，并选择 Symbolic Breakpoint...:
为了能够捕获 viewDidLoad 方法的调用，需要在断点弹出框的 Symbol 中填写 -[UIViewController viewDidLoad]，之后点击 Add Action 按钮添加一个日志打印，这里我们填写 po $arg1，最后勾选一下底部的勾选框 Automatically continue after evaluating actions，意思是当触发这个断点的时候不要停止代码运行。
最后，我们当我们再次运行代码，每个控制器在执行 viewDidLoad 方法时就会在控制器把这个控制器名称打出来，方便我们查看哪些 viewDidLoad 被提前调用了。
在之前的文章中还讲过一篇关于控制器销毁的文章，感兴趣可以去看看：
点击下方公众号卡片，关注我，每天分享一个关于 iOS 的新知识
本文同步自微信公众号 "iOS新知"，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！