Eine vorläufige Studie zu JSBridge in Javascript

Der Ursprung von JSBridge

In den letzten Jahren sind mobile Endgeräte immer beliebter geworden und die Frage, ob man sich im Entwicklungsprozess für Native oder H5 entscheidet, war schon immer ein heißes Thema. Native und H5 haben beide ihre eigenen Vor- und Nachteile. Um den Geschäftsanforderungen gerecht zu werden, kombinieren Unternehmen die beiden häufig für die Hybridentwicklung während der Entwicklung tatsächlicher Projekte. Native und H5 befinden sich an zwei verschiedenen Orten und scheinen nicht miteinander verbunden zu sein. Wie können die beiden Seiten also zusammenarbeiten, um Funktionen zu erfüllen?

Zu diesem Zeitpunkt dachten wir an Codova, das eine Reihe gerätebezogener APIs bereitstellt und eine gängige Lösung für frühe JS darstellt, um nativen Code aufzurufen und native Funktionen zu implementieren. Aufgrund der Popularität des mobilen Internets wird JSBridge im Land jedoch häufig verwendet.

JSBridge ist eine JS-implementierte Brücke, die Native und H5 an beiden Enden der Brücke verbindet. Es ermöglicht Native, JS aufzurufen und JS, Native bequem innerhalb der APP aufzurufen, und es ist ein bidirektionaler Kommunikationskanal. JSBridge bietet JS hauptsächlich die Möglichkeit, nativen Code aufzurufen, um native Funktionen wie das Anzeigen lokaler Fotoalben, das Öffnen der Kamera, die Zahlung per Fingerabdruck usw. zu implementieren.

H5 vs. Native

Das bidirektionale Kommunikationsprinzip von JSBridge

JS ruft Native auf

Es gibt viele Möglichkeiten, JS-Aufrufe nativ zu implementieren, hauptsächlich durch das Abfangen des URL-Schemas, das Umschreiben der Eingabeaufforderung, das Einfügen der API und andere Methoden.

Abfangen von URL-Schema

Sowohl Android als auch iOS können das URL-Schema abfangen und analysieren, um zu entscheiden, ob die entsprechende native Code-Logikverarbeitung durchgeführt werden soll.

Für Android stellt Webview die Methode shouldOverrideUrlLoading bereit, die es Native ermöglicht, die von H5 gesendete URL-Schema-Anforderung abzufangen. Der Code lautet wie folgt:

öffentliche Klasse CustomWebViewClient erweitert WebViewClient {
    @Überschreiben
    öffentliches Boolean shouldOverrideUrlLoading(WebView-Ansicht, String-URL) {
      ......
      // Szenario 1: Anforderung abfangen und Schema empfangen
        wenn (url.equals("xxx")) {

            // handhaben
            ...
            // Rückruf
            view.loadUrl("JavaScript:setAllContent(" + json + ");")
            gibt true zurück;
        }
        gibt super.shouldOverrideUrlLoading(url) zurück;
     }
}

WKWebview von iOS kann basierend auf dem abgefangenen URL-Schema und den entsprechenden Parametern zugehörige Vorgänge ausführen. Der Code lautet wie folgt:

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler{
    wenn ([navigationAction.request.URL.absoluteString hasPrefix:@"xxx"]) {
        [[SharedApplication für UIApplication] openURL:navigationAction.request.URL];
    }
    EntscheidungsHandler(WKNavigationActionPolicyAllow);
}

Die Vorteile dieser Methode bestehen darin, dass sie keine Schwachstellen aufweist, flexibel einsetzbar ist und ein nahtloser Wechsel zwischen H5- und nativen Seiten möglich ist. Wenn eine Seite beispielsweise schnell gestartet werden muss, wird zuerst eine H5-Seite entwickelt. Wenn ein Link als H5-Link ausgefüllt wird, springt er zur H5-Seite, bevor die entsprechende native Seite entwickelt wird. Nachdem die native Seite entwickelt wurde, wird sie abgefangen und springt zur nativen Seite. Zu diesem Zeitpunkt muss der H5-Link nicht geändert werden. Wenn Sie zum Senden des URL-Schemas jedoch iframe.src verwenden, muss die Länge der URL kontrolliert werden, was komplex und langsam ist.

