JD Gate 詳細ワンコードマルチターミナルの探索と実践 | JD Cloud テクニカルチーム

この記事では主に京東門郷事業のサポートプロセスで遭遇した困難について説明し、効率向上と品質保証の方向で私たちが模索し実践してきた問題点を解決するためのアイデアとソリューションを共有します。練習の過程での問題点や新たなインスピレーションもお届けできればと思っています

1. 背景

1.1 JD Gateの詳細な紹介

1.1.1. JD.comの詳しい事業内容

店舗詳細ページは略してMenxiangと呼ばれます。Menxiangビジネスには、店舗詳細、リスト、注文収集、検索、店舗到着などのページが含まれます。2020年にJD.comのメインWebサイトAPPで初めて開始されました。当初は次のように使用されていました。 JD Daojia のオフラインの高品質販売者であり、モデルは JD.com のメイン Web サイトに配置され、ユーザーは店舗情報の閲覧、商品の閲覧、納期の確認、クーポンの収集、車両の追加、注文などの完全なショッピング プロセスを完了できます。門郷でのワンストップでの配置。その後の事業の発展に伴い、Menxiang は天衞、時間単位購入、医薬品配送、フロント倉庫などのビジネス モデル シナリオを次々と実行し、徐々にインスタント小売の特徴を形成し、家庭と店舗のシナリオをカバーし、ラインを引き受けるようになりました。オンライン・オフラインの総合業務システム

1.1.2. ビジネス形態の詳細

ドアの詳細なビジネスには、Jiamenxiang (時間ごとの購入、薬の配達)、および店舗の詳細 (POP、Wanjia) が含まれます。テクノロジー スタックには、JD アプレット [2]、WeChat アプレット [3]、H5、RN が含まれます。ページには 20 以上の店舗が含まれます。ページ、受注、検索、評価、資格、一覧など。

1.2. Menxiang のビジネスサポートの過程で直面した問題点

• 京東アプリとWeChatアプレットではドアの詳細に大きな違いがあります
• 歴史的な理由により、Jingdong アプリと Jinggou アプレットの 2 セットのドアの詳細を同時に維持する必要に直面しています。
• 事業計画の需要は膨大で、二重の要件が頻繁に繰り返され、研究開発リソースは逼迫しており、短期間では消化できない
• 両端のビジネス シナリオとさまざまなテクノロジ スタックが、品質保証に大きな課題をもたらしています

1.3. 京溝ミニプログラムビジネス党の蒙祥へのアピール

• Jinggou アプレットの詳細な機能は Jingdong アプリと連携することが期待されます
• 新しい要件を繰り返すことで、WeChat ドメインに迅速に同期することが期待されます
• 研究開発要件のスループットが向上し、より多くの要件を迅速に吸収できることが期待されます

2. 技術的解決策

2.1. プログラムの予備調査

予備的な技術ソリューションの調査として、RN、Flutter、Taro、uni-app などのさまざまな人気の多端末フレームワークについても学び、多端末のサポート、開発エコロジー、フロントエンド フレームワークに関する研究を実施しました。調査と比較；JD APPとWeChatアプレットをサポートする予定であるため、Taro3[1]、uni-app[10]、mpvue[11]、chameleon[12]などのアプレットをサポートするマルチターミナルフレームワーク]、WePY[13]等を優先；フロントエンドフレームワークの互換性、Jingdongアプレット[2]のサポート、チーム自身の状況（チームがReactに精通している）などを総合的に考慮した結果、最終的には、マルチターミナルの再構築に Taro フレームワークを使用することが決定されました。

2.2. 技術的解決策の策定と実践

2.2.1. 解決すべき問題を考える

• JD アプレット、WeChat アプレット、H5 などの複数端末のニーズをより適切にサポートするにはどうすればよいでしょうか?
• 変革プロセス中に新しい要件が繰り返し開発されることを避けるにはどうすればよいでしょうか?
• 研究開発のリードタイムをいかに短縮するか？
• 開発プロセスの効率を向上するにはどうすればよいでしょうか?
• 迅速な反復プロセスにおいて研究開発の品質を確保するにはどうすればよいでしょうか?
• より多くのビジネスシナリオを柔軟にサポートするにはどうすればよいでしょうか?
• ページのパフォーマンスを確保するにはどうすればよいですか?

2.2.2. 解決策の策定

2.2.2.1. 細かい業務向けのマルチ端末ソリューション

