在性能优化中一个最具参考价值的属性是FPS:FramesPerSecond,其实就是屏幕刷新率，苹果的iphone举荐的刷新率是60Hz，也就是说GPU每秒钟刷新屏幕60次，这每刷新一次就是一帧frame，FPS也就是每秒钟刷新多少帧画面。静止不变的页面FPS值是0，这个值是没有参考意义的，只有当页面在执行动画或者滑动的时候，FPS值才具备参考价值，FPS值的大小体现了页面的晦涩水平高下，当低于45的时候卡顿会比拟显著。

图层混合：

每一个 layer是一个纹理，所有的纹理都以某种形式重叠在彼此的顶部。对于屏幕上的每一个像素，GPU须要算出怎么混合这些纹理来失去像素 RGB的值。

当 Sa = 0.5时，RGB值为(0.5,  0, 0)，能够看出，当两个不是齐全不通明的 CALayer笼罩在一起时,GPU大量做这种复合操作，随着这中操作的越多，GPU越繁忙，性能必定会受到影响。

公式：

R = S + D * ( 1 – Sa )

后果的色彩是源色调(顶端纹理)+指标色彩(低一层的纹理)*(1-源色彩的透明度)。
当 Sa = 1时，R = S,GPU将不会做任何合成，而是简略从这个层拷贝，不须要思考它下方的任何货色(因为都被它遮挡住了)，这节俭了 GPU相当大的工作量。

一、入门级

1、用 ARC治理内存

2、在正确的中央应用  reuseIdentifier

3、尽量把 views设置为通明

4、防止过于宏大的  XIB

5、不要阻塞主线程

6、在 ImageViews中调整图片大小。如果要在 UIImageView中显示一个来自  bundle的图片，你应保障图片的大小和 UIImageView的大小雷同。在运行中缩放图片是很消耗资源的，特地是 UIImageView嵌套在
UIScrollView中的状况下。如果图片是从远端服务加载的你不能管制图片大小，比方在下载前调整到适合大
小的话，你能够在下载实现后，最好是用  backgroundthread，缩放一次，而后在 UIImageView中应用缩放后的图片。

7、抉择正确的 Collection。

  • Arrays:有序的一组值。应用  index来  lookup很快，应用  value lookup很慢，插入/删除很慢。
  • Dictionaries:存储键值对。用键来查找比拟快。
  • Sets:无序的一组值。用值来查找很快，插入/删除很快。

8、关上 gzip压缩。app可能大量依赖于服务器资源，问题是咱们的指标是挪动设施，因而你就不能指望网
络情况有多好。减小文档的一个形式就是在服务端和你的 app中关上 gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。
iOS曾经在  NSURLConnection中默认反对了 gzip压缩，当然  AFNetworking这些基于它的框架亦然。

二、中级

1、重用和提早加载(lazy load) Views

  • 更多的  view意味着更多的渲染，也就是更多的 CPU和内存耗费，对于那种嵌套了很多view在
    UIScrollView里边的  app更是如此。
  • 这里咱们用到的技巧就是模拟 UITableView和 UICollectionView的操作:不要一次创立所有的 subview，
    而是当须要时才创立，当它们实现了使命，把他们放进一个可重用的队列中。这样的话你就只须要在滚动产生时创立你的 views，防止了不划算的内存调配。

2、Cache, Cache,还是   Cache!

  • 一个极好的准则就是，缓存所须要的，也就是那些不大可能扭转然而须要常常读取的货色。
  • 咱们能缓存些什么呢？一些选项是，远端服务器的响应，图片，甚至计算结果，比方 UITableView的行高。
  • NSCache和  NSDictionary相似，不同的是零碎回收内存的时候它会主动删掉它的内容。

3、衡量渲染办法.性能能还是要 bundle放弃适合的大小。

4、解决内存正告.移除对缓存，图片 object和其余一些能够重创立的 objects的  strong references.

5、重用大开销对象

6、一些 objects的初始化很慢，比方 NSDateFormatter和  NSCalendar。然而，你又不可避免地须要应用它们，比方从 JSON或者 XML中解析数据。想要防止应用这个对象的瓶颈你就须要重用他们，能够通过增加属性到你的 class里或者创立动态变量来实现。

7、防止重复解决数据.在服务器端和客户端应用雷同的数据结构很重要。

