画像のグリッドを持つ UIScrollView があります。現在は 6 人ですが、いつかは数百人になるかもしれません。もちろん、その UIScrollView 内に数百の UIImageView オブジェクトを作成し、それらすべてを画像データで埋めるのは悪い考えです。Apple docs のどこかでこれを読んでいたと思います。スクロール可能な表示領域を埋める必要があるため、非常に多くの要素のみを作成することをお勧めします。
しかし、UIImageView 要素を即座に再配置すると、パフォーマンスの問題が発生するのではないかと心配しています。おもう。ユーザーが下にスクロールし始めると (0,0 から始まると仮定しましょう)、上部の可視領域からはみ出す UIView オブジェクトを再配置し、それらをすばやく下部に配置してから、非常に (!! ) 行内のその UIImageViews に新しい画像オブジェクトをすばやく追加します。つまり、ユーザーが野生のガゼルのようにどんどん速くスクロールし始めたらどうなるでしょうか。
それを行うためのあなたのアプローチはどうですか？
UIScrollView (または実際には UIKit) は、変更されないものを再描画しないという点で非常に優れています。画面外 (または切り取られた) ビューのみを移動 (または削除してリサイクル) する場合、再描画は発生しません。サブビューを画面外に追加することも同様です。
ページングを有効にしていない場合は、おそらく UIView が提供するより高速な描画コードを実装する必要があります。ただし、最初にテストします。iPhone の物理的な制限により、スクロールがある程度制限されます。
同様の小規模な状況では、データセット全体ではなく、スクロールビューのサイズに必要以上にロードすることでこれに対処しました。私は水平方向にのみスクロールしていましたが、現在表示されている画像の両側に 1 つまたは 2 つの画像を読み込むと、スムーズに表示されることがわかりました。1 つしか表示されていない場合でも、3 つまたは 5 つの画像を読み込むことになりますが、何十もの画像を読み込むよりははるかに優れています。可視領域の周りにどの程度の傾斜を許容する必要があるかを確認するには、少し実験する必要があります。
画像の動的なロード/アンロードは、スクロール ビューのデリゲート メソッドで処理するのが最適です。