问题描述

在使用 UITableView 时，我们可以使用 [[ UITableViewCell alloc] initWithStyle: reuseIdentifier:] 和 [uiTableViewInstance dequeueReusableCellWithIdentifier:] 方法重用它的单元格.这有助于检查大型表格的内存，因为在给定的时刻视图中只有几个单元格.

When using UITableView, we can reuse its cells using [[ UITableViewCell alloc] initWithStyle: reuseIdentifier:] and [uiTableViewInstance dequeueReusableCellWithIdentifier:] methods. This helps keep memory in check for huge tables as only a few cells are there in the view at a given instant.

我想创建一个有很多子视图的 UIScrollView.插入所有子视图会占用我想要避免的大量内存和初始时间.Apple API 是否提供了重用此类自定义组件(此处为 UIView 或其子类)的方法，就像使用标识符的单元格视图一样?

I want to create a UIScrollView that has many subviews. Inserting all the subviews takes up a lot of memory and initial time that I want to avoid. Does Apple API provides ways to reuse such custom components (a UIView or a subclass of it here) just like cell views using a identifier?

如果没有 API，我会创建一个，但对此有一些疑问.例如，对于每个新的子视图，我都在 previos 视图之后设置它的框架位置.回收时我应该如何更新每个子视图的框架?我应该在每个子视图被回收时删除并重新加载它的内容吗?我应该在另一个线程中进行所有这些计算以避免生涩的滚动吗?总而言之，我希望在 UITableView 中获得流畅的滚动体验，并包含所有重用内容.

I will create one if there is no API, but have some doubts regarding this. For example, for every new subview, I am setting its frame position, after the previos views. How should I go about updating the frame for each subview while recycling? Should I delete and reload the content of every subview as it gets recycled? Should I do all these calculations in another thread to avoid jerky scrolling? In all, I would like to have a smooth scrolling experience like in UITableView with all the reusing stuff.

这是我目前编写的代码示例:

Here is a sample of code that I have written so far:

int numberOfPages = 0;
int pageWidth = 100;
int pageHeight = 100

UIScrollView *myScrollView = //allocate and initialize a scrollview
//set its size to 100 by 100 (width equal to pageWidth)
//set paging enabled for myScrollView

通过多次调用的方法向其添加子视图

Adding subviews to it from a method, that is called multiple times

- (void) appendSubViewToScrollView {
    UIView *view = //allocate and initialize a view and dump data in it.

    CGRect rect = view.frame;
    rect.size.height = pageHeight;
    rect.size.width = pageWidth;
    rect.origin = CGPointMake(pageHeight * numberOfPages, 0);
    view.frame = rect;

    [myScrollView addSubview:view];

    numberOfPages++;

    [scrollView setContentSize:CGSizeMake(pageHeight * numberOfPages, pageWidth)];

    [view release];
}

深入了解 tableview 及其单元格如何在幕后实现这一点会很有用.

Some insight into how tableview and its cells achieve this behind the scenes would be useful.

推荐答案

是的，你应该每次都恢复每个子视图的内容，就像在表格视图中一样.回收子视图的优点是节省了视图存储的内存，节省了视图分配的时间，但当然内容数据管理取决于您.

Yes, you should restore each subview content each time, exactly as in the table view. The advantage of recycling subviews is in memory saving for view storage, and time saving for view allocation, but of course content data management is up to you.

因此，标准回收方法要求您使用的单元格数量等于屏幕上同时可见的视图数量 + 开始滚动时可能获得的额外单元格数量.例如，假设您一次显示 5 个完整视图(滚动视图稳定)，然后在滚动时您将需要一个部分显示的额外视图，因此最后您需要 5+1=6 个视图.这是理论上的，建议多使用2个视图.因此，您需要编写两个池:一个称为visibleViews"，由作为子视图添加到滚动视图的所有视图组成，另一个称为availableViews"，由所有可重复使用的视图组成.然后创建所有这些视图并将它们添加到滚动视图(是的:您需要根据它们在滚动视图中的位置调整它们的框架，是的，您需要再次设置内容).最后，您需要通过设置委托来跟踪滚动视图的移动.此跟踪的目的是计算哪些可见视图不再可见，然后将其从可见池中移除并移至可用池.此外，代表必须了解何时会出现一个新单元格但它仍然不可见，然后从可用池中获取它(或者如果池为空，则分配/初始化它)并将其添加到可见池和作为子视图滚动视图.当然，如果你想提高性能，你可以在滚动视图中放置更多的子视图，以避免在单元格开始出现在屏幕上时准确地移动它们，这就是为什么我建议在滚动视图的两侧使用几个额外的视图.

So the standard recycling approach requires you to use a number of cells which is equal to the number of views visible at the same time on screen + the number of extra cells you may get when starting scrolling. Let's say for example you're showing 5 full views at a time (scroll view stable) and then while scrolling you will need one extra view which is partially shown, so at the end you need 5+1=6 views. This is in theory, it is recommended to use 2 more views. So you need to write two pools: one called "visibleViews" which is made of all views added as subviews to the scrollview, and another one called "availableViews" which is made of all views available for re-use. Then you create all these views and add them to the scroll view (yes: you need to adjust their frame according to their position in the scrollview, and yes, you need to setup the content again). Finally you need to track the scroll view movement by setting a delegate. The purpose of this tracking is to calculate which of the visible views is no more visible, then remove it from the visible pool and move to the usable pool. Besides the delegate must understand when a new cell is going to appear but it is still not visible, then getting it from the available pool (or alloc/init it if the pool is empty) and adding to both the visible pool and as subview of the scrollview. Of course if you want to increase performance you can place more subviews in the scroll view in order to avoid to move cells exactly when they start appearing on screen, that's why I recommended to use a couple of extra views at the sides of the scroll view.

WWDC 2010 上有一个很棒的视频(如果您是注册开发者，您可以访问它)关于在 iOS 中使用滚动视图:它解释了这项技术.

There is a great video from WWDC 2010 (you can access it if you're a registered developer) about usage of scroll views in iOS: it explains this technique.

XCode 文档中 Apple 的 PhotoScroller 示例代码基本上实现了 WWDC 视频中所述的内容并解释了该技术.

The Apple's PhotoScroller example code in the XCode documentation does essentially what is stated in the WWDC video and explains this technique.