當 Adobe 放棄 Flash 後，ruffle 為什麼值得你用

ruffle：為消逝的 Flash 生態撐起一把傘

2020 年 Adobe 正式終止 Flash Player 的支援，這個曾經佔據網路互動內容半壁江山的技術，一夜之間成為了瀏覽器的棄兒。成千上萬的經典 Flash 遊戲、互動動畫、甚至整個網站的互動功能，都隨著各大瀏覽器陸續移除 Flash 支援而無法正常運作。我自己就是在那陣子開始尋找替代方案的——翻遍了獨立開發者論壇、嘗試過好幾款自稱能跑 Flash 的工具，大部分不是只能跑單機遊戲、就是性能差到讓人想摔鍵盤。ruffle官網 就是在這樣的背景下讓我眼前一亮的：它不是一個單純的遊戲模擬器，而是一個以 Rust 語言編寫、透過 WebAssembly 執行的 Flash 相容層，讓過去的 Flash 內容能夠在現代瀏覽器中無需任何外掛即可重新運行。它的野心顯然比「讓幾個老遊戲跑起來」更大——ruffle 想做的，是撐起整個消逝的 Flash 生態遺產。

安裝

ruffle 的 Android 安裝包（APK）大小約 42MB，安裝過程與一般 Android 應用相同：ruffle下載 APK 後允許未知來源安裝即可。首次啟動時，它會請求儲存權限以讀取本地的 SWF 檔案。桌面版則提供 Windows、macOS、Linux 三平台的獨立安裝程式，首次啟動時會自動檢查並提示是否要下載 OpenH264 解碼器（約數 MB，用於支援 H.264 影片格式）——這個提示很容易被忽略，如果你發現某些包含 H.264 影片的 Flash 內容有畫面沒聲音，八成就是這一步跳過了。而網站嵌入版本最為簡單，只需在 HTML 頁面插入一行 script 標籤，CDN 會自動完成後續的 WebAssembly 執行時下載與初始化，訪客完全不需要做任何額外配置。

同類工具格局與 ruffle 的定位

我用過好幾款同類工具，大致可以分成三類：第一類是獨立開發者打包的舊版 Flash Player 安裝包，本質上就是硬把 Adobe 過時的執行檔塞進容器裡，優點是相容度高、幾乎能跑所有 Flash 內容，但缺點也非常致命——安全漏洞一堆、只能跑單機、無法嵌入網站。第二類是瀏覽器擴充功能型的 Flash 替代方案，它們在瀏覽器側攔截 Flash 元素並嘗試模擬執行，但性能普遍不佳，複雜一點的遊戲就卡死。第三類就是以 ruffle 為代表的原生 WebAssembly 相容層，這是目前最有前景的方向——不依賴任何外掛或舊版執行檔，在現代瀏覽器的沙箱裡安全地模擬 Flash。在這個格局下，ruffle 的定位很清楚：它不是一個純粹的遊戲模擬器，而是想成為 Flash 內容的通用執行層，從單機到網站嵌入都想覆蓋。

三個讓 ruffle 脫穎而出的設計

用了幾個月下來，ruffle 有三個設計決策讓我覺得它跟其他同類工具不是一個量級的。

第一，WebAssembly 原生嵌入，一行 script 接管整站 Flash。 這是我認為最革命性的一點。如果你經營一個有舊 Flash 內容的網站，其他方案要嘛讓訪客裝外掛、要嘛你得把每個 SWF 單獨轉換成 HTML5。ruffle 的做法完全不同——在頁面插入一行 script 標籤，它會自動掃描整頁所有 Flash 元素（不管是 <object>、<embed> 還是 swfobject 動態生成的），全部替換成自己的執行容器，訪客打開頁面的瞬間就完成了，零配置。這種設計讓存量 Flash 網站的遷移成本降到了幾乎為零——我幫朋友的一個舊論壇網站接入 ruffle文檔 裡介紹的方法，前前後後只花了五分鐘。

