修復客戶端瀏覽器上 Jitsi Meet 的 CPU 使用率過高問題。
透過檢查視訊圖塊、相機效果、瀏覽器圖形和主機設定來診斷 Jitsi Meet 瀏覽器 CPU 峰值並降低客戶端負載。
Element 在開啟狀態下可以正常接收訊息,但螢幕鎖定後卻無法收到通知。在沒有安裝 Google Play 服務的 Android 手機上,這通常指向的是訊息路徑的問題,而不是 Matrix 帳戶本身的問題。本指南的目標不僅僅是讓一條測試通知顯示出來。理想的結果應該是可重複的:即使 Element 在背景運行,手機處於閒置狀態,無需重新開啟應用,也能收到訊息。
本指南重點介紹目前適用於 Android 的 Element X 版本,Element 建議新使用者使用此版本。截至 2026 年 10 月 6 日,最新的公開 GitHub 版本為 Element X Android 26.09.4,近期版本皆包含 UnifiedPush 元件。 UnifiedPush 是一種開放協議,可讓 Android 應用程式透過 Google Firebase 雲端訊息傳遞 (FCM) 之外的其他分發器接收推播訊息。 Element 的專案指南指出,安裝 UnifiedPush 發行器後,Element X 即可偵測到它並將其作為推播提供者提供。請參閱Element X Android 程式碼庫、Element X Android 版本發布以及 Element 團隊關於無需 Google Play 服務即可接收通知的討論。
在更改設定之前,請先明確您想要達到的結果。當以下所有條件都滿足時,通知設定才算正常:
如果訊息僅在開啟 Element 後才顯示,表示同步已啟用,但後台推播不可靠。如果訊息在應用程式開啟時立即顯示,但在應用程式關閉後延遲顯示,則應專注於檢查推播分發器和 Android 後台限制,而不是房間通知規則。
大多數主流安卓應用程式都使用Google的推播服務 FCM 在有新資料可用時喚醒應用程式。 Element 的通知文件解釋說,FCM 需要Google Play 服務。在未安裝Google服務的手機上,僅使用 FCM 的配置無法提供正常的喚醒方式。安卓系統也限制了一般應用程式在背景可以執行的操作,尤其是當裝置處於空閒狀態時。
UnifiedPush 使用分發器取代了該依賴項。分發器是 Android 應用,它負責維護推播連線並將收到的通知傳遞給已註冊的應用程式。 UnifiedPush 專案列出了 ntfy、Sunup、NextPush、gCompat-UP 等選項。請參閱 UnifiedPush 官方分發器清單。
先從最簡單的故障點入手。在 Android 13 及更高版本中,應用程式需要POST_NOTIFICATIONS執行時間權限才能顯示正常通知。開啟 Android 設置,在「應用程式」下找到 Element X,並確認已允許通知。如果您的 Android 版本或製造商提供了通知類別,也請檢查各個通知類別的權限設定。
Android官方文件確認,在Android 13或更高版本上新安裝的應用,在用戶授予權限之前無法發送普通通知。請參閱Android通知權限文件。
品質檢查:如果 Android 顯示通知已停用,請先修復此問題並重新測試。如果已允許通知,但 Element 在背景執行時仍未收到任何通知,請繼續聯絡推播服務提供者。
從適合您裝置的來源安裝 UnifiedPush 分送器。 ntfy 是一個常見的選擇,因為它可以使用其公共伺服器或自架伺服器。 ntfy 的 UnifiedPush 快速入門指南會引導使用者安裝 ntfy,授予所需的通知和電池權限,然後在相容的應用程式中選擇 ntfy 作為分發器。請參閱ntfy 官方 UnifiedPush 快速入門指南。
開啟 ntfy 並確保已啟用 UnifiedPush 支援。如果您使用自架的 ntfy 伺服器,請驗證 Android 應用程式是否已連接至該伺服器,以及手機目前網路是否可透過 HTTPS 存取該伺服器。
品質檢查:僅僅安裝 ntfy 是不夠的。分發器必須啟用且可存取。如果 Element 在安裝後無法找到分發器,請完全關閉並重新開啟 Element X,然後在變更伺服器端矩陣設定之前檢查應用程式更新。
開啟 Element X 設定並進入通知區域。當偵測到相容的分發器時,Element X 會顯示推送提供者選項。選擇已安裝的 UnifiedPush 分送器,而不是 Firebase/FCM。 Element 的專案維護者已明確描述了針對未使用 Google 服務的裝置的此流程,並且目前原始程式碼中包含一個 UnifiedPush 推送提供者模組。
如果在安裝分發器後,您的版本仍然不會顯示提供者選擇器,請不要斷定主伺服器發生故障。首先,請將 Element X 更新到目前支援的版本,然後重新啟動 Element X 和分發器。 Element X 不同版本之間的 UI 標籤有所更改,因此選單名稱可能略有不同。
品質檢查:有效的判斷標準不僅僅是顯示提供者名稱。在 Element 背景執行時,使用另一個 Matrix 帳號傳送一條真實訊息。如果提供者正常運作,應該能夠喚醒 Element 並顯示訊息通知,而無需手動開啟應用程式。
UnifiedPush 依賴於分送器保持可連線狀態。如果 Android 將 ntfy 或其他分發器置於受限電池狀態,則推送連線可能會中斷。 Android 文件中記錄了許多裝置上的三種主要後台電池模式:非受限、最佳化和受限。受限模式可能會阻止應用程式依賴的任務、鬧鐘和前台服務行為。
打開 Android 設置,找到分銷商,並將電池使用模式從“受限”更改為“不受限”,以防通知在閒置期間延遲或消失。您也可以檢查 Element X 本身,確保它沒有被明確限制。廠商客製化的 Android 版本可能會新增單獨的控制選項,用於設定自動啟動、背景資料或套用休眠。
谷歌的 Android 文件指出,使用者選擇的「受限」狀態可以完全阻止應用程式在某些裝置上於背景運行。請參閱Android 背景優化指南。
品質檢查:鎖定手機並閒置 10 到 20 分鐘,然後使用另一個帳戶發送幾個訊息。如果提醒能夠及時且穩定地到達,則後台運行狀況比在打開應用後立即進行的測試更佳。
| 觀察到的結果 | 最可能區域 | 下一步行動 |
|---|---|---|
| 即使 Element 打開,也不會收到任何通知。 | 房間規則、帳戶通知設定或 Android 通知權限 | 請先檢查 Element 的房間/帳號通知設定和 Android 權限。 |
| 通知僅在 Element 開啟時顯示。 | 推送提供者或分銷商背景連接 | 確認 Element 正在使用 UnifiedPush,並從經銷商移除電池限制。 |
| 能工作幾分鐘,然後閒置一段時間後就停止工作了。 | Doze、OEM 電池控制、睡眠應用程式策略 | 將分發器設定為“不受限制”,並檢查製造商特定的背景控制。 |
| Element 顯示了經銷商,但沒有收到任何實際訊息。 | 分髮伺服器、Matrix推送閘道或端點速率限制 | 在重新安裝 Element 之前,請先測試不同的分發器/伺服器。 |
| 只有一個房間是寂靜的。 | 房間特定通知規則 | 檢查該房間的通知層級,而不是更改全域推送設定。 |
配置在技術上可能正確,但仍然可能不適用。 Element 的問題追蹤器記錄了一些案例,其中某些 UnifiedPush 端點(包括某些 Matrix 場景中的公共 ntfy 基礎設施)可能存在速率限制,這意味著註冊可能看起來正確,但通知仍然無法送達。請參閱 Element 關於UnifiedPush 端點速率限制的問題。
如果權限、提供者選擇和電池設定都正確,但推播仍然不穩定,請嘗試使用不同的 UnifiedPush 發行器或自架推播伺服器。 UnifiedPush 文件中同時介紹了託管和自託管兩種方案。這通常比重複清除 Element 資料更有效的診斷方法,因為它會改變推送鏈中最可能故障的環節。
自託管可以提供更多控制權,但也增加了維運責任。對於 ntfy 來說,必須正確設定 Matrix 閘道才能進行自架部署。 UnifiedPush 的 ntfy 官方指南中也提到了這項要求。不要僅僅因為一次測試通知延遲就切換到自託管;只有在故障可以重複出現,並且您已經排除了 Android 系統限制的情況下,才應該進行切換。
上一代 Element Android 應用程式也實作了非 FCM 操作和 UnifiedPush。其官方文件描述了 F-Droid 後台輪詢和 UnifiedPush 支援。然而,Element 現在建議新用戶使用 Element X,因此除非您有特定的相容性要求,否則目前的 Element X 是更好的起點。舊版實作細節仍然有助於理解為什麼在 Android 空閒模式下僅靠輪詢不太可靠。請參閱Element Android 中 UnifiedPush的存檔/目前專案文件。
沒有一種通用的設定能夠保證在所有 Android 版本上都能即時送達。設備廠商可能會施加額外的後台限制,網路可能會幹擾持續連接,推播端點也可能暫時不可用或受到速率限制。因此,最可靠的結果是在多次後台和空閒狀態下測試中都能重複出現相同的行為,而不是僅僅一次成功的通知。
透過檢查視訊圖塊、相機效果、瀏覽器圖形和主機設定來診斷 Jitsi Meet 瀏覽器 CPU 峰值並降低客戶端負載。
使用 Jitsi Videobridge 內建的 Prometheus 端點追蹤其運作狀況、會議負載和流量,然後在 Grafana 中探索和繪製資料圖表。
為 Jitsi Meet Docker 配置自訂網域,包括 DNS、PUBLIC_URL、HTTPS、Let's Encrypt、防火牆連接埠、NAT 設定和端對端驗證。
透過檢查正確的 URL 和連接埠、代理程式路由、服務狀態、已部署的憑證和日誌,修復 SSL 續訂後 Zimbra 管理控制台的 404 錯誤。
透過檢查活動的 PHP SAPI、大小限制、註解和重新驗證設置,了解如何診斷和修復 Nextcloud 的 PHP OPcache 配置警告。
透過檢查備份、伺服器版本、SQL 模式、字元集、模式狀態和日誌,追蹤 MySQL 或 MariaDB 升級後 Kopano 資料庫遷移失敗的問題。
透過安全傳輸、使用者和群組篩選器、登入屬性以及經過測試的部署,將 Nextcloud 連接到 LDAP 或 Active Directory。
透過設定 UnifiedPush、Android 權限、電池設定和可靠的驗證測試,修復已移除 Google 的手機上的 Element Android 通知問題。
使用官方的 occ 指令清除 Nextcloud 的資料庫索引缺少警告。請先備份,預覽更改,執行修復,然後驗證結果。
透過將 OIDC 連接到 Synapse、設定確切的回呼 URL、映射使用者聲明和測試登出來設定 Element Web 的 Keycloak SSO。