18

なぜ HTML/Web UI の応答が WinForms/WPF/Android View/Native UI よりも遅いのですか?

ネイティブ UI には、Web UI の CSS、DOM、javascript イベント以外のスタイル、要素のネスト、イベントもあります。

イベント応答時間には、フォーカスの変更、ドロップダウン、スクロール、アニメーションの移動、アニメーションのサイズ変更などが含まれます。

DOM ツリーの挿入/置換も遅く、10000 文字の html を挿入すると、Android 4.0 の Google Chrome で 100 ミリ秒かかりますが、テンプレートの解析には 20 ミリ秒しかかかりません (jQuery マイクロ テンプレート)。

イベント応答が遅くなる最大の要因は、おそらく次のとおりです。

  1. 並列 JavaScript プロセス間の UI ロック。
  2. レンダリング エンジンは、JavaScript ワーカーからの新しい UI 変更メッセージを処理するには遅すぎます。特に、ブラウザのレンダリング エンジンが最後の UI 更新でビジー状態の場合 (ポイント 3 のため);
  3. HTML レイアウト メソッド (例: css カスケード、インライン フロー レイアウト、レスポンシブ レイアウトなど) は、部分的な UI の更新を遅くする場合があります。
  4. html/xml の解析には長い時間がかかります。ヒント: Android ビューのインフレーションは、ビルド時に行われる XML ファイルの前処理に大きく依存しています ( http://developer.android.com/reference/android/view/LayoutInflater.html ) 。

HTML および CSS 標準のサブセットは、webview アプリ開発の将来のソリューションになる可能性があります。

http://www.silexlabs.org/haxe/cocktail/

http://www.terrainformatica.com/htmlayout/

http://www.nativecss.com/

http://www.pixate.com/

https://github.com/tombenner/nui

http://steelratstory.com/steelrat-products/wrathwebkit

http://trac.webkit.org/wiki/EFLWebKit

https://github.com/WebKitNix/webkitnix

http://qt-project.org/doc/qt-4.8/richtext-html-subset.html

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

ネイティブ UI マークアップ言語の山: http://en.wikipedia.org/wiki/User_interface_markup_language

これらのネイティブ UIML を置き換える単純化された HTML 標準と単純化された Webcore レイアウト エンジンがないのはなぜですか?

kivy.org プロジェクトでサブセット html を実現できるかもしれません。

PC、Android ブラウザ = アプリケーションスレッド + UI スレッド

iOS ブラウザ = アプリケーション スレッド + UI データ スレッド + UI ハードウェア スレッド (CoreAnimation/OpenGL ES)

iOS ブラウザでは、アプリケーション スレッドが UI ハードウェア スレッドを直接呼び出すことができました。

4

5 に答える 5

16

Web UI がクライアント側の JavaScript によって完全に実装されている場合、WinForms/Native UI との違いはわずかです。

ただし、ほとんどの場合、Web UI は Web サーバーへの Web 要求をトリガーします。次に、WinForms/ネイティブ アプリと同じ効果を得るには、次の手順を実行する必要があります。

  1. HTTP リクエスト (GET/POST/...) を Web サーバーに送信する
  2. Web サーバーは、1 つまたは複数のポートをリッスンする (外部アプリまたはサービスの形式の) 実行可能ファイルです。リクエストを受信すると、それを解析して、Web アプリケーションを見つけます。
  3. Web サーバーは、アプリケーション内でバックエンド (サーバー側) ロジックを実行します。
    ASP.NET などの Web アプリケーションはプリコンパイルされています。このステップの時間の複雑さは、Windows アプリに非常に近い可能性があります。
  4. Web サーバーは結果をマークアップにレンダリングし、それをクライアントに送り返します
  5. クライアント (ブラウザ) は結果を解析し、必要に応じて UI を更新します。Web ページのコントロール/画像/その他のリソースは、通常、Windows アプリが表示をレンダリングするよりも、ブラウザー内でレンダリングするのに少し時間がかかります。

Web サーバーがローカルであっても、データの解析/フォーマット/転送で発生するコストを単純に無視することはできません。

一方、WinForms/Native UI を使用するアプリケーションは、通常、マシン コードでアクティブでホストされるメッセージ ループを維持します。UI リクエストは通常​​、メッセージ テーブルのルックアップをトリガーし、バックエンド ロジックを実行します (上記のステップ 2)。
結果を返し、UI を更新する場合、単純なバイナリ データ構造にすることができます (マークアップである必要はありません)。 、画面にレンダリングする別のアプリケーション（ブラウザ）に応答しません。

最後に、WinForms/Native アプリケーションは通常、複数のスレッドを維持して UI を徐々に更新するための完全な制御を持っていますが、Web アプリケーションはそのタイプのサーバー側リソースを直接制御することはできません。

UPDATE :
同じ Web サービスを使用して UI を部分的に更新する Web アプリケーションと Windows/WPF (またはネイティブ) アプリケーションを比較すると、

ここに画像の説明を入力

2 つの UI が応答し、無視できる速度差で更新されるはずです。UI に応答して更新するためのバイナリ実行とスクリプト実行の実装の違いはほとんどありません。
どちらの UI も、コントロール ツリーを再構築して外観全体を更新する必要はありません。同じ条件が与えられた場合、それらは同じ CPU 優先度、メモリ/仮想メモリ キャッシング、およびプロセス/スレッド レベルでのカーネル オブジェクトと GDI ハンドルの数が同じ/近い可能性があります。
この場合、おっしゃる通り、視覚的な違いはほとんどないはずです。

更新 2:
実際、Web アプリと Windows アプリのイベント処理メカニズムは似ています。DOM にはイベント バブリングがあります。同様に、MFC にはコマンド ルーティングがあります。Winforms にはイベント フローがあります。WPF には、イベント バブリングやトンネリングなどがあります。アイデアは、UI イベントが 1 つのコントロールに厳密に属していない可能性があり、コントロールにはイベントが「処理された」と主張する何らかの方法があるということです。標準コントロールの場合、フォーカスの変更、テキストの変更、ドロップダウン、スクロール イベントは、Web アプリと Windows アプリの両方で同様のクライアント側の応答時間を持つ必要があります。

パフォーマンスに関しては、レンダリングが最大の違いです。Web ページは外部アプリケーション (Web ブラウザー) によってホストされるため、Web アプリでは "デバイス コンテキスト" の制御が制限されます。Windows アプリケーションは、WPF などの GPU リソースを使用してアニメーション効果を実装し、「デバイス コンテキスト」を部分的に更新することでレンダリングを高速化できます。これが、Windows ゲーム開発者が 10 年以上 OpenGL/DirectX を使用している一方で、HTML5 キャンバスが Web 開発者を興奮させる理由です。

更新 3:
各 Web ブラウザー エンジン ( http://en.wikipedia.org/wiki/Layout_engine ) には、DOM、CSS のレンダリングの独自の実装があります。（CSS）セレクターの実装。Web ページ内で要素を移動およびサイズ変更すると、DOM、CSS (ツリー) の設定が変更されます。セレクターとレンダリングのパフォーマンスは、Web ブラウザー エンジンに大きく依存します。

  1. UI 操作により、セレクターが UI を更新するために不要な手順を実行する可能性があります。
  2. Web ページには、ブラウザーに部分的なレンダリングを行うように通知する制御がありません。

ファンシーな JavaScript コントロール (一部の jQuery UI、dojo、Ext JS) をリアルタイムで高速にすることはできず、通常は Flash コントロールよりも遅くなります。

于 2012-05-27T06:44:44.493 に答える
2

クライアントで費やされる時間は、データがネットワーク上を移動するのに費やされる時間と比較して無視できます。ブラウザーでの Windows フォームまたは Web ページの実際のレンダリング時間は、数十または数百マイクロ秒で測定されます。サーバーへのリクエストの送信と結果の取得は、ミリ秒単位で測定されます。

これは非常に簡単に確認できます。

  1. シンプルな Winforms アプリケーションを作成し、時間を計ります。
  2. 同様の Web ベースのアプリケーションを作成します。自分の PC、IE //localhost/myapp.asp の Web サーバーで実行し、時間を計ります。
  3. リモート Web サーバーで実行し、時間を計ります。

1 が最も速く、2 がそれに続き (HTML や CSS などの解釈が少し遅い)、3 はネットワーク時間が原因で非常に遅いことがわかります。

あなたの質問に答えると、違いはほぼ完全にネットワークの遅延によるもので、ローカルの処理時間よりも桁違いに大きくなります。

編集：理由を説明するコメントを追加するのは一種の反対票です。

于 2012-05-29T15:11:58.890 に答える
0

覚えておくべきことの 1 つは、ブラウザー自体がネイティブ アプリケーションであるため、ブラウザーで実行するために構築されたものは、ネイティブ実行用に直接記述されたものに対して、本質的に (少なくとも) 1 つの追加の抽象化レイヤーで記述されているということです。

次のようなダイナミクスにも注目する価値があります。

300 ミリ秒のタップ遅延、なくなりました http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

この人為的な遅延の最初の原動力は、ピンチズームと他のタッチ操作をサポートすることでした。つまり、この場合の遅い応答は、さまざまなユーザー アクションを明確にする意図的な方法でした。

確かに、これは特定のユースケースですが、一般的な概念は、ブラウザーベースの実装とネイティブの実装のさまざまな考慮事項の例として役立ちます。つまり、ブラウザーベースのエクスペリエンスには、さまざまなインタラクションとコンテンツを解決するための通常のフレームワーク コストの一部が含まれますが、ネイティブ エクスペリエンスは当然、目的のインタラクション モデルのみをリッスン/応答するように、より具体的に調整されます。

実装全体を通して、多くの小さなパーツ (このようなもの) がよりスリムになり、未加工のネイティブ バージョンにより焦点が当てられるため、応答性が向上するという一般的な効果に貢献できます。

于 2013-12-20T03:05:47.870 に答える
0

3つの大きな違い

  1. WebUI アプリはブラウザー内で実行されますが、これはブラウザーがどれだけ最適化されているかに依存します。

  2. ブラウザには、独自の javascript jvm もあります。実行する前にコードを実行して解釈する必要がある別のプロセス。

これらはすべて、ネイティブ OS の上にある追加のレイヤーです。コンピューターのアクティビティ モニターを起動し、ブラウザーで Web ページを表示すると、Web ブラウザーがリソースを大量に消費することがわかります。

  1. ネイティブ UI 要素は、グラフィック アクセラレーションをサポートしています。OS によっては、ネイティブ UI テンプレートがネイティブ形式にコンパイルされるため、レンダリングのために解析する必要はありません。
于 2013-12-19T13:42:29.540 に答える
-1

標準以下のブラウザーのみ (これには、すべての Android ブラウザー、すべての Mac OS ブラウザー、すべての Linux ブラウザー、およびすべての最悪のバージョンの Google Chrome が含まれます)。これらは、タッチスクリーンの遅延、UI の応答性、スムーズなスクロールを考慮していない、適切に作成されておらず、最適化されていないブラウザーです。それらは、あらゆる種類の CPU アクティビティ、ディスクまたはネットワーク I/O、およびユーザー入力中にロックアップしてスタッターします。

Internet Explorer 11 や iOS Safari などの優れたブラウザーは、最適化されていないネイティブ アプリよりも応答性が高い場合があります。

基本的に Windows 8.1 と iOS のみがレスポンシブ ブラウザーを備えています。UI の応答性に関する限り、他のすべてのブラウザーは劣っています。その違いは本当に大きいです。IE11と iOS Safariは、UI の遅延と滑らかさで他のブラウザーを圧倒します。

于 2013-12-18T10:51:49.187 に答える