1

ユーザーが編集可能なアイテムの大きなテーブルを表示するページを持つ Web アプリケーションを構築しています。このテーブルには、行を上下に移動するための各行のコントロールと、行を削除するためのオプションがあります。また、各行には 2 つの select 要素があります。

このテーブルは、極端な状況では約 200 行で構成される可能性があります。多くの行がある場合、重大なパフォーマンスの問題が発生します。ページのスクロールが信じられないほど遅く、画面に「チェッカーボックス」が表示されます。また、行の削除には約 30 秒、場合によってはそれ以上かかります! 上下に移動するのにも同様の時間がかかり、ページは通常使用できません。

問題が何であるかを正確に絞り込もうとしてきましたが、行からこれらを削除すると、テーブル内の選択要素に関係していると確信しています。スクロールは完璧で、上下の移動は約 1 秒、行の削除は約 7 秒です。

200 行のテーブルの一番下から 1 行削除すると、ほぼ瞬時に削除されます。

ページの CSS に問題があるようです。プロファイラーを実行すると、スタイルの再計算に約 3 秒かかります。

このページは他のブラウザでも問題なく動作します。ヘルプや知識があれば幸いです。

ありがとう

4

2 に答える 2

0

iOS 6 の Web アプリにはいくつかのテーブルがあり、そのうちのいくつかにはテキストのみの読み取り専用として数百行が含まれていますが、一部には SELECT 要素も含まれています。

table-layout を固定に設定すると、パフォーマンスに多大な影響がありました。大きなテーブルの一部には、デフォルトの動的なテーブル幅の計算で大きなレンダリングの問題がありましたが、これまで解決できていませんでした。これは特に、行にチェックボックスが含まれている場合に当てはまりました。

たとえば、一部のテーブルで最後の行がレンダリングされなかったり、テーブルが下部近くで切り取られていたりしました。

縦向きモードには特別なスタイルシートを使用します。これにより、TABLE 要素と TD 要素の幅が変更され、一部の列も完全に削除されます。

これは非常にうまく機能し、これまでのところ副作用や問題は発生していません.

スクロールには、定義された高さを持ち、「-webkit-overflow-scrolling: touch」を使用するテーブルを囲む特別な DIV 要素を使用します。約 850 のエントリを持つ最大のテーブルでさえ、パフォーマンスの低下やちらつきなしにスクロールします。

いつテーブルをレンダリングしますか? ページのレンダリング/準備/読み込みイベント中? 「innerHTML」割り当てを使用しますか、それともロジックで DOM ツリーを作成しますか?

于 2012-12-11T16:27:31.707 に答える
-1

table-layout:fixed;テーブル (スタイルシート内) のスタイル プロパティとして設定すると、応答が速くなる場合があります。ブラウザが行う計算は少なくて済みますが、欠点は、列幅を自分で指定する必要があることです。

于 2012-12-06T15:06:30.847 に答える