8、抉择正确的数据格式.解析 JSON会比 XML更快一些，JSON也通常更小更便于传输。从 iOS5起有了官网内建的 JSON deserialization就更加方便使用了。然而  XML也有  XML的益处，比方应用  SAX来解析  XML就像解析本地文件一样，你不需像解析 json一样等到整个文档下载实现才开始解析。当你解决很大的数据的时候就会极大地减低内存耗费和减少性能。

9、正确设定背景图片

  • 全屏背景图，在 view中增加一个 UIImageView作为一个子   View
  • 只是某个小的 view的背景图，你就须要用  UIColor的 colorWithPatternImage来做了，它会更快地渲染
    也不会破费很多内存。

10、缩小应用 Web个性。想要更高的性能你就要调整下你的 HTML了。第一件要做的事就是尽可能移除不必要的 javascript，防止应用过大的框架。能只用原生 js就更好了。尽可能异步加载例如用户行为统计  script这种不影响页面表白的 javascript。留神你应用的图片，保障图片的合乎你应用的大小。

11、Shadow Path。CoreAnimation不得不先在后盾得出你的图形并加好暗影而后才渲染，这开销是很大的。应用 shadowPath的话就防止了这个问题。应用 shadow path的话  iOS就不用每次都计算如何渲染，它应用一个事后计算好的门路。但问题是本人计算 path的话可能在某些 View中比拟艰难，且每当  view的   frame变动的时候你都须要去 update shadow path.

12、优化 Table View

  • 正确应用 reuseIdentifier来重用  cells
  • 尽量使所有的 view opaque，包含 cell本身
  • 防止突变，图片缩放，后盾选人
  • 缓存行高
  • 如果 cell内事实的内容来自 web，应用异步加载，缓存申请后果
  • 应用 shadowPath来画暗影
  • 缩小 subviews的数量
  • 尽量不实用 cellForRowAtIndexPath:，如果你须要用到它，只用-一次而后缓存后果
  • 应用正确的数据结构来存储数据
  • 应用 rowHeight, sectionFooterHeight和   sectionHeaderHeight来设定固定的高，不要申请   delegate

13、抉择正确的数据存储选项

  • NSUserDefaults的问题是什么？尽管它很  nice也很便捷，然而它只实用于小数据，比方一些简略的布尔型的设置选项，再大点你就要思考其它形式了
  • XML这种结构化档案呢？总体来说，你须要读取整个文件到内存里去解析，这样是很不经济的。应用SAX又是一个很麻烦的事件。
  • NSCoding？可怜的是，它也须要读写文件，所以也有以上问题。
  • 在这种利用场景下，应用 SQLite或者   Core Data比拟好。应用这些技术你用特定的查问语句就能只加载你须要的对象。
  • 在性能层面来讲，SQLite和  Core Data是很类似的。他们的不同在于具体应用办法。
  • Core Data代表一个对象的 graph model，但 SQLite就是一个  DBMS。
  • Apple在个别状况下倡议应用  Core Data，然而如果你有理由不应用它，那么就去应用更加底层的  SQLite吧。
  • 如果你应用 SQLite，你能够用 FMDB这个库来简化 SQLite的操作，这样你就不必花很多经验理解   SQLite的 C API了。

三、高级

首先作为一个开发者，有一个学习的气氛跟一个交换圈子特地重要，这是一个我的ioser公众号：编程大鑫，不论你是小白还是大牛都欢送入驻 ，让咱们一起提高，独特倒退！（会收费提供一些群主珍藏的收费学习书籍材料以及整顿好的几百道面试题和答案文档！）

1、减速启动工夫。疾速关上 app是很重要的，特地是用户第一次关上它时，对 app来讲，第一印象太太太重要了。你能做的就是使它尽可能做更多的异步工作，比方加载远端或者数据库数据，解析数据。防止过于宏大的 XIB，因为他们是在主线程上加载的。所以尽量应用没有这个问题的 Storyboards吧！肯定要把设施从 Xcode断开来测试启动速度

