Analyse der prinzipiellen Implementierung aus dem Quellcode des Mini-Programm-Entwicklertools

So zeigen Sie den Quellcode der Miniprogramm-Entwicklertools an

Als Nächstes verwenden wir den Quellcode des WeChat Mini-Programm-Entwicklertools, um die zugrunde liegenden Implementierungsprinzipien des Mini-Programms zu erläutern. Verwenden Sie den Quellcode des Entwicklertools mit der Versionsnummer State v1.02.1904090, um einen Blick auf die Implementierungsideen des Miniprogramms zu werfen. Wie kann ich den WeChat-Quellcode anzeigen? Mac-Benutzer sehen sich den Paketinhalt der WeChat Mini Program Developer Tools an, gehen dann zu Contents/Resources/app.nw/js/core/index.js und kommentieren den folgenden Code aus, um den von den Entwicklertools gerenderten Code anzuzeigen.

// Öffne das Inspektionsfenster if (nw.App.argv.indexOf('inspect') !== -1) {
    tools.openInspectWin()
}

Starten Sie dann das Mini-Programmentwicklertool neu. Die folgende Seite links wird angezeigt. Klicken Sie auf eine der Seiten, um die DOM-Struktur der Ansichtsebene anzuzeigen, wie in der folgenden Abbildung rechts dargestellt.

Mini-Programm Architektur-Design

1. Wird das Miniprogramm im selben Thread gerendert? Doppelgewindemechanismus

Jeder, der schon einmal ein Miniprogramm entwickelt hat, weiß, dass es sich bei Miniprogrammen um ein Dual-Thread-Design handelt, d. h. die Ansichtsdarstellung und die Geschäftslogik werden jeweils in unterschiedlichen Threads ausgeführt. Mit diesem Entwurf soll vor allem ein Problem der Web-Technologie gelöst werden:

Der Rendering-Thread und der Skript-Thread der Webseitenentwicklung schließen sich gegenseitig aus. Das langfristige Ausführen von Skripts kann dazu führen, dass die Seite nicht mehr reagiert oder ein weißer Bildschirm angezeigt wird, was zu einer schlechten Erfahrung führt.

Um ein besseres Erlebnis zu bieten, trennt das Miniprogramm den Seitenrendering-Thread und den Skript-Thread und führt sie in unterschiedlichen Threads aus. Die konkrete Implementierung lautet:

• Die Ansichtsebene wird in der Webansicht gerendert, und eine Seite entspricht einer Webansicht
• Die Appservice-Schicht der Geschäftslogik wird im selben JSCore-Thread ausgeführt, genauer gesagt JavaScriptCore für iOS und X5 JSCore für Android, und die Entwicklertools befinden sich in der Webansicht.

Dies löst das Problem, dass Skripte die Seitendarstellung über einen langen Zeitraum blockieren, bringt jedoch auch einige neue Probleme mit sich:

• Inhärente Verzögerungen, Threads müssen kommunizieren
• Die Geschäftslogikschicht kann nicht auf DOM- und BOM-APIs zugreifen, da sie in JSCore ausgeführt wird.

Das Entwicklertool verwendet Webview, um den Code der Geschäftslogikschicht zu laden. Obwohl die abhängige Umgebung über DOM- und BOM-APIs verfügt, lokalisiert das Miniprogramm zur Wahrung der Konsistenz alle Module, sodass sie nicht auf diese APIs zugreifen können. Auf diese Weise durchlaufen die beiden Threads nativ, und das Entwicklertool fungiert über den WebSocket-Dienst im Hintergrund als Nachrichtenübertragungsmedium zwischen den beiden und stellt einige grundlegende Funktionen bereit. Einzelheiten entnehmen Sie bitte der Karte auf der offiziellen Website:

2. Ist das Miniprogramm Web-Rendering? Mechanismus zur Schnittstellendarstellung

Es gibt drei Hauptmethoden zum Rendern einer Seite:

• Reines Web-Rendering
• Reines natives Rendering
• Hybrid-Rendering, also eine Kombination aus Web- und nativem Rendering