ソリューション全体は、フロントエンド、サーバー、プラットフォームを通じて、マルチターミナルおよびフロアベースのソリューションの完全なセットを構築します。サーバー側は、ドア詳細機能を複数のドメイン サービス、ドメイン モデル、拡張ポイントに分割します。 PaaS アーキテクチャ フロントエンドは iPaas フロア、コンポーネント標準策定、詳細なマルチターミナルおよびフロアベースのスキームに基づいており、管理プラットフォームは Odysseus (小規模プログラム トランザクション デジタル プラットフォーム) を介して Huangliu デジタル プラットフォームおよび iHub プラットフォームに接続され、ビジネス、ページ、フロア、コンポーネント、データなどを管理します。オンライン リリースでは、次のようなソリューション全体のパノラマが示されます。

2.2.2.2. ドア詳細のフロントエンド技術フレームワーク

フロントエンドは、Taro3[1] + React[8] + Recoil[7] を技術ベースとしており、ネットワーク、アドレス、埋め込みポイント、クーポン、名刺、ショッピング カートなどにドアの詳細なビジネスを分割します。基本機能と基本コンポーネントの原則に従って、50 以上の機能ポイントを備えたページ標準は、ドア詳細レンダリング エンジン部分を iPaas ページ プロトコルに追加し、iHub プラットフォームを通じてフロアとコードを管理し、最後にページ コンテナによってレンダリングします。以下は、マルチポータル アーキテクチャ図のプロセスでドアの詳細が直面する問題点と、実装プロセスでの計画の一部に基づいています。

2.2.3. 技術的ソリューションの実装プロセス

1) 業務機能の分類とフロアとコンポーネントの分割

構造に応じて、ドア詳細ホームページはヘッダー、リスト、フッター、ポップアップレイヤーなどに分割され、ページヘッダー、店舗情報、会員フロア、割引キャンペーン、商品リスト、決済伝票、ショッピングカート、フロアに応じてなど 12+ フロアコンポーネント

2) 多端末適応過程における差分処理

マルチターミナル フレームワークはクロスプラットフォーム開発シナリオの解決に役立ちましたが、異なるプラットフォーム間の基本的な原理と基本機能の実装方法が異なるため、特定のプラットフォームに合わせて調整して処理する必要があるワークロードがまだいくつかあります。最初にドアを整理します。細部で使用される小規模プログラム プラットフォームの 40 以上の基礎的な機能、マルチ端末プラットフォーム上の機能の違いを列挙して比較し、API を均一に標準化するためにプラットフォームの違いに対する中間適応層を定式化します (例:ログイン、アドレス、埋め込みポイント、ルーティング、システム情報など）

3) 開発プロセスの効率を向上させる方法

• コンポーネント化: コンポーネントのカプセル化は 2 つの層に分かれており、最下層は最小単位の機能コンポーネントであり、上位層は最小の再利用可能なビジネス コンポーネントの原則カプセル化であり、同一および類似のコードの冗長性を効果的に削減します。同時に、ツール jscpd[4] も定期的に使用されます。 コード監査を実施して、最適化のために類似のコード フラグメントをさらに見つけます。

• 階層化: 関連するビジネス コンポーネントを組み合わせて、店舗情報フロア、割引プロモーション フロアなどの機能の再利用性を最大限に高めます。フロア コンポーネントはページ スキーマ プロトコルに従って開発され、一部の機能はカスタマイズできます。

• MVVM モード: 反応フック[6] を使用して、元のページのロジックとデータ処理をビュー モード レイヤーに調整します。これにより、ロジックと UI の間の明確な分離を維持しやすくなり、コードの可能性も大幅に高まります。再利用

4) 改修プロセス中の新たな要件への対応

古いドアの詳細は JD.com の小さなプログラムのネイティブ言語を使用して開発され、新しいドアの詳細は Taro+React を使用して開発されています。新しいドアの詳細が完全にリリースされる前に、新しい要件にはデュアルエンドのサポートが必要です。調査後、ハイブリッド開発モデル [9] を通じてアプレットから直接参照できるネイティブ コンポーネントに Taro コンポーネントをパッケージ化し、新旧プロジェクトの繰り返し開発の問題を解決しました。

2.3. ドア詳細アプレットのパフォーマンスの最適化

Menxiang はまた、パブリック ベータ段階でいくつかのパフォーマンスの問題を明らかにしました。シナリオに応じて、それらを 2 つのカテゴリに分類しました: エクスペリエンス パフォーマンスと起動パフォーマンス。ここで、関連するケースと解決策を共有します。友人たちに役立つことを願っています。同じような困難を抱えている人たちに新しいアイデアを

