最近从4s换回3GS，测试TavleView插图非常卡，于是测试了一下，发现initWithContentsOfFile并不是造成卡顿的主凶。因为这个动作本来就不在main queue里边的。而setImage必须是在main queue。于是写代码在本地生成一些更小的缩略图例如原本240px的直接缩放成80px，发现会快得多。

我的解决方法是：
1、写代码在http下载图片的complete block里面顺便把图片缩放成另外一个大小，另存一份。
2、cell for row代码：

//先把id记录下来，这是在cell里面加的property
cell.objectIdforThisCell=**这个cell所代表的对象的id**;

//在这个block里面的id，到这一步是设置为cell.objectIdforThisCell一样的
NSString *blockObjectid=cell.objectIdforThisCell;
        
        dispatch_async(imagequeue, ^{
            UIImage *image = [[UIImage alloc] initWithContentsOfFile:小图文件path];
            dispatch_async(dispatch_get_main_queue(),
                           ^{
                               [self setImage:image forState:state];
                           });
            
            image = [[UIImage alloc] initWithContentsOfFile:大图文件path];
            dispatch_async(dispatch_get_main_queue(),
                           ^{
                               if ([cell.objectIdforThisCell isEqualToString:blockObjectid]) {


                                   //关键在这里，当列表拖动速度很快的时候，cell的property已经被修改（因为reuse了），但是blockObjectid在这个线程里面还是旧的。
                                   //当它们****不相等****，这个cell就是刷太快而被另外一个线程用上了，也就是说，这张大图已经不再需要输出到cell里面了（被另外一个线程的另外一张图冲掉了）
                                   //这样一来，在列表快速拖动的时候，瞬间把低清晰的图像给贴上去，等拖动速度慢下来之后，再贴高清晰的图，用户也感觉不出来，也不卡了。


                                   [self setImage:image forState:state];
                               }
                           
                           });
        });
        
        dispatch_release(imagequeue);

把图片变小:

CGSize newSize=CGSizeMake(80, 80);
UIGraphicsBeginImageContextWithOptions(newSize, NO, 0.0);
[img drawInRect:CGRectMake(0, 0, newSize.width, newSize.height)];
newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

先在其他线程做async loading，就是其中的initWithContentsOfFile,然后当image loading完了再调用主线程update UI.

dispatch_queue_t imagequeue = dispatch_queue_create("com.company.imageLoadingQueue", NULL);
    
    // Start the background queue
    dispatch_async(imagequeue, ^{
      UIImage *image = [[UIImage alloc] initWithContentsOfFile:fullPath];
      dispatch_async(dispatch_get_main_queue(),
           ^{
               [self setImage:image forState:state];
            }); //end of main thread queue
    }); //end of imagequeue

    dispatch_release(imagequeue);

把图片等比例缩小。网络加载大图片必然要卡，SDWebImage这个开源项目也是去缩小图片的。

我觉得，你这个问题不处在UIButton的渲染上。根据我的经验，这种情况造成的卡，有两个点要去优化：

1. 单独控件（一个UIButton）内的对象数量。这方面你不存在问题，一个Cell一个UIButton，一个UIButton一个UIImage
2. 单独UIImage对象内的图片大小。我遇到的问题是在iPad1或2上使用了兼容iPad3而采用的高分图片造成的卡

我想这两个问题你都不存在，那么问题就处在你的图片载入顺序不合理。看你的描述不知道你是UITableView还是用UIScrollView实现的瀑布流，如果是UITableView，就没必要用Button了，因为每个Cell都是可点击的。如果是UIScrollView实现的瀑布流，优化余地较大。这里假设你是瀑布流的图片

1. 降低刷新频率。通过UIScrollView的代理方法，没滚动超过100或200像素，才检测一次可视区域，刷新控件。
2. 适时地回收控件。我们认为用户单方向滑动ScrollView的时候是一种趋势，也就是说当向下滑动到某一位置，那么意味着他即将继续向下滑动。因此一般建议向用户滑动方向一屏幕高度，反向半屏幕高度，加当前屏幕高度，供2.5屏幕高度的位置是活跃区域，活跃区域意外的控件，你这里就是一个UIButton，回收，放进一个池，等待复用。
3. 复用回收的空间。当非活跃区域进入状态，从池内提取控件，载入数据，进行显示。这样可以保证不论用户如何操作，总能保证整个界面只有固定数量控件，不会占用过多内存。
4. 图片数据尽量放在内存里。图片缓存不要全部放进闪存，尽量放进内存，当内存储存一定数量后再回写。内存操作性能远远高于闪存，频繁的的闪存操作性能很低。

最后还有一个牺牲体验提升性能的方案。对于部分低配置设备（如iPhone3GS，iPad1）等，采用滑动过程不加载，滑动停止才加载的方案。