iOS 卡顿总结优化

1.除了UI部分，所有的加载操作都在后台完成。

1.1  文本计算

          如果一个界面中包含大量文本，文本的宽高计算会占用很大一部分资源，并且不可避免。如果你对文本显示没有特殊要求，可以参考下 UILabel 内部的实现方式：用 [NSAttributedStringboundingRectWithSize:options:context:] 来计算文本宽高，

        用 -[NSAttributedStringdrawWithRect:options:context:] 来绘制文本。尽管这两个方法性能不错，但仍旧需要放到后台线程进行以避免阻塞主线程。

        如果你用 CoreText 绘制文本，那就可以先生成 CoreText 排版对象，然后自己计算了，并且 CoreText 对象还能保留以供稍后绘制使用。

1.2文本渲染

       屏幕上能看到的所有文本内容控件，包括 UIWebView，在底层都是通过 CoreText 排版、绘制为 Bitmap 显示的。常见的文本控件 （UILabel、UITextView 等），其排版和绘制都是在主线程进行的，当显示大量文本时，CPU 的压力会非常大。对此解决方案只有一个，那就是自定义文本控件，用 TextKit 或最底层的 CoreText 对文本异步绘制。

        尽管这实现起来非常麻烦，但其带来的优势也非常大，CoreText 对象创建好后，能直接获取文本的宽高等信息，避免了多次计算（调整 UILabel 大小时算一遍、UILabel 绘制时内部再算一遍）；CoreText 对象占用内存较少，可以缓存下来以备稍后多次渲染。

1.3图片的解码

       用 UIImage 或CGImageSource 的那几个方法创建图片时，图片数据并不会立刻解码。图片设置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的数据才会得到解码。这一步是发生在主线程的，并且不可避免。如果想要绕开这个机制，常见的做法是在后台线程先把图片绘制到 CGBitmapContext 中，然后从 Bitmap 直接创建图片。目前常见的网络图片库都自带这个功能。

 1.4图像的绘制

        图像的绘制通常是指用那些以 CG 开头的方法把图像绘制到画布中，然后从画布创建图片并显示这样一个过程。这个最常见的地方就是 [UIView drawRect:] 里面了。由于CoreGraphic 方法通常都是线程安全的，所以图像的绘制可以很容易的放到后台线程进行。一个简单异步绘制的过程大致如下（实际情况会比这个复杂得多，但原理基本一致）：

 

 

- (void)display {

    dispatch_async(backgroundQueue,^{

        CGContextRef ctx =CGBitmapContextCreate(...);

        // draw in context...

        CGImageRef img =CGBitmapContextCreateImage(ctx);

        CFRelease(ctx);

        dispatch_async(mainQueue, ^{

            layer.contents = img;

        });

    });

}

 

可以通过dispatch或者performSelectorInBackground或者NSOperationQueue来实现。

 1.5   I/o操作

        文件读写

        网络

 

2. 避免后台加载完成多个资源之后集中到达占用UI线程的处理时间太长。（短时间内UI集中刷新）

        通过NSOperationQueue来实现，将资源到UI的展现过程放在队列中逐个执行，且在每个操作完成之后进行强制等待，可以用usleep(int microSeconds)来解决。

3.线程数太多

 原因：

      （1）大量的任务提交到后台队列时，某些任务会因为某些原因被锁住导致线程休眠，或者被阻塞。

      concurrentqueue 随后会创建新的线程来执行其他任务。

        当这种情况变多时，或者 App 中使用了大量 concurrent queue 来执行较多任务时，App 在同一时刻就会存在几十个线程同时运行、创建、销毁。

         CPU 是用时间片轮转来实现线程并发的，尽管 concurrent queue 能控制线程的优先级，但当大量线程同时创建运行销毁时，这些操作仍然会挤占掉主线程的 CPU 资源。

     （2）线程数量达到 64个，导致也是导致卡顿的原因。

 

4 使用lock 时 ，不能Unlock 造成

 解决方式： 使用自旋锁，递归锁。

-(void) dispatch_reentrant(void(^block)())

{

   staticNSRecursiveLock *lock = nil;

   staticdispatch_once_t onceToken;

  dispatch_once(&onceToken, ^{

     lock =[[NSRecursiveLock alloc]init];

   });

   [locklock];

  block();

   [lockunlock];

}

 

  dispatch_queue_t queueA = dispatch_queue_create("com.queueA", NULL);

  dispatch_block_t block = ^{

     //do something

   };

  dispatch_sync(queueA, ^{

    dispatch_reentrant(block);

   }); 

 

5 使用 GCDdispatch_sync 死锁卡顿

 

queueA—>queueB—>queueA

 

- (void)deadLockFunc

{

   dispatch_queue_t queueA =dispatch_queue_create("com.queueA", NULL);

   dispatch_queue_t queueB =dispatch_queue_create("com.queueB", NULL);

   dispatch_sync(queueA, ^{

     dispatch_sync(queueB, ^{

       dispatch_block_t block = ^{

         //do something

       };

       func(queueA, block);

     });

   });

}

解决方式， FMDB，AFNetWork 中 采用dispatch_queue_set_specific  ，dispatch_get_specific标记 队列 ，然后 进行判断处理，或给出log告警

 dispatch_queue_t queueA =dispatch_queue_create("com.queueA", NULL);

   dispatch_queue_t queueB =dispatch_queue_create("com.queueB", NULL);

  dispatch_set_target_queue(queueB, queueA);

  

   static int specificKey;

   CFStringRef specificValue =CFSTR("queueA");

  dispatch_queue_set_specific(queueA,

                 &specificKey,

                 (void*)specificValue,

                (dispatch_function_t)CFRelease);

  

   dispatch_sync(queueB, ^{

     dispatch_block_t block = ^{

         //do something

     };

     CFStringRef retrievedValue =dispatch_get_specific(&specificKey);

     if (retrievedValue) {

       block();

     } else {

       dispatch_sync(queueA, block);

     }

   });

 

6  视图的混合 

       当多个视图（或者说 CALayer）重叠在一起显示时，GPU 会首先把他们混合到一起。如果视图结构过于复杂，混合的过程也会消耗很多 GPU 资源。为了减轻这种情况的 GPU 消耗，应用应当尽量减少视图数量和层次，并在不透明的视图里标明 opaque 属性以避免无用的 Alpha 通道合成。当然，这也可以用上面的方法，把多个视图预先渲染为一张图片来显示。

7  主线程中UI对象创建

      对象的创建会分配内存、调整属性、甚至还有读取文件等操作，比较消耗 CPU 资源。尽量用轻量的对象代替重量的对象，可以对性能有所优化。

          比如 CALayer 比 UIView 要轻量许多，那么不需要响应触摸事件的控件，用 CALayer 显示会更加合适。如果对象不涉及 UI 操作，则尽量放到后台线程去创建，但可惜的是包含有 CALayer 的控件，都只能在主线程创建和操作。

·      

参考： http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/