IOS造成卡顿的主要原因

1. cellForRowAtIndexPath, 单元格视图重用,

注意尽量让所有视图重用, 只根据单元格row和section的不容更换不同的数据, 而不是每次都生成新的单元格, 这是程序奔溃的前兆

2. 不要使用阴影

//    //设置阴影
//    _contentV.layer.shadowOffset = CGSizeMake(0, 1);
//    _contentV.layer.shadowColor = UIColorFromRGB(0x111111).CGColor;
//    _contentV.layer.shadowOpacity = 0.3;
//    _contentV.layer.shadowRadius = 0.5;

 以上的代码永远不要使用

3. loadView, viewDidLoad, viewDidAppear

这三个方法时间顺序从左到右递增

一些跟数据有关系的耗时较长的视图或操作放在viewDidAppear

4.NSDictionary

for (NSInteger i = 0;i < 10000;i ++ ) {
  _propertyArray = [nsdictionary allKeys];  
}

 大批量的调用

[nsdictionary allKeys], 会消耗很多内存, 而且无法回收, 要慎用

 

5.可变对象不能直接使用, 否则导致内存泄露

NSString *string = [[NSString alloc] initWithString:@"Leaker"];

原因是这样的，NSString本身是不可以修改的，我们使用了@操作符分配了字符串的内存之后，编译器帮助我们提高了程序的效率。编译器自动把具有相同内容的字符串分配了相同的地址。

（Cocoachina解释：也就是说 string 和 @"Leaker"的地址通过编译器编译后，是同一个，而如果你看过之前的文章，你就会知道”Leaker”这个字符串在程序运行期间是永远不会被释放的，这样一来，string也就不用释放，也就不存在内存泄露问题了。但是这仅仅是编译器的优化，并不能保证任何情况下都是这样。）

在这段例子代码中，NSString永远不会泄露，那这段例子也就没什么用了。并不是说这种写法的NSString永远不会泄露，所以你应该习惯地在不需要NSString时，调用-release方法去释放它们。不过在我们的测试里，NSString的内存泄露从来没有被检测到。而当我们把NSString换成NSMutableString时，正如所想，内存泄露开始显现。