2、应用 Autorelease Pool。NSAutoreleasePool负责开释 block中的 autoreleased objects。个别状况下它会主动被 UIKit调用。然而有些情况下你也须要手动去创立它。如果你创立很多长期对象，你会发现内存始终在缩小直到这些对象被 release的时候。这是因为只有当 UIKit用光了  autorelease pool的时候  memory才会被开释。音讯是你能够在你本人的@autoreleasepool里创立长期的对象来防止这个行为。

3、抉择是否缓存图片。常见的从 bundle中加载图片的形式有两种，一个是用 imageNamed，二是用imageWithContentsOfFile，第一种比拟常见一点。

4、防止日期格局转换。如果你要用 NSDateFormatter来解决很多日期格局，应该小心以待。就像先前提到的，任何时候重用 NSDateFormatters都是一个好的实际。如果你能够管制你所解决的日期格局，尽量抉择Unix工夫戳。你能够不便地从工夫戳转换到   NSDate:

这样会比用 C来解析日期字符串还快！须要留神的是，许多 web API会以微秒的模式返回工夫戳，因为这种格局在 javascript中更方便使用。记住用dateFromUnixTimestamp之前除以  1000就好了。

平时你是如何对代码进行性能优化的？

  • 利用性能剖析工具检测，包含动态  Analyze工具，以及运行时   Profile工具，通过   Xcode工具栏中Product->Profile能够启动,比方测试程序启动运行工夫，当点击 Time Profiler应用程序开始运行后.就能获取到整个利用程序运行耗费工夫散布和百分比.为了保障数据分析在对立应用场景实在须要留神肯定要应用真机,因为此时模拟器是运行在 Mac上，而 Mac上的  CPU往往比  iOS设施要快。
  • 为了避免一个利用占用过多的系统资源，开发 iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下，“看门狗”会监测利用的性能。如果超出了该场景所规定的运行工夫，“看门狗”就会强制终结这个利用的过程。开发者们在 crashlog外面，会看到诸如 0x8badf00d这样的错误代码。

优化 Table View

  • 正确应用 reuseIdentifier来重用  cells
  • 尽量使所有的 view opaque，包含 cell本身
  • 如果 cell内事实的内容来自 web，应用异步加载，缓存申请后果缩小 subviews的数量
  • 尽量不实用 cellForRowAtIndexPath:，如果你须要用到它，只用一次而后缓存后果
  • 应用 rowHeight, sectionFooterHeight和 sectionHeaderHeight来设定固定的高，不要申请   delegate

UIImage加载图片性能问题

  • imagedNamed初始化
  • imageWithContentsOfFile初始化

* imageNamed默认加载图片胜利后会内存中缓存图片,这个办法用一个指定的名字在零碎缓存中查找并返回一个图片对象.如果缓存中没有找到相应的图片对象,则从指定中央加载图片而后缓存对象，并返回这个图片对象.

  • imageWithContentsOfFile则仅只加载图片,不缓存.
  • 加载一张大图并且应用一次，用 imageWithContentsOfFile是最好,这样 CPU不须要做缓存节约工夫.
  • 应用场景须要编程时，应该依据理论利用场景加以辨别，UIimage虽小，但应用元素较多问题会有所凸显.
  • 不要在 viewWillAppear中做费时的操作：viewWillAppear:在    view显示之前被调用，出于效率思考，办法中不要解决简单费时操作；在该办法设置  view的显示属性之类的简略事件，比方背景色，字体等。否则，会显著感觉到  view有卡顿或者提早。
  • 在正确的中央应用 reuseIdentifier：table view用  tableView:cellForRowAtIndexPath:为 rows调配

cells的时候，它的数据应该重用自  UITableViewCell。

  • 尽量把 views设置为通明：如果你有通明的 Views你应该设置它们的  opaque属性为  YES。零碎用一个最优的形式渲染这些 views。这个简略的属性在 IB或者代码里都能够设定。
  • 防止过于宏大的 XIB：尽量简略的为每个 Controller配置一个独自的 XIB，尽可能把一个  ViewController的  view层次结构扩散到独自的 XIB中去,当你加载一个援用了图片或者声音资源的    nib时，nib加载代码会把图片和声音文件写进内存。
  • 不要阻塞主线程：永远不要使主线程承当过多。因为 UIKit在主线程上做所有工作，渲染，治理触摸反馈，回应输出等都须要在它下面实现,大部分妨碍主过程的情景是你的 app在做一些牵涉到读写内部资源的 I/O操作，比方存储或者网络。
  • 在 Image Views中调整图片大小

