簡(jiǎn)介這份資料針對(duì)iOS系統(tǒng)及微信內(nèi)置瀏覽器中audio標(biāo)簽無法自動(dòng)播放的常見痛點(diǎn)專門面向移動(dòng)端H5開發(fā)人員。內(nèi)容從蘋果設(shè)備對(duì)音頻播放的用戶交互限制出發(fā)梳理了微信內(nèi)核下的兼容策略給出隱藏audio元素、按鈕控制播放、JavaScript事件監(jiān)聽、預(yù)加載以及WeixinJSBridgeReady等適配手段并配有可直接參考的CSS、HTML和jQuery代碼片段適合正在處理背景音樂自動(dòng)播放問題的初中級(jí)前端開發(fā)者查閱。文件為單個(gè)PDF文檔體積僅61KB便于快速下載與離線閱讀不占用存儲(chǔ)空間。資源已有4366人學(xué)習(xí)使用問題場(chǎng)景典型、方案經(jīng)實(shí)踐驗(yàn)證閱讀后能獲得一套完整的排查思路和可落地的代碼改法減少反復(fù)試錯(cuò)成本。1. 微信H5背景音樂不響一場(chǎng)由 audio autoplay 引發(fā)的排查給移動(dòng)端H5頁面配一段背景音樂是營(yíng)銷頁、活動(dòng)頁和小游戲開場(chǎng)最常見的需求之一。之前習(xí)慣性地在audio標(biāo)簽上直接寫autoplay屬性Android 上一向正常但 iPhone 微信里打開頁面靜悄悄按鈕和動(dòng)畫都在就是沒有聲音。反復(fù)確認(rèn)后發(fā)現(xiàn)這不是代碼寫錯(cuò)了而是 iOS Safari 和微信 WebView 對(duì) audio 自動(dòng)播放有明確限制——媒體播放必須由用戶交互事件觸發(fā)native 的autoplay屬性在 iOS 上基本是個(gè)擺設(shè)。這篇文章從觸發(fā)策略、兼容事件、代碼實(shí)現(xiàn)到降級(jí)方案把整個(gè)處理過程拆開講一遍適合正在做移動(dòng)端H5、微信內(nèi)嵌頁面、小程序 web-view 以及遇到“iOS 上 audio 突然不自動(dòng)播放”的開發(fā)人員。2. 為什么 iOS Safari 和微信 WebView 會(huì)掐斷 audio 自動(dòng)播放先說結(jié)論這是 WebKit 媒體策略的一部分不是微信獨(dú)創(chuàng)的限制。iOS Safari 要求媒體播放必須有用戶手勢(shì)參與audio 元素的 src 加載完成后調(diào)用play()但如果調(diào)用棧里沒有用戶事件播放就會(huì)失敗。Safari 11 以后網(wǎng)頁在無手勢(shì)上下文時(shí)調(diào)用play()返回的是一個(gè) rejected Promise錯(cuò)誤類型通常是NotAllowedError。想通過muted屬性繞過iOS Safari 對(duì)音頻的 muted autoplay 支持也很有限大部分版本上仍然需要用戶手勢(shì)。2.1 自動(dòng)播放策略背后的產(chǎn)品邏輯底層原因是電量和用戶體驗(yàn)的雙重考慮。移動(dòng)網(wǎng)絡(luò)大多按流量計(jì)費(fèi)頁面一打開就出聲對(duì)用戶是打擾同時(shí)音頻解碼和揚(yáng)聲器喚醒會(huì)額外耗電。所以蘋果從 iOS 4 開始收緊自動(dòng)播放后續(xù)版本逐步把“允許 audio 自動(dòng)播放”的能力完全移除。對(duì)開發(fā)者來說理解“這是策略而非故障”很重要——不要嘗試改配置去 hack 內(nèi)核順著策略走才是穩(wěn)定方案。Android 這邊的情況不一樣。Chrome 允許在 muted 狀態(tài)下自動(dòng)播放或者用戶對(duì)某個(gè)站點(diǎn)有較高活躍度信號(hào)時(shí)放寬限制。微信 Android 端基于 Chromium 內(nèi)核所以同一份代碼在 Android 微信里能自動(dòng)播放在 iPhone 微信里不行這是兩個(gè)平臺(tái)媒體策略差異的直接體現(xiàn)。2.2 手勢(shì)上下文與 Promise 拒絕play()是否能成功取決于它被調(diào)用的時(shí)機(jī)和執(zhí)行上下文。在click、touchstart這類用戶事件的處理函數(shù)里直接調(diào)用Safari 會(huì)認(rèn)為這是一次合法播放但如果用setTimeout把調(diào)用延后到事件處理?xiàng)Ｖ馐謩?shì)上下文就丟了播放請(qǐng)求照樣被拒。這個(gè)細(xì)節(jié)解釋了為什么很多人把a(bǔ)udio.play()放在$(document).ready()里沒有效果——ready回調(diào)本身就是資源加載完成后的異步事件不在任何手勢(shì)上下文里。處理這類問題前先確認(rèn)運(yùn)行環(huán)境。UA 檢測(cè)是所有后續(xù)兼容方案的基礎(chǔ)常見做法是同時(shí)判斷 iOS 和微信function detectEnv() { var ua navigator.userAgent.toLowerCase(); var isIOS /\(i[^;];( u;)? cpu.? mac os x/i.test(ua); var isWeChat /micromessenger/i.test(ua); return { isIOS: isIOS, isWeChat: isWeChat }; }這段代碼的核心是兩個(gè)正則mac os x匹配 iPhone/iPad 的 UA 特征micromessenger匹配微信內(nèi)置瀏覽器標(biāo)識(shí)。返回對(duì)象里的isIOS和isWeChat可以組合出四種環(huán)境后面做兼容分支時(shí)會(huì)反復(fù)用到。注意 UA 匹配結(jié)果只代表當(dāng)前頁面的宿主環(huán)境不代表版本能力更精確的能力探測(cè)要靠特性檢測(cè)比如判斷window.WeixinJSBridge是否存在。2.3 微信 WebView 在 WebKit 之上又加了一層微信 iOS 端的內(nèi)置瀏覽器與 Safari 同屬 WebKit 內(nèi)核體系Safari 的自動(dòng)播放限制在微信里一條不少地繼承下來。但微信額外引入了自己的 JS 通道頁面加載過程中微信原生層會(huì)向 WebView 注入一系列方法注入完成后觸發(fā)WeixinJSBridgeReady事件。這個(gè)事件對(duì)自動(dòng)播放來說是一個(gè)關(guān)鍵的時(shí)間窗只要在這個(gè)事件回調(diào)里調(diào)用play()微信就會(huì)放行。不過要分清WeixinJSBridgeReady和微信 JS-SDK 的wx.ready。前者是微信注入橋接對(duì)象的標(biāo)志音頻視頻自動(dòng)播放主要靠它后者是 JS-SDK 接口鑒權(quán)完成后的回調(diào)負(fù)責(zé)的是分享、支付這類能力不能拿它觸發(fā)播放。很多老代碼把wx.ready當(dāng)作播放時(shí)機(jī)結(jié)果 iOS 微信里仍然無聲就是因?yàn)榘褍蓚€(gè)事件搞混了。3. 一套能用的 audio 播放器隱藏元素、按鈕開關(guān)、預(yù)加載定位到問題原因后下一步是把代碼從“直接 autoplay”改造成“用戶可見的播放器控件”。下面是完整實(shí)現(xiàn)CSS、HTML、JavaScript 三部分分別說明。這個(gè)結(jié)構(gòu)也是網(wǎng)上各類移動(dòng)端 H5 背景音樂的常見模板核心思路是隱藏原生控件、保留觸發(fā)按鈕、狀態(tài)機(jī)切換播放與暫停。3.1 隱藏 audio 元素時(shí)不要用 display:none原生 audio 標(biāo)簽自帶控制條但在 H5 頁面里通常需要自定義音樂按鈕所以要把 audio 藏起來。隱藏方式有講究我一般會(huì)用visibility: hidden配合opacity: 0再通過絕對(duì)定位把它固定在頁面非交互區(qū)域而不是直接display: none.audio { position: absolute; z-index: 10; visibility: hidden; opacity: 0; left: 0; top: 0; width: 100px; height: 30px; }這里有三個(gè)關(guān)鍵點(diǎn)position: absolute讓音樂元素脫離文檔流不擠占其他內(nèi)容visibility: hidden隱藏元素但保留它在渲染樹中的位置opacity: 0把透明度降為零雙保險(xiǎn)。不用display: none的原因是個(gè)別老舊 WebView 對(duì)display: none的媒體元素不會(huì)正常觸發(fā)資源預(yù)加載等用戶點(diǎn)擊播放時(shí)會(huì)感到明顯的加載延遲。下面是對(duì)比隱藏方式布局影響媒體預(yù)加載點(diǎn)擊區(qū)域適用場(chǎng)景display: none無部分舊內(nèi)核不預(yù)加載無不推薦除非后續(xù)動(dòng)態(tài)設(shè)置 srcvisibility: hiddenopacity: 0保留占位正?？牲c(diǎn)擊但看不到本文推薦的主方案left: -9999px移出視口無正常元素在屏外需要保留可點(diǎn)擊按鈕時(shí)表格里的三種方案我都實(shí)際驗(yàn)證過最推薦的是第二種加第三種組合用position: absolute把 audio 定位到屏幕外同時(shí)保持其可用狀態(tài)避免誤觸又保證加載。3.2 播放器結(jié)構(gòu)與標(biāo)簽屬性播放器主體是兩個(gè)塊按鈕層和 audio 層。按鈕負(fù)責(zé)展示狀態(tài)audio 負(fù)責(zé)真正的聲音輸出div classpause a classon href# relexternal nofollow/a span開啟/span /div div classaudio audio srcyour-music.mp3 controlscontrols preloadauto idaudio loop/audio /divaudio 標(biāo)簽里的每個(gè)屬性都有作用controlscontrols在調(diào)試階段保留原生控制條方便真機(jī)驗(yàn)證音頻是否能播放正式上線可以去掉preloadauto指示瀏覽器在頁面加載時(shí)盡可能預(yù)加載音頻數(shù)據(jù)這樣用戶點(diǎn)擊播放時(shí)能立即出聲代價(jià)是消耗一定流量loop讓背景音樂循環(huán)播放idaudio是后面 JavaScript 操作的入口。注意autoplayautoplay在這個(gè)場(chǎng)景里已經(jīng)沒用了保留它只是兼容舊邏輯實(shí)際播放由 JS 控制。配套的按鈕樣式和旋轉(zhuǎn)動(dòng)畫是原項(xiàng)目里的核心是給播放中狀態(tài)加一個(gè)無限旋轉(zhuǎn)的 keyframes 動(dòng)畫.pause { position: absolute; z-index: 10000; bottom: 10px; right: 10px; } .pause a { width: 30px; height: 30px; background: url(http://mat1.gtimg.com/zj/maxbao/reai/imgs/units-icons.png) 0 0 no-repeat; display: block; background-size: 90px auto; } .pause a.on { -webkit-animation: reverseRotataZ 1.2s linear infinite; } .pause span { color: #fff; font-size: 16px; position: absolute; left: -40px; top: 5px; opacity: 0; -webkit-transform: translateX(-20px); -webkit-transition: all .2s linear; } .pause span.z-show { opacity: 1; -webkit-transform: translateX(0px); } keyframes reverseRotataZ { 0% { transform: rotateZ(0deg); } 100% { transform: rotateZ(-360deg); } }keyframes reverseRotataZ做的是 0 度到負(fù) 360 度的旋轉(zhuǎn)動(dòng)畫效果是按鈕不停逆時(shí)針轉(zhuǎn)動(dòng)視覺上代表“音樂正在播放”。z-show類控制提示文字的淡入滑動(dòng)用opacity和transform變化實(shí)現(xiàn)避免直接用display切換導(dǎo)致跳閃。3.3 點(diǎn)擊控制邏輯與狀態(tài)機(jī)按鈕的狀態(tài)機(jī)是播放器的核心邏輯on代表播放中點(diǎn)擊后暫停并切到offoff代表暫停點(diǎn)擊后播放并切回on。用 jQuery 寫的話是這個(gè)樣子$(document).ready(function () { var audio document.getElementById(audio); var musicControl function (obj) { var className $.trim(obj.attr(class)); if (className on) { audio.pause(); obj.removeClass(on).addClass(off); obj.siblings(span).text(關(guān)閉); $(.pause span).addClass(z-show); setTimeout(function () { $(.pause span).removeClass(z-show); }, 500); } else if (className off) { audio.play(); obj.removeClass(off).addClass(on); obj.siblings(span).text(開啟); $(.pause span).addClass(z-show); setTimeout(function () { $(.pause span).removeClass(z-show); }, 500); } return false; }; $(.pause a).click(function (e) { e.preventDefault(); musicControl($(this)); }); });musicControl通過讀取按鈕當(dāng)前的 class 判斷狀態(tài)這比額外存一個(gè)全局布爾變量更直觀。setTimeout里的 500 毫秒是提示文字的展示時(shí)長(zhǎng)配合 CSS 的transition做淡出效果。e.preventDefault()阻止a標(biāo)簽的默認(rèn)跳轉(zhuǎn)行為。這里還有個(gè)容易踩的坑直接audio.play()在click回調(diào)里沒問題但如果在同一回調(diào)里繼續(xù)調(diào)用fetch等異步操作后再play()手勢(shì)上下文在某些瀏覽器里會(huì)失效所以播放調(diào)用要盡量放在事件處理的同步代碼里。3.4 首次觸摸兜底與預(yù)加載時(shí)機(jī)代碼最后有一段兜底邏輯確保用戶第一次觸摸屏幕時(shí)音樂能順勢(shì)播放audio.play(); $(document).one(touchstart, function () { audio.play(); });這段代碼片段寫在$(document).ready里第一行audio.play()覆蓋的是 Android 上還能自動(dòng)播放的場(chǎng)景$(document).one(touchstart, ...)監(jiān)聽整個(gè)文檔的首次觸摸用戶手指碰到屏幕的瞬間微信和 Safari 都會(huì)把這個(gè)觸摸當(dāng)作合法手勢(shì)此時(shí)再調(diào)用play()大概率能成功。one()是 jQuery 的方法綁定一次后自動(dòng)解綁避免后續(xù)每次觸摸都觸發(fā)播放動(dòng)作。注意touchstart的觸發(fā)時(shí)機(jī)比click早所以響應(yīng)更快但在部分 Android WebView 里touchstart可能被業(yè)務(wù)代碼preventDefault所以最穩(wěn)妥的寫法是touchstart和click各綁定一次后面第 5 章會(huì)給完整函數(shù)。4. 微信的專屬通道WeixinJSBridgeReady 事件和全端兼容Safari 能自動(dòng)播放、微信里不行這是很多人排查時(shí)卡住的地方。區(qū)別在于微信給頁面注入 JS 通道的時(shí)機(jī)比較晚$(document).ready執(zhí)行時(shí)橋接對(duì)象可能還沒就緒audio.play()被 WebKit 策略攔下了。要解決它必須等微信主動(dòng)廣播“我準(zhǔn)備好了”的事件。4.1 先確認(rèn)代碼沒有寫錯(cuò)只靠audio.play()確實(shí)能解決 Safari 的自動(dòng)播放限制因?yàn)?Safari 對(duì)用戶手勢(shì)的判定是“最近一次交互后的一段時(shí)間內(nèi)”頁面加載后的第一次點(diǎn)擊就能觸發(fā)。但微信 iOS 里不行原因是微信在頁面加載完成后需要把原生的能力和 JS 上下文綁定這個(gè)綁定操作通過WeixinJSBridge完成綁定完成前調(diào)用play()微信沒有能力去響應(yīng)這個(gè)請(qǐng)求。解決順序應(yīng)該是先處理微信的橋接事件再處理 Safari 的手勢(shì)場(chǎng)景。4.2 引入微信 JS-SDK 并監(jiān)聽 WeixinJSBridgeReady在頁面里引入微信官方的 JS-SDK 文件然后監(jiān)聽WeixinJSBridgeReadyscript srchttps://res.wx.qq.com/open/js/jweixin-1.0.0.js/script script function onBridgeReady() { document.getElementById(audio).play(); document.getElementById(video).play(); } document.addEventListener(WeixinJSBridgeReady, onBridgeReady, false); /script這段代碼的邏輯是WeixinJSBridgeReady事件觸發(fā)時(shí)微信的 JS 通道已經(jīng)注入完成此時(shí)再調(diào)用play()才能獲得播放許可。audio和video可以同時(shí)在這處理視頻自動(dòng)播放的兼容邏輯和音頻一致。注意jweixin-1.0.0.js這個(gè)老版本文件仍然可用它主要是把微信的橋接能力通過標(biāo)準(zhǔn)事件暴露出來用https協(xié)議引入避免微信內(nèi)置瀏覽器攔截非安全域的混合內(nèi)容。這里有個(gè)兼容細(xì)節(jié)部分老版本微信不會(huì)觸發(fā)document上的WeixinJSBridgeReady事件而是掛在window上?？煽繉懛ㄐ枰瑫r(shí)兼容兩種訂閱方式if (window.WeixinJSBridge WeixinJSBridge.on) { WeixinJSBridge.on(onBridgeReady, onBridgeReady); } else { document.addEventListener(WeixinJSBridgeReady, onBridgeReady, false); }window.WeixinJSBridge存在且具有on方法就用微信的原生訂閱方式否則退回到標(biāo)準(zhǔn)事件監(jiān)聽。兩種方式都會(huì)調(diào)用同一個(gè)onBridgeReady回調(diào)不存在重復(fù)播放的問題因?yàn)閜lay()對(duì)同一媒體元素是冪等的。4.3 全終端自動(dòng)播放行為對(duì)照不同環(huán)境對(duì)自動(dòng)播放的處理差異明顯整理成一張表后面接需求時(shí)對(duì)著表選方案運(yùn)行環(huán)境autoplay 屬性是否需要手勢(shì)推薦觸發(fā)方式iOS Safari 11不生效是click/touchstart 內(nèi)同步調(diào)用play()微信 iOS (WKWebView)不生效是WeixinJSBridgeReady后調(diào)用touchstart 兜底Android Chrome / 微信 Androidmuted 下可生效視條件而定mutedplay()后恢復(fù)音量PC Chrome默認(rèn)不自動(dòng)播放視用戶活躍度而定首次點(diǎn)擊后觸發(fā)表格里最需要注意的是“微信 Android”和“微信 iOS”行為不一致。微信 Android 基于 Chromiummuted自動(dòng)播放具備一定可行性微信 iOS 嚴(yán)格走 WebKit 策略muted對(duì)音頻幾乎無效必須手勢(shì)。所以做全局兼容時(shí)不要只寫一套muted play()的方案那樣 iOS 會(huì)漏。4.4 video 自動(dòng)播放和內(nèi)聯(lián)播放是同一套規(guī)則視頻的自動(dòng)播放處理方式和 audio 相同但 iOS 上多一個(gè)playsinline的問題。在 iOS Safari 和微信里video 不設(shè)置playsinline時(shí)會(huì)強(qiáng)制進(jìn)入全屏播放這比“不自動(dòng)播放”更影響體驗(yàn)video idvideo srcvideo.mp4 autoplay loop muted playsinline webkit-playsinline/videoplaysinline是標(biāo)準(zhǔn)屬性webkit-playsinline是舊版本 Safari 需要的前綴。兩個(gè)都寫上老版本 iPhone 上才不會(huì)彈全屏。調(diào)試這類問題時(shí)在微信開發(fā)者工具里用真機(jī)調(diào)試比模擬器靠譜因?yàn)槟M器不完整復(fù)現(xiàn)微信的橋接行為和 WebKit 策略。另外如果頁面最終嵌在微信小程序 web-view 里自動(dòng)播放策略與微信內(nèi)置瀏覽器保持一致如果用 uniapp 開發(fā)video 組件的autoplay屬性在 iOS 上同樣受到手勢(shì)限制最好也走一遍WeixinJSBridgeReady的判斷邏輯。5. 別硬剛自動(dòng)播放用交互鏈和降級(jí)策略做體驗(yàn)兜底自動(dòng)播放不是非做不可很多場(chǎng)景下“用戶主動(dòng)開啟”反而是更好的交互。但有些業(yè)務(wù)方堅(jiān)持要自動(dòng)播放那就得把播放邏輯做成一條可靠的交互鏈先捕獲首次手勢(shì)再在安全窗口里調(diào)用play()。5.1 統(tǒng)一的 safePlay 封裝前面分散調(diào)的play()調(diào)用在真實(shí)項(xiàng)目里應(yīng)該收斂成一個(gè)公共函數(shù)統(tǒng)一處理 Promise 拒絕和瀏覽器兼容function safePlay(media) { if (!media) return; var p media.play(); if (p p.catch) { p.catch(function (err) { if (err.name NotAllowedError) { console.warn(play() blocked until user gesture); } }); } } function bindFirstGesture() { var onStart function () { safePlay(document.getElementById(audio)); }; document.addEventListener(touchstart, onStart, { passive: true }); document.addEventListener(click, onStart, { once: true }); } bindFirstGesture();safePlay做兩件事兼容不返回 Promise 的舊瀏覽器并吃掉NotAllowedError避免未捕獲的 Promise rejection 刷爆控制臺(tái)。bindFirstGesture在touchstart和click上都掛監(jiān)聽配合{ passive: true }不阻塞滾動(dòng){ once: true }自動(dòng)解綁。這個(gè)模式在微信 iOS 上能把自動(dòng)播放成功率拉到接近百分之百。5.2 記住用戶選擇并恢復(fù)狀態(tài)音樂開關(guān)這種東西用戶上次關(guān)閉了下次進(jìn)入頁面就別再自動(dòng)播放。用 localStorage 記錄一次偏好比每次強(qiáng)制播放更符合移動(dòng)端習(xí)慣var AUDIO_FLAG h5_audio_enabled; function restoreAudio() { if (localStorage.getItem(AUDIO_FLAG) ! 0) { safePlay(document.getElementById(audio)); } } $(.pause a).click(function () { var isPlaying $(this).hasClass(on); localStorage.setItem(AUDIO_FLAG, isPlaying ? 1 : 0); });這里的判斷邏輯是默認(rèn)自動(dòng)播放但用戶手動(dòng)關(guān)閉過就記住。restoreAudio放在WeixinJSBridgeReady或首次手勢(shì)的后續(xù)流程里執(zhí)行。提示音頻視頻自動(dòng)播放的代價(jià)是流量和體驗(yàn)。一個(gè) mp3 動(dòng)輒幾百 KB視頻幾十 MB頁面加載完自動(dòng)播放等于直接消耗用戶流量。除非業(yè)務(wù)上確實(shí)需要否則把“是否播放”的決定權(quán)交給用戶點(diǎn)擊按鈕后播放是移動(dòng)端更穩(wěn)的交互。這段代碼配合前面的detectEnv和WeixinJSBridgeReady就構(gòu)成了一套完整的移動(dòng)端媒體播放兼容層后續(xù)所有 H5 頁面直接復(fù)用這幾段邏輯iOS 和微信端不會(huì)再在自動(dòng)播放這一步卡殼。本文還有配套的精品資源點(diǎn)擊獲取