第二，Rust 編寫帶來的性能與安全優勢。 Flash 當年的安全問題是有目共睹的，Adobe 不得不放棄它很大程度也是因為漏洞實在太多。ruffle 用 Rust 從頭寫 Flash 的 AVM1 和 AVM2 虛擬機，Rust 的記憶體安全保證意味著它不會有 Flash Player 那些被利用了無數次的緩衝區溢位漏洞。而 WebAssembly 的執行效率也遠高於 JavaScript 寫的模擬器——我測試過幾個複雜的 AVM2 遊戲，ruffle 的幀率比同類 JS 方案高出 30% 到 50%。

第三，自帶 FLV 解碼器，不依賴外部資源。 Flash 的影片內容長期以來是模擬器的重災區——要嘛依賴 Adobe 的授權編解碼器、要嘛乾脆不支援。ruffle 自己實現了 FLV（VP6/Sorenson Spark 影片 + MP3 音訊）的解碼器，內建在執行時裡，用戶不需要額外安裝任何東西就能播放 FLV 影片。H.264 的部分雖然因為專利原因需要用 Cisco 的 OpenH264，但桌面版會自動提示下載、Web 版直接調用瀏覽器原生解碼，用戶感知幾乎為零。

這些優勢的代價：ruffle 尚未完善的地方

說完優勢，也得講講它還做不到的事情——畢竟我說的是「值得你用」，不是「完美無缺」。

首先是 AVM 2 的覆蓋還不全。 這是目前最明顯的短板。AVM 1 的相容度已經很高了，大部分老 Flash 遊戲都能跑；但 AVM 2 還缺好幾個關鍵特性：RTMP 串流（這意味著部分線上 Flash 遊戲無法連線）、原始 TCP/UDP Socket、Pixel Bender 2 著色器、相機/麥克風接入、Adobe AIR 的檔案系統與原生 API。如果你遇到的 SWF 用到了這些特性，ruffle 會直接報錯或者白屏。官方的說法是這些特性要嘛涉及專利、要嘛實作複雜度太高，短期內不會完全覆蓋。

其次是瀏覽器安全策略的限制。 既然是跑在瀏覽器沙箱裡，ruffle 就得服從瀏覽器的規則——自動播放策略就是最頭痛的一個。Chrome、Edge、Safari（尤其是 iOS Safari）都規定用戶沒跟頁面互動之前，帶聲音的內容不能自動播放。ruffle 的 Web 版如果頁面加載完就嘗試播放 SWF，聲音會被瀏覽器靜音。解決辦法是設計上假設「首次進入頁面不會自動播放」，加一個「點擊開始」按鈕讓用戶先互動一下，之後音訊就自動解禁了。CORS 策略、本地檔案系統存取也都是類似的問題——現代瀏覽器的安全設計，跟 Flash 當年的設計哲學根本是兩條路。

最後是桌面版的 OpenH264 手動開啟。 雖然 Web 版自動用瀏覽器原生 H.264 解碼很方便，但桌面版預設是不開 OpenH264 的——你得進參數設定手動勾選，第一次勾選還要下載 Cisco 提供的二進位檔。這個步驟太容易被忽略，我自己第一次用桌面版時就卡在這裡：某個包含 H.264 影片的 Flash 動畫有畫面沒聲音，折騰了半天才發現是 OpenH264 沒開。

結論：什麼情況下該選 ruffle

經過這段時間的使用，我的結論很明確：如果你想要讓 Flash 內容在現代瀏覽器裡活過來，ruffle 是目前最好的選擇。但它不是萬能的——如果你的需求是跑那些用到 RTMP 串流、Pixel Bender、AIR 檔案系統等進階特性的複雜 AVM 2 應用，ruffle 現在還幫不了你，這些場景下其他工具可能更合適。但對於絕大多數的存量 Flash 網站（經典遊戲、互動動畫、教學演示），ruffle 已經足夠好用了，而且它的迭代速度很快，每週都有新的提交，很多今天還不支援的特性明天可能就修好了。

我會推薦 ruffle 給所有想保留 Flash 遺產的人——不管你是網站站長想讓舊內容繼續被訪客看到、還是懷舊玩家想重溫童年遊戲、或是教育工作者想保住那些用 Flash 做的互動教學素材，ruffle 都是目前最值得投入時間的方案。它未必是終點，但在這個方向上，它走得比任何人都遠。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。