如果要在 UIImageView中显示一个来自 bundle的图片，你应保障图片的大小和  UIImageView的大小雷同。在运行中缩放图片是很消耗资源的.

讲讲你用 Instrument优化动画性能的经验吧（别问我什么是  Instrument）


facebook启动工夫优化

1.瘦身申请依赖

2.UDP启动申请后行缓存

3.队列串行化解决启动响应

四、光栅化

光栅化是将几何数据通过一系列变换后最终转换为像素，从而出现在显示设施上的过程，光栅化的实质是坐标变换、几何离散化咱们应用  UITableView和   UICollectionView时常常会遇到各个   Cell的款式是一样的，这时候咱们能够应用这个属性进步性能：

五、日常如何查看内存泄露？

目前我晓得的形式有以下几种

  • Memory Leaks
  • Alloctions
  • Analyse
  • Debug Memory Graph
  • MLeaksFinder

泄露的内存次要有以下两种：

  • Lak  Memory这种是遗记   Release操作所泄露的内存。
  • Abandon  Memory这种是循环援用，无奈开释掉的内存。

下面所说的五种形式，其实前四种都比拟麻烦，须要一直地调试运行，第五种是腾讯浏览团队出品，成果好一些

六、如何高性能的画一个圆角？

视图和圆角的大小对帧率并没有什么卵影响，数量才是挫伤的外围输入

首先下面的形式是不可取的，会触发离屏渲染。

  • 如果可能只用  cornerRadius解决问题，就不必优化。

  • 如果必须设置  masksToBounds，能够参考圆角视图的数量，如果数量较少（一页只有几个）也能够思考不必优化。

    • UIImageView的圆角通过间接截取图片实现，其它视图的圆角能够通过   Core  Graphics画出圆角矩形实现。

七、如何晋升  tableview的晦涩度？

实质上是升高  CPU、GPU的工作，从这两个大的方面去晋升性能。

CPU：对象的创立和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格局转换和解码、图像的绘制

GPU：纹理的渲染

卡顿优化在CPU层面

  • 尽量用轻量级的对象，比方用不到事件处理的中央，能够思考应用  CALayer取代   UIView
  • 不要频繁地调用  UIView的相干属性，比方    frame、bounds、transform等属性，尽量减少不必要的批改
  • 尽量提前计算好布局，在有须要时一次性调整对应的属性，不要屡次批改属性
  • Autolayout会比间接设置   frame耗费更多的    CPU资源
  • 图片的  size最好刚好跟   UIImageView的   size保持一致
  • 管制一下线程的最大并发数量

  • 尽量把耗时的操作放到子线程

    • 文本处理（尺寸计算、绘制）
    • 图片解决（解码、绘制）

卡顿优化在GPU层面

  • 尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
  • GPU能解决的最大纹理尺寸是   4096x4096，一旦超过这个尺寸，就会占用  CPU资源进行解决，所以纹理尽量不要超过这个尺寸
  • 尽量减少视图数量和档次
  • 缩小通明的视图（alpha<1），不通明的就设置  opaque为   YES
  • 尽量避免呈现离屏渲染

1.预排版，提前计算

在接管到服务端返回的数据后，尽量将  CoreText排版的后果、单个控件的高度、cell整体的高度提前计算好，将其存储在模型的属性中。须要应用时，间接从模型中往外取，防止了计算的过程。尽量少用  UILabel，能够应用 CALayer。防止应用    AutoLayout的主动布局技术，采取纯代码的形式

2.预渲染，提前绘制

例如圆形的图标能够提前在，在接管到网络返回数据时，在后盾线程进行解决，间接存储在模型数据里，回到主线程后间接调用就能够了防止应用  CALayer的   Border、corner、shadow、mask等技术，这些都会触发离屏渲染。

3.异步绘制

4.全局并发线程

5.高效的图片异步加载

八、如何优化  APP的电量？

程序的耗电次要在以下四个方面：

·CPU解决

·定位

·网络

·图像

优化的路径次要体现在以下几个方面：

·尽可能升高  CPU、GPU的功耗。

·尽量少用定时器。

·优化  I/O操作。

o 不要频繁写入小数据，而是积攒到肯定数量再写入