2.3.1、パフォーマンスの最適化を体験する

ドア詳細ホームページにおけるユーザー操作で最も頻度が高いのは、カテゴリー切り替えやリストスライドなどの機能であり、ユーザーからのフィードバックが多い部分でもありますが、上記2種類の問題に関連する事例分析を以下に示します。

2.3.1.1. 製品リストのレンダリングパフォーマンスの最適化

ドア詳細のマルチターミナル化後、アンケート調査を通じてユーザー体験のフィードバックを収集したところ、一部のユーザーから商品リストのスクロール時にフリーズ現象が発生したと報告されていることがわかりました。Taro のデバッグ環境ログを使用して分析すると、ページの読み込み中に setData の量が増加し続け、所要時間も増加し続けていることがわかります。

デバッグ環境ログ:

setData に時間がかかる傾向曲線:

調査の結果、リストをページングしてレンダリングするときに大量のデータによりフレーム損失が発生することが判明しました。大規模レンダリングと繰り返しレンダリングの問題を解決するために、商品リストの元の 2 次元配列データ構造をリンク リスト + 再帰的手法に最適化し、階層ネストされたタイル レンダリングを行い、データの多層計算を削減します。 、およびビューでのページごとの読み込みとレンダリングの制御 単一ページでは、次のような最適化されたリスト効果が得られます。

リスト効果:

setData に時間がかかる傾向曲線:

最適化前後の分割画面データレンダリングの時間のかかる比較:

上図の左側は最適化前のリストの効果を示しており、要求されたデータをロードする際のフリーズがより顕著になり、特にデータ量が増加するにつれてフリーズ時間がますます長くなっていることがわかります。右側は最適化された効果で、十数ページを読み込んだ後でも効率的なレンダリング パフォーマンスを維持しています。上記の最適化後、各画面のデータ レンダリング時間は約 200 ミリ秒に維持され、大量のページ データの読み込みがある場合でもレンダリングは効率的になります。

2.3.1.2. カテゴリ切り替え時のリスト描画ロジックの最適化

フロント倉庫の業務支援プロセスにおいて、一部の特殊なシナリオにおいてカテゴリー切り替え時の待ち時間が長く、ユーザーエクスペリエンスが低いことが判明しました。分析の結果、分類リストにデータをロードする際、フロントエンド処理ロジックは、製品が 1 つの画面に収まらない場合に次のページのデータを自動的にロードし、ユーザーが満足できるように製品リストを完成させることになっていることがわかりました。より多くの製品データを表示できますが、インターフェイスがポーリング要求を行うと、ユーザーの待ち時間が長くなります。

上図左側は最適化前の分類切り替え時の商品読み込みロジックですが、ユーザーの待ち時間を短縮するために分類レンダリングロジックを最適化（図右側）し、分類がクリックされた後の処理ロジックが調整され、現在の分類のデータのみが要求されます。クロスレベル分類インターフェイスの要求は行われなくなりました。分類されたレンダリング時間は、n (インターフェイス リクエストの数) * 250 (インターフェイス リクエスト時間) + 200 ミリ秒 (フロントエンド レンダリング時間) から 250 ミリ秒 + 200 ミリ秒に短縮されます。

2.3.2. 起動時のパフォーマンスの最適化

詳細なアプレットの起動プロセスを分析し、起動の各リンクとそれに対応する時間のかかるデータを整理し、最適化計画を策定します。

• 京東小規模プログラム パッケージ圧縮 (jdapkg ファイルを圧縮し、ファイル サイズを 8.6 MB から 3.4 MB に削減)
• 小さなプログラム テンプレート パッケージの再利用 (複数の小さなプログラムのコールド スタート ダウンロードを避けるため)
• 詳細なミニプログラム テンプレート パッケージが APP に組み込まれています (時間のかかるミニプログラム パッケージのダウンロードを削減します)
• APP の起動時にアプレット テンプレート パッケージをプリロードします (アプレットのコールド スタートにかかる時間を短縮します)。
• ミニプログラム エンジンの読み込みに時間がかかる最適化 (ミニプログラム エンジンの予熱)
• 小型プログラム エンジンがメイン スレッド ラグの最適化を開始 (ロジック層とレンダリング層は並行して処理されます)
• 小規模プログラムコード構築パッケージ jdapkg最適化（エンジン共通コード抽出）
• アプレットの情報インターフェースが同期から非同期に変更されました（平均オンライン時間が 158 ミリ秒短縮されました）
• 小規模プログラムのネットワーク ライブラリのタイムアウトと再試行メカニズムの最適化
• ドア詳細のメインインターフェイスの時間のかかる最適化 (最初の画面ではデータの非同期は不要)
• 詳細なビジネス コード パッケージ削減 (コードの最適化、サブパッケージなど、パッケージ サイズは 3.4MB から 648KB に削減)

