如何重用/回收像uitableviewcell这样的自定义元素呢？
使用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，它由作为子视图添加到scrollview的所有视图组成，另一个名为availableViews，由所有可用于重复使用的视图组成。
然后你创建所有这些视图并将它们添加到滚动视图（是的：你需要根据它们在scrollview中的位置调整它们的帧，是的，你需要再次设置内容）。
最后，您需要通过设置委托来跟踪滚动视图移动。此跟踪的目的是计算哪些可见视图不再可见，然后将其从可见池中删除并移至可用池。除了委托必须了解新单元格何时出现但仍然不可见，然后从可用池中获取它（如果池为空则为alloc / init）并添加到可见池和子视图中滚动视图。
当然如果你想提高性能，你可以在滚动视图中放置更多的子视图，以避免在它们开始出现在屏幕上时准确移动单元格，这就是为什么我建议在侧面使用一些额外的视图滚动视图。
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.