私は jQtouch アプリを開発しています。ajax を介して行われる各リクエストは、読み込まれたコンテンツのドキュメントに新しい div を作成します。一度に 1 つの div のみが表示されます。
アプリが応答しなくなり遅くなる前に、いくつの div を使用できますか?
誰でもこれについて何か考えがありますか?
編集:Safariで実行されているiPadアプリで、非常に基本的なコンテンツで1000未満のdivになります
一度に数万、場合によっては 10 万の div が画面に表示されました。パフォーマンスは、以下に応じて良好または不良のいずれかになります。
HTML から解析するか、JavaScript で動的に生成しますか?
HTML から解析されるということは、HTML ソースが大きいことを意味し、ブラウザがハングアップする可能性があります。Generated in JS は、JS 用のすべてのブラウザーの中で最も遅い Internet Explorer でも驚くほど高速です。
正直なところ、この質問に対する絶対的な答えが本当に必要な場合は、設計を再検討することをお勧めします。
アプリケーションに固有の多くの要因に依存するため、ここでの答えは正しくありません。たとえば、CSS の使用量が多いか少ないか、div のサイズ、div ごとに必要な実際のグラフィックス レンダリングの量、ターゲット ブラウザー/プラットフォーム、DOM イベント リスナーの数など.
できるからといって、そうしなければならないわけではありません。:-)
他の方もおっしゃっていますが、正解はありません。
ただし、Google Maps API バージョン 3 に関するこの講演では、スピーカーは、ブラウザーの不満の基本的なしきい値として、1 万回という数字を何度も取り上げています。
特定の環境を定義しないと、質問に答えることができません。
それでも、誰かがあなたに言うことはすべて推測にすぎません。さまざまなブラウザーとハードウェアを使用して、実際の構成で独自のテストを行う必要があります。また、「遅すぎる」とはどういう意味かを判断するために、いくつかのパフォーマンス ベンチマークを確立する必要があります。
問題なく数千の div を追加できました。もちろん、後で何をするか、およびクライアントマシンのメモリに依存します。他の誰もがそれについて正しいです。
Harpo が言ったように、10K はおそらく適切な上限です。一時期、約 4K div から速度の問題に気付きましたが、ハードウェアはその後改善されました。
そして、Neil N が言ったように、スクリプトを使用して div を追加することは、巨大な HTML ソースを持つよりも優れています。
そして、Harpo のコメントに答えるために、JS がページをロックして「ページの実行が遅い」というエラーを生成しないように「分割」する 1 つの方法は、各「div の追加」ルーチンの最後にタイマーを呼び出すことです。 、そしてタイマーは今度はあなたの「divを追加」関数を再び呼び出します。
さて、私の質問は、何千もの div を追加する必要がないように「ペイント」することは可能ですか? これは、一部のブラウザーでは canvas タグで実行できますが、IE の VML (excanvas プロジェクト) では実行できないと思います。またはそれは?VML は新しい要素を DOM に追加することで「ペイント」すると思います。その時点で、単純な形状でない限り、DIV を使用することもできます。
スクリプトを使用して画像のソースを変更することは可能ですか? (もちろん、サーバー上の元の画像ではなく、DOM 内の画像です。)