o 读写大量的数据能够应用  Dispatch_io，GCD外部曾经做了优化。

o 数据量比拟大时，倡议应用数据库

  • 网络方面的优化

o 缩小压缩网络数据（XML  -> JSON -> ProtoBuf），如果可能倡议应用 ProtoBuf。

o 如果申请的返回数据雷同，能够应用  NSCache进行缓存

o 应用断点续传，防止因网络失败后要从新下载。

o 网络不可用的时候，不尝试进行网络申请

o 长时间的网络申请，要提供能够勾销的操作

o 采取批量传输。下载视频流的时候，尽量一大块一大块的进行下载，广告能够一次下载多个

  • 定位层面的优化

o 如果只是须要疾速确定用户地位，最好用  CLLocationManager的   requestLocation办法。定位实现后，会主动让定位硬件断电

o 如果不是导航利用，尽量不要实时更新地位，定位结束就关掉定位服务

o 尽量升高定位精度，比方尽量不要应用精度最高的  kCLLocationAccuracyBest

o 须要后盾定位时，尽量设置  pausesLocationUpdatesAutomatically为   YES，如果用户不太可能挪动的时候零碎会主动暂停地位更新

o 尽量不要应用startMonitoringSignificantLocationChanges，优先思考startMonitoringForRegion:

  • 硬件检测优化

o 用户挪动、摇摆、歪斜设施时，会产生动作(motion)事件，这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不须要检测的场合，应该及时敞开这些硬件

九、如何无效升高  APP包的大小？

升高包大小须要从两方面着手

可执行文件

  • 编译器优化
  • Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为  YES
  • 去掉异样反对，Enable C++ Exceptions、Enable Objective-C Exceptions设置为   NO， Other C Flags增加  -fno-exceptions
  • 利用  AppCode检测未应用的代码：菜单栏   -> Code -> Inspect Code
  • 编写 LLVM插件检测出反复代码、未被调用的代码

资源

资源包含图片、音频、视频等

  • 优化的形式能够对资源进行无损的压缩
  • 去除没有用到的资源

十、什么是离屏渲染？什么状况下会触发？该如何应答？

离屏渲染就是在以后屏幕缓冲区以外，新开拓一个缓冲区进行操作。

离屏渲染登程的场景有以下：

  • 圆角（maskToBounds并用才会触发）
  • 图层蒙版
  • 暗影
  • 光栅化

为什么要防止离屏渲染？

CPU GPU在绘制渲染视图时做了大量的工作。离屏渲染产生在   GPU层面上，会创立新的渲染缓冲区，会
触发  OpenGL的多通道渲染管线，图形上下文的切换会造成额定的开销，减少   GPU工作量。如果   CPU GPU累计耗时   16.67毫秒还没有实现，就会造成卡顿掉帧。

圆角属性、蒙层遮罩都会触发离屏渲染。指定了以上属性，标记了它在新的图形上下文中，在未愈合之前，不能够用于显示的时候就登程了离屏渲染。

  • 在 OpenGL中，GPU有  2种渲染形式

    • On-Screen Rendering：以后屏幕渲染，在以后用于显示的屏幕缓冲区进行渲染操作
    • Off-Screen Rendering：离屏渲染，在以后屏幕缓冲区以外新开拓一个缓冲区进行渲染操作

  • 离屏渲染耗费性能的起因

    • 须要创立新的缓冲区
    • 离屏渲染的整个过程，须要屡次切换上下文环境，先是从以后屏幕（   On-Screen）切换到离屏（Off-Screen）；等到离屏渲染完结当前，将离屏缓冲区的渲染结果显示到屏幕上，又须要将上下文环境从离屏切换到以后屏幕

  • 哪些操作会触发离屏渲染？

    • 光栅化，layer.shouldRasterize = YES
    • 遮罩，layer.mask
    • 圆角，同时设置  layer.masksToBounds = YES、layer.cornerRadius大于  0
    • 思考通过  CoreGraphics绘制裁剪圆角，或者叫美工提供圆角图片
    • 暗影，layer.shadowXXX，如果设置了  layer.shadowPath就不会产生离屏渲染

十一、如何检测离屏渲染？

1、模拟器 debug-选中 color Offscreen - Renderd离屏渲染的图层高亮成黄可能存在性能问题

