一、背景與簡介
優酷的視頻互動是在播放頁橫豎屏彈出的互動浮層，旨在讓看片更有趣。現有投放評分、高級彈幕、特效廣告、子母屏雙視頻流等運營及廣告活動，以及基於 AI 的場景互動，投放效果如下圖。
針對這些大量的投放活動，爲了衡量活動曝光的質量，我們定義了互動曝光成功率：
通過添加技術埋點，我們統計了現有互動平均曝光成功率在 97.7%，即互動投放後，大約有 2%的用戶是看不到的，雖然投放的主要都是 weex/h5 活動頁，但是投放失敗的比例還是偏高的。爲此，我們花了一個多月的時間，分析了鏈路問題，來優化曝光成功率。
二、優化策略
互動業務曝光分腳本數據獲取、插件預加載、插件加載渲染顯示三個階段，在接手業務後，我們首先添加了相關節點技術埋點。通過分析技術埋點和 TLog 日誌，發現加載失敗主要有以下三種情況：
1）加載超時；
2）weex 和接口業務錯誤；
3）數據統計不準確。
查看日誌，大部分還是超時問題，直接錯誤佔所有錯誤的比例只有 10%左右。於是，首先來解決的是超時問題。
- 超時問題
1）預加載時間增大
我們首先拿評分 weex 頁加載時間區間分佈來分析，從技術埋點統計的加載時間範圍看，90% 區間最大需要 457 毫秒，但是到了 99%區間大約需要 17 秒。這裏可以看到 90%區間並不能準確衡量業務的好壞，之前配置的 5 秒預加載時間明顯不足，導致超時問題一直較多。現在 weex 和接口的預加載時間都調整到了 20 秒以上，確保 99%的用戶都可以加載完畢。
2）補齊 zcache 配置
由於投放的 weex 活動頁是由多人開發完成的，實際看投放的 weex 頁面，發現部分老頁面、新頁面沒有配置 zcache，導致曝光成功率不足 96%，於是找到相應的 weex 開發，跟進配置 zcache。
3）提前觸發 zcache 下載
通過觀察了多個 weex 頁面，發現 zcache 命中率都在 80%左右，現象就是用戶在第一次彈出互動時，基本無法命中 zcache，而在沒有 zcache 時，頁面加載超時的問題就很明顯，不解決 zcache 命中率問題，曝光成功率很難再提升。我這邊想過幾個策略：
方案 1：調整 zcache 優先級，強制更新和全網更新；
方案 2：預置 zcache 到 apk；
方案 3：提前觸發 zcache 下載。
方案 1 並不適合互動這樣的普通業務，方案 2 因 weex 業務代碼更新涉及到重新配置及老版本兼容問題，操作麻煩，而且會增大 apk 大小。後來想到只需要在進入播放頁時按需提前觸發 zcache 下載即可，於是去查看了 weex 加載鏈路源碼，發現確有 zcache 下載能力接口，於是增加了進入播放頁後有相關互動立即提前下載對應 zcache 文件，來提升 zcache 命中率。
從線上發版數據看，weex 頁的命中率從 77%提升到 98%左右，首屏平均時間減少 40%，既解決了部分用戶的超時問題，也解決了所有用戶首次渲染時間問題，提升效果明顯。
同時從曝光數據來看，zcache 命中率提升到 95%後，相關互動曝光成功率大約提升了 1%，普通 weex 頁面經此優化曝光成功率提升到 99%左右。現在 zcache 預加載能力已經沉澱到互動引擎，在以後的互動活動，及其它 weex、h5 頁面都可以使用此能力。
4）超時補償
現有預加載能力，可以保證互動準時彈出，但是也有一個很明顯的缺陷，有時間限制，超時即認爲加載失敗，針對部分不需要準時彈出的互動，超時就認定加載失敗，是不太合理的，因爲這裏大部分還是可以加載成功。於是我們在預加載邏輯裏新增一個策略，如果超過一定時間，還未預加載完畢，允許 plugin 直接彈出，等待 weex 頁面加載完畢。目前評分業務已使用了此策略，另外雙流業務也存在同步超時問題，android 端同步問題比 iOS 端高的多，我在雙流同步時也增加了超時認爲同步成功的補償邏輯。
- 錯誤問題
1）weex native 錯誤
新業務上線時，往往存在很多 js 錯誤，這期跟進核心互動評分、tips 互動的 weex 頁面 js 錯誤修復，反饋給對應開發來解決。目前 weex 核心頁面（評分、tips）暫無業務錯誤，不過還存在少量的白屏錯誤，後續待繼續優化這種容器層的 js 錯誤。
2）異常率
我們每期都在跟進互動業務 crash/anr 問題解決，但是實際分析曝光鏈路過程中，發現相鄰兩個階段總是會有少部分數據丟失，但是沒有 crash 信息。我從分析代碼鏈路看主要是 try catch 導致鏈路斷掉，於是想到來治理 warn 問題。業務內有很多 try 代碼，僅僅是爲了避免出錯時影響播放業務，但是卻沒有來解決這些警告。這些警告卻會導致互動曝光失敗，因此在 catch 之後統一執行異常上報，在 appmonitor 上報異常名稱，詳細錯誤日誌寫入 TLog，這樣可以統計警告個數。上線後統計警告數據如下：
實際上線後發現確實存在不少空指針、多線程異常，尤其是多線程 list 讀寫異常，影響了插件生命週期。我在新版本解決了這些警告。只有數量無法分析某個版本的好壞，於是參考崩潰率，以初始化個數爲分母，計算出警告率，可以來衡量各版本警告的指標。
優化一版後異常率從 1.085% 減少到 0.052%，解決了長久以來一直存在的多線程輪詢時的 list 讀寫異常。現在只優化了主要的幾個問題，由於在定位過程中發現從 TLog 拉取歷史日誌，存在設備不在線、數據丟失問題，使用不很方便，後面考慮把錯誤文件名、行號同時上傳到統計後臺，方便快速定位問題。其他業務如互動這邊彈幕、評論等業務以此爲參考，重點治理下警告問題。
- 互動容器 bug 及數據統計校準
針對曝光成率統計，雙端統計分子實際曝光數沒有問題，但是在統計分母應該曝光數時，都存在統計不準的問題，爲此我們雙端討論並約定分母中，去除了無網導致的預加載問題、音頻模式不彈（設計約定）、互斥不彈、未登錄用戶態導致的不彈、黑名單配置等干擾數據統計，同時解決了分母重複統計問題，跟進播放器解決推薦廣告導致的首次不彈 bug，確保雙端數據準確、標準一致。
三、總結
本次曝光成功率優化，核心業務的成功率都提升到了 99%以上，主要使用了以下三個策略：
1）提前預加載；
2）增大預加載時間；
3）增加超時補償邏輯。
同時解決 weex 錯誤、客戶端的錯誤、警告，補全了互動監控、預警能力，監控並保障投放活動的穩定性，沉澱了 zcache 預加載能力、異常率指標。
通過此次優化，從互動平臺角度解決了現有的互動曝光率問題，完善平臺化能力，確定了業務投放衡量標準，以此來推進提升及保障各互動業務的質量。
作者 | 阿里文娛高級無線開發工程師 憑海