パブリック テンプレート パッケージを使用すると、複数の販売者がコード パッケージを共有して、繰り返しのダウンロードを削減します。

前門アプレットの平均起動時間は 2227.7 ミリ秒を最適化しました。上記の最適化措置を実装した後、全体の起動時間は 954 ミリ秒に短縮され、起動速度が 57.6% 向上しました。これも採用しています。プログラム エンジン チームの強力なサポートに心からの感謝を表明する機会です。

2.4. ISV共同構築スキームの検討と品質保証

2.4.1. なぜ共同建設と探査を行う必要があるのでしょうか?

ビジネスサイドからの需要が多く流入しており、詳細化・汎用化されていない機能の中には特殊なシナリオの個別ニーズに属するものもありますが、研究開発リソースが不足する場合には、どのように対応するかについても検討しています。ビジネスをより適切にサポートするために、需要のスループットを向上させる , ビジネスとの綿密なコミュニケーションの結果、一部のビジネス側には独自の R&D チームもあり、個別のニーズを独自に開発できることが判明しました。具体的な共同建設プロセスは以下のとおりです。

システム ISV ソリューションの変革と探索の後、パーソナライズされた需要の待ち時間は大幅に短縮され、過去 2 四半期と比較して、パーソナライズされた需要の全体的な受け入れは 30% 以上増加しました。システムの安定性を確保するために、ジョイント構築プロセスの仕様と、ジョイントのアクセス、開発、立ち上げに関する関連するパフォーマンス、品質、その他の制約を策定しました。建設要件。

2.4.2. 研究開発の品質を確保するにはどうすればよいですか?

また、複数チームおよび複数人の共同作業プロセス中にいくつかの問題も見つかりました。いくつかの一般的な問題を回避するために、ここで関連する開発仕様を策定し、要件開発およびオンライン プロセス全体で必要な検証リンクをいくつか追加しました。詳細は次のとおりです。

• 統一標準仕様（ディレクトリ構造仕様、gitブランチ仕様、コード記述仕様、開発仕様、ファイル仕様、オンライン仕様など）
• 要件レビュー後、開発前にフロントエンドとバックエンドの技術ソリューションをレビューします。
• コード仕様のスキャンと文法仕様のチェックにツール (ESLint) を使用する
• オンライン化前にコードレビューを実施し、影響範囲を見積もる
• チェックリスト（重要なプロセス、コア機能、特別なシナリオ）の立ち上げ時の検査
• オンラインになった後、グレースケールは監視、異常、顧客の苦情、その他のシステムを切断して観察します
• ボトムアップ ソリューションは、オンライン ページと機能のワンクリック ダウングレードをサポートします。

3. テクノロジーの沈降とビジネスの強化

3.1. 技術変革の過程における能力の析出

• マルチターミナルおよびフロアベースの開発フレームワーク、ISV アクセスと共同構築をサポート
• 仕様ページではフロアベースのプロトコルをプログラムでき、一部の機能は動的に構成できます。
• 標準化された床コンポーネント開発テンプレートにより、コンポーネントの開発および構成プロセスが削減されます。
• 基本関数ライブラリには、16 の基本 API、25 の基本コンポーネント、50 以上のビジネス コンポーネント、および 3 つのパッケージ化されたプラグインが含まれています
• 自社開発の多端末デバッグツール（核）、公開記事2件、国家特許庁の審査段階に入った特許2件を公開
• ビルドツール cola-cli、cola-server
• 小さなプログラムの標準化ドアの詳細が SDK を強化

3.2. 多端末化によるメリット

• 基本機能により、新規ビジネス（倉庫ドアの詳細、店舗の詳細、POP ドアの詳細など）の開発効率を 40% 以上向上させることが可能
• Jingdong アプリ上の Menxiang の 95% 以上の機能は、WeChat アプレットおよび H5 端末で直接再利用でき、限られた研究開発リソースの下で複数端末の要件のスループットを大幅に向上させます。
• 4 か月にわたるマルチターミナルの変革を経て、2 年以上遅れていた Jinggou アプレットのドア詳細ビジネスのニーズが満たされました
• 20 以上のミニプログラムの権限付与 (例: Jinggou ミニプログラム、JD スーパーマーケット ミニプログラム、Hourbuy など)