2、真机 Instrument-选中 Core Animation-勾选 Color Offscreen-Rendered Yellow

离屏渲染的触发形式

设置了以下属性时，都会触发离屏绘制：

1、layer.shouldRasterize（光栅化）

光栅化概念：将图转化为一个个栅格组成的图象。

光栅化特点：每个元素对应帧缓冲区中的一像素。

2、masks（遮罩）

3、shadows（暗影）

4、edge antialiasing（抗锯齿）

5、group opacity（不通明）

6、简单形态设置圆角等

7、突变

8、drawRect

例如咱们日程常常打交道的 TableViewCell,因为 TableViewCell的重绘是很频繁的（因为 Cell的复用）,如果Cell的内容一直变动,则  Cell须要一直重绘,如果此时设置了 cell.layer可光栅化。则会造成大量的离屏渲染,升高图形性能。

如果将不在 GPU的以后屏幕缓冲区中进行的渲染都称为离屏渲染，那么就还有另一种非凡的“离屏渲染”形式：CPU渲染。如果咱们重写了  drawRect办法，并且应用任何 Core Graphics的技术进行了绘制操作，就波及到了 CPU渲染。整个渲染过程由 CPU在  App内同步地实现，渲染失去的  bitmap最初再交由  GPU用于显示。

当初摆在咱们背后得有三个抉择：以后屏幕渲染、离屏渲染、CPU渲染，该用哪个呢？这须要依据具体的
应用场景来决定。

尽量应用以后屏幕渲染

鉴于离屏渲染、CPU渲染可能带来的性能问题，个别状况下，咱们要尽量应用以后屏幕渲染。

离屏渲染  VS CPU渲染

因为 GPU的浮点运算能力比 CPU强，CPU渲染的效率可能不如离屏渲染；但如果仅仅是实现一个简略的成果，间接应用 CPU渲染的效率又可能比离屏渲染好，毕竟离屏渲染要波及到缓冲区创立和上下文切换等耗时操作

UIButton的   masksToBounds = YES又设置  setImage、setBackgroundImage、[buttonsetBackgroundColor:[UIColor colorWithPatternImage:[UIImage imageNamed:@"btn_selected"]]];

下产生离屏渲染，然而[button setBackgroundColor:[UIColor redColor]];是不会呈现离屏渲染的

对于  UIImageView,当初测试发现(现版本: iOS10),在性能的范畴之内,给 UIImageView设置圆角是不会触发离屏渲染的,然而同时给 UIImageView设置背景色则必定会触发.触发离屏渲染跟  png.jpg格局并无关联

日常咱们应用 layer的两个属性，实现圆角

imageView.layer.cornerRaidus = CGFloat(10);

imageView.layer.masksToBounds = YES;

这样解决的渲染机制是 GPU在以后屏幕缓冲区外新开拓一个渲染缓冲区进行工作，也就是离屏渲染，这会给咱们带来额定的性能损耗。如果这样的圆角操作达到肯定数量，会触发缓冲区的频繁合并和上下文的频繁切换，性能的代价会宏观地表当初用户体验上——掉帧

十二、怎么检测图层混合？

1、模拟器 debug-选中   color blended layers红色区域示意图层产生了混合

2、Instrument-选中 Core Animation-勾选 Color Blended Layers

防止图层混合：

1、确保控件的 opaque属性设置为 true，确保 backgroundColor和父视图色彩统一且不通明

2、如无非凡须要，不要设置低于 1的 alpha值

3、确保 UIImage没有 alpha通道

UILabel图层混合解决办法：

iOS8当前设置背景色为非通明色并且设置  label.layer.masksToBounds=YES让 label只会渲染她的理论  size区域，就能解决 UILabel的图层混合问题

iOS8之前只有设置背景色为非通明的就行

为什么设置了背景色然而在 iOS8上依然呈现了图层混合呢？

UILabel在  iOS8前后的变动，在 iOS8以前，UILabel应用的是   CALayer作为底图层，而在  iOS8开始，UILabel的底图层变成了_UILabelLayer，绘制文本也有所扭转。在背景色的周围多了一圈通明的边，而这一圈通明的边显著超出了图层的矩形区域，设置图层的 masksToBounds为 YES时，图层将会沿着  Bounds进行裁剪图层混合问题解决了.