Hablemos de los complementos de Chrome basados en los principios del navegador

Evolución de la arquitectura del navegador

Era del navegador de proceso único

Un navegador de proceso único significa que todos los módulos funcionales del navegador se ejecutan en el mismo proceso. Estos módulos incluyen la red, los complementos, el entorno de ejecución de JavaScript, el motor de renderizado y las páginas, etc. Antes de 2007, todos los navegadores del mercado eran de proceso único.

Arquitectura de navegador de proceso único

Muchos módulos funcionales se ejecutan en un proceso, lo cual es un factor importante que hace que los navegadores de proceso único sean inestables, fluidos e inseguros.

Inestable: los primeros navegadores requerían complementos para implementar varias funciones poderosas, como videos web y juegos web, sin embargo, los complementos son los módulos más propensos a tener problemas y también se ejecutan en el proceso del navegador, por lo que el accidente de un complemento. Una falla provocará que todo el navegador falle. Además de los complementos, el módulo del motor de renderizado también es inestable. Por lo general, algún código JavaScript complejo puede provocar que el módulo del motor de renderizado falle. Al igual que los complementos, una falla en el motor de renderizado puede causar que todo el navegador falle.
No es fluido: todos los módulos de representación de páginas, entornos de ejecución de JavaScript y complementos se ejecutan en el mismo hilo, lo que significa que solo se puede ejecutar un módulo al mismo tiempo. Si un script consume mucho tiempo, monopolizará todo el hilo, lo que provocará que otras páginas que se ejecutan en el hilo no tengan posibilidad de realizar tareas, lo que provocará que todo el navegador deje de responder y se retrase.
Inseguro: cuando ejecuta un complemento en una página, el complemento puede acceder a los recursos del sistema operativo. Si es un complemento malicioso, puede liberar virus y robar su cuenta y contraseña, causando problemas de seguridad.

Era del navegador multiproceso

arquitectura temprana

Arquitectura de proceso cuando se lanzó Chrome en 2008

Como puede verse en la figura, la arquitectura inicial dividió las capacidades del navegador en tres categorías principales: proceso del navegador, proceso de complemento y proceso de renderizado. Cada página se ejecuta en un proceso de representación separado, y los complementos de la página también se ejecutan en un proceso de complemento separado. Los procesos se comunican a través del mecanismo IPC. Esto resuelve varios problemas de los navegadores en la era del proceso único:

Resolviendo la inestabilidad: dado que los procesos están aislados entre sí, cuando una página o un complemento falla, solo el proceso de la página actual o el proceso del complemento se ve afectado, y el navegador y otras páginas no se ven afectados.
Resuelva el problema de la falta de suavidad: JavaScript se ejecuta en el proceso de renderizado, por lo que incluso si JavaScript bloquea el proceso de renderizado, solo afectará la página de renderizado actual y no afectará al navegador ni a otras páginas, porque los scripts de otras páginas se ejecutan en sus Procesos de renderizado propios.
Resuelva el problema de la inseguridad: Chrome bloquea el proceso de complemento y el proceso de renderizado en la zona de pruebas. Los programas en la zona de pruebas pueden ejecutarse, pero no pueden escribir ningún dato en el disco duro ni leer ningún dato en ubicaciones confidenciales. De esta manera, incluso durante el proceso de renderizado o si se ejecuta un programa malicioso en el proceso del complemento, el programa malicioso no puede atravesar el entorno limitado para obtener permisos del sistema.

Arquitectura reciente

En comparación con antes, la arquitectura reciente ha sufrido muchos cambios nuevos.

Arquitectura de proceso reciente de Chrome

Como se puede ver en la figura, el último navegador Chrome incluye: 1 proceso de navegador principal, 1 proceso de GPU, 1 proceso de red, múltiples procesos de renderizado y múltiples procesos de complemento.

