UIScrollView に問題があります。独自の行 (個別のペン先) を持つ sth のようなテーブルを作成してみます。1 ~ 10 行ではすべて問題なく動作しますが、20 を超える要素では問題が発生します。アプリケーションの動作が遅くなり、スタントします。100 ~ 200 個の独自のサブビューのスクロール ビューを最適化するソリューションはありますか?
2 に答える
を使用しUITableView
ます。それがまさにそのために設計されたものです。
UITableView and UICollectionView are both optimizing by removing subviews that are no longer needed and putting them in a reuse queue. By reusing those views the system does not have to create and destroy their backing layers but can reuse them. This way you only have ever as many subviews on screen as can fit.
Typically you want to add/remove visible subviews in either the layoutSubviews of a scroll view subclass or the corresponding didScroll delegate method. Personally I prefer the layoutSubviews since it is a bit earlier in the chain of events.
Basically you would get a reusable subview from your reuse queue as soon as at least 1 px of the subview should appear within the bounds of the scroll view and remove the subview as soon as no pixel of it is visible any more.
If you use UITableview or UICollectionView instead of a plain scroll view they provide a mechanism to register views in NIB for certain reuse identifiers and then the dequeueing will automatically load a new instance of a subview from NIB is none is queue or dequeue one if there is.