我有一个ikimageview，我正在把cgimages（我用nsimages制作的）放到上面。然而，一个正常的200 dPi 85/11页面需要3秒的时间出现，一次出现在矩形上大约2英寸（屏幕）。这真烦人。有办法解决这个问题吗？
或者，有没有办法对视图进行双重缓冲？要有两个ikimageview并绘制成一个，然后显示它？
预计到达时间：
翻倍我的滚动视图（用IKVIEVIEWS内部），然后绘制到它们，然后取消它们，似乎没有帮助…或者，也许有点帮助，但没什么
我用乐器四处探访了一下，发现memcopy中似乎有很多工作要做：
22 commpage [libSystem.B.dylib] 78.0 __memcpy
21 ImageIO 37.0 CGImageReadGetBytesAtOffset
20 ImageIO 37.0 CGImageReadSessionGetBytes
19 ImageIO 37.0 myTIFFReadProc
18 libTIFF.dylib 37.0 TIFFReadRawStrip1
17 libTIFF.dylib 37.0 TIFFFillStrip
16 libTIFF.dylib 37.0 _cg_TIFFReadEncodedStrip
15 ImageIO 37.0 copyImageBlockSetTIFF
14 ImageIO 37.0 ImageProviderCopyImageBlockSetCallback
13 CoreGraphics 37.0 CGImageProviderCopyImageBlockSet
12 CoreGraphics 37.0 img_blocks_create
11 CoreGraphics 37.0 img_blocks_extent
10 CoreGraphics 37.0 img_interpolate_extent
9 CoreGraphics 37.0 img_data_lock
8 CoreGraphics 37.0 CGSImageDataLock
7 libRIP.A.dylib 37.0 ripc_AcquireImage
6 libRIP.A.dylib 37.0 ripc_DrawImage
5 CoreGraphics 37.0 CGContextDrawImage
4 ImageKit 37.0 -[IKImageLayer drawInContext:]
3 QuartzCore 37.0 tiled_layer_render(_CAImageProvider*, unsigned int, unsigned int, unsigned int, unsigned int, void*)
2 QuartzCore 37.0 CAImageProviderThread(void*)
1 libSystem.B.dylib 37.0 _pthread_wqthread
0 libSystem.B.dylib 37.0 start_wqthread
我不知道这告诉了我什么…
编辑：对于记录，问题不在于数据大小。我有一个旧版本的程序，它使用不推荐的quickdraw方法调用。当我将图像放大到300%时，一个屏幕像素=一个图像像素，所以它需要使用整个图像，它仍然可以一页接一页地调整大小。
我被这个最初写的人嘲笑，因为他的版本在他古老的10.3 G5上比我在最新的英特尔盒子上移动的速度快。至少快10倍。
最佳答案
200dpi 8.5/11页
假设这些是rgb颜色，那么每张图像的像素数为11.22兆字节。你的应用程序占用了大量内存，绘制374万像素（不考虑颜色空间）将会很慢。
侧面2英寸（屏幕）
好好利用这个。使用72 dpi常量和the window's user-space scale factor计算2英寸屏幕像素的数量，并将页面光栅化为该大小。目前，这些矩形将是144点在一边，一个144×144的图像是非常有效的内存和绘制。
如果您有缩放设置，您将希望在这些图像更改时使其缓存无效，并在不早于要求您的视图绘制时重新计算每个图像。