Proceso del navegador: principal responsable de la visualización de la interfaz, la interacción del usuario, la gestión de subprocesos y el suministro de almacenamiento y otras funciones. Se puede entender que el proceso del navegador es un " maestro de programación " unificado para programar otros procesos. Por ejemplo, cuando ingresamos una URL en la barra de direcciones, el proceso del navegador primero llamará al proceso de red.
Proceso de renderizado: la tarea principal es convertir HTML, CSS y JavaScript en páginas web con las que los usuarios puedan interactuar. El motor de composición tipográfica Blink y el motor JavaScript V8 se ejecutan en este proceso. De forma predeterminada, Chrome creará un proceso de renderizado para cada etiqueta Tab. . . Por razones de seguridad, el proceso de renderizado se ejecuta en modo sandbox.
Proceso GPU: de hecho, cuando se lanzó Chrome por primera vez, no existía ningún proceso GPU. La intención original de usar GPU era lograr el efecto de CSS 3D, pero las páginas web posteriores y la interfaz UI de Chrome optaron por usar GPU para dibujar, lo que hizo de GPU un requisito común para los navegadores. Finalmente, Chrome también introdujo procesos GPU en su arquitectura multiproceso.
Proceso de red: Principalmente responsable de cargar los recursos de red de la página, solía ejecutarse como un módulo en el proceso del navegador, no fue hasta hace poco que se independizó y se convirtió en un proceso separado.
Proceso de complemento: principal responsable de la ejecución de los complementos. Debido a que los complementos son propensos a fallar, deben ser aislados por el proceso del complemento para garantizar que la falla del proceso del complemento no afecte el navegador y la página.

Arquitectura actual

La arquitectura del navegador Chrome actualmente está experimentando algunos cambios, lo que se llama arquitectura orientada a servicios (SOA) . El propósito es dividir las partes relacionadas con el propio navegador (Chrome) en diferentes servicios. Después de la orientación a servicios, estas funciones Puede ejecutarse en diferentes procesos o fusionarse en un solo proceso para ejecutarse. La razón principal para hacer esto es permitir que Chrome funcione de manera diferente en hardware con diferentes capacidades. Cuando Chrome se ejecuta en algún hardware con mejor rendimiento, los servicios relacionados con el proceso del navegador se ejecutarán en diferentes procesos para mejorar la estabilidad del sistema. Por el contrario, si el rendimiento del hardware no es bueno, estos servicios se ejecutarán en el mismo proceso para reducir el uso de memoria.

Arquitectura orientada a Servicios

Mecanismo operativo enchufable

Antes de ejecutar el mecanismo, revisemos lo que sucede cuando abres la página:

¿Qué sucede cuando abres la página?

Cuando el usuario agrega una pestaña, se crearán el proceso del navegador del sistema, el proceso de renderizado, el proceso de GPU y el proceso de red;
El usuario ingresa una URL y el proceso del navegador verifica la URL, ensambla el protocolo y forma una URL completa;
El proceso del navegador envía la solicitud de URL al proceso de red a través de la comunicación entre procesos (IPC);
Después de recibir la solicitud de URL, el proceso de red verifica si el caché local ha almacenado en caché el recurso solicitado y, de ser así, devuelve el recurso al proceso del navegador;
De lo contrario, el proceso de red inicia una solicitud http (solicitud de red) al servidor web;
Proceso de red que analiza el proceso de respuesta;
- Verifique el código de estado, si no es 200, ejecute la lógica de procesamiento correspondiente al código de estado;
- Procesamiento de respuesta 200: verifique el tipo de respuesta Tipo de contenido. Si es un tipo de flujo de bytes, la solicitud se enviará al administrador de descargas y no se realizará ninguna representación posterior. Si es html, se notificará al proceso del navegador para que se prepare. el proceso de renderizado para renderizar;
Preparar el proceso de renderizado
- El proceso del navegador comprueba si la URL actual es la misma que el nombre de dominio raíz del proceso de renderizado abierto anteriormente. Si son iguales, se reutiliza el proceso original. Si son diferentes, se inicia un nuevo proceso de renderizado;
Transferir datos y actualizar estado
- Una vez que el proceso de renderizado está listo, el navegador inicia un mensaje de "enviar documento" al proceso de renderizado, quien recibe el mensaje y establece una "canalización" para transmitir datos con el proceso de red;
- Después de que el proceso de renderizado recibe los datos, envía un mensaje de confirmación al navegador;
- Después de que el proceso del navegador recibe el mensaje de confirmación, actualiza el estado de la interfaz del navegador: seguridad, URL de la barra de direcciones, estado del historial de avance y retroceso y actualiza la página web;

