zoukankan      html  css  js  c++  java
  • 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时,正如所想,内存泄露开始显现。

  • 相关阅读:
    CF1051F The Shortest Statement 题解
    CF819B Mister B and PR Shifts 题解
    HDU3686 Traffic Real Time Query System 题解
    HDU 5969 最大的位或 题解
    P3295 萌萌哒 题解
    BZOJ1854 连续攻击游戏 题解
    使用Python编写的对拍程序
    CF796C Bank Hacking 题解
    BZOJ2200 道路与航线 题解
    USACO07NOV Cow Relays G 题解
  • 原文地址:https://www.cnblogs.com/apem/p/4201725.html
Copyright © 2011-2022 走看看