iOS开屏页设计演变
一. 开屏页的对与错
目前大多数APP在启动的时候都会使用开屏页，比如网易新闻，微博，头条等。
实际上，并不是所有的应用都需要有闪屏。甚至在 iOS 人机交互手册里，Apple 建议开发者尽最大努力不要展示闪屏。
但是现在为什么开屏页满天飞呢？ 首先在最初的时候，开屏页被发明的初衷是：比如APP启动的时候，会有一些耗时的操作，比如网络加载，SDK初始化，插件初始化等等，为了避免用户出现等待，另一方面为了从公司的角度来说做一些运营活动，广告的曝光等，因此开屏页就泛滥了。
这一点我觉得国外的软件就比较好，很少在APP启动的时候添加开屏页，一方面准守苹果设计规范，同样也减少对用户体验的影响。
但是这篇文章的目的不是为了表达开屏页的不好，因为对开发来说，需求来了，你照做就行，别哔哔。
二. 开屏页设计V1.0
在做V1.0版本的时候，也参照了网上其他家APP的开屏页的设计方式：
1） APP在启动的时候，创建一个window，然后把开屏页的view加载window上。
2）APP在启动的时候，还是正常初始化跟控制器，然后把View加到控制器的VC上。
对于这两种方式，都能满足我们开屏页的需求。我们的实现方式参考了第一种，在这个阶段也遇到了一些问题：
- 对于添加的window的时候，不要依赖
keyWindow，这个是有可能发生变化的，还有可能存在为nil的情况。解决方法，使用[[UIApplication sharedApplication] delegate].window - 断网或者弱网的处理，断网比计较容易解决，对于弱网来说，可能开屏页接口回来的慢，如果我们一开始就把开屏页加在
window上，默认开屏页展示的是启动页的图片，就可能出现长时间等待，甚至不消失。解决方法就是，对接口做一个2s超时处理(具体时间可以根据产品来定)，如果没有返回就认为失败，移除开屏页。 - 关于图片显示的问题，如果开屏页接口回来之后，立刻展示可能会出现刚开始图片没有加载出来，但是倒计时再走，然后还剩1s左右的时候，图片才加载出来。解决方法，在显示的时候，根据本地的
URL判断图片是否已经缓存，如果缓存了，从本地读取。从本地读取可能会出现问题，对于有的活动有确定的显示周期，因此需要做特殊判断。 - 对于APP来说，其实根控制器已经初始化完了，只是因为在window上盖了一个View看不出来。会出现首页的弹框或者toast突然出现在开屏页上，由于window优先级的问题。
三. 开屏页设计V2.0
在介绍V2.0的实现方式之前，我们先看一下Android是如何实现开屏页的？ 对于Android来说，我觉得他们的处理逻辑就很好。首先他们有个SplashActivity，如果存在开屏页，就展示开屏页， 并在开屏页结束之后再展示首页。 如果没有，直接进入首页。 也就是说SplashActivity始终是他们启动的时候，最先初始化的控制器(和iOS的跟控制器很相似)。 从APP的启动逻辑来看，貌似这更符合APP正常启动流程。同时如果按照这种方式的话，也自然避免了V1.0出现的一些问题。逻辑上也变得更加清晰。
实现细节
先看一整流程图，这是简版，没有参入具体业务。
image.png
- 我们现在
lanuchVC里面控制开屏页展示， 登录，进首页，还是进教师页面(角色不同，教师功能是用RN写的) 。
部分代码如下：
image.png
- 为什么还有一个
lanuchManger呢？对于这个类主要做了一下事情
- 创建跟控制器，比如我们的
lanuchVC - 如果有开屏页，我们就在开屏页显示的3s时间内做一些耗时的启动操作，如果没有开屏页就正常初始化相关逻辑。
- 如果APP在杀死的情况下，通过
scheme打开APP的时候，不应该展示开屏页 - 对于切换账号，登录成功之后，需要根据不同角色，显示不同的APP样式，这个逻辑在
lanuchVC内部，因此这个时候也不应该再展示开屏页 - 在开屏页存在的时候，不应该展示
toast或者弹框 - 在
lanuchManger还要处理一些生命周期方法，比如前后台，锁屏等特殊情况处理。
部分代码，如下：
image.png
