contorno de núcleo de parpadeo de cromo_51CTO博客_switchyomega_chromium.crx
Arquitectura multiproceso, hay un proceso de navegador y N procesos de procesamiento de sandbox, Blink se ejecuta en renderizado de sandbox. Las pestañas del navegador y los iframes pueden compartir el mismo proceso de representación.
Operación de sandbox: en sandbox, el proceso principal del navegador debe usarse para programar y usar recursos (acceso a archivos, red, reproducción de audio y video, lectura de archivos de configuración de usuario (cookie, contraseña), etc. Blink abstrae el proceso del navegador en un grupo Servicios, use Mojo para interactuar con los servicios y los procesos del navegador.
subprocesos en el proceso de renderizado
1 subproceso principal: ejecutar JavaScript, DOM, CSS, estilo, cálculo de diseño
N subprocesos de trabajo: ejecutar Web Worker, ServiceWorker, Worklet
subproceso interno: Blink y V8 crearán varios subprocesos para manejar
la comunicación entre subprocesos , como audio web, base de datos, GC , etc .: debe usar la API PostTask para usar la mensajería. Se desaconseja la programación de memoria compartida a menos que haya algunos lugares donde se necesite por motivos de rendimiento. Esta es la razón por la que no ve muchos MutexLocks en el código base de Blink.
Página, Marco, Documento, ExecutionContext y DOMWindow son los siguientes conceptos:
Página: una página corresponde al concepto de una pestaña (si OOPIF explicado a continuación no está habilitado). Cada proceso de representación puede contener varias pestañas.
Frame: Un marco corresponde al concepto de marco (main frame o iframe). Cada página puede contener uno o más marcos dispuestos en una jerarquía de árbol. 1:n
DOMWindow corresponde al objeto de Windows en JavaScript. Cada marco tiene solo una DOMWindow. El documento 1:1
corresponde al objeto window.document en JavaScript. Cada iframe tiene solo un Documento. 1:1
ExecutionContext es un concepto que abstrae Document (para el subproceso principal) y WorkerGlobalScope (para el subproceso de trabajo).
Proceso de renderizado: Página = 1: N En el caso de un solo proceso, en el caso de múltiples procesos, debe distinguirse según el modo.
Página : Cuadro = 1 : M
Marco: DOMWindow: Documento (o ExecutionContext) = 1: 1: 1
page es una pestaña o una página de fondo en una extensión de cromo.
Contexto de ejecución ExecutionContext es el contexto de ejecución de JS. Una página corresponde a múltiples: después de que cada marco se adjunte al DOM, habrá un contexto de ejecución implícito; la extensión tiene otro contexto de ejecución.
DOMWindow (objeto js windows) y Document (js window.document) (o ExecutionContext) se utilizan para el control interactivo en JS.
Los fotogramas que son locales para el proceso de renderizado están representados por LocalFrame, mientras que los fotogramas que no son locales para el proceso de renderizado están representados por RemoteFrame.
Desde la perspectiva del marco principal, el marco principal es LocalFrame y <iframe> es RemoteFrame. Desde la perspectiva de <iframe>, el marco principal es RemoteFrame y <iframe> es LocalFrame.
La comunicación entre LocalFrame y RemoteFrame (que puede existir en diferentes procesos de representación) se maneja a través del proceso del navegador.
Es muy importante comprender los conceptos de aislamiento, contexto y mundo al escribir código para la API V8. Están representados por v8::Isolate, v8::Context y DOMWrapperWorld respectivamente en el código base.
Isolate corresponde a un hilo físico. Aislar: hilo físico en Blink = 1: 1. El hilo principal tiene su propio aislamiento. Los subprocesos de trabajo tienen su propio aislamiento.
Una instancia de V8 se llama Isolate, y cada aislado tiene su propio espacio de pila para GC. Esto significa que los objetos de JavaScript en un Isolate no pueden acceder directamente a los objetos en otro Isolate.
En Chrome, cada proceso de renderizado tiene un Isolate V8 y todos los códigos JavaScript de los sitios procesados por el mismo proceso de renderizado se ejecutan en el mismo Isolate. Pero para los trabajadores de la Web, cada trabajador tiene su propio Isolate.
En Isolate, hay uno o más contextos de JavaScript (contenido de JavaScript). Chrome crea un entorno JavaScript para cada iframe. Además, cada extensión de Chrome tiene su propio entorno de JavaScript para un iframe. Blink generalmente usa el objeto ScriptState como una referencia al entorno de JavaScript, y blink::ScriptState tiene una relación 1:1 con v8::Context. (Referencia: https://zhuanlan.zhihu.com/p/279920830)
El contexto corresponde al objeto global (en el caso de Frame, es el objeto de ventana de Frame). Dado que cada cuadro tiene su propio objeto de ventana, existen múltiples contextos en el proceso de representación. Cuando llame a la API V8, debe asegurarse de estar en el contexto correcto. De lo contrario, v8::Isolate::GetCurrentContext() devolverá el contexto incorrecto y, en el peor de los casos, terminará filtrando objetos y causando problemas de seguridad.
World es un concepto que admite secuencias de comandos de contenido de extensión de Chrome. El mundo no se corresponde con nada en los estándares web. Los scripts de contenido desean compartir el DOM con la página web, pero por motivos de seguridad, los objetos JavaScript del script de contenido deben estar aislados del montón de JavaScript de la página web. (El montón de JavaScript de otra secuencia de comandos de contenido debe estar aislado del montón de JavaScript de otra secuencia de comandos de contenido). Para lograr el aislamiento, el subproceso principal crea un mundo principal para la página web y un mundo aislado para cada secuencia de comandos de contenido. El mundo principal y el mundo aislado tienen acceso a los mismos objetos DOM de C++, pero sus objetos de JavaScript están aislados. Este aislamiento se logra mediante la creación de múltiples contenedores V8 para un objeto DOM de C++. es decir, un envoltorio V8 por mundo.
¿Cuál es la relación entre Contexto, Mundo y Marco?
Imagine que hay N mundos en la línea principal (un mundo principal + (N - 1) mundos aislados). Entonces, un marco debe tener N objetos de ventana, y cada objeto de ventana es para un mundo. Un contexto es un concepto correspondiente a un objeto ventana. Esto significa que cuando tenemos M marcos y N mundos, tenemos M * N contextos (pero los contextos se crean con pereza).
Para los trabajadores, solo hay un mundo y un objeto global. Por lo tanto, sólo hay un contexto.
Además, cuando usa la API V8, debe tener mucho cuidado de usar el contexto correcto. De lo contrario, terminará filtrando objetos de JavaScript entre mundos aislados y provocando un desastre de seguridad (por ejemplo, una extensión de A.com puede manipular una extensión de B.com).
Por Jeff Mony
Enlace: https://www.jianshu.com/p/2a2424bdc057
Fuente: Jianshu
Los derechos de autor pertenecen al autor. Para reimpresión comercial, comuníquese con el autor para obtener autorización, para reimpresión no comercial, indique la fuente.
El proceso de renderizado del navegador es de subprocesos múltiples (si no entiende esto, consulte la distinción entre procesos y subprocesos)
Por fin llego al concepto de hilo????, que amable. Luego, veamos qué subprocesos contiene (enumere algunos de los principales subprocesos residentes):
1. Subproceso de renderizado de GUI
Responsable de renderizar la interfaz del navegador, analizar HTML, CSS, construir el árbol DOM y el árbol RenderObject, el diseño y el dibujo, etc.
Cuando la interfaz necesita ser repintada (Repintar) o el reflujo (reflujo) es activado por alguna operación, el hilo se ejecutará
Tenga en cuenta que el subproceso de representación de la GUI y el subproceso del motor JS se excluyen mutuamente. Cuando se ejecuta el motor JS, el subproceso de la GUI se suspenderá (equivalente a estar congelado) y la actualización de la GUI se guardará en una cola y se ejecutará inmediatamente cuando el JS el motor está inactivo. .
2. Hilo del motor JS
También conocido como kernel JS, es responsable de procesar los programas de script de Javascript. (por ejemplo, motor V8)
El subproceso del motor JS es responsable de analizar los scripts de Javascript y ejecutar el código.
El motor JS ha estado esperando la llegada de la tarea en la cola de tareas y luego la procesó. Solo hay un subproceso JS que ejecuta el programa JS en una página de pestaña (proceso de representación) en cualquier momento.
También tenga en cuenta que el subproceso de procesamiento de la GUI y el subproceso del motor JS se excluyen mutuamente, por lo que si el tiempo de ejecución de JS es demasiado largo, el procesamiento de la página será incoherente, lo que provocará el bloqueo del procesamiento y la carga de la página.
3. Subproceso de activación de eventos
Perteneciente al navegador en lugar del motor JS, se usa para controlar el bucle de eventos (es comprensible que el motor JS en sí mismo esté demasiado ocupado y el navegador necesita abrir otro hilo para ayudar)
Cuando el motor JS ejecuta bloques de código como setTimeOut (u otros subprocesos del kernel del navegador, como clics del mouse, solicitudes asíncronas de AJAX, etc.), agregará la tarea correspondiente al subproceso del evento.
Cuando el evento correspondiente cumple con las condiciones de activación y se activa, el hilo agregará el evento al final de la cola para ser procesado, esperando el procesamiento del motor JS.
Tenga en cuenta que debido a la relación de subproceso único de JS, los eventos en estas colas pendientes deben ponerse en cola para que el motor JS los procese (se ejecutarán cuando el motor JS esté inactivo)
4. Hilo de activación de sincronización
El hilo donde se encuentran los legendarios setInterval y setTimeout
El motor de JavaScript no cuenta el contador de tiempo del navegador (debido a que el motor de JavaScript es de subproceso único, si está en un estado de subproceso bloqueado, afectará la precisión del tiempo)
Por lo tanto, use un subproceso separado para cronometrar y activar el tiempo (después de que finalice el tiempo, agréguelo a la cola de eventos, espere a que el motor JS esté inactivo y ejecútelo)
Tenga en cuenta que W3C estipula en el estándar HTML que un intervalo de tiempo inferior a 4 ms en setTimeout debe contarse como 4 ms.
5. Hilo de solicitud http asíncrono
Después de conectar XMLHttpRequest, se abre una nueva solicitud de subproceso a través del navegador
Cuando se detecta un cambio de estado, si se establece una función de devolución de llamada, el subproceso asíncrono generará un evento de cambio de estado y luego colocará esta devolución de llamada en la cola de eventos. Luego ejecutado por el motor de JavaScript.
El subproceso de representación de la GUI y el subproceso del motor JS son mutuamente excluyentes.
Dado que JavaScript puede manipular el DOM, si la interfaz se representa mientras se modifican las propiedades de estos elementos (es decir, el subproceso JS y el subproceso de la interfaz de usuario se ejecutan al mismo tiempo), los datos del elemento obtenidos antes y después del subproceso de representación pueden ser incoherentes.
Por lo tanto, para evitar resultados de representación impredecibles, el navegador configura el subproceso de representación de la GUI y el motor JS como una relación mutuamente excluyente. Cuando se ejecuta el motor JS, el subproceso de la GUI se suspenderá.
Las actualizaciones de la GUI se almacenarán en una cola y se ejecutarán inmediatamente cuando el subproceso del motor JS esté inactivo.
JS bloquea la carga de la página
De la relación de exclusión mutua anterior, se puede deducir que si JS se ejecuta durante demasiado tiempo, bloqueará la página.
Por ejemplo, suponiendo que el motor JS esté realizando una gran cantidad de cálculos, incluso si la GUI se actualiza en este momento, se guardará en la cola y se ejecutará después de que el motor JS esté inactivo.
Luego, debido a la gran cantidad de cálculos, es probable que el motor JS esté inactivo durante mucho tiempo y, naturalmente, sentirá que la enorme tarjeta es extremadamente grande.
Por lo tanto, intente evitar que el tiempo de ejecución de JS sea demasiado largo, lo que provocará una representación incoherente de la página, lo que dará como resultado la sensación de que la página se procesa y se bloquea la carga.
WebWorker, ¿multihilo para JS?
Como se mencionó en el artículo anterior, el motor JS es de subproceso único, y si el tiempo de ejecución de JS es demasiado largo, bloqueará la página, entonces, ¿JS es realmente inútil para los cálculos intensivos de la CPU?
Por lo tanto, Web Worker fue compatible con HTML5 más adelante.
La explicación oficial de MDN es:
Web Workers proporciona una manera fácil para que el contenido web ejecute scripts en subprocesos en segundo plano. Los subprocesos pueden realizar tareas sin interferir con la interfaz de usuario. Un trabajador es un objeto creado mediante un constructor (por ejemplo, Worker()) que ejecuta un archivo JavaScript con nombre. Este archivo contiene el código que se ejecutará en el subproceso de trabajo; los trabajadores se ejecutan en otro global El contexto es diferente de la ventana actual, por lo tanto, usar el acceso directo de la ventana para obtener el alcance global actual (en lugar de uno mismo) devolverá un error dentro de un Worker
Entendido de esta manera:
Al crear un Worker, el motor JS se aplica al navegador para abrir un subproceso (el subproceso lo abre el navegador y está completamente controlado por el subproceso principal, y no puede operar el DOM)
El subproceso del motor JS se comunica con el subproceso de trabajo de una manera específica (la API postMessage necesita serializar objetos para interactuar con el subproceso para obtener datos específicos)
Por lo tanto, si tiene un trabajo que consume mucho tiempo, abra un subproceso de Worker por separado, de modo que no importa cuán impactante sea, no afectará el subproceso principal del motor JS.
Justo después de calcular el resultado, comunica el resultado al hilo principal, ¡perfecto!
Y tenga en cuenta que el motor JS es de un solo subproceso, y la esencia de esto no ha cambiado.Se puede entender que el navegador abre Worker para el motor JS, y se usa especialmente para resolver esos problemas de cálculo masivos.
Además, la explicación detallada de Worker está más allá del alcance de este artículo, por lo que no la repetiré aquí.
Ahora que tanto WebWorker como SharedWorker
están aquí, mencionemos SharedWorker nuevamente (para evitar confundir estos dos conceptos más adelante)
WebWorker solo pertenece a una página determinada y no se compartirá con el proceso Render (proceso del núcleo del navegador) de otras páginas
Entonces, Chrome crea un nuevo hilo en el proceso de procesamiento (cada página de pestaña es un proceso de procesamiento) para ejecutar el programa JavaScript en Worker.
SharedWorker es compartido por todas las páginas del navegador y no se puede implementar de la misma manera que Worker, porque no pertenece a un proceso de Render y puede ser compartido por múltiples procesos de Render
Por lo tanto, el navegador Chrome crea un proceso separado para que SharedWorker ejecute programas JavaScript. Solo hay un proceso SharedWorker para cada JavaScript idéntico en el navegador, sin importar cuántas veces se cree.
Al ver esto, debería ser fácil entender que es esencialmente la diferencia entre un proceso y un hilo. SharedWorker es administrado por un proceso independiente, y WebWorker es solo un hilo bajo el proceso de renderizado
Autor: jony0114
Enlace: https://www.jianshu.com/p/f1e5ad3b4afb
Fuente: Jianshu
Los derechos de autor pertenecen al autor. Para reimpresión comercial, comuníquese con el autor para obtener autorización, para reimpresión no comercial, indique la fuente.
Frame y WebFrame
Existe una correspondencia uno a uno entre Frame y WebFrame. Frame puede encontrar WebFrame a través del cliente, y WebFrame también puede encontrar Frame a través del Cliente.
Otras clases encapsuladas Web** pueden hacer referencia a esto
IFrame, ventana, documento se conectan
LocalFrame* marco = nodo_-> GetDocument() .GetFrame()
;
event_->GetEventPath().EnsureWindowEventContext(); //Obtener el evento de envío de domWindow del evento
//Enviar eventos desde el contexto
auto* window = To<LocalDOMWindow>(GetExecutionContext());
window->DispatchEvent(*Event::Create(event_name));
Obtener domwindow en el marco Enviar evento
frame_? frame_->DomWindow()
frame_->DomWindow() is null??
frame_->DomWindow()->DispatchEvent(unload_event, this);
Obtener el marco
1, obtener el marco actual
LocalFrame* Documento: :ExecutingFrame() { LocalDOMWindow* ventana = ExecutingWindow(); if (!ventana) devuelve nullptr; devuelve ventana->GetFrame(); }
2. Encuentra el marco superior. El marco tiene una ventana y un objeto js del documento
Frame& top = GetFrame()->Tree().Top();
KURL top_document_url;
auto* top_local_frame = DynamicTo<LocalFrame>(&top);
3. Obtener marco de domwindow
1.
LocalDOMWindow* executing_window = ExecutingWindow();
1.
LocalFrame* frame = executing_window->GetFrame();
Obtener el marco del objeto js del documento
_->GetDocument() en el marco
localDomWindow envía evento, prototipo: DispatchEventResult LocalDOMWindow::DispatchEvent(Event& event,EventTarget* target)
DispatchEvent(*Event::Create(event_type_names::kLanguagechange));
DispatchEvent(*PageTransitionEvent::Create(event_type_names::kPageshow,false /* persistente */),document_.Get());
-----------------------------------
esquema de núcleo de parpadeo de cromo
https://blog.51cto.com/u_15057855 /4536130