¿Qué sucede cuando abres el complemento?

El funcionamiento del complemento se simplificará en comparación con la página.

1. Abrimos el navegador y agregamos una pestaña en blanco.

2. Haga clic derecho en un espacio en blanco en la barra de pestañas, seleccione Administrador de tareas y abra el panel del Administrador de tareas.

3. Puede ver que se están ejecutando 6 procesos, a saber, el proceso del navegador, el proceso de GPU, el proceso de red, el proceso de almacenamiento, el proceso de renderizado y el proceso de extensión.

La página de extensión se ejecuta en el proceso de extensión, e incluye principalmente background.html y popup.html;
- No hay contenido en backgrount.html. Es creado y generado por background.js. Cuando se abre el navegador, el archivo background.js del complemento se cargará automáticamente. Es independiente de la página web y siempre se ejecuta. en segundo plano, llama principalmente al archivo background.js proporcionado por el navegador API para interactuar con el navegador;
- popup.html tiene contenido, al igual que nuestras páginas web normales, está compuesto de html, css y javascript. Se carga bajo demanda y requiere que el usuario haga clic en el botón en la barra de direcciones para activarlo antes de que la página pueda aparecer. ;
El proceso de renderizado ejecuta principalmente la página web. Cuando se abre la página, content_script.js se cargará e inyectará en el entorno de la página web. Al igual que el Javascript introducido en la página web, puede operar el árbol DOM de la página web y cambiar el efecto de visualización de la página;
El proceso de GPU proporciona principalmente soporte de capacidad de hardware para la representación de la interfaz del complemento;
El proceso de red maneja principalmente solicitudes de recursos externos en complementos. Por ejemplo, el complemento nexydy depende de algunos js externos;
El proceso de almacenamiento proporciona capacidades de almacenamiento local para complementos, como el uso de chrome.storage.local para almacenamiento persistente;
El proceso del navegador juega aquí más bien un papel de puente: como tránsito, puede realizar la comunicación de mensajes entre la página de extensión y content_script.js.

Introducción básica a los complementos

Desarrollo de versiones

Hay tres versiones del complemento de Chrome, a saber, Manifest V1, Manifest V2 y Manifest V3 . Entre ellos, la versión MV1 ha sido abandonada, actualmente existen versiones MV2 y MV3 en el mercado, siendo MV2 la corriente principal y poco a poco reemplazada por MV3. línea de tiempo:

Nuevas características del manifiesto V2

https://developer.chrome.com/docs/extensions/mv2/manifestVersion/#manifest-v1-changes

La política de seguridad de contenido predeterminada `script-src 'self'; object-src 'self';` está configurada. Para una configuración detallada de la política de seguridad de contenido, consulte la documentación de MDN;
De forma predeterminada, los recursos dentro de un paquete de complementos ya no están disponibles para sitios web externos. Debe incluirse explícitamente en la lista blanca a través del atributo web_accessible_resources del manifiesto;
cambios en la API de acción del navegador;
cambios en la API de acción de la página;
chrome.extension reemplaza chrome.self para apuntar al complemento en sí;
chrome.extension.getTabContentses y chrome.extension.getExtensionTabs están obsoletos y reemplazados por extension.getViews;
Port.tab está obsoleto y reemplazado por runtime.Port;

Nuevas características del manifiesto V3