Neuschreiben nativer JS-Methoden wie Prompt

Vor Android 4.2 war die Schnittstelle zum Einfügen von Objekten addJavaScriptInterface, sie wird jedoch aus Sicherheitsgründen nach und nach verworfen. Der Vorgang wird normalerweise durch die Änderung einiger Methoden des Fensterobjekts des Browsers abgeschlossen. Es fängt hauptsächlich die vier Methoden Alert, Confirm, Prompt und Console.log ab, die jeweils von onJsAlert, onJsConfirm, onConsoleMessage und onJsPrompt von Webview überwacht werden. Der onJsPrompt-Überwachungscode lautet wie folgt:

public boolean onJsPrompt(WebView-Ansicht, String-Ursprung, String-Nachricht, String-Standardwert, endgültiges JsPromptResult-Ergebnis) {
  Zeichenfolge handledRet = parentEngine.bridge.promptOnJsPrompt(Herkunft, Nachricht, Standardwert);
  xxx;
  gibt true zurück;
}

Aufgrund des Sicherheitsmechanismus von iOS fängt WKWebView Methoden wie Alarm, Bestätigung und Eingabeaufforderung ab. Wenn Native und JS auf diese Weise interagieren, müssen Sie die drei WKUIDelegate-Proxy-Methoden von WKWebView implementieren. Das Codebeispiel lautet wie folgt:

-(void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)Nachricht initiiertByFrame:(WKFrameInfo *)Frame-AbschlussHandler:(void (^)(void))AbschlussHandler{

  UIAlertController *alertController = [UIAlertController alertControllerWithTitle:nil Nachricht:Nachricht?:@"" bevorzugter Stil:UIAlertControllerStyleAlert];

  [alertController addAction:([UIAlertAction actionWithTitle:@"Bestätigen" style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

      AbschlussHandler();

  }])];

  [selbst presentViewController:alertController animiert:JA Abschluss:nil];

}

Wenn Sie diese Methode verwenden, können Sie sich mit Android und iOS auf das Format der Parameterübergabe einigen, sodass H5 Native direkt aufrufen kann, indem es verschiedene Parameter übergibt, ohne den Client zu identifizieren. Der Rest wird dem Client überlassen, der dieselbe Methode abfängt, dieselben Parameter identifiziert und seine eigene Verarbeitungslogik ausführt, um eine konsistente Leistung auf mehreren Terminals zu erreichen. wie:

alert("Sind Sie sicher, xxx?", "Abbrechen", "OK", callback());

Darüber hinaus werden andere Formate von Eingabeaufforderungen und anderen Methoden nicht erkannt, wenn Sie die Spezifikationen des aufrufenden Protokolls wie Methodennamen und Parameterübergabe mit Native ermitteln können, was eine isolierende Rolle spielen kann.

##### Injektions-API

Basierend auf den von Webview bereitgestellten Funktionen können wir Objekte oder Methoden in Window einfügen. Wenn JS dieses Objekt oder diese Methode aufruft, führt es die entsprechende logische Operation aus und kann die native Methode direkt aufrufen. Wenn Sie diese Methode verwenden, muss JS warten, bis Native die Ausführung der entsprechenden Logik abgeschlossen hat, bevor die Vorgänge im Rückruf ausgeführt werden.

Androids Webview bietet die Methode addJavascriptInterface, die Android 4.2 und höher unterstützt.

