Chrome扩展的核心：manifest 文件（中）
大家好，我是 dom 哥。我正在寫關于 Chrome 擴展開發的系列文章，感興趣的可以 點個小星星 。
在上一篇中已經完成了 Chrome 擴展的雛形，本篇接著介紹 manifest 中的可選字段，完善擴展的細節。
manifest 中的可選字段
"content_scripts"
向 web 頁面注入 JavaScript 和 CSS。可以說這是 Chrome 擴展的靈魂。當指定 content_scripts 后，每當頁面加載時，content_scripts 也將隨之加載。
"content_scripts": [
{
"css": ["content-style.css"],
"js": ["content-script.js"],
"matches": ["<all_urls>"],
"run_at": "document_idle", // optional
"world": "ISOLATED" // optional
}
]
content_scripts 里的配置項解釋：
-
"css"：指定注入的 css 樣式文件 -
"js"：指定注入的 js 腳本文件
值得注意的是，css 和 js 指定的文件路徑必須是相對路徑！總是相對于擴展根目錄！
-
"matches"：用于指定往哪些頁面注入 css 和 js，必填項。其值并非普通的 url，而是滿足如下結構的匹配模式。
<scheme>://<host>/<path>-
scheme：指明協議格式，只能是以下幾種- http
- https
- 通配符
*, 表示 http 或 https - file
-
host：指明主機名。支持通配符*，但有限制，通配符*的屁股后面必須跟.或/！也就是只有以下兩種使用方式-
*.example.com匹配子域 -
*/匹配所有域
-
-
path：指明匹配的網址路徑。/*表示匹配所有路徑。
特殊 case：
"<all_urls>"匹配所有頁面！一般，額，簡單粗暴，就用這個??！ -
-
"run_at"：腳本注入時機。默認情況下，擴展會在頁面處于空閑狀態時注入 css 和 js。有以下3個時機可供選擇：-
document_start頁面 html 開始加載前就注入。此時 DOM 樹還未建立！ -
document_endwindow DOMContentLoaded 事件觸發后注入。此時 DOM 樹已建立，但圖片，字體，腳本等資源尚未加載完畢。 -
document_idle當頁面空閑時注入。這也是默認的注入時機！瀏覽器會在document_end和window.onload觸發前這個時間段內選擇時機注入，具體注入時機取決于頁面的復雜程度。
下面這張圖片可以直觀的看出注入時機和頁面加載狀態的先后時間順序。?? 紅色字是頁面內腳本打印，?? 綠色字是擴展 content-script 打印。
-
-
"world"：content-script 的腳本執行環境。默認情況下，content-script 運行在一個隔離的沙箱環境中。這意味著和頁面的運行時環境是隔離開來的兩個獨立環境，最明顯的表現就是兩個環境里的 全局變量window不通。該字段有以下2個選擇：-
ISOLATED隔離沙箱環境。這也是默認的 content-script 執行環境。 -
MAIN頁面運行時環境。這意味者擴展腳本和頁面腳本共享運行時，同一個 window，同一個世界，同一個夢想。
理解兩者的不同非常重要！假設頁面上的 js 給
window對象增加了一個customVariable全局變量，<head> <script> window.customVariable = "window.customVariable" </script> </head>下面是擴展的 content-script 在
ISOLATED和MAIN兩個不同的環境中打印window.customVariable變量的結果：可以發現
ISOLATED隔離環境訪問不到window.customVariable，值是 undefined，而MAIN環境則能訪問到！我畫了一張圖，以便直觀的展示
ISOLATED和MAIN執行環境的區別 -
"background"
注冊一個 service worker 作為后臺服務。"content_scripts" 是頁面級別的腳本，運行于前臺頁面，隨頁面銷毀。"background" 是瀏覽器級別的服務，可以長期運行于后臺，但事情也并沒有那么簡單，Chrome 擴展的 service worker 會在需要時自動加載，在閑置時自動休眠。
作為后臺服務，service worker 的主要用途是注冊事件監聽，響應各種事件，比如網絡請求，content_scripts 傳來的 message 等等。Chrome 擴展提供了大量 chrome.* 接口可供使用，這些接口大多都能在 "background" 中使用，但 "content_scripts" 只能使用其中的少數，這是為安全起見故意設計的。
"background": {
"service_worker": "service-worker.js",
"type": "module"
}
不同于 "content_scripts" 可以用數組指定多個，"background" 只支持設置一個。
-
type：指明支不支持 ES Modules，只有module一個值，加上就支持 import，不加上就不支持！
配置完 "background" 后在擴展管理里更新擴展，就能看到注冊的 Service Worker 啦！
當 service worker 閑置時，它會自動休眠，顯示為無效。如下圖所示：
"permissions"
明確申明你的擴展需要用到哪些特殊的擴展 APIs，就像手機 App 詢問網絡權限，位置權限，照片權限等等。權限和 API 綁定，每個權限被授權后都將解鎖一批 API。有些權限只需要申明，瀏覽器就會授予權限，而有些權限還將展示警示彈窗需要用戶明確授權才行。
舉幾個例子：
-
"webRequest"，獲得訪問chrome.webRequestAPI，可以監控所有網絡流量。 -
"cookies"，獲得訪問chrome.cookiesAPI，可以操作網站 cookie -
"bookmarks"，獲得訪問chrome.bookmarksAPI，可以讀寫管理書簽 -
"desktopCapture"，獲得訪問chrome.desktopCaptureAPI，可以進行窗口或頁面的截圖 -
"downloads"，獲得訪問chrome.downloadsAPI，可以操作和管理瀏覽器下載
截至目前，crx-demo 項目的目錄結構如下：
crx-demo
├── background
│?? ├── service-worker.js
│?? └── sub.js
├── content-scripts
│?? ├── document_end.css
│?? ├── document_end.js
│?? ├── document_idle.css
│?? ├── document_idle.js
│?? ├── document_idle_main.js
│?? ├── document_start.css
│?? └── document_start.js
├── icon128.png
├── icon48.png
└── manifest.json
已經可以在 content-script 和 background 里任意編寫代碼來實現自己匪夷所思的奇思妙想啦！
crx-demo 項目已經放在 github 上啦，后續會繼續更新豐富細節。
本篇就介紹到這里，下篇接著將把剩余的 manifest 重要選項整理完。
覺得不錯可以 點個小星星 支持一下??
總結
以上是生活随笔為你收集整理的Chrome扩展的核心：manifest 文件（中）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 鸿海推出新时代自动驾驶轨迹预测深度学习模
- 下一篇： C++ Qt开发：ComboBox下拉组