El trabajador del servicio reemplaza la página de fondo;
Las modificaciones de solicitudes de red dejan obsoletas la API webRequest y utilizan la nueva API declarativeentrequest para manejarlas;
Ya no se permite la ejecución de código alojado de forma remota, solo se puede ejecutar JS incluido en el paquete de extensión;
Se han agregado promesas a muchos métodos, pero las devoluciones de llamada aún se admiten como alternativa;
La API de acción del navegador y la API de acción de la página están unificadas en una única API de acción;
Los recursos accesibles en la web solo pueden estar disponibles para sitios y extensiones específicos;
Política de seguridad de contenido (CSP), ahora es posible especificar CSP separados para diferentes contextos de ejecución dentro de un solo objeto;
Con el cambio de ejecutarScript, ya no se pueden ejecutar cadenas arbitrarias, solo se pueden ejecutar archivos de script y funciones;

Problemas causados al cambiar a MV3

Dado que el fondo ya no admite la configuración de la página background.html, no se puede llamar a XMLHttpRequest en el objeto de ventana para construir una solicitud ajax. Esto significa que no podemos usar XMLHttpRequest en background.html para enviar solicitudes como la versión V2. En su lugar, es necesario utilice buscar para obtener datos de la interfaz;
Dado que los trabajadores del servicio son de corta duración y finalizan cuando no están en uso, esto significa que continuarán iniciándose, ejecutándose y finalizándose durante todo el período de ejecución del complemento, lo cual es inestable; por lo tanto, es posible que debamos modificar el código en segundo plano. js en V2 Se han realizado algunas transformaciones en la lógica. En el pasado, estábamos acostumbrados a almacenar algunos datos directamente en variables globales, como las siguientes:

// V2 background.js
let saveUserName = "";

// 其他页面，比如content-script或者popup中存储数据
chrome.runtime.onMessage.addListener(({ type, name }) => {
  if (type === "set-name") {
    saveUserName = name;
  }
});

// 点击popup时展示数据
chrome.action.onClicked.addListener((tab) => {
  // 这里saveUserName可能为空字符串
  console.log(saveUserName, "saveUserName");
});

Por lo tanto, en V3, este tipo de datos variables globales deben transformarse. El método de transformación también es muy simple, que consiste en conservar los datos en el almacenamiento y llevarlos a donde sea necesario:

// V3 service worker
chrome.runtime.onMessage.addListener(({ type, name }) => {
  if (type === "set-name") {
    chrome.storage.local.set({ name });
  }
});

chrome.action.onClicked.addListener(async (tab) => {
  const { name } = await chrome.storage.local.get(["name"]);
  chrome.tabs.sendMessage(tab.id, { name });
});

Al cambiar de la API webRequest a la API declarativeentrequest , es necesario refactorizar mucha lógica del código;

¿Por qué cambiar a MV3?

Desde Manifest V1 hasta Manifest V2, podemos ver que Chrome quiere mejorar la privacidad y seguridad de los complementos y también optimiza muchas API. Además de mejorar la seguridad, Manifest V3 también trabaja duro en el rendimiento. El núcleo de Manifest V3 es muy claro: limitar el uso de recursos del sistema por parte de las extensiones. Chrome siempre ha sido criticado por su alto uso de recursos y, debido a que las extensiones se ejecutan en segundo plano, es aún más difícil localizar y administrar problemas si ocurren. Aunque añade muchas restricciones, Manifest V3 todavía tiene ventajas:

Service Worker permite que las extensiones ya no residan en segundo plano, lo que permite reciclar los recursos ocupados por las extensiones, lo que reduce la sobrecarga general del navegador;
Limitar el número de reglas equivale a controlar el límite superior de uso de recursos de una única extensión en el cálculo de reglas;

Estos cambios pueden hacer que Chrome sea más fluido, lo cual es bueno para los usuarios.

Formulario de visualización

Los complementos de Chrome tienen las siguientes 8 formas de presentación comunes:

browserAction (esquina superior derecha del navegador)

Se muestra en la columna de extensión en la esquina superior derecha del navegador, incluido un ícono, un nombre y una ventana emergente

