大型項目自動化釋出平台前端系統實作與優化
随着移動平台的興起，傳統的前後端耦合的開發模式不再合适，後端改為專門負責提供資料接口，以應對多平台開發的需求。
故而前後端開始獨立，web應用開始了工程化的改造。在前端工程化的改造中，開發人員除了要探求适合前端開發的工程化實踐範式，還需要應對實踐過程中出現的性能問題，及時予以解決。
在項目工程化實踐過程中，結合架構原理以及新興的技術，對開發過程中遇到的諸多性能問題，分别給出了解決方案，并予以實施。
針對采用單頁應用的開發範式導緻的頁面最早可互動時間延後的問題，分别對檔案的拉取流程和解析渲染流程做出了優化。
運用基于CacheAPI的預加載技術減少了拉取流程的時延，使用漸進式渲染的方式，對頁面進行有梯度的渲染，提升了頁面的整體渲染速度。
對于大型表格的渲染更新慢，操作效率低下的問題，在vnode渲染（render）階段，檢查vnode的狀态是否發生了改變，在未發生改變的情況下，複用緩存的vnode，避免了大量高開銷的vnode建立操作。
在更新送出（commit）階段，架構需要使用Diff算法對比新舊vnode的差異，以确定需要執行的DOM操作，項目内使用LIS算法優化了架構原有的Diff算法，減少了不必要的DOM操作，避免了大型表格的更新造成的卡頓。
使用者生成的釋出任務，需要經過審批人的審批，才能被使用者操作。審批人在任務生成後，會在企業微信中收到通知，審批人通過點選連結進入任務審批頁面。
無論任務包含多少子任務，都會在此頁面展示出來。為了友善使用者檢視，通過折疊面闆分别展示了釋出任務的基本資訊與計劃的具體批次安排。
如果出現釋出申請中包含多個釋出任務的情況，系統将設定Set類型的對象viewedTabs，用于記錄使用者已經通路過的釋出任務，當使用者通路過一個釋出任務後，會将該釋出任務的id存入viewedTabs中。
Set類型的對象儲存的内容是總是唯一的，對象内不會出現重複的值。是以隻有當viewedTabs的長度等于關聯釋出的任務的數量時，操作按鈕才可以被使用。
這樣就保證了審批人檢查到所有的釋出任務。
審批人最終可以對釋出申請執行通過或駁回的操作。當選擇駁回時，審批人可以向申請人回報不給予通過的具體原因，友善申請人優化方案。
任務清單頁面展示了使用者生成的所有釋出任務，每一列都展示了一個任務的相關資訊，比較重要的就是任務釋出進度和操作按鈕。
對于未進行審批的任務，使用者可以在這裡主動觸發提醒，提醒審批人完成工作。如果已經被審批通過，使用者就可以執行任務的開始，結束，終止等操作。
為了保證任務進度的同步顯示，應用會通過setInterval方法在背景發起輪詢操作，不斷更新頁面。
任務監控頁面展示單個任務釋出的詳細情況，展示釋出過程中每一個批次的釋出進度，同樣通過輪詢確定使用者擷取資訊的實時性。
使用者可以對正在釋出或未釋出的批次進行調控，包括編輯批次釋出安排，提前釋出某個批次等操作。
確定釋出的順利進行。釋出中的任務可以暫停，終止或者復原。
使用者正在使用的身份會通過localStorage存儲在本地，使用者打開應用時，讀取本地存儲的身份，確定使用者身份的一緻性。
應用會通過getAllTanants方法對使用者所擁有的身份進行拉取，通過下拉選擇框的形式進行展示，并提供切換身份的功能。
當使用者切換身份時，會對localStorage進行更新，并使用router.go（0）方法實作頁面的原地重新整理，拉取更新後的身份對應的内容。
應用在運作過程中，如果沒有在本地讀取到使用者的身份資訊，說明使用者是新使用者，會自動跳轉至身份管理頁面，指引使用者選擇身份或建立新身份。
原有的持續釋出平台，随着上線後使用者逐漸增多，為了應對不同使用者繁多的需求，平台的功能持續不斷的優化新增，随之而來的就是代碼庫變得越來越龐大。
這種龐大不僅展現在開發過程中需要更細心的維護、組織代碼，也展現頁面加載性能越來越差上。
因為本平台采用單頁面網絡應用的開發範式，在未經過優化的情況下，使用者請求的頁面不會攜帶任何資訊，浏覽器需要拉取頁面中引用的JavaScript腳本，接着執行腳本生成可以互動的頁面。
代碼庫越龐大，浏覽器自然就要花更多的時間執行，頁面的最早可互動時間越來越難以控制在可以接受的範圍内。
通過詳盡的測試，驗證了持續釋出平台的功能實作的完善性以及穩定性。通過對比實驗的方式，證明項目在最早可互動時間，大型表單性能優化等方面的實踐的有效性。