gpcWebView.addJavascriptInterface(neues JavaScriptInterface(), 'nativeApiBridge'); 
öffentliche Klasse JavaScriptInterface {
    Kontext mContext;

  JavaScriptInterface(Kontext c) {
    mContext = c;
  }

  öffentliche void share(String webMessage){            
    // Native Logik}
}

Beispiel für einen JS-Aufruf:

Fenster.NativeApi.share(xxx);

iOS UIWebview bietet die Methode JavaScriptScore, die iOS 7.0 und höher unterstützt. WKWebview bietet die Methode window.webkit.messageHandlers, die iOS 8.0 und höher unterstützt. UIWebview wurde vor einigen Jahren häufig verwendet, ist heute jedoch nicht mehr üblich. Nachfolgend sehen Sie ein Beispiel für die Erstellung einer WKWebViewConfiguration und einer WKWebView:

WKWebViewConfiguration *Konfiguration = [[WKWebViewConfiguration alloc] init];
WKPreferences *Einstellungen = [WKPreferences neu];
Einstellungen.javaScriptCanOpenWindowsAutomatically = JA;
Einstellungen.MinimumFontSize = 40,0;
configuration.preferences = Einstellungen;
    

- (void)viewWillAppear:(BOOL)animiert
{
    [super viewWillAppear:animiert];
    [self.webView.configuration.userContentController addScriptMessageHandler:selbstname:@"teilen"];
      [self.webView.configuration.userContentController addScriptMessageHandler:self name:@"pickImage"];
}
- (void)viewWillDisappear:(BOOL)animiert
{
    [super viewWillDisappear:animiert];
    [self.webView.configuration.userContentController entfernenScriptMessageHandlerForName:@"share"];
    [self.webView.configuration.userContentController entfernenScriptMessageHandlerForName:@"pickImage"];
}

Beispiel für einen JS-Aufruf:

window.webkit.messageHandlers.share.postMessage(xxx);

Native ruft JS auf

Für Native ist es relativ einfach, JS aufzurufen. Sie müssen lediglich die JS-Methode im Fenster verfügbar machen, damit Native sie aufrufen kann.

Es gibt zwei Hauptmöglichkeiten, es in Android zu implementieren. Vor 4.4 wurde dies durch die Ausführung eines JS-Codeteils über die Methode loadUrl erreicht. Ab 4.4 kann dies mit der Methode „evaluateJavascript“ erreicht werden. Die Methode loadUrl ist praktisch und übersichtlich in der Anwendung, aber sie ist ineffizient und kann keine Ergebnisse zurückgeben. Außerdem aktualisiert sie die WebView, wenn sie aufgerufen wird. Die Methode evaluateJavascript ist effizient und einfach, um den Rückgabewert abzurufen. Sie aktualisiert die WebView nicht, wenn sie aufgerufen wird, unterstützt jedoch nur Android 4.4+. Der entsprechende Code lautet wie folgt:

webView.loadUrl("javascript:" + javaScriptString);
webView.evaluateJavascript(javaScriptString, neuer ValueCallback<String>() {
  @Überschreiben
  öffentliche void onReceiveValue(String-Wert){
    xxx
  }
});

iOS kann in WKWebview über evaluateJavaScript:javaScriptString implementiert werden, das iOS 8.0 und höher unterstützt.

// schnell
Funktion evaluateJavaScript(_ javaScriptString: String, 
    completionHandler: ((Irgendein?, Fehler?) -> Void)? = nil)
// javascriptString JS-Code, der aufgerufen werden soll // completionHandler-Rückruf nach der Ausführung // objective-c
[jsContext evaluateJavaScript:@"ZcyJsBridge(ev, Daten)"]

Einsatz von JSBridge

Zitierhinweis

• Diese Methode wurde von H5 verwendet, als sie in der ersten Version unseres mobilen Terminals referenziert wurde, und der Aufruf erfolgte durch die lokale Einführung des npm-Pakets. Diese Methode kann bestätigen, dass JSBridge existiert, und die native Methode direkt aufrufen. Wenn sich die Implementierung der Bridge jedoch später ändert, müssen beide Parteien für mehr Kompatibilität sorgen, und die Wartungskosten sind hoch.
• Native Injection ist die Methode, die derzeit von unserem mobilen Endgerät verwendet wird. Unter Berücksichtigung der zukünftigen Geschäftsanforderungen wurde ein Redesign durchgeführt und die Native-Injection-Methode zur Referenzierung von JSBridge verwendet. Dies trägt zur Wahrung der Konsistenz zwischen API und Native bei, hat jedoch den Nachteil, dass die Methode und der Zeitpunkt der Native-Injektion begrenzt sind. Bevor JS Native aufruft, muss festgestellt werden, ob JSBridge erfolgreich injiziert wurde.

Nutzungsrichtlinien

Pseudocodebeispiel für H5, das eine native Methode aufruft, wie etwa:

Parameter = {
  api_version: "xxx", // API-Versionstitel: "xxx", // Titeldateiname: "xxx", // Dateinamebild: "xxx", // Bildlink-URL: "xxx", // URL-Link erfolgreich: Funktion (Res) {
    xxx; //Ausführen nach erfolgreichem Aufruf},
  fehlgeschlagen: Funktion (Fehler) {
    wenn (Fehlercode == '-2') {
      fail && fail(err); // Die API-Version, die im aktuellen Client nicht vorhanden ist, wurde aufgerufen } else {
      const msg = err.msg; //Ausnahmeinformationen Toast.fail(msg);
    }
  }
};
Fenster.NativeApi.share(Parameter);

Im Folgenden werden die Abstraktionen gängiger Methoden kurz aufgelistet. Derzeit folgt die bidirektionale Kommunikation im Wesentlichen den folgenden Spezifikationen.

Fenster.NativeApi.xxx({
    api_version:'',
    Name: "xxx",
    Pfad: "xxx",
    ID: "xxx",
    Erfolg: Funktion (res) {
      konsole.log(res);
    },
    fehlgeschlagen: Funktion (Fehler) {
      console.log(fehler);
    }
});

Da in der ersten Version die lokale Verwendung von JSBridge in H5 gewählt wurde, wurde in der späteren Version die native Injektionsmethode übernommen. Das bestehende H5 muss mit verschiedenen Situationen kompatibel sein. Die logische Abstraktion lautet wie folgt:

reqNativeBridge(vm, fn) {
  wenn (!istApp()) {
    // Wenn der Aufruf nicht in der APP erfolgt vm.$dialog.alert({
      Meldung: „Um diese Funktion nutzen zu können, ist ein Zugriff auf die App erforderlich“,
    });
  } anders {
    wenn (!window.NativeApi) {
      // Für frühere Versionen vm.$dialog.alert({
        Meldung: „Um diese Funktion nutzen zu können, aktualisieren Sie bitte auf die neueste App“,
      });
    } anders {
      // Hier behandeln wir nur die Fehlermeldung „Aufruf einer API-Version, die im aktuellen Client nicht vorhanden ist“ // Andere Arten von Fehlerinformationen werden von bestimmten Unternehmen behandelt fn && fn((err) => {
        vm.$dialog.alert({
          Meldung: „Um diese Funktion nutzen zu können, aktualisieren Sie bitte auf die neueste App“,
        });
      });
    }
  }
}

Zusammenfassen

Der obige Inhalt stellt kurz einige Prinzipien von JSBridge vor. Ich hoffe, dass er für Studenten hilfreich ist, die JSBridge noch nicht kennen. Wenn Sie ein tieferes Verständnis der Prinzipien und der Implementierung von JSBridge benötigen, beispielsweise die Kapselungsimplementierung von JSBridge-Schnittstellenaufrufen, die Eindeutigkeit von Rückrufen, wenn JS Native aufruft usw. Sie können nach weiteren Informationen suchen, ausführlichere zugehörige Dokumente zu Rate ziehen oder die zusammengestellten und schriftlichen Niederschriften anderer Personen einsehen.

Das Obige ist der detaillierte Inhalt der ersten Erkundung von JSBridge in Javascript. Weitere Informationen zu JSBridge in Javascript finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!