Ventana emergente del complemento Shanhaiguan

pageAction (lado derecho de la barra de direcciones)

pageAction se refiere al icono que se muestra cuando se abren determinadas páginas. En versiones anteriores de Chrome, pageAction se colocaba en el extremo derecho de la barra de direcciones. Al hacer clic con el botón izquierdo aparecerá una ventana emergente y al hacer clic con el botón derecho aparecerá el menú de opciones predeterminado relacionado. La nueva versión de Chrome ha cambiado esta estrategia: la pageAction se coloca en la esquina superior derecha del navegador como la browserAction normal, excepto que es gris cuando no está encendida y es de color cuando está encendida. gris, no importa si hace clic hacia la izquierda o hacia la derecha. Cada clic muestra opciones emergentes.

menú de clic derecho

El menú contextual del navegador se puede personalizar desarrollando un complemento de Chrome, principalmente a través de la API chrome.contextMenus. El menú contextual puede aparecer en diferentes contextos, como páginas normales, texto seleccionado, imágenes, enlaces, etc.

Menú contextual del complemento Nuggets

anular (cubrir páginas específicas)

Utilice la anulación para reemplazar algunas de las páginas específicas predeterminadas de Chrome y utilice en su lugar las páginas proporcionadas por la extensión. La extensión puede reemplazar páginas como esta:

Historial: la página que visitas cuando haces clic en Historial en el menú Herramientas o ingresas chrome://history directamente desde la barra de direcciones.
Página de nueva pestaña: la página visitada al crear una nueva pestaña, o ingrese chrome://newtab directamente desde la barra de direcciones
Marcadores: marcadores del navegador o ingrese chrome://bookmarks directamente

El complemento Nuggets reemplaza la página de nueva pestaña

devtools (herramientas de desarrollo)

Chrome permite desarrollar complementos en herramientas de desarrollo (devtools), principalmente en:

Personalice uno o más paneles al mismo nivel que Elementos, Consola y Fuentes;
Personaliza la barra lateral Actualmente, solo puedes personalizar la barra lateral del panel Elementos;

Reaccionar herramientas de desarrollo

opción (página de opciones)

Para la página de configuración del complemento, puede hacer clic derecho en la entrada en la esquina superior derecha y habrá una pestaña de opciones.

omnibox

El omnibox es una forma de proporcionar sugerencias de búsqueda a los usuarios. Pueden ingresar un identificador específico en la barra de búsqueda y presionar Tab para ingresar a la búsqueda.

Complemento de visor JSON

Notificaciones de escritorio

Chrome proporciona una chrome.notificationsAPI para complementos que envían notificaciones de escritorio. Aún no se han encontrado diferencias ni ventajas significativas entre chrome.notifications y la notificación que viene con HTML5. En JS en segundo plano, ya sea que use chrome.notifications o Notification, no necesita solicitar permiso (el método HTML5 requiere solicitar permiso), puede usarlo directamente.

Introducción central

manifiesto.json

Este es el archivo más importante y esencial de un complemento de Chrome. Se utiliza para configurar todas las configuraciones relacionadas con el complemento y debe colocarse en el directorio raíz. Entre ellos, manifest_version, nombre y versión son esenciales.

Manifiesto V2

