一. 開屏頁的對與錯
目前大多數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出現的一些問題。邏輯上也變得更加清晰。
實現細節
先看一整流程圖，這是簡版，沒有參入具體業務。
- 我們現在
lanuchVC里面控制開屏頁展示， 登錄，進首頁，還是進教師頁面(角色不同，教師功能是用RN寫的) 。
部分代碼如下：
- 為什么還有一個
lanuchManger呢？對于這個類主要做了一下事情
- 創建跟控制器，比如我們的
lanuchVC - 如果有開屏頁，我們就在開屏頁顯示的3s時間內做一些耗時的啟動操作，如果沒有開屏頁就正常初始化相關邏輯。
- 如果APP在殺死的情況下，通過
scheme打開APP的時候，不應該展示開屏頁 - 對于切換賬號，登錄成功之后，需要根據不同角色，顯示不同的APP樣式，這個邏輯在
lanuchVC內部，因此這個時候也不應該再展示開屏頁 - 在開屏頁存在的時候，不應該展示
toast或者彈框 - 在
lanuchManger還要處理一些生命周期方法，比如前后臺，鎖屏等特殊情況處理。
部分代碼，如下：