ドアディテールの多端子多層化の過程で蓄積された開発フレームワーク、基本機能ライブラリ、汎用開発テンプレートは、店舗ドアディテール、店舗店舗ディテール、ポップドアディテールなどの業務でも活用されています。 。

3.3. 玄関ドアのきめ細かなクイックサポート

JD アプリのプレ倉庫の第 2 フェーズ構築中、ミニプログラムのドア詳細のコンポーネントと機能の再利用率は 95% 以上に達しました。マルチターミナル フレームワーク機能に基づいて、フロントエンドの倉庫ドアの詳細な権限強化により、京溝ミニプログラムは 2 日以内に完了しました ビジネス側 フロントエンドの倉庫ドアの詳細機能を京東スーパーマーケット ミニプログラム (WeChat) に導入できることが期待されています。 Odysseus プラットフォームの認証、モデル管理、データ管理、視覚化、および構成の機能を備えたドア詳細のマルチターミナルおよびフロアベースの機能を提供し、足場とプラットフォームの組み合わせを通じてビジネス パーティにワンクリック アクセスを提供します。 -ストップエンパワーメントサービス. この標準化された方法により、京東スーパーマーケットの小規模なプログラム要件をサポートするだけでなく、Huangliu SDKの標準化されたドアツードア機能も拡張されます. ワンクリックトリガーにより、Huangliu SDK全体のエンパワーメントを5以内に完了できますパッケージの構築

4. 今後の展望

ドア詳細ビジネスに関係するシナリオの数が増加するにつれて、一般的なフロア コンポーネントは徐々にすべての差別化されたシナリオを満たすことができなくなりますが、すべてのフロアをパブリック テンプレート パッケージに入れることは、間違いなく小さなプログラム パッケージのサイズをテストすることになります。ワンコードマルチターミナルフレームワークと自社開発の小規模プログラム公開システムの考え方により、小規模プログラムの詳細なバッチを分類して管理し、ビルド時にタイプと要求に応じてビルドし、公開テンプレートパッケージを複数のテンプレートに分割してビルドすることができます。差別化された方法で個別にリリースします

京東のフロントエンド技術領域における iPaas2.0 構築プラットフォームが徐々に改善すると同時に、Menxiang のビジネスはマルチターミナルとフロアベースのフレームワークから恩恵を受けており、マルチターミナルの分野でも一歩前進しました。 Menxiang アプレットのターミナル視覚化構築により、ビジネス シナリオに合わせて標準化されたドアの詳細を提供します

参考文献

[1]Taro3：https://taro-docs.jd.com/docs/

[2] 京東アプレット: https://mp-docs.jd.com/doc/dev/framework/-1

[3] WeChat ミニプログラム: https://developers.weixin.qq.com/miniprogram/dev/framework/

[4]jscpd：https://github.com/kucherenko/jscpd

[5] 状態管理ライブラリの比較: https://cloud.tencent.com/developer/article/1685891

[6]Reactフック：https://react.docschina.org/learn#using-hooks

[7]リコイル：https://www.recoiljs.cn/docs/introduction/getting-started

[8]React：https://react.docschina.org/learn

[9] ネイティブ プロジェクトでは Taro を使用します: https://taro-docs.jd.com/docs/taro-in-miniapp

[10]ユニアプリ：https://github.com/dcloudio/uni-app

[11]mpvue：https://github.com/Meituan-Dianping/mpvue

[12]カメレオン：https://github.com/didi/chameleon

[13]WePY：https://github.com/Tencent/wepy

著者: JD Retail 徐宏偉

出典: JD Cloud 開発者コミュニティ

インド国防省が自社開発した Maya OS は、Windows Redis 7.2.0 を完全に置き換えるもので、最も広範囲にわたるバージョンの 7-Zip 公式 Web サイトが、Baidu によって悪意のある Web サイトであると特定されました 。 Xiaomi がCyber​​Dog 2をリリース、オープンソース率80％以上 ChatGPTの1日コスト約70万ドル、OpenAIが破産寸前の可能性 瞑想ソフトが上場へ、「中国初のLinux人」が設立 Apache Doris 2.0.0版正式リリース: ブラインド テストのパフォーマンスが 10 倍向上、より統合され多様な超高速分析エクスペリエンス Linux カーネル (v0.01) のオープン ソース コード解釈の最初のバージョン Chrome 116 が正式リリース

{{名前}}

{{名前}}