{
// 清单文件的版本，这里先使用2演示
"manifest_version": 2,
// 插件的名称
"name": "...",
// 插件的版本
"version": "1.0.0",
// 插件描述
"description": "...",
// 图标，一般偷懒全部用一个尺寸的也没问题
"icons": {
"16": "img/icon.png",
"48": "img/icon.png",
"128": "img/icon.png"
  },
// 会一直常驻的后台JS或后台页面
"background": {
"scripts": ["js/background.js"]
  },
// 浏览器右上角图标设置，browser_action、page_action、app必须三选一
"browser_action": {
"default_icon": "img/icon.png",
"default_title": "...",
"default_popup": "popup.html"
  },
// 当某些特定页面打开才显示的图标
"page_action": {
"default_icon": "img/icon.png",
"default_title": "...",
"default_popup": "popup.html"
  },
// 需要直接注入页面的JS
"content_scripts": [{
"matches": ["<all_urls>"],
"js": ["js/content-script.js"],
"css": ["css/custom.css"],
// 代码注入的时机，document_start, document_end, document_idle，默认document_idle
"run_at": "document_start"
    },
  ],
// 权限申请
"permissions": [
"contextMenus", // 右键菜单
"tabs", // 标签
"notifications", // 通知
"webRequest", // web请求
"webRequestBlocking",
"storage", // 插件本地存储
"https://*/*" // 可以通过executeScript或者insertCSS访问的网站
  ],
// 普通页面能够直接访问的插件资源列表，如果不设置是无法直接访问的
"web_accessible_resources": ["js/inject.js"],
"homepage_url": "...", // 插件主页
"chrome_url_overrides": { // 覆盖浏览器默认页面
"newtab": "newtab.html"
  },
"options_ui": { // 插件选项页
"page": "options.html",
"chrome_style": true
  },
"omnibox": { "keyword" : "..." }, // 向地址栏注册一个关键字以提供搜索建议，只能设置一个关键字
"default_locale": "zh_CN", // 默认语言
"devtools_page": "devtools.html", // devtools页面入口，注意只能指向一个HTML文件，不能是JS文件
"content_security_policy": "...", // 安全策略
"web_accessible_resources": [ // 可以加载的资源
    RESOURCE_PATHS
  ]
}

Manifiesto V3 (solo muestra las diferencias con la versión V2)

{
"manifest_version": 3,
"background": {
"service_worker": js/background.js"
  },
  "action": { //browser_action 和 page_action，统一为 Action
    "default_icon": "img/icon.png",
    "default_title": "这是一个示例Chrome插件",
    "default_popup": "popup.html"
  }
  "content_security_policy": {
    "extension_pages": "...",
    "sandbox": "..."
  },
  "web_accessible_resources": [{
    "resources": [RESOURCE_PATHS]
  }]
}

guiones de contenido

Es una forma de inyectar scripts en la página en el complemento de Chrome (aunque se llama script, en realidad puede incluir css). Con los scripts de contenido, podemos inyectar fácilmente JS y CSS en la página especificada a través de la configuración. Los scripts de contenido y la página original comparten el DOM, pero no el JS. Si desea acceder a la página JS (como una variable JS), solo puede usar js inyectados. Los scripts de contenido no pueden acceder a la mayoría de las API de Chrome, excepto a las cuatro siguientes:

extensión.chrome
cromo.i18n
chrome.runtime
almacenamiento.cromo

Estas API son suficientes la mayor parte del tiempo. Si necesita llamar a otras API, puede pedirle al trabajador de fondo o del servicio que le ayude a llamarlas a través de la comunicación.

fondo

El fondo es una página permanente y su ciclo de vida es el más largo entre todos los tipos de páginas del complemento. Se abre cuando se abre el navegador y se cierra cuando se cierra el navegador, por lo que generalmente las páginas que necesitan ejecutarse todas En este momento, el código global que se ejecuta al inicio se coloca en segundo plano. El fondo tiene permisos muy altos y puede llamar a casi todas las API de extensión de Chrome (excepto devtools), puede cruzar dominios sin restricciones y puede acceder a cualquier sitio web a través de dominios sin necesidad de que la otra parte configure CORS. El concepto de fondo ha cambiado al de trabajador de servicio en la versión MV3. La diferencia es que el ciclo de vida se ha acortado. Los trabajadores de servicio son scripts basados en eventos de corta duración, por lo que no son adecuados para guardar variables globales.

surgir

Una ventana emergente es una pequeña ventana de una página web que se abre cuando se hace clic en el icono de la esquina superior derecha. Se cierra inmediatamente cuando el foco abandona la página web. Generalmente se utiliza para algunas interacciones temporales. El nivel de permiso es similar al de fondo, pero el ciclo de vida es relativamente corto.