Da die Hostumgebung des Miniprogramms WeChat ist, ist es unwahrscheinlich, dass reines natives Rendering verwendet wird. Andernfalls müssten alle Miniprogramme zusammen mit WeChat codiert und veröffentlicht werden. Es scheint machbar, reines Web-Rendering zu verwenden, das schnelle Online-Updates unterstützt und durch die lokale Installation der neuesten Ressourcen gerendert werden kann. Beim reinen Web-Rendering kann es jedoch auf einigen Seiten mit komplexen Interaktionen zu Leistungsproblemen kommen. Dies liegt daran, dass in der Webtechnologie sowohl das UI-Rendering als auch die Ausführung von JavaScript-Skripten in einem einzigen Thread ausgeführt werden, was leicht dazu führt, dass einige logische Aufgaben UI-Rendering-Ressourcen belegen. Daher wird das Applet im Hybridmodus gerendert, wie auf der offiziellen Website beschrieben:

Die Schnittstelle wird größtenteils durch ausgereifte Webtechnologie bereitgestellt und durch eine große Anzahl von Schnittstellen ergänzt, um native Rich-Client-Funktionen bereitzustellen.

Gleichzeitig wird jede Miniprogrammseite mithilfe einer anderen WebView gerendert. Dies ermöglicht eine bessere interaktive Erfahrung, die näher an der nativen Erfahrung liegt, und vermeidet, dass die Aufgabe einer einzelnen WebView zu schwer ist.

Da Hybrid-Rendering verwendet wird, kann die Seite mit nativem Rendering gerendert werden. Unter welchen Umständen wird natives Rendering verwendet?

Die Antwort besteht darin, vom Miniprogramm bereitgestellte Komponenten wie Karten, Videos, Leinwand, Textbereiche usw. zu verwenden. Das Rendering-Prinzip des nativen Renderings auf der Seite kann auf die nativen Komponenten der offiziellen Website verweisen. In den Miniprogramm-Entwicklertools werden jedoch native Komponenten mithilfe von HTML-Tags simuliert. Einzelheiten finden Sie in den Rendering-Ergebnissen der Kartenkomponente im nächsten Abschnitt.

3. Wird das Miniprogramm mithilfe von Web-HTML-Tags gerendert? Exparser-Komponentenframework

Wie oben erwähnt, werden Miniprogramme hauptsächlich mit ausgereiften Webtechnologien gerendert. Können wir die von HTML bereitgestellten Tags wie div, table usw. direkt verwenden, um Seiten zu organisieren? Die Antwort ist nein. Wichtige Überlegungen:

• Kontrolle und Sicherheit: Web-Technologien können sensible Seiteninhalte abrufen und ändern oder nach Belieben über Skripte auf andere Seiten springen.
• Begrenzte Möglichkeiten schränken die Präsentation von Miniprogrammen ein
• Es gibt viele Tags, was das Verständnis erschwert.

Daher kann das Miniprogramm HTML-Tags nicht direkt zum Rendern von Seiten verwenden. Es bietet mehr als 10 integrierte Komponenten zum Konvergieren von Web-Tags und eine JavaScript-Sandbox-Umgebung, um zu verhindern, dass JS auf Browser-APIs zugreift.

Da das Miniprogramm HTML-Tags nicht direkt zum Rendern von Seiten verwenden kann, bedeutet dies, dass die von ihm bereitgestellten integrierten Komponenten wie Ansicht und Cover-Ansicht letztendlich in von HTML zum Rendern bereitgestellte integrierte Tags konvertiert werden? Die Antwort ist nein. Schauen wir uns den folgenden Code an:

<Klasse anzeigen="Kartencontainer">
  <map Breitengrad='39.9088230000' Stil="Höhe: 100%; Breite:100%;" Längengrad='116.3974700000' Maßstab='16' id="id" bindregionchange="onRegionChange"></map>
  <view catchtap="onTap">Test</view>
</Ansicht>

Der obige Code rendert die Elemente schließlich in den Entwicklertools wie unten gezeigt:

Es ist ersichtlich, dass die vom Miniprogramm bereitgestellten Komponenten letztendlich nicht in entsprechende HTML-Tags für das Rendering umgewandelt werden, sondern mithilfe von benutzerdefinierten Elementen gerendert werden. Diese integrierten Komponenten werden alle vom Exparser-Framework verwaltet, das in die Basisbibliothek des Miniprogramms integriert ist und grundlegende Unterstützung für verschiedene Komponenten des Miniprogramms bietet.

