[iOS] 跟着大神们学习代码(12)
目录：
- 事件分发
- 内存泄漏检测
- Find Unused Imports
- cell的view懒加载
- Autolayout
1. 事件分发
这个其实是之前鹏鹏写的，借用了runtime的事件转发，讲真我觉得写的用起来非常方便，传参之类的都很方便。
然鹅，runtime呢其实很耗时，如果频繁的调用还是不太好，所以建议还是做成类似系统notification那种啦。
阿里有个库其实是类似DI 以及 事件分发的https://github.com/alibaba/BeeHive，里面的实现也是类似noti在事件这一块儿，感觉其实使用起来没有利用runtime直接调用伪装对象好~
- 有一个我觉得还挺好的地方，在设计observer的时候，可以给它包一层，用一个属性来保存它监听了哪些protocol，这样的话，移除的时候就不用漫天找它了~~
2. 内存泄漏检测
可参考：https://cloud.tencent.com/developer/article/1337757
腾讯的那个MLeaksFinder真的还挺好用的，引入以后会自动在VC pop的时候检测并弹出alert，但是它自带的其实主要是UI的内存检测，比如单例之类的也可能持有应该被回收的东东，这种时候就需要手动开启检测啦。
原理：MLeaksFinder一开始是从UIViewController入手的，UIViewController在POP或dismiss之后该控制器及其上的view，view的subviews都会被释放掉，MleaksFinder就是在控制器POP或dismiss之后去查看该控制器和其上的view是否都被释放掉。
具体的方法是，为基类 NSObject 添加一个方法 willDealloc 方法，该方法的作用是，先用一个弱指针指向 self，并在一小段时间(3秒)后，通过这个弱指针调用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中断言。这样，当我们认为某个对象应该要被释放了，在释放前调用这个方法，如果3秒后它被释放成功，weakSelf 就指向 nil，不会调用到 -assertNotDealloc 方法，也就不会中断言，如果它没被释放（泄露了），-assertNotDealloc 就会被调用中断言。这样，当一个 UIViewController 被 pop 或 dismiss 时（我们认为它应该要被释放了），我们遍历该 UIViewController 上的所有 view，依次调 -willDealloc，若3秒后没被释放，就会中断言。
简而言之就是当一个对象3秒之后还没释放，那么指向它的 weak 指针还是存在的，所以可以调用其 runtime 绑定的方法 willDealloc 从而提示内存泄漏。
所以如果你想特意看某个对象是不是释放，可以在它应该被释放的时候调用它的willDealloc~
3. Find Unused Imports
可参考：https://www.cnblogs.com/huangzs/p/10986142.html
这个库的description也真的够简洁，Find unused Objective-C imports. 就是找到没有被使用的类以及import。
方法也比较容易，就是：
sudo gem install fui -n /usr/local/bin
然后cd到项目路径
执行fui find
其实我记得之前还有那种找不用图片的，但是其实有个问题是如果手动拼接图片的路径就可能会遗漏。
4. cell的view懒加载
我们有的时候经常使用懒加载，毕竟用的时候再初始化比较方便。但是对于cell这种比较特殊，就是会涉及UI卡顿的，如果没有最开始把cell里的view都初始化好，可能滑动的时候不知道到第几个cell就需要初始化view了，会造成卡顿。
所以对于cell最好不要懒加载哦。
5. Autolayout
我们新的lead大哥哥说只要掌握masonry和snapkit（swift的）就好啦，并推荐了一篇文章就拿来学习了：https://www.raywenderlich.com/811496-auto-layout-tutorial-in-ios-getting-started
At first, Apple made one screen size for the iPhone. Developers didn’t have to create flexible interfaces as they only had to fit that one size. Today, differently sized devices and more emphasis on landscape mode demand user interfaces of different sizes. Auto Layout is Apple’s solution to this problem, enabling UI elements to grow, shrink and move depending on screen size.
虽然xib的解析是耗费时间的，所以我们推荐用代码布局，但是这里因为是参考原文，所以都是xib啦~
从iOS7以后就就有了safe area的参照了，所以你看当我们加约束的时候，顶部不会覆盖状态栏。
safe area
如果你规定了一个view到四周的边距，以及它的宽高，然后当你切换横屏的时候可能就会crash，提示下面酱紫：
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this: (1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(...)
Will attempt to recover by breaking constraint....
这就是constraints太多的样例，因为不是每个屏幕宽高都一样的，所以不能这么干，你只要去除两个方向的constraint就可以啦，例如trailing和bottom，只保留leading top width height。
不crash的constraint
Content Priority Ambiguity
布局
Content Priority Ambiguity
当上面那样布局可能会遇到Content Priority Ambiguity的error，怎么理解这个error呢？比如现在我们固定container的高是200，图片和label的高都自适应；然后如果container的高变为300了呢，要怎么分配这多出来的100？都给图片，还是都给label，还是他俩五五分、四六分？
如果你不指定，那么Auto Layout会去猜，那么结果就不一定了。
解决方案就是Content Hugging Priority，
You can imagine hugging here to mean size-to-fit. In other words, the bounds of the view will hug the intrinsic content size. A higher value here means the view will be less likely to grow and more likely to stay the same.
也就是这个值越大，它约包裹内容即可，高度不容易变大。
如果设置label的Content Hugging Priority高于image，那么当container高度变大的时候，label会保持高度，image会变高。
这篇有点儿水，原谅我这周。。疲于奔命。。
