去年接了個把 Unity 項目搬進瀏覽器的活美術(shù)和策劃直接在網(wǎng)頁上驗收第一句話就是怎么點了全屏沒反應。當時我以為加個按鈕調(diào)一下瀏覽器的全屏接口就完事結(jié)果一頭撞進坑里按鈕點了沒反應、全屏之后畫面糊成一片、按 Esc 退出來 UI 還掛著全屏中的狀態(tài)、嵌在 iframe 里干脆整套接口都摸不到。前前后后折騰了兩三天才把 UnityWebGl 網(wǎng)頁全屏顯示這件事從能點做到能用再到敢交付。這篇東西就是把那幾天的過程攤開講。全屏在 Unity WebGL 里從來不是調(diào)一個 API的問題它橫跨三層瀏覽器的視口控制、canvas 的繪制緩沖區(qū)、Unity 內(nèi)部的相機與 UI 適配。任何一層沒對齊表現(xiàn)出來都是全屏壞了但壞的地方完全不一樣。下面這套內(nèi)容適合三類人看剛把項目導出成 WebGL、被全屏按鈕折磨過的開發(fā)者要交付給第三方嵌入、被 iframe 卡住的同學以及畫面全屏后糊掉、變形、鼠標點不準找不到原因的人。代碼可以直接抄思路可以直接套。1. 先把全屏拆成三層不然后面全是返工1.1 瀏覽器視口層全屏接口到底給了你什么瀏覽器提供的全屏能力本質(zhì)上是讓某一個 DOM 元素脫離頁面布局獨占整個屏幕。它的調(diào)用入口是元素上的requestFullscreen()退出入口在document上叫exitFullscreen()。這兩個動作都有一個硬前提必須由用戶的真實交互觸發(fā)。你在定時器里調(diào)、在數(shù)據(jù)加載完成后的回調(diào)里調(diào)瀏覽器一律拒絕而且拒絕方式很安靜多數(shù)情況下只在控制臺留一條警告。判斷當前是否處于全屏不看按鈕狀態(tài)看document.fullscreenElement——它有值就說明有元素正在獨占屏幕值是null就說明沒有。這個判斷比維護一個布爾變量可靠得多因為用戶隨時可以按 Esc 或用系統(tǒng)手勢退出你的變量根本收不到通知。狀態(tài)變化靠事件監(jiān)聽fullscreenchange在進入和退出時都會觸發(fā)fullscreenerror只在失敗時觸發(fā)。這兩個事件是你做 UI 同步的唯一正確入口后面第 4 節(jié)會重點講。還有一個容易忽略的開關(guān)document.fullscreenEnabled。它是false的時候說明當前環(huán)境從策略層面就不允許全屏典型場景就是被嵌在一個沒有授予全屏權(quán)限的 iframe 里。先查這個值能省掉一半的排查時間。注意老版本 WebKit 內(nèi)核用的是帶前綴的寫法webkitRequestFullscreen/webkitfullscreenElement移動端部分瀏覽器至今仍然只認帶前綴的版本。穩(wěn)妥的封裝里要把這兩套都寫上而不是只調(diào)標準接口。1.2 畫布層canvas 的顯示尺寸和繪制尺寸是兩回事這一層是絕大多數(shù)全屏后畫面糊的根源我見過太多人卡在這。canvas 有兩個尺寸概念。一個是 CSS 尺寸也就是它在頁面上占多大地方由width/height樣式或者父容器決定另一個是繪制緩沖區(qū)尺寸也就是canvas.width/canvas.height這兩個屬性它決定了實際有多少像素參與渲染。兩者不一致的時候瀏覽器會把緩沖區(qū)拉伸到 CSS 尺寸上顯示于是要么糊要么鋸齒。Unity 的 WebGL 框架在啟動時會根據(jù)發(fā)布配置給 canvas 設一個初始緩沖區(qū)尺寸之后窗口尺寸變化時它會自己重算。但這個重算依賴一個條件它讀到的 canvas 的 CSS 尺寸必須是真實鋪滿容器的。如果你的容器用了transform: scale()、或者給 canvas 加了padding、或者父級有奇怪的定位方式框架讀到的clientWidth就不是你以為的那個值重算出來的緩沖區(qū)尺寸自然也是錯的。所以我在模板里的做法永遠是讓 canvas 老老實實width: 100%; height: 100%; display: block;父容器負責布局canvas 只負責填滿中間不加任何花活。1.3 游戲內(nèi)部層別指望Screen.fullScreen在 WebGL 上生效Unity 的Screen.fullScreen和Screen.SetResolution這套東西在 WebGL 平臺上是失效的。原因很直白瀏覽器沙箱里的分辨率由 canvas 緩沖區(qū)決定Unity 運行時無權(quán)直接改操作系統(tǒng)層面的窗口尺寸它能做的只是改自己那塊畫布的像素數(shù)。這意味著你寫在桌面端跑得好好的全屏邏輯搬到 WebGL 上會變成什么都不發(fā)生而且不報錯。我第一版就是這么翻車的——C# 里判斷了一下平臺以為是編輯器模擬的問題導出來才發(fā)現(xiàn)是真不生效。正確的分工是全屏的進入和退出交給瀏覽器接口畫面的清晰度和比例交給 canvas 尺寸與 Unity 相機適配。Unity 側(cè)只負責發(fā)指令和收狀態(tài)不負責真正的全屏動作。2. 方案選型真全屏、偽全屏還是兩個都要2.1 三種常見落地方式的橫向?qū)Ρ仍趧邮种跋劝芽蛇x路徑擺清楚。我實測過的三種方式如下方式實現(xiàn)手段覆蓋范圍主要短板適用場景真全屏元素調(diào)用requestFullscreen()桌面端瀏覽器覆蓋率很高安卓主流瀏覽器可用iOS 上的瀏覽器對任意元素支持極差必須用戶手勢觸發(fā)桌面端為主的運營后臺、展示型項目偽全屏CSS 把容器鋪滿視口position: fixedinset: 0 高層級全平臺無差別可用瀏覽器地址欄、標簽欄依然存在按 Esc 退不出移動端為主的 H5 小游戲、必須兼容 iOS 的項目混合方案優(yōu)先真全屏失敗或環(huán)境不支持時自動降級到偽全屏全平臺代碼量翻倍兩套狀態(tài)的同步要寫清楚我實際交付的項目基本都用這個偽全屏的核心就三行 CSS容器固定定位、四邊貼零、層級拉到足夠高同時把body的滾動關(guān)掉。它看上去沒有真正全屏但在移動端瀏覽器里用戶感知上的差別遠小于你的預期——尤其是當頁面本身就沒有其他內(nèi)容的時候。真全屏和偽全屏最大的行為差異在于退出的方式真全屏下用戶按 Esc 或系統(tǒng)返回手勢會退出這個動作你攔不住只能監(jiān)聽偽全屏下退出只能靠你自己的按鈕所以反而狀態(tài)更可控。這個差異直接影響第 4 節(jié)的狀態(tài)同步邏輯。2.2 我的選型結(jié)論默認走混合判斷條件寫死我現(xiàn)在的固定做法是先判斷環(huán)境能力再決定走哪條路判斷邏輯在下發(fā)指令那一刻執(zhí)行而不是在頁面加載時緩存。判斷條件按順序來document.fullscreenEnabled為true且當前元素上存在requestFullscreen方法走真全屏否則直接走偽全屏。iOS 上的瀏覽器基本都會落到第二條分支上這不是缺陷是現(xiàn)狀提前接受它比事后打補丁省事得多。還有一層要考慮如果項目是嵌在 iframe 里交給第三方用的真全屏這條路還得額外滿足兩個條件——iframe 標簽上要有allowfullscreen屬性同時allow屬性里要顯式寫明全屏權(quán)限。少任何一個document.fullscreenEnabled直接是false你連嘗試的機會都沒有。提示混合方案里最容易出問題的是降級后狀態(tài)沒對齊。比如真全屏失敗了代碼走了偽全屏分支但 Unity 側(cè)收到的信號是進入成功UI 顯示成退出全屏按鈕用戶點了才發(fā)現(xiàn)根本沒全屏。所以指令的下發(fā)結(jié)果必須回傳不能只發(fā)不收。3. 改造發(fā)布模板把控制權(quán)從 Unity 手里拿回來3.1 自定義模板目錄怎么建名字和路徑都是硬要求Unity 的 WebGL 發(fā)布模板放在工程目錄下的Assets/WebGLTemplates/里。這個路徑的名字、大小寫、層級都不能錯錯一個字母在發(fā)布面板里就看不到你的模板。建目錄的步驟很死板但每次新建工程我都得提醒自己一遍在Assets下建WebGLTemplates文件夾注意首字母大寫、其余小寫、中間不能有空格和下劃線然后在這個文件夾里建你的模板文件夾比如叫FullscreenTpl把默認模板里的index.html復制進去再檢查一下模板文件夾里有沒有thumbnail.png——沒有的話發(fā)布面板里那塊預覽圖是空白的不影響功能但影響心情。發(fā)布的時候在 Player Settings 的 Resolution and Presentation 里把 WebGL Template 選成你的模板名。選完之后建議清一次瀏覽器緩存在本地跑一遍因為我遇到過發(fā)布配置改了但瀏覽器拿著舊 index.html 的情況排查半天以為是代碼問題。模板里的占位符在不同 Unity 版本寫法有差異。老版本用的是%UNITY_WIDTH%、%UNITY_HEIGHT%、%UNITY_WEBGL_LOADER_URL%、%UNITY_WEBGL_DATA_URL%這種百分號包裹的形式2020 之后的版本改成了{{{ UNITY_WIDTH }}}這種大括號形式。改模板之前先打開原始文件看一眼用的是哪套別照著一個四年前的教程硬改改完占位符沒被替換頁面白屏。3.2 index.html 的骨架改造容器、canvas、覆蓋層三層結(jié)構(gòu)原始模板的結(jié)構(gòu)一般是一個外層容器包著 canvas 和加載條。我要改的是把容器角色拆清楚外層負責鋪滿視口中間層負責承載 canvas最上面放我自己的一層 UI 覆蓋元素。結(jié)構(gòu)大致長這樣div idunity-viewport div idunity-container canvas idunity-canvas tabindex-1/canvas /div div idfs-ui button idfs-btn typebutton全屏/button /div /div幾個細節(jié)值得說。canvas上的tabindex-1是為了讓它能被腳本聚焦——退出全屏后如果不把焦點還給 canvas鍵盤輸入會丟玩家按 WASD 沒反應這是我在一個項目里被反饋了三次的 bug。#fs-ui這層要有pointer-events: none只給按鈕開pointer-events: auto否則它會擋住 canvas 的鼠標事件全屏進去之后點哪兒都沒反應。加載條的改動要謹慎。Unity 的加載進度是掛在原始結(jié)構(gòu)上的直接刪掉#unity-loading-bar相關(guān)內(nèi)容會讓createUnityInstance的進度回調(diào)無處可寫。我的做法是保留結(jié)構(gòu)只調(diào)整樣式把加載條改成覆蓋在 canvas 上方居中的形式加載完成后由框架自己隱藏。3.3 樣式層撐滿、去滾動條、處理移動端視口高度樣式這塊有三類坑我按順序?qū)憽５谝活愂菨L動條。html, body上要同時設margin: 0; padding: 0; overflow: hidden;。只設overflow: hidden而不清margin頁面頂上會留 8 像素的白邊全屏之后白邊跟著進去看起來像畫面沒鋪滿。#unity-viewport上設position: fixed; inset: 0;比width: 100%; height: 100%更省心因為它不受父級定位影響。第二類是高度單位。移動端瀏覽器用100vh會有經(jīng)典的地址欄問題——地址欄收起時100vh比可視區(qū)小地址欄展開時又比可視區(qū)大表現(xiàn)為畫面下方被切掉一條或者出現(xiàn)一條空白。新一點的寫法是用100dvh動態(tài)視口高度能跟著地址欄變化。但dvh在部分老設備上不認識所以要寫成兜底疊加的形式#unity-viewport { position: fixed; inset: 0; height: 100vh; height: 100dvh; overflow: hidden; background: #1a1a1a; }后一行覆蓋前一行認識的用dvh不認識的自動退回vh。這是我用了兩年最穩(wěn)的寫法。第三類是 canvas 的顯示尺寸#unity-container { position: absolute; inset: 0; display: flex; align-items: center; justify-content: center; } #unity-canvas { display: block; width: 100%; height: 100%; outline: none; background: #000; }display: block是為了干掉行內(nèi)元素基線帶來的底部空隙outline: none是為了去掉聚焦時的虛線框——那個框在游戲里特別扎眼。容器用 flex 居中是為了后面做等比留黑邊的時候讓 canvas 縮小后仍然居中不用手算偏移。4. 實操一套可復用的全屏控制代碼4.1 JS 側(cè)封裝能力探測、進入、退出、狀態(tài)回調(diào)先給一個能直接用的封裝。幾個設計取舍我在注釋里寫了理由。(function () { const el document.getElementById(unity-viewport); const btn document.getElementById(fs-btn); function canNative() { return !!(document.fullscreenEnabled (el.requestFullscreen || el.webkitRequestFullscreen)); } function isNative() { return !!(document.fullscreenElement || document.webkitFullscreenElement); } function applyPseudo(on) { if (on) { el.classList.add(pseudo-fs); document.body.style.overflow hidden; } else { el.classList.remove(pseudo-fs); document.body.style.overflow ; } notify(on ? enter : exit, pseudo); } function notify(state, mode) { // Unity 側(cè)收到的結(jié)果一定要帶 mode不然分不清是真全屏還是降級 if (window.__unityInstance) { window.__unityInstance.SendMessage(WebBridge, OnFullscreenChanged, JSON.stringify({ state: state, mode: mode })); } } function enter() { if (!canNative()) { applyPseudo(true); return; } const p el.requestFullscreen ? el.requestFullscreen({ navigationUI: hide }) : el.webkitRequestFullscreen(); if (p p.catch) { p.catch(function () { applyPseudo(true); }); } } function exit() { if (isNative()) { const p document.exitFullscreen ? document.exitFullscreen() : document.webkitExitFullscreen(); if (p p.catch) { p.catch(function () {}); } } else { applyPseudo(false); } } function bind() { // 關(guān)鍵直接掛 DOM 點擊不要經(jīng)過 Unity 的輸入鏈路轉(zhuǎn)一圈再調(diào) btn.addEventListener(click, function () { if (isNative() || el.classList.contains(pseudo-fs)) { exit(); } else { enter(); } }); [fullscreenchange, webkitfullscreenchange].forEach(function (ev) { document.addEventListener(ev, function () { const on isNative(); btn.textContent on ? 退出全屏 : 全屏; notify(on ? enter : exit, native); // 布局穩(wěn)定后再觸發(fā)重算見 5.3 setTimeout(function () { window.dispatchEvent(new Event(resize)); if (window.__canvas) { window.__canvas.focus(); } }, 120); }); }); } window.__fsApi { enter: enter, exit: exit, toggle: function () { if (isNative() || el.classList.contains(pseudo-fs)) exit(); else enter(); } }; window.addEventListener(DOMContentLoaded, bind); if (document.readyState ! loading) bind(); })();這里最值得單獨拎出來講的是按鈕掛載的位置。很多教程給的方案是Unity 里做一個 UI 按鈕點擊后走 C# → jslib → 調(diào)requestFullscreen()。這條路在 Chromium 內(nèi)核上通常能跑通因為用戶激活狀態(tài)有大約五秒的有效期但在 WebKit 內(nèi)核上全屏調(diào)用必須嚴格發(fā)生在事件處理函數(shù)的調(diào)用棧里經(jīng)過 Unity 的輸入系統(tǒng)轉(zhuǎn)一圈之后激活狀態(tài)可能已經(jīng)被判定失效表現(xiàn)就是點了完全沒反應控制臺報一個 attempt to use fullscreen API failure。所以我的做法是把全屏按鈕做成 DOM 元素浮在 canvas 上面。這樣做還有個額外好處全屏按鈕在 Unity 加載完成之前就能用用戶不會遇到點了沒反應因為游戲還在加載的情況。代價是按鈕樣式要自己寫不能復用游戲內(nèi)的 UI 組件——但說實話一個全屏按鈕而已兩種狀態(tài)、一個圖標五分鐘的事。4.2 Unity 側(cè)C# 與 jslib 的橋接怎么寫才不翻車Unity 調(diào) JS 走 jslib文件放Assets/Plugins/WebGL/下擴展名是.jslib。內(nèi)容是標準的mergeInto結(jié)構(gòu)mergeInto(LibraryManager.library, { FS_Enter: function () { if (window.__fsApi) window.__fsApi.enter(); }, FS_Exit: function () { if (window.__fsApi) window.__fsApi.exit(); }, FS_Toggle: function () { if (window.__fsApi) window.__fsApi.toggle(); }, FS_IsActive: function () { var on !!(document.fullscreenElement || document.webkitFullscreenElement); var pseudo document.getElementById(unity-viewport); if (!on pseudo) on pseudo.classList.contains(pseudo-fs); return on ? 1 : 0; } });C# 這頭包一層重點是條件編譯不能少using System.Runtime.InteropServices; using UnityEngine; public static class FullscreenBridge { #if UNITY_WEBGL !UNITY_EDITOR [DllImport(__Internal)] private static extern void FS_Enter(); [DllImport(__Internal)] private static extern void FS_Exit(); [DllImport(__Internal)] private static extern void FS_Toggle(); [DllImport(__Internal)] private static extern int FS_IsActive(); #endif public static void Enter() { #if UNITY_WEBGL !UNITY_EDITOR FS_Enter(); #endif } public static void Exit() { #if UNITY_WEBGL !UNITY_EDITOR FS_Exit(); #endif } public static void Toggle() { #if UNITY_WEBGL !UNITY_EDITOR FS_Toggle(); #endif } public static bool IsActive { get { #if UNITY_WEBGL !UNITY_EDITOR return FS_IsActive() 1; #else return Screen.fullScreen; #endif } } }DllImport(__Internal)里的雙下劃線加 Internal 是固定寫法寫成別的名字在瀏覽器里會直接報找不到函數(shù)。另外編輯器下必須走#else分支否則 Play 模式一跑就拋異常一堆人第一次搭這套東西的時候就被這個卡住以為是 jslib 沒生效。回過頭來接收 JS 的回調(diào)需要一個掛在場景里的 GameObject名字要和 JS 里SendMessage的第一個參數(shù)完全一致。我一般叫它WebBridge掛在啟動場景最上面的一個空物體上里面就這么點東西using UnityEngine; using System; public class WebBridge : MonoBehaviour { public static event Actionbool, string OnFullscreenChanged; // 由 JS 調(diào)用參數(shù)是 JSON 字符串 public void OnFullscreenChanged(string json) { var state json.Contains(\enter\); var mode json.Contains(native) ? native : pseudo; OnFullscreenChanged?.Invoke(state, mode); } }解析 JSON 那里我用字符串包含判斷看起來很土。原因是這個回調(diào)調(diào)用頻率極低用戶點一次全屏才觸發(fā)一次引入一個 JSON 庫不值當而且 WebGL 下 IL2CPP 裁剪有可能把反射用到的字段裁掉我遇到過一次序列化出來全是默認值的情況從那以后這種極簡場景我就手寫了。4.3 狀態(tài)雙向同步別讓 UI 和真實狀態(tài)打架真全屏有個繞不過去的特性用戶按 Esc 就能退出你攔不住也不該攔。所以游戲里顯示全屏中實際早就退出來了這種狀態(tài)錯位只能靠事件監(jiān)聽解決靠按鈕點擊是解決不了的。我的同步規(guī)則是三條第一UI 狀態(tài)只由事件驅(qū)動不由按鈕點擊驅(qū)動。點了按鈕不改 UI等fullscreenchange回來再改。這樣用戶按 Esc 退出的時候UI 也會跟著變回全屏。第二Unity 側(cè)的響應要區(qū)分模式。真全屏和偽全屏在游戲內(nèi)的處理不一樣真全屏下瀏覽器 UI 消失可視區(qū)變大相機需要重新算比例偽全屏下視口尺寸其實沒變position: fixed的元素本來就是這個尺寸只是被提到了最上層相機不需要調(diào)整。如果不區(qū)分模式偽全屏下會出現(xiàn)畫面被二次拉伸的詭異效果。第三進入和退出都要能被打斷。全屏請求是異步的返回一個 Promise可能成功也可能失敗。失敗之后必須走降級而不是停在那里。我在enter()里掛的.catch就是干這個的。注意不要在fullscreenchange里立刻讀尺寸。這個事件觸發(fā)的時候布局往往還沒穩(wěn)定讀到的clientWidth可能是舊值重算出來的緩沖區(qū)尺寸就是錯的。加一個 100 到 150 毫秒的延遲或者用requestAnimationFrame套兩層實測都行。4.4 iframe 嵌入這兩個屬性少一個就白干交付給第三方嵌入的時候問題基本都出在 iframe 上。宿主頁面那邊iframe標簽必須同時帶上allowfullscreen和allowfullscreen。前一個是老式寫法后一個是新式的權(quán)限策略寫法兩個都寫是為了覆蓋不同版本的瀏覽器。只寫一個的話在某些組合下全屏請求會被靜默拒絕。嵌入方這邊你的index.html里沒法自己給自己授權(quán)。所以能力探測這一步特別重要document.fullscreenEnabled返回false的時候立刻走偽全屏別去嘗試真全屏。嘗試失敗的后果是用戶點了按鈕畫面完全沒變化連降級都不會觸發(fā)——因為 Promise 被拒絕了而你如果沒寫 catch那就什么都不會發(fā)生。還有一個更麻煩的情況如果宿主和 iframe 不同源你連fullscreenEnabled都可能讀不到真實值。這種場景我一般直接默認走偽全屏同時給宿主方提供一段說明告訴他們?nèi)绻嫒列枰?iframe 上加哪些屬性。把選擇權(quán)交出去比自己猜要靠譜。如果游戲里有需要鼠標鎖定的操作比如第一人稱視角requestPointerLock也有類似的權(quán)限要求iframe 上要額外加allowfullscreen; pointer-lock。這個細節(jié)我在一個項目里漏了導致嵌入版里視角拖不動查了兩天才發(fā)現(xiàn)問題在宿主頁面的 iframe 標簽上。5. 全屏之后才是真正的難點分辨率與畫面比例5.1 DPR 與渲染分辨率清晰度和顯存的拉扯進全屏之后畫面變糊八成是 DPR 的問題。window.devicePixelRatio在普通筆記本上一般是 1 或 1.25在高端顯示器上是 2在手機上普遍是 2 到 3。Unity 的 WebGL 框架會讀取這個值把 canvas 的緩沖區(qū)尺寸按 DPR 放大這樣在高分屏上畫面才清晰。問題在于這個放大是平方級的。假設你的可視區(qū)是 1920×1080DPR 是 2緩沖區(qū)就是 3840×2160像素數(shù)是原來的四倍。WebGL 的填充率、顯存占用、后期處理的采樣成本全部翻四倍。我一個項目在開發(fā)機上跑得挺流暢到了配置一般的機器上開了全屏直接掉到二十幀原因就是這個。我的處理原則是給 DPR 設一個上限并且允許玩家自己調(diào)。具體做法是在createUnityInstance之前先覆寫一次像素比(function () { const MAX_DPR 1.5; const raw window.devicePixelRatio || 1; const capped Math.min(raw, MAX_DPR); if (capped raw) return; Object.defineProperty(window, devicePixelRatio, { get: function () { return capped; }, configurable: true }); })();這段必須在 Unity 的加載腳本執(zhí)行之前跑放在index.html里加載腳本的上方就行。1.5 這個值是我反復試出來的折中從 1 提到 1.5清晰度提升肉眼可見從 1.5 提到 2多數(shù)場景下幾乎看不出差別但性能開銷是實打?qū)嵉?。另外提一句Application.targetFrameRate在 WebGL 里是生效的設成 60 配合瀏覽器的刷新節(jié)奏比較穩(wěn)。但要注意標簽頁切到后臺時瀏覽器會主動降頻這時候測出來的幀率沒有參考價值測性能必須保證標簽頁在前臺。5.2 寬高比變化拉伸、裁切還是留黑邊從普通頁面進全屏可視區(qū)的寬高比一定變了。原來是瀏覽器里嵌著一塊 16:9 的區(qū)域全屏之后可能變成 16:10 甚至 21:9。這時候畫面怎么處理只有三個選項。拉伸鋪滿canvas 直接 100% 撐滿不改相機。畫面會被橫向或縱向拉伸圓形變橢圓角色變胖變瘦。除非你的游戲是純 2D 抽象的否則別選這個。留黑邊canvas 保持原始比例居中顯示兩邊或上下留黑。做法是在容器的 flex 布局基礎上給 canvas 設aspect-ratio: 16 / 9;同時max-width: 100%; max-height: 100%;。這是最省事、最不破壞畫面構(gòu)圖的方式代價是浪費一部分屏幕面積。動態(tài)適配canvas 撐滿然后 Unity 側(cè)根據(jù)新的寬高比調(diào)整相機。正交相機調(diào)orthographicSize透視相機調(diào)fieldOfView或者用Camera.rect做視野擴展。這種方式觀感最好但要處理多出來的視野里露出場景邊界的問題——我們的做法是在場景四周預留一圈裝飾性元素視野擴大時露出來也不突兀。實際項目里我用得最多的是留黑邊 關(guān)鍵 UI 動態(tài)適配的組合。渲染層保持嚴格的比例保證畫面不變形UI 層用CanvasScaler的Match Width Or Height模式match值設成 0.5讓 UI 在寬高比變化時做等比縮放兩邊的錨點該貼邊的貼邊。這樣一個 16:9 的工程在 21:9 的屏幕上畫面居中留黑邊UI 該在右上角的還在右上角不會跑到屏幕外面去。5.3 重算尺寸的時機與順序順序錯了白算全屏切換之后尺寸重算涉及三個動作順序有講究第一等 CSS 布局落地。全屏切換會引起容器尺寸變化瀏覽器需要一幀來重新布局。這就是為什么fullscreenchange里不能立刻讀尺寸。第二讓 canvas 的 CSS 尺寸先正確?？蚣茏x的是clientWidth/clientHeight這兩個值由 CSS 決定必須先對。第三觸發(fā)重算。多數(shù)版本的做法是派發(fā)一個窗口resize事件讓 Unity 的框架按它自己的邏輯去更新緩沖區(qū)。我實測下來的寫法是function refreshCanvas() { requestAnimationFrame(function () { requestAnimationFrame(function () { window.dispatchEvent(new Event(resize)); }); }); }雙requestAnimationFrame是為了保證布局一定已經(jīng)完成。用setTimeout100 毫秒也行但rAF更精確而且不會在后臺標簽頁里亂跑。如果你的版本框架重算不靈還有一個兜底方案手動改canvas.width/canvas.height然后等下一次框架自己校準。但我不推薦長期用這個因為手動改和框架內(nèi)部的尺寸記錄會打架容易出現(xiàn)改完一幀之后又被改回去的現(xiàn)象表現(xiàn)是畫面抖一下。還有一點重算之后要主動把焦點還給 canvas。前面提過tabindex-1的用法配合canvas.focus()一起用。不做這一步的用戶體驗是全屏之后打字打不了、按方向鍵頁面在滾動尤其在有聊天框或者輸入功能的項目里必現(xiàn)。6. 踩坑記錄與排查手冊6.1 高頻問題速查表下面這張表是我這幾年攢下來的遇到現(xiàn)象先查這張表能覆蓋八成情況?，F(xiàn)象最可能的原因處理方式點按鈕完全無反應調(diào)用不在用戶手勢的調(diào)用棧里或 iframe 缺全屏權(quán)限按鈕掛 DOM 層直接監(jiān)聽檢查allowfullscreen與allow全屏后畫面模糊DPR 過高或 canvas 緩沖區(qū)未重算限制 DPR 上限全屏后延遲派發(fā)resize全屏后畫面拉伸變形canvas 撐滿但相機未適配用aspect-ratio留黑邊或按寬高比重算相機按 Esc 退出后 UI 狀態(tài)錯亂UI 只由點擊事件驅(qū)動沒監(jiān)聽fullscreenchange改為事件驅(qū)動點擊后不改狀態(tài)全屏后鼠標點擊位置偏移canvas 上有 padding、border 或transform: scale去掉所有影響clientRect的樣式全屏后鍵盤輸入失效焦點沒回到 canvascanvas.focus()并加tabindex-1頁面底部有一條空白用了100vh但移動端地址欄變化改用100dvh并保留vh兜底全屏按鈕被畫面擋住UI 層層級或pointer-events設置錯誤覆蓋層pointer-events: none按鈕單獨開auto全屏進入后立刻自動退出同時調(diào)了兩次進入/退出或和頁面其他全屏邏輯沖突調(diào)用前先查fullscreenElement判斷當前狀態(tài)移動端全屏后無法橫屏屏幕方向鎖定未申請或不被支持先進入全屏再調(diào)screen.orientation.lock失敗則改用 UI 提示6.2 幾個不好查的疑難 case說三個我印象最深的。第一個是全屏后鼠標點不準。表現(xiàn)是角色能跑但點擊 UI 按鈕的位置偏了大概二十來個像素。查了半天發(fā)現(xiàn)是覆蓋層的按鈕用了padding而 Unity 計算鼠標位置的時候用的是 canvas 的包圍盒兩者坐標系看似一樣實際因為覆蓋層居中對齊多算了偏移。最后的解決方式是給 canvas 加一個明確的getBoundingClientRect打印在瀏覽器里對一遍一眼就看出來 canvas 的實際位置比視覺位置高了一截。這種問題的排查思路是不要猜把getBoundingClientRect()的四個值打出來和視覺位置對比。第二個是偽全屏下畫面被放大了一倍。原因是偽全屏的 CSS 里寫了transform: scale(1)之類的變換而 Unity 框架在算緩沖區(qū)尺寸的時候用的是offsetWidthtransform不改變offsetWidth但它會改變視覺呈現(xiàn)。視覺上放大了緩沖區(qū)沒跟上于是糊。教訓是布局不要用transform要用尺寸本身去控制。第三個是退出全屏后黑屏一瞬。原因是退出全屏時容器尺寸從大變小框架重算緩沖區(qū)還沒完成瀏覽器已經(jīng)用舊的緩沖區(qū)做了拉伸顯示。視覺上就是一閃。處理方式是在容器上加一個短暫的背景色過渡或者干脆接受這一幀——如果追求極致可以在退出前先把 canvas 縮放到目標尺寸再退出全屏但這樣代碼復雜度會上去不少。6.3 我總結(jié)的幾條硬規(guī)矩最后這幾條是長期踩坑總結(jié)出來的寫在這里當備忘。全屏按鈕永遠是 DOM 元素不做成 Unity 內(nèi) UI。這條前面說過再強調(diào)一次因為它能一次性解決點了沒反應和加載期間不能用兩個問題。能力探測在調(diào)用那一刻做不在加載時緩存。iframe 的權(quán)限、用戶手勢狀態(tài)、瀏覽器策略這些都可能在運行期間變化。緩存一個布爾值看起來省事實際會埋雷。狀態(tài)只認事件不認操作。UI 顯示什么完全由fullscreenchange決定。用戶按 Esc 退出這件事你管不了能管的只有自己的狀態(tài)。降級路徑必須是默認路徑的一部分不是異常處理。我在enter()里把降級寫在.catch里但更重要的是canNative()返回false的時候直接走偽全屏那條分支。這兩條路在我這里地位是對等的。尺寸重算永遠延遲一幀。任何一個進入/退出全屏之后立即讀尺寸的寫法都有概率讀到舊值。加rAF不加成本不加就是玄學 bug。別在 iframe 里賭權(quán)限。拿不到fullscreenEnabled的時候直接告訴嵌入方需要加什么屬性比自己嘗試要快。這套代碼現(xiàn)在是我們幾個 WebGL 項目的標準模板新建工程直接拷過去改一下按鈕位置和配色就能用。中間那層混合方案的設計其實是被逼出來的——剛開始只想做真全屏結(jié)果第一個交付的客戶就用 iPad 驗收當場翻車回來才把偽全屏補上?，F(xiàn)在回頭看早一點接受全屏不是一個按鈕的事而是一套狀態(tài)機能省下的時間遠超寫這套代碼的時間。