Das Exparser-Framework basiert auf dem Shadow DOM-Modell, das dem ShadowDOM von WebComponents sehr ähnlich ist. Weitere Einzelheiten finden Sie auf der offiziellen Website des Komponentensystems.
Die Namenskonventionen für integrierte Komponenten beginnen alle mit wx-. Externe Verweise auf integrierte Komponenten wie view rufen letztendlich die zugrunde liegende wx-view-Komponente auf. Die view-Komponente von Exparser wird wie folgt erstellt:

4. Können Miniprogramme DOM betreiben? Datengesteuert

Aus Kontroll- und Sicherheitsgründen bietet das Miniprogramm eine JavaScript-Sandbox-Umgebung zum Ausführen von JavaScript-Code. Der JS-Code kann nicht auf browserbezogene Schnittstellen zugreifen, was bedeutet, dass JS Dom und Bom nicht ausführen kann, da sonst möglicherweise ein Fehler gemeldet wird. Wie implementiere ich eine Sandbox-Umgebung für Miniprogramme? Das heißt, durch die Kapselung der Geschäftslogik in einer lokalen Umgebung ändert die lokale Umgebung die relevanten API-Zeiger von DOM und BOM. Die konkreten Verpackungsformen sind wie folgt:

Die Frage ist also, wie fügt das Miniprogramm die obige Kapselung zum Geschäftscode hinzu? Eigentlich ist es ganz einfach. Im Miniprogramm-Entwicklertool gibt es einen Hintergrunddienst. Beim Zugriff auf den Pfad jedes Moduls des Miniprogramms ruft der Hintergrunddienst die Methode wrapSourceCodeInDefine auf, um den Inhalt der angeforderten JS-Datei in das Definitionsfeld einzuschließen. Der Code der Methode ist in der folgenden Abbildung dargestellt:

Die Methode define ist hier eine der Methoden, um Modularisierung auf der untersten Ebene des Miniprogramms zu implementieren. Eine andere ist die Methode require. Define wird verwendet, um ein Modul zu definieren, und require wird verwendet, um auf ein durch define definiertes Modul zu verweisen. Aus der Kapselung des Geschäftsmodulcodes durch das obige Applet können wir Folgendes ersehen:

Das durch „define“ definierte Modul übergibt APIs mit denselben Namen wie browserbezogene Schnittstellen, z. B. Fenster, Dokument, lokaler Speicher usw. Manche Leute sagen möglicherweise, dass auf das Fensterobjekt mit globalem Gültigkeitsbereich über Function('return this')() zugegriffen werden kann, aber das Applet blockiert diesen Pfad, schreibt Function neu und eval wird auf undefiniert zurückgesetzt. Beispielsweise die folgende Abbildung:

Wenn ein Modul erforderlich ist, werden nur require, module und exports übergeben. Die Werte anderer Parameter sind undefiniert und auf diese Schnittstellen kann im Geschäftscode nicht zugegriffen werden.

Sie können sich den durch require definierten Quellcode ansehen:

In der tatsächlichen WeChat-Umgebung wird die Geschäftslogikschicht in JSCore ausgeführt, das keine browserbezogenen Informationen enthält und nicht auf DOM zugreifen kann. Das Miniprogramm-Entwicklertool verwendet jedoch Webview, um Geschäftslogikcode auszuführen, der über DOM-bezogene Schnittstellen verfügt. Daher wird die obige Sandbox-Umgebung verwendet, um JS einheitlich daran zu hindern, DOM zu betreiben.

Wenn der Geschäftscode nicht auf das DOM zugreifen kann, wie können wir die Seite dynamisch aktualisieren?

Die Antwort besteht darin, die datengesteuerte Idee von MVVM-Frameworks wie Vue zu übernehmen, d. h. den Ansichtsstatus und die Ansicht miteinander zu verknüpfen. Wenn sich der Status ändert, kann sich auch die Ansicht automatisch ändern, sodass das DOM nicht direkt bedient werden muss.

Die dynamische Aktualisierung der Ansicht wird durch virtuelle DOM-Technologie implementiert. Ich glaube, jeder hat virtuelles DOM bereits verstanden. Der Prozess ist wie folgt:

Die eigentliche Verarbeitung kann kurz wie folgt beschrieben werden:

Verwenden Sie JS-Objekte, um den DOM-Baum zu simulieren -> vergleichen Sie die Unterschiede zwischen den beiden virtuellen DOM-Bäumen -> wenden Sie die Unterschiede auf den realen DOM-Baum an.

Unter diesen kann virtuelles DOM WXML über integriertes WCC in eine JS-Objektform konvertieren, um die DOM-Baumstruktur darzustellen.

