![]()
去年團隊里有人隨口問了一句:"要是視頻處理能全在瀏覽器里搞定,不用服務器呢?"
我當時正在一家在線視頻平臺做技術評估,這句話把我拽進了一個長達8個月的WASM深坑。現在回頭看,有些發現挺反直覺的——比如Safari這個"老拖后腿"的,居然開始翻身了。
從服務器賬單開始的實驗
我們給客戶的核心服務是視頻上傳和處理。傳統流程很標準:用戶傳文件→服務器做編碼/切片/分析→返回結果。
但賬單和延遲都在漲。文件越大,服務器成本越高,用戶等得越久。哪怕只是做個簡單的預處理或元數據提取,也要走完整的服務器鏈路,這件事本身就透著浪費。
"客戶端能不能扛?"這個想法成了評估WASM的起點。
答案是可以,而且比預期能干得多。
我們用的是ffmpeg.wasm——FFmpeg編譯成WebAssembly的版本。以下功能全部能在瀏覽器里直接跑:
不需要服務器。文件不出用戶設備。從隱私角度說,這是實打實的優勢。
性能數據比我想象的好看。短視頻編碼速度大概是原生FFmpeg的1/5到1/2——聽著很慢,但別忘了這是在瀏覽器標簽頁里跑。能跑起來本身就夠離譜了。
視頻元數據提取幾乎是實時的。不用上傳就能拿到分辨率、碼率、時長這些信息,UX可以直接上一個臺階。
1GB文件引發的內存慘案
最大的坑是內存。
瀏覽器里的WebAssembly有硬性上限。處理大文件時稍有不慎就會內存溢出崩潰——我親手踩過這個雷。直接把1GB視頻文件丟進去,標簽頁當場死亡。
解決方法是分塊處理。把大文件切成64MB的塊,順序寫入緩沖區:
分塊處理繞過了內存限制,代價是代碼復雜度上升——但這個代價付得起。
實現起來不算優雅,但穩定。我們線上跑了幾個月,沒再出現過內存崩潰。
Safari的翻身仗
評估過程中我順便掃了一眼整個WASM生態。和兩年前比,變化很大。
以前Safari是WASM世界的"新IE"——開發者要么寫降級代碼,要么干脆避開某些功能,因為蘋果在WASM支持上一直比Chrome和Firefox慢半拍。
現在情況變了。Safari 18.4支持了新的Wasm異常處理規范,Safari 26.0又加了原地解釋器來加速啟動。蘋果終于開始認真跟進了。
這個轉變的實際意義是什么?以前要維護三套代碼路徑的模塊,現在可以逐步收攏。對中小型團隊來說,維護成本是實打實的下降。
當然,Chrome和Firefox還是跑在前頭。但"Safari能用"和"Safari好用"之間的差距,正在以肉眼可見的速度縮小。
沒說完的部分
回到那個最初的問題:我們把多少服務器負載成功遷到了客戶端?
目前大約是30%的預處理任務——主要是元數據提取、縮略圖生成、格式預檢。編碼和重度處理還是留在服務端,畢竟2-5倍的性能差距在批量場景下扛不住。
但這個比例在動。WASM的編譯工具鏈在成熟,瀏覽器內存限制也在緩慢放寬。我們內部在測一個新的流式處理方案,目標是把單文件處理上限從現在的2GB推到10GB。
有個細節挺有意思:用戶其實感知不到背后換了技術。他們只發現"上傳前就能看到視頻信息了""小文件處理變快了"。技術債務的減少,最終變成了產品體驗的平滑。
所以如果你也在評估WASM,我的建議是——先找一個具體的成本痛點下手,而不是為了技術而技術。我們的起點只是一張服務器賬單,和一句"要是能……"的假設。
現在的問題是:當瀏覽器能做的事越來越多,你準備把哪些服務器任務"還"給用戶設備?
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.