script inyectado

En realidad, no existe el concepto de script inyectado en el complemento de Chrome, este es un concepto derivado por los desarrolladores durante el proceso de desarrollo y se refiere a un tipo de JS inyectado en la página a través de operaciones DOM. Debido a que el script de contenido no puede acceder al JS en la página, aunque puede operar el DOM, el DOM no puede llamarlo, es decir, el código en el script de contenido no se puede llamar en el DOM mediante eventos vinculantes. Sin embargo, la capacidad de agregar un botón a una página web para llamar a un complemento es una necesidad relativamente común, por lo que nació el script inyectado.

Mecanismo de comunicación enchufable

Antes de hablar sobre el mecanismo de comunicación, revisemos los tipos de scripts que existen en el complemento. Los complementos JS de Chrome se pueden dividir principalmente en estas cinco categorías: script inyectado, script de contenido, js emergente, js de fondo y js devtools.

Comparación de permisos

tipo JS	API accesibles	Estado de acceso DOM	Estado de acceso JS	Directamente entre dominios
inyectado	No es diferente del JS normal y no puede acceder a ninguna API extendida.	Puede acceder	Puede acceder	No poder
contenido	Solo se puede acceder a algunas API, como la extensión y el tiempo de ejecución.	Puede acceder	No poder	No poder
surgir	Acceso a la mayoría de las API, excepto a la serie devtools.	No accesible directamente	No poder	Poder
fondo	Acceso a la mayoría de las API, excepto a la serie devtools.	No accesible directamente	No poder	Poder
herramientas de desarrollo	Solo se puede acceder a algunas API, como devtools, extensiones, tiempo de ejecución, etc.	Poder	Poder	No poder

A través de la comparación de permisos, podemos ver que cada script tiene permisos diferentes, por lo que la comunicación entre varios scripts es muy importante, y esta también es la base para que el complemento realice muchas funciones.

Descripción general de la comunicación

	inyectado	contenido	surgir	fondo
inyectado	-	ventana.postMessage	-	-
contenido	ventana.postMessage	-	chrome.runtime.sendMessage chrome.runtime.connect	chrome.runtime.sendMessage chrome.runtime.connect
surgir	-	chrome.tabs.sendMessage chrome.tabs.conectar	-	extensión.cromo. obtener página de fondo
fondo	-	chrome.tabs.sendMessage chrome.tabs.conectar	chrome.extensión.getViews	-
herramientas de desarrollo	chrome.devtools. ventana inspeccionada.eval	-	chrome.runtime.sendMessage	chrome.runtime.sendMessage

Ideas de implementación para algunos complementos comunes

Detección de registros de puntos enterrados

En los negocios generales, se informan algunos puntos ocultos. La esencia de los puntos ocultos es enviar algunas solicitudes con parámetros específicos. Al depurar el front-end localmente, si desea ver la información del punto oculto en tiempo real, generalmente debe verificar Los parámetros de entrada de la interfaz de informes o ir al punto enterrado correspondiente son muy inconvenientes para ver en la plataforma. En base a esto, podemos usar complementos que nos ayuden a ver rápidamente información oculta:

Dispositivo de inyección de página

Otro uso común de los complementos es inyectar algún código de herramienta en la página, como herramientas de eliminación de publicidad de la página.

Resumir

Con el continuo desarrollo de los navegadores, Chrome ha separado gradualmente algunos servicios básicos, similar a un sistema operativo en línea multiplataforma.
Los complementos de Chrome proporcionan una amplia gama de capacidades, como inyección de código, solicitudes entre dominios, soluciones de persistencia, diversos mecanismos de comunicación, etc. Los desarrolladores pueden usar su imaginación para ensamblar diferentes capacidades para satisfacer las necesidades de diferentes escenarios, que básicamente pueden lograr lo que la web moderna puede soportar: todas las funciones.
La versión MV2 del complemento de Chrome se abandonará por completo el 24 de enero y debe migrarse a la versión MV3 lo antes posible.