对于 iPhone 来说，我们都常有一个使用习惯，即将屏幕自动旋转锁定，毕竟 iOS 的这个陀螺仪的方向检测有时候会出现蜜汁现象。不过这样做的话，就错过了验证各大厂 App LaunchScreen 对屏幕方向的支持情况。举个 🌰：众所周知，天猫和淘宝在 iPhone 上的实际使用中只支持横屏。但如果你把屏幕自动旋转锁定关闭，然后将你的 iPhone 横屏，会发现淘宝的 LaunchScreen 也“躺”下了，而天猫没有…… emmmmmmmm
这篇文章会梳理官方提供的几种屏幕旋转控制的方式以及它们的优先级，当然上面提到的这个问题自然就迎刃而解了。
意如分类标题(这个博客主题貌似没有，😂)那样，笔者打算开始探究框架与源码。毫无疑问，这其中会遇到各种各样的挑战，但是我觉得我们应尽早走出这一步，不然就错过了很多的精彩。也许这精彩是更加开阔的程序视野，亦或是逻辑思维与编程能力的提升，这其中对耐心与意志的磨炼绝对会让人十分“酸爽”。
而这简而繁BlocksKit就成为了第一道菜，为什么呢？因为之前对它的认知就是对系统API的block方式调用的高度封装，这是它简单的使用特性。然而它的灵魂——动态代理让我深切感受到了框架的设计哲学：把简洁留给别人，把复杂留给自己。不信？那就接着往下看！
相信大家都清楚，iOS 设备上我们可以设置系统字体显示效果，比如字体变大或者加粗之类的。但如果使用的是自定义字体的话，则不在以上开关打开之后的调整范围之内。如果你的 App 想要适配这种情况的话，可能有一些周折，因为这里的 Bold Text 有一个坑点。这也致使我们的“上帝”向我们提出了批评：你们的前端该换人了，虽然这实际上是移动端的事，或者说是 iOS 的问题，😂
不得不承认，这回标题党了一把！那博主为什么要这么厚颜无耻，究竟是道德的沦丧，还是人性的扭曲…… 高僧：施主，苦海无边，回头是岸，南无阿弥陀佛。
非也，非也，之所以如此这般，只能说博主实在太想表达粗心大意害死人(太想吸引眼球、太想博客有人看、太想出名、太想上电…… 啪啪)这句话了。历史上这样的大事件想必各位历历在目，比如…… loading…… loading…… 服务器忙～
好吧，想不起来了，那就进入这篇文章的主题，看看博主这次维护老代码遇到的坑长成啥样！(前言总算凑够字数，😄)
早在 iPhone X 发布的时候，即 iOS 11 的时候，就加入了一个新的关于布局的概念：Safe Area，它可以帮助我们让 UI 不被 UINavigationBar、UITabBar 和 UIStatusBar 遮挡。而苹果为了让开发者更好适配刘海屏搞出来的这一套东西，对于老项目的 UI 适配可能不是一个好消息，如果你是基于 UINavigationBar 或 UITabBar 来布局的，系统可以很好地帮助你完成。但是对于一些静态界面，可能你得慢慢理理，然后让涉及到的代码适配 Safe Area。也因此你会看到几乎所有 App 在 iPhone X 出来之后，都会有一次更新，其中的更新信息中就有适配 iPhone X。但是在 iPhone XS/XR 上使用的 App，你可能还是会发现有些 UI 布局还是有点问题，而在 iPhone X 上却又是正常的(就像扇贝的 App，自黑一波～)，原因在于当初适配 iPhone X 时只是简单的用了一个判断 isIPhoneX 来决定 UI 的样子。
笼统来说，我们在编写代码时候，通常会有两种方式来组织。一个是继承语言本身的数据类型然后派生出新的，这种方式的使用通常是你需要对此类型大改造以满足你的需求。典型的例子就是UIViewController，我们在构造视图控制器时，这个基类只是给我们提供了一个模版，其中包括了一些管理生命周期方法的默认实现。而关于UI方面，则只提供了一个父视图，我们的交互细节则需要在此基础上自行构建。而另外一种就是以扩展的方式，为基本的数据类型增加新的函数或者方法来达成我们的使用目的。后者的一个好处就是使用者不需要特意去用派生类型，只需要基本类型本身调用对应的扩展方法即可。但是它的坏处就是可能会再语言本身的版本迭代过程中与其所新增的函数或者方法名冲突，导致在运行出现二义性，引起程序崩溃。因此我们需要为这些Extensions做出一些命名和使用上的规范，以规避此风险。(文章主要以iOS开发用到的Objective-C和Swift两门语言举出🌰)
转眼间又来到了九月末，只是这个九月与自读书以来的不太一样，因为开学是TA们的，我只有代码，😂。
不过，我想这不是什么感伤的情绪，而是对学生时期的青春岁月的缅怀，尽管早已逝去，但又怎么不叫人留念呢？👌，祭出代码表示表示吧，:)
嘿，web page，你为何如此的淘气？让我不知道你什么时候才加载完毕！
嘿，UIWebview，你为何如此的坑人？你的delegate表示对你webViewDidFinishLoad方法的调用时机感到怀疑！
嘿，WKWebview，你为何如此的害羞？对你的第一次“拍照”结果总是白屏！
哟哟，切克闹，Apple你还能让我愉快地工作了吗？Apple: 小蚱蜢，你还没悟到吗？想对网页完整截图你首先得知道网页的内嵌资源什么时候加载完毕，或者用我提供的方法，当然这得要你配合，让你的应用只支持iOS 11，🤷♂️……
UIView是iOS可视化图形界面开发所使用的基类，并负责响应用户的交互行为；
UIWindow是包含图形界面的窗口，它是一切可视化界面的容器(使用Reveal可以得到验证)，并且它还将持续跟踪App当前的firstResponder(第一响应者)，并负责处理由Application对象传递过来的消息(依据其 sendEvent实例方法的文档注释可以得出，亦即response chain(响应链)的开端)；
UIScreen是硬件设备屏幕的抽象，因此它会包含所有的UIWindow实例，通常会用mainScreen的 bounds属性来初始化一个适合屏幕大小的key window(主窗口)，因为官方文档明确说明UIWindow是无法响应在其bounds之外的触摸事件的，对用户而言就是其触屏事件将得不到响应。
以上是关于它们三兄弟我们认知的比较清楚的一些知识点，但前两者在使用上的区别我们有必要做进一步深究。而对于UIScreen的其他使用，比如mirrored，我想它也是蛮有意思的。这一切的思考源自我对项目中关于截屏触发的反馈界面是应该使用UIWindow还是UIView，系统状态栏和键盘为什么是*Window而不是*View。
2001.6 自童年步入学校(幼儿园，🤣)
2018.6.28 由成年拥抱社会(被学校赶出来，然后卷铺盖走人了……)
在学校17年的求学之路至此已经落下了帷幕，没有半点拖泥带水，甚至来不及感慨，或者说我们根本不能感慨，因为：披坚执锐陷阵营，男儿至死是少年！