2022手Q春節活動主會場頁面日PV過億，活動期間覆蓋用戶總數更是達到數億，多項數據刷新歷史記錄。
為了支持這個億級DAU項目，項目前端團隊從項目架構到頁面性能，實施了各種常規和非常規的創新實踐及優化，確保了用戶體驗的平穩順滑。
下面就從整體技術方案、穩定性考慮及監控、性能調優、資源帶寬優化、日志效率幾個方面來說說前端團隊所做的創新和優化。
1 整體技術方案1) 主會場的截屏效果
主會場是一個游戲化的單頁應用。
上方星空是主要用戶交互區，點擊星星可以抽獎。
右側按鈕區是背包、碎片列表、小游戲、好友互動等二級頁和子功能入口。
下方是小窩、小世界、王者榮耀、公益等分會場入口。
在項目初期，首先面臨的問題是技術方案選型。
2) 前端頁面的技術選型
主會場是整個活動的入口，是核心頁面，主會場的技術選型是重中之重。
因為主會場是一個“游戲化”的頁面，一開始我們考慮引入egret、cocos游戲引擎，把主會場當做一個H5小游戲來做。
我們使用egret游戲引擎做了較深入的技術調研，甚至架設好了項目Demo，但很快就意識到這個方案可能存在各種問題：
主會場內容無法一屏容納，需要滾動，游戲引擎會很吃性能且較難優化即使用了游戲引擎，也還是要結合dom頁面來配合完成所有功能游戲引擎代碼復雜，代碼量大在分發、加載等多個方面都更加耗損效率游戲引擎都使用webgl渲染，低端機特別容易出現黑屏花屏等需要更多時間精力來定位解決的問題主會場游戲化的交互比較輕，使用游戲引擎帶來的“效益”并不明顯
于是我們再次梳理了主會場的技術方案，并對使用游戲引擎方案和Dom方案做一更加細致的對比考慮。
從這個對比看，每一個維度都不支持我們引入厚重的游戲引擎，最終我們放棄了游戲引擎，決定使用Dom方案，動畫引擎使用非常輕量的anime。
最終的實踐確實證明，我們的選擇是正確的。anime非常輕量，代碼量僅17kb，性能也很好，hold住了所有的動畫場景，完全滿足產品設計對動畫的需要。在滿足產品需求的基礎上，使項目盡可能簡單化，本身也是簡潔高效的體現！
關于anime，有需要了解的可以前往其官網：
主會場的技術方案確定后，其它頁面的動畫、復雜程度都比主會場輕的情況下，就可以統一參考主會場的方案來做了。
3) 前后端接入方案
日常業務，一般是走直出，異步數據走https請求。直出對于效率的優化意義，很大程度上得益于接口數據的請求是在node端實現的，但代價是需要部署額外的node服務器。
春節紅包這樣基于手Q客戶端的大規模的活動，為了增強安全性和穩定性，數據請求我們考慮走客戶端的sso加密通道。
這種情況下，node直出的優勢得不到發揮，并且還要額外部署大量的node服務器。所以我們沒有考慮使用node直出方案，而是直接從CDN加載靜態代碼文件和資源，然后接口通過客戶端sso通道異步獲取。
但是這樣一來，首次加載頁面的用戶，在沒有緩存的情況下，頁面白屏時間可能會比較長，為了解決這個問題，我們與客戶端緊密配合，使用了內置包 + 離線包方案。具體來說，就是把代碼、資源等文件隨客戶端一起打包發布，當用戶進入頁面發起資源請求時，客戶端會攔截用戶請求并判斷是否存在本地資源，如果存在就直接使用，不存在時才通過網絡加載。
內置包 + 離線包的方案，極大提供了用戶進入各個頁面的速度，讓頁面達到了秒開的效果。
4) 整體動畫方案
整體項目有大量的轉場、軌跡、場景動畫，我們的動畫方案是 + apng + css。本質也是css動畫。
這個方案避開了、webgl渲染等可能引起黑屏、花屏問題的前端特性，并且完全滿足產品、設計的需要，即是穩定、高效的方案。
對于普通的位移、漸變、循環旋轉等動畫，簡單寫點css即可解決。
比如按鈕掃光、窗口上浮，還有主會場的環型星空的自轉、抽獎星星的自轉等。用好css動畫，本身就可以解決非常多的動畫場景了。
對于一些較復雜的路徑動畫，比如摘星時星星的曲線運動軌跡，則通過anime控制。
比如下面這段代碼就是實現星星的拋物線運動動畫的代碼：
而對于一些較復雜的場景動畫，難以通過純前端實現的，則通過優化后的apng來渲染。
背景中的繁星點點閃光、流星飛過、極光效果等屬于此類動畫。此類動畫根據性能分級，部分機型不展示。
如有興趣了解這些動畫的最終效果，可以觀看本文前面的錄屏。
這些都是前端穩定實踐了很多年的方案，使用起來沒什么顧慮，最終的實踐也證明了這樣的實現是很穩定高效的。
5) 小游戲接入方案
項目設計包括了多個小游戲。所有小游戲都是是基于cocos 制作的，游戲的開發、迭代都由各自的開發商負責。
我們采取的方案是讓合作方提供的小游戲的單機版本，接入我們統一提供的SDK。開發商發版本時通過郵件把編譯結果輸出，我們把編譯結果代碼合入項目版本中發布。
統一游戲SDK提供了獲取分數、開始游戲、關卡完成、提交分數、振動等接口，實現了結果頁、排行榜等界面，并提供了標準化的文檔。
統一SDK及相關文檔的設計，確保了游戲接入的高效和標準化，為后續高效改造和添置各種功能、數據上報等提供了前提。
另外，所有的游戲都是基于cocos 制作的，游戲引擎文件達到2M左右，我們要求各開發商使用一致的版本構建頁面加載時顯示進度條，游戲邏輯和引擎邏輯分享，這樣就可以共用一個游戲引擎、物理引擎等，節省了引擎庫版本，并把引擎相關的資源早早地合入了離線包、內嵌包，確保了引擎庫加載的穩定高效。
2 穩定性及監控
項目整體的穩定是整體技術方案選型以及接口優化的效果，而接口優化需要完善的監控數據來提供指引。
常規的https請求方案鏈路長，從性能和安全性方面都難以承載這樣大規模的請求量。所以頁面的數據請求走的是客戶端sso通道，而一些關鍵操作則由客戶端提供了接口，前端只需要直接調用，比如抽獎、數據上報等。客戶端直接執行的效率比頁面處理要更好，這一點毫無疑問的。
對于端到端的接口監控，我們使用TAM提供的前端監控解決方案。關于日志上報后文還會有提及。
整體技術方案之前已有介紹，這里說說接口優化。
1) 接口監控
每一次演練結束后，我們都會從TAM撈取相關的質量數據來分析對比，來洞察性能優化的效果及存在的問題，為下一波優化提供數據支撐。
第二次演練后的質量數據分析（部分）
需要注意，我們頁面所有的數據請求走的是手Q客戶端的SSO通道，而TAM默認的API性能邏輯是不會偵察到這類接口請求的，需要自己實現API性能數據的上報：
2) 接口優化
經過前端、客戶端、后臺、測試緊密合作聯調，我們排查或優化了如下這些場景：
① 降低數據請求頻率
比如常規星星數的扣減由前端直接執行，取消不必要的數據更新策略而是通過更周密的邏輯保障數據一致。
② 聚合數據請求
接口在設計的時候就考慮少用，比如核心主會場，進入首頁只會請求一個后臺接口，把所有必要的數據都聚合到這個接口。另外，數據上報量較大，不是每次請求都即時上報，客戶端有聚合上報的策略。
③ 精簡單接口數據量
理論上，數據量越大越影響傳輸性能。每輪演練后都會梳理所有的數據項，檢查可精減、可合并的數據，確保沒有一項數據是多余的，以確保數據簡潔高效。
④ 解決頁面切后臺時數據請求失敗率高的問題
通過分析收集到的數據發現，頁面在切后臺時，sso數據請求的失敗率較高。聯合客戶端定位后發現，這是sso的機制本身如此。
于是前端這里做了一個優化：頁面切后臺時不執行數據請求，而是監聽頁面切前臺事件，等頁面切回前臺時再執行。因為頁面切后臺時對用戶不可見，所以這個優化并不影響用戶體驗。
⑤ 推動客戶端基礎側優化或解決其它sso鏈路問題
整個開發期間頁面加載時顯示進度條，遇到的sso鏈路問題，比如某段時間超時率較高，某些場景回包數據為空等，都能從收集到的反饋及上報的日志分析發現，并推動優化解決。
而這些問題能高效地發現、定位，得益于我們完善的日志上報體系及埋點。
最終，經過多輪調整優化，所有接口的端到端的耗時都小于500毫秒，除邏輯和數據量較重的首頁接口外，耗時均小于300毫秒，接口端到端的成功率均在99.5%以上。
3 性能調優
春節紅包這樣大規模的活動，性能優化帶來的效益是貫穿于整個鏈路的，從項目的維護成本降低、分發效率提升、用戶體驗提升、帶寬流量降低等。
常規的性能優化措施，我們從項目的設計和開發階段開始貫徹執行，比如：
常規圖片使用之前盡可能壓縮、合并、復用資源跨項目復用，比如字體、公用圖片、項目公用庫、vue、小游戲引擎等盡可能降低請求數量，特別是首屏請求數量邏輯、組件跨項目復用，比如抽獎浮層、上報SDK、游戲SDK等，都是獨立且高度復用的模塊
后期還針對性地做了多項專門的性能優化，比如：
1) 首屏優化
具體措施有，對于不必要首屏加載的資源，先隔離出去，后續按需加載；進一步梳理壓縮資源，加快請求速度；全部資源確保走離線包加載；接口請求數據量經過多輪壓縮合并，同時優化請求速度。經過一系列優化，最終使用首屏渲染性能達到1秒左右。
經過n輪演練、優化，最終，大部分頁面的首屏性能都實現了秒開的目標。
下圖是第5輪演練總結時的頁面性能數據，此時離線包資源還未全面鋪開。后面離線包資源鋪開后，頁面性能進一步提升。
2) 資源預加載
針對某些場景，打開后會出現資源加載慢、圖片切換瞬間視覺跳變等問題，進行必要的預加載處理。
3) 小游戲專項優化
小游戲合作模式是外包提供的單機版本，接入我們統一提供的SDK。
所有小游戲都是基于cocos 制作的，除了SDK、引擎復用，還指導開發商進行了資源的壓縮、合并、復用等。
從包大小看，單個游戲包大小最終都控制在3M以內，包大小優化到只占首次提供版本的30%左右，優化效果還是相當明顯的。
另外在加載速度、體驗順滑性等方面，也針對不同游戲進行了區別調整，比如優先顯示背景圖減少白屏機率、定制更加精確的加載進度條、減少游戲開始前的資源加載量、把聲音加載放在游戲開始后等，進一步提升了用戶體驗，提高了用戶留存率。
經過多輪優化，所有游戲的5秒進入率達到50%以上
4) 主會場分級特效體驗
在所有可能的優化措施都做了之后，還是會有部分低端機會出現卡頓的情況，而在春節紅包這種數億級用戶參與量的活動中，低端機的絕對數量不可忽視。為了確保核心體驗，對低端機型做一些特效減配是非常有必要的。
經過分析定位，卡頓的原因指向了場景特效過多，于是我們打算對所有機型分為全開性能、中等性能、較低性能三個級別，按照性能級別從高往低減配特效展示。
首先面臨的問題是機型的配置及分布，借助天璇巨量的頁面訪問，我們在天璇頁面中下發了上報機型配置到TAM系統的邏輯，很快就收集到了近10萬條機型配置的數據。通過對這10萬條數據進行分析，并結合測試同事提供的少量機型實測數據，我們按平臺給出了如下分級策略：