Das folgende Bild von der offiziellen Website veranschaulicht den Vorgang der dynamischen Ansichtsaktualisierung:

// wxml
 <Ansicht>{{msg}}</Ansicht>

// js
Daten: {
   Nachricht: „Hallo Welt“
} 

Oben wurde erklärt, wie die Ansicht aktualisiert wird. Tatsächlich gibt es im Prozess der Datenantwort eine weitere wichtige Verbindung, nämlich wie die Geschäftslogikschicht die geänderten Daten mit der Ansichtsschicht synchronisiert. Dies beinhaltet eine Dual-Thread-Kommunikation.

5. Was ist die Funktion der Miniprogramm-Basisbibliothek?

Wenn wir Miniprogramme in Entwicklertools entwickeln, wählen wir normalerweise eine Basisbibliothek aus, beispielsweise die Auswahlschnittstelle des Miniprogramm-Entwicklertools:

Die Basisbibliothek des Miniprogramms ist in JavaScript geschrieben, wir verweisen jedoch nicht direkt in unserem Miniprogramm darauf. Wie verwenden wir also die von der Basisbibliothek bereitgestellten Funktionen? Die Antwort ist:

Die WeChat-Hostumgebung verfügt bereits über integrierte Basisbibliotheken. Wenn Sie ein Miniprogramm öffnen, werden die Basisbibliotheken automatisch in die Ansichtsebene und die Geschäftslogikebene des Miniprogramms eingefügt. Die Entwicklertools des Miniprogramms werden vom zugrunde liegenden HTTP-Dienst eingefügt.

Die folgende Abbildung zeigt den relevanten Code, der vom zugrundeliegenden HTTP-Dienst des Applets über das Skript eingefügt wird:

Zu den grundlegenden Bibliotheksfunktionen des Miniprogramms gehören WAWebview.js für die beiden Teilansichtsebenen und WAService.js für die Geschäftslogikebene. Hier eine kurze Beschreibung der entsprechenden Funktionen:

WAService stellt grundlegende Funktionen für die Business-Logik-Schicht bereit

Werfen wir einen Blick auf die Miniaturansicht des Quellcodeinhalts von WAService.js:

Aus dem Quellcode können wir ersehen, dass die von der Basisbibliothek bereitgestellte WAService.js viele Funktionen hat, hauptsächlich die folgenden Teile

• WeixinJSBridge: Einheitliche Kapselung der Nachrichtenkommunikation, einfach aufzurufen, hauptsächlich für die Kommunikation zwischen der WeChat-Umgebung und nativer Umgebung sowie zwischen der Entwicklungsumgebung und dem Backend-Dienst des Entwicklertools.
• wx: API-Methodenkapselung unter wx-Objekt
• appServiceEngine: definiert globale Methoden wie „define“, „require“, „App“, „Page“, „Component“, „getApp“, „getCurrentPages“ usw.
• virtualDOM: VirtualDOM-, Diff- und Render-UI-Implementierung
• expraser: Methodendefinition der Framework-Komponente expraser, was bedeutet, dass die Logikschicht auch über bestimmte Funktionen zur Komponentenbaumorganisation verfügt.
• Reporter: Mini-Programmprotokollkomponente

WAWebview stellt grundlegende Funktionen für die Ansichtsebene bereit

Einige der von der Mini Program Basic Library für die Ansichtsebene bereitgestellten Grundfunktionen sind dieselben wie die von WAService. Die Hauptfunktionen sind wie folgt:

• Die Nachrichtenkommunikationskapselung ist WeixinJSBridge
• Protokollkomponente Reporter-Kapselung
• Die API unter dem wx-Objekt unterscheidet sich von der in WAService darin, dass es sich bei den meisten davon um Methoden handelt, die sich auf die Verarbeitung der UI-Anzeige beziehen.
• Implementierung des Mini Program Expraser-Komponentenframeworks und Registrierung integrierter Komponenten
• VirtualDOM-, Diff- und Render-UI-Implementierung
• Definieren Sie seitenbezogene Ereignisauslöser

Oben finden Sie den detaillierten Inhalt der Analyse der Hauptimplementierung aus dem Quellcode des Miniprogramm-Entwicklertools. Weitere Informationen zur Hauptimplementierung aus dem Quellcode des Miniprogramm-Entwicklertools finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!