♓️ 🏝️ 🤽🏾 高性能GWT。パート1 🏴󠁧󠁢󠁳󠁣󠁴󠁿 👨🏾‍🤝‍👨🏼 🤸

この投稿は、GWTアプリケーションのパフォーマンスの最適化と改善に関する一連の記事の始まりです。私はたくさんの資料を蓄積してきたので、2〜3の部分に分けることにしました。

最初の記事で私たちを待っているものを説明します。

対処すべき質問

GWTアプリケーションの最適化に関する一連の記事の最初の部分では、次のことについて説明します。

クライアントコード分離、オンデマンドダウンロード
クライアントでの重いクラスの使用を取り除く
リソースキャッシング
RESTを使用したGWT RPCパフォーマンスの問題
レイアウトがアプリケーションに与える影響の特徴
伝送の最適化
スケジューラを使用する
ディスパッチャーを使用してサーバー要求を集約する

そして今、言及された各点について詳細に説明します。

クライアントコード分離、オンデマンドダウンロード

GWTには、開発者がアプリケーションをパーツに「カット」できる組み込みメカニズムがあります。これはまず、次の目的のために必要です。

ダウンロードしたデータの初期サイズを減らす
遅延ロードの原則を使用-必要なデータは必要に応じてアプリケーションによってダウンロードされます

クライアントコードを部分に分割するには、GWT.runAsyncメソッドの呼び出しを使用します。

