現在、市場に出回っているアプリは頻繁に反復変更されています。ビジネスニーズを満たすために、基本的にハイブリッドを使用して高速なオンラインおよびオフラインビジネスを実現しています。H5の柔軟な開発とオンラインホットアップデートメカニズムの特性は、頻繁なビジネスイテレーションに非常に適しています。H5の強力な開発およびイテレーション機能を最大限に活用し、H5に強力な基盤機能とユーザーエクスペリエンスを提供するには、完全なハイブリッドテクノロジーアーキテクチャソリューションが必要です。既存の成熟したネイティブコンポーネントを再利用できます。
ハイブリッド技術の原則
ハイブリッドのコアポイントは、ネイティブとH5の間の双方向通信レイヤーをどのように処理するかです。実際、ネイティブ（Java / Objective-c /）を完成させるには、一連の言語間通信ソリューションが必要であることも理解できます。 …）およびJavaScript。通信。これがJSBridgeと呼ばれるものです。ハイブリッドアプリの実装の鍵は、WebViewをコンテナーとして使用してWebページを直接ホストすることです。
Webコンテナは、ネイティブとH5の間のリンクであり、JavaScript通知からネイティブおよびネイティブ通知JavaScriptに分割されます。
JavaScript通知ネイティブ
- APIインジェクションの原則は、実際には、ネイティブがJavaScript環境コンテキストを取得し、それにオブジェクトまたはメソッドを直接マウントすることです。これにより、jsを直接呼び出すことができます。AndroidとIOSにはそれぞれ対応するマウントメソッドがあります。
- WebViewでのプロンプト/コンソール/アラートのインターセプトでは、通常、プロンプトが使用されます。これは、このメソッドがフロントエンドで使用される頻度が低く、競合が少ないためです。
- WebViewURLスキームジャンプインターセプト
2番目と3番目のメカニズムの原理は似ています。それらはすべてWebView情報送信の傍受を通じて通信を実現します。次に、主に原理の5つの側面から詳しく説明します-カスタムプロトコル-傍受プロトコル-パラメータ転送-コールバックメカニズム。3番目のスキーム-URLブロックスキーム。
実装の原則
クライアントは、WebViewで送信されたネットワーク要求を監視およびキャプチャできます
契約のカスタマイズ
URLスキームルールのセットを作成する必要があります。通常、リクエストは、さまざまな意味を表す一般的なhttps://xxx.comやfile：//1.jpgなどの対応するプロトコルから始まります。ここで、プロトコルタイプ要求を次のようにカスタマイズできます。
xxcommand：// xxxx？param1 = 1＆param2 = 2
注意すべき点がいくつかあります。
（1）xxcommand：//は単なるルールであり、ビジネスに応じて定式化して意味を持たせることができます。たとえば、xxcommand：//を会社のすべてのアプリに共通と定義し、共通のツールです。契約：
xxcommand：// getProxy？h = 1
とし、xxapp：//をアプリごとに個別のサービス契約として定義します。
xxapp：// openCamera？h = 2
異なるプロトコルヘッダーは異なる意味を表すため、各プロトコルの適用可能な範囲を明確に知ることができます。
（2）location.hrefを使用してここに送信しないでください。これは、複数の同時リクエストが同時に1つにマージされてプロトコルが無視されるという独自のメカニズムに問題があり、同時プロトコルは実際には非常に一般的な機能。iframeを作成する方法を使用してリクエストを送信します。
（3）一般的にセキュリティを考えると、社内のビジネス契約が第三者から直接呼び出されないように、クライアントにドメイン名のホワイトリストや制限を設ける必要があります。
プロトコル傍受
クライアントは、APIを介してWebViewによって送信された要求をインターセプトできます。
IOSの場合：shouldStartLoadWithRequest
Android：shouldOverrideUrlLoading
要求URLヘッダーが指定されたプロトコルであることが解決されると、対応するリソース要求は開始されませんが、パラメーターが解析され、関連する関数またはメソッドが呼び出されてプロトコル関数のマッピングが完了します。
プロトコルコールバック
プロトコルの本質は実際にはリクエストを送信することであるため、これは非同期プロセスであり、対応するコールバックメカニズムを処理する必要があります。ここではJSイベントシステムを使用し、ここでは2つの基本的なAPIwindow.addEventListenerとwindow.dispatchEventを使用します。
契約を送信するときは、契約の一意の識別子を使用してカスタムイベントを登録し、コールバックを対応するイベントにバインドします。
クライアントは、対応する関数を完了すると、BridgeのディスパッチAPIを呼び出し、データを直接伝送して、プロトコルのカスタムイベントをトリガーします。
イベントメカニズムにより、開発はフロントエンドの習慣に沿ったものになります。たとえば、クライアントの通知をリッスンする必要がある場合は、addEventListenerを介してリッスンするだけで済みます。
ヒント：ここで注意すべきことの1つは、イベントの複数の繰り返しバインディングを回避する必要があることです。したがって、一意の識別子がリセットされると、removeEventListenerに対応するイベントを削除する必要があります。
パラメータの受け渡し方法
WebViewにはURLの長さに制限があるため、検索パラメーターを渡す従来の方法には問題があります。渡されるパラメーターが長すぎると、base64が渡される場合や大量のパラメーターが渡される場合などに切り捨てられる可能性があります。データが渡されます。
したがって、新しいパラメーター受け渡しルールを作成する必要があり、関数呼び出しメソッドを使用します。ここでの原則は主に以下に基づいています：
Nativeは、JSメソッドを直接呼び出して、関数の戻り値を直接取得できます。
プロトコルごとに一意の識別子をマークし、パラメータをパラメータプールに保存するだけで、クライアントは一意の識別子を介してパラメータプールから対応するパラメータを取得できます。
Native
はH5のホストとしてカウントできるため、Javascriptに通知するため、より大きな権限があります。NativeはWebViewAPIを介してJsコードを直接実行できることにも言及されています。そのような権威はまた、この方向でのコミュニケーションを非常に便利にします。
IOS: stringByEvaluatingJavaScriptFromString
// Swift
webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")
Android：loadUrl（4.4-）
// jsでJSBridge.triggerメソッドを呼び出す
//このメソッドの欠点は、関数の戻り値を取得できないことです。
webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")
ヒント：システムが4.4未満の場合、evaluateJavascriptを使用できないため、loadUrlを使用するだけではJSの戻り値を取得できません。このとき、互換性のために前述のプロンプトメソッドを使用し、H5に送信を終了させる必要があります。プロンプトを介してデータ、クライアントはデータを傍受して取得します。
Android：evaluateJavascript（4.4 +）
// 4.4+以降、このメソッドを使用して関数の戻り値を呼び出して取得します。
mWebView.evaluateJavascript（"javascript:JSBridge.trigger('NativeCall')", new ValueCallback<String>() {
@Override
public void onReceiveValue(String value) {
//此处为 js 返回的结果
}
});
上記の原理に基づいて、JSBridgeの最も基本的な原理を理解し、ネイティブ<=> H5の双方向通信メカニズムを実現できます。
JSBridgeアクセス
次に、コードに必要なリソースを整理しましょう。上の図からわかるように、このスキームの実現は2つの部分に分けることができます。
JSパート（ブリッジ）：プロトコルアセンブリ/送信/パラメータプール/コールバックプールなどのいくつかの基本機能を含む、ブリッジの実装コードをJS環境に挿入します。
ネイティブパーツ（SDK）：クライアント内のブリッジの機能マッピングコード。URLの傍受と分析/環境情報の挿入/一般的な機能のマッピングなどの機能を実現します。
ここでのアプローチは、2つの部分を一緒にネイティブSDKにカプセル化することです。これは、クライアントによって導入されます。クライアントがWebViewを初期化してページを開くときに、ページアドレスがホワイトリストに含まれている場合、クライアントは対応するbridge.jsをHTMLの先頭に直接挿入します。このアプローチには、次の利点があります。
バージョン分割を回避するために、両当事者のコードは一律に維持されます。更新がある場合、SDKがクライアントによって更新されている限り、バージョンの互換性の問題はありません
。アプリへのアクセスは非常に便利です。ドキュメントによると、SDKの最新バージョンにアクセスするだけで済みます。ハイブリッドソリューション全体を直接実行できるため、複数のアプリケーションに便利です。アプリへの迅速なアクセス
。H5エンドに注意を払う必要がないため、サードパーティのページへの架け橋を開くことができます。
ここで注意すべきことの1つは、bridge.jsが正常に挿入された後に、プロトコルの呼び出しを実行する必要があるということです。クライアントのインジェクション動作は追加の非同期動作であるため、H5側から完了の正確なタイミングをキャプチャすることは困難です。したがって、上記のコールバックに基づいてH5側に通知するために、クライアントを介してページを監視する必要があります。メカニズムであり、ページをウィンドウ.addEventListener（ 'bridgeReady'、e => {}）に渡して初期化できます。
アプリのH5アクセス方法
H5をアプリに接続するには通常2つの方法があります。
（1）オンラインH5、これが最も一般的な方法です。H5コードをサーバーにデプロイし、対応するURLアドレスをクライアントに指定し、WebViewでURLを開いて、それを埋め込むだけです。この方法の利点は次のとおりです。
非常に独立した開発/デバッグ/更新/オンライン機能を備えた強力な独立性。リソースはサーバーに配置され、クライアントのパッケージサイズにはまったく影響しません。アクセスコストは非常に低く、完全なホットアップデートメカニズムです。
しかし、比較的、この方法には対応する欠点もあり
ます。完全にネットワークに依存し、オフラインではページを開くことができません。
最初の画面の読み込み速度はネットワークに依存し、ネットワークが遅い場合は最初の画面の読み込みまた、速度も遅くなります。
通常、この方法は、ヘルプページ、ヒントページ、使用ガイドなど、比較的軽量なページに適しています。これらのページの特徴は、あまり機能的ではなく、複雑な機能プロトコルを必要とせず、オフラインで使用する必要がないことです。一部のサードパーティのページアクセスでは、このメソッドも使用されます。たとえば、このページではWeChatJS-SDKが呼び出されます。
（2）ローカライズされた埋め込み方法である組み込みパッケージH5。コードをパッケージ化してクライアントに送信する必要があり、クライアントはそれをローカルストレージに直接解凍します。通常、比較的大きくて重要なモジュールで使用します。
その利点は次のとおりです。
ローカリゼーションにより、最初の画面の読み込み速度が速く、ユーザーエクスペリエンスが元の状態に近くなります。ネットワークに依存せずにオフラインで実行できます
が、同時に、欠点も非常に明白です。
開発プロセス/更新メカニズムは複雑であり、顧客は、クライアントとさえサーバ間の連携を必要とされ、それに応じてアプリケーションパッケージのサイズが大きくなります。
これらの2つのアクセス方法は、自分の長所と短所があり、そして異なるに応じて選択する必要がありますシナリオ。
参照元：https
：//segmentfault.com/a/1190000015678155 Android：WebViewとJavascriptの相互作用（パラメーターの相互呼び出し、値の受け渡し）
| テクノロジーにも熱心な方は、グループに参加して一緒に進歩してください：230274309。一緒に共有し、一緒に進歩しましょう！ストライクを減らし、乾かしてください！！みなさん、ようこそ！！！（ダイバーのグループに参加しないでください） |
リンクをクリックして、グループチャットに参加します[プログラミングの美しさ]：https：//jq.qq.com/？_ wv = 1027＆k = h75BfFCg
またはコードをスキャンします
