首先第一點，我們要以平和的心態面對這些需求（貧窮使我平和）！！！
隨着一個程序的迭代發展，APP首頁總會被設計出越來越多的彈框：
（1）常見的有系統級的“請求獲取用戶網絡”，“請求給用戶發通知”，“請求獲取用戶定位”，“請求同意協議”等權限要求彈框。
（2）還有提示“APP版本更新”，“新手引導”，“綁定其他賬號”，“賬號異常退出登錄”等通用提示彈框。
（3）更有想提醒（引誘）用戶進行一些升級操作的，比如“滿100-99優惠券”，“年度超值大禮包”，“恭喜您被選中”，“快去確認賬單領積分”，“快去參加活動抽大獎”，“您的好友邀請您xxx”等業務彈框。
如果這些彈框的業務代碼全被寫在首頁的控制器裏面，會導致代碼越來越臃腫，後續維護起來越來越費力，如果產品經理隨便提出調整一些“小需求”，比如修改一下這幾十個彈框裏邊的其中幾個業務和彈出順序，着實令開發人員頭大。
困難總是有的，但是有句話說的好，“老闆花錢把你找來是爲了解決問題的，不是讓你提出問題的！”，下面我們就來講講如何處理這個問題。
首先爲了保證一個良好的用戶體驗，我是這樣想的，當用戶進入程序之後，先保證用戶能看到首頁內容，再保證用戶能操作，最後再做彈框提示處理！具體操作如下：
進入首頁後，先從本地數據庫取出一部分數據渲染界面，讓用戶先看到一部分緩存內容，但禁止用戶操作，再彈出loading圖，開啓異步線程組，同時請求多個展示數據所需要的接口，加載完之後關閉loading圖，再次刷新界面，此時已可以讓用戶進行滑動和點擊按鈕等操作，然後加載彈框業務有關的接口，等需要的數據全部加載完之後進行統一彙總處理。如果用戶此時還在當前頁，就直接彈出所需提示的彈框，如果用戶已經離開了當前頁，就等用戶再次返回首頁的時候再彈出所需提示的彈框。
接下來就講講如何彙總處理彈框的業務，首先我們想想需要達到一個什麼效果，我認爲以下需求肯定都是必不可少的：
（1）彈框肯定不能一下全部彈出，那會醜爆的，必須一個一個彈出，
（2）順序一定要靈活配置，產品的不同發展階段，不同業務的彈框提示順序肯定不會相同，
（3）耦合度不能太高，不能改了這個影響那個，
（4）擴展性也得好，要不面對後續“小需求”怎麼辦，
（5）統一處理的時候也得方便，比如某些特殊情況全部不讓展示。
明確了目的之後，我們就開始設計吧
從視圖層面考慮，爲了降低耦合度，我們肯定要把每一個彈框都設計爲一個自定義視圖，然後只暴露出來這個視圖對應的一個模型供傳遞參數使用，但爲了方便統一管理彈框和設置一些通用屬性，比如背景透明度，顏色，彈出動畫，關閉彈框方法等，我們就要先建立一個自定義的父類視圖，讓這些彈框都繼承自這個父視圖。
然後從數據層面考慮，因爲彈框的數量衆多，又隨時可能增加減少調整順序，我們就在本地建立一個專門處理彈框數據的類，在這個類裏邊請求彈框所需的所有網絡數據，獲取所有數據之後，根據數據生成一個模型數組，和這個彈框列表形成映射關係，在每一個模型上增加一些屬性，包括彈框id，彈框名稱，彈框是否需要彈出，彈框所需的Jason參數等屬性。等數組建立完之後，就單獨寫一個遍歷這個數組的方法，遍歷數組內的每一個模型，如果這個模型的彈框是否需要彈出屬性是YES,就彈出對應的彈框，當關閉這個彈框時，就將彈框是否需要彈出屬性改爲NO，然後從上一個模型的位置開始繼續朝下遍歷，直到數組內所有的模型的是否需要彈出屬性全部變爲NO爲止。
這樣處理完之後，如果產品經理想整體換個背景透明度，顏色，彈出動畫等，直接在父視圖的一個地方調整就行，想單獨調整某個彈框樣式，就單獨改某個子視圖彈框樣式。想要加減彈框或調整順序，就只需要修改我們本地生成的模型數組就可以了，除非加新的彈框，否則其他地方都可以不怎麼改動就行。
一番折騰完之後，希望大家遇到同樣問題再也不用擔心被產品經理懟了：
“我就改個小彈框，你就想報兩天工作量？？？”