RunAsyncの例：

 GWT.runAsync(new RunAsyncCallback() { public void onSuccess() { new MySettingsDialog().show(); } public void onFailure(Throwable ohNoes) { // indicate that something went wrong, // usually a connectivity or server problem } });

同時に、GWTコンパイラは、クライアントコードを分割するだけでなく、コードのコーディング方法を分析する責任も負います。分離が正しいことが保証されます。ただし、分離が発生しない場合があります。この理由は、コード内の相互参照である可能性があります。

Google I / Oを使用したGWT Can What Whatプレゼンテーションでは、runAsyncを使用してアプリケーションをダウンロードする前と後でアプリケーションのダウンロード速度を比較できます。

したがって、runAsyncを使用すると、アプリケーションの初期ロード時間が大幅に短縮され、クライアントに送信されるデータ量が削減されます。

AsyncProxyクラスに注意する価値があります。おそらく、私は彼の説明を記事の第2部で説明しますが、彼の文書に従って彼に精通することができます。

クライアントでの重いクラスの使用を取り除く

Google Web Toolkitグループページでは、コンパイルされたGWTアプリケーションのサイズを削減する方法に関する議論を見つけることができます。特に、クライアント側で「重い」クラスを使用することを拒否し、クライアント側で大量のコードを含める必要があるというアプローチが注目されています。

まず、クライアントでComparatorを使用する例を示します。これを使用するには、クライアント関連部分に〜10 Kbのコード関連クラスを含める必要があります。

RequestFactoryを使用すると、クライアントがさらに増加します。上記の説明では、クライアント部分が150 Kb増加しました。

外部モジュールを使用する場合も注意する価値があります-プロジェクトにそれらを含めると、他の多くのクラスが追加されるため、クライアント部分が大幅に増加する可能性があります。

リソースキャッシング

クライアント側のHTTPリクエストは、アプリケーションのクライアント側の重要なパフォーマンス制限です。アプリケーションが各リソースを個別に要求する場合、すべてのリソースをダウンロードするための料金は高くなります。

クライアントアプリケーションの速度低下を防ぐために、リソースキャッシングに関連するアプローチが使用されます。

GWTにはClientBundleというメカニズムがあります。 ClientBundleは、さまざまなタイプのリソース（テキスト、グラフィック、CSSなど）をキャッシュします。 ClientBundleについてはこちらをご覧ください。

ClientBundleアプローチの利点：

必要なリソースは、使用されるたびにロードするのではなく、一度ロードされます
保管されるリソースの合計量は少なくなります

ClientBundleでリソースストレージの最小化はどのように機能しますか？

GWTでできることプレゼンテーションに戻る。その中に次の図を見ることができます：

したがって、同じデータを格納するためのオーバーヘッドが削減されます。

結果としてどのようにリソースを削減できますか？

RESTを使用したGWT RPCパフォーマンスの問題

GWT RPCは本当に便利なツールです。 IDEのサポートを受けて、サービスのクライアントコードとサーバーコードを整理するためのインターフェイスを提供することは、GWTでAJAXアプリケーションを構築する素晴らしい機能の1つです。ただし、自分に合っているかどうかを検討する価値があります。

GWT RPCを使用する場合の主な欠点は、要求に冗長なデータが過剰に追加され、デバッグが複雑になることです。

RESTの使用は、これらの問題の解決策として注目することができます。 Zack Grossbartによる記事で、GWTプロジェクトにRESTを使用する例を見つけることができます。

同時に、彼の記事 4 More GWT Anti-patternsで、RESTの主な利点に注目しています。

RESTにより、開発者はAPIについて考えるようになります。 APIは外部サービスやアプリケーションにも提供できるため、対話の利便性と機能が追加されます。
ユーザビリティテスト
クライアントとサーバーの明確な分離

レイアウトがアプリケーションに与える影響の特徴

多くの場合、gwt開発者は自動調整レイアウトを使用します。この例は、コンポーネントでのheight = "100％"の使用です。 contentHeight、offsetHeightは重い操作であると言う価値があります。以下は、Google I / O 2009の「ミリ秒単位の測定」プレゼンテーションから取得したIEH offsetHeightランタイム統計です。

操作の結果が不十分に予測されるだけではありません。 18回の測定のピーク値は、85 msのオーダーの値に達しました。

サイズ変更イベントの完全な処理には時間がかかります。多くの場合、強制レイアウトの場合のサイズ変更操作は、スタイルの再計算よりも数倍時間がかかります。

どうすればこの問題を取り除くことができますか？ CSSを使用する必要があります。 CSSで定義されたレイアウトは、より高速にレンダリングされるため、コンポーネントのDOM階層全体に対してoffsetHeightなどの重いメソッドを呼び出す必要がなくなります。

サイズ変更オプションでjavaScriptを使用しない、更新されたDockPanelを使用できます。

ネストされたウィジェットの大きなツリーを作成して保存することは強くお勧めしません。ウィジェットには追加のオーバーヘッドがあり、使用されるメモリとクライアントのサイズに悪影響を及ぼします（結果として、速度）。 HTMLPanelをソリューションとして使用できます。ページ上のウィジェットの数を追跡するために、InspectorWidgetツールがあります。プラグインのプロパティについては、そのページで確認できます。

伝送の最適化

シリアル化可能なオブジェクトは、クライアントとサーバー間で常に送信されます。開発者は自問する必要があります-最も必要なデータのみが実際に送信されますか？オブジェクトの大きなグラフ、ネストされたサブオブジェクト、および不要なパラメータのセットは貴重な時間を費やし、余分な負荷を作成します。クライアントで必要なものだけを送信します。多くの場合、ユーザーに表示されるもののみ。必要に応じて、データで必要なものをすべて入手できます。もちろん、このアプローチは、クライアント側でリソースをキャッシュするというポリシーと矛盾するべきではありません。

スケジューラを使用する

GWTには保留中の呼び出しメカニズムがあります。以前はDeferredCommandと呼ばれていましたが、非推奨と宣言されました。現在、このメカニズムはスケジューラと呼ばれています。

スケジューラは、実際にアクションを非同期に実行するためのクラスを提供します。ブラウザーのイベントループの終了後にアクションが実行されることが保証されています。

利点：

実行のスレッドをブロックしません
最初のUIイベントを完了できます。

多くの場合、スケジューラは一部のオブジェクトの構築の後半で使用されます。ただし、場合によっては、UIイベントの優先順位がより高くなるため、アプリケーションUIを適切に使用するとアプリケーションUIが高速になります。

ディスパッチャーを使用してサーバー要求を集約する

サーバーへの各呼び出しは、実行に一定の遅延を課します。サーバーに対して頻繁に複数の呼び出しを行う必要がある場合は、それらをいくつかのバッチ単位に集約できます。

バージョン2.3以降、GWTにはRequestFactoryを使用する機能があります。

 requestContext.method1().to(new Receiver<T>(){...}); requestContext.method2().to(new Receiver<T>(){...}); requestContext.fire(new Receiver<Void>(){...}); //called only 1

このアプローチの利点は明らかです-呼び出しの数が大幅に削減され、その結果、実行の遅延が発生します。

サーバーの応答をキャッシュできる場合は、キャッシュマネージャーを使用できます。リンクをクリックして、それらの使用方法を確認できます。

結論として

GWTは、優れたクロスブラウザインターフェイスを作成できる強力なツールであり、Google以外で既に広く使用されています。ただし、その最も便利なツールのいくつかは、アプリケーションのパフォーマンスに重大な制限を課しています。ユーザーがアプリケーションの操作に満足できるように、アプリケーションの速度を慎重に最適化する必要があります。

次回の記事では、パフォーマンスの改善とGWTアプリケーションの最適化の機能について引き続き話し合う予定です。特に、GWT RPC、JS Shrink、クライアントでネイティブコードを使用する機能、スクリプトのサイズを縮小するためのヒントの速度を改善する方法を検討します。また、コンパイル速度の最適化について話し、インターフェイスのレイアウトに関するヒントを提供する予定です。

ご清聴ありがとうございました！

有用なリソース：

高性能GWT。 パート1