iOS 程序性能优化

时间  2019-11-20
标签 ios 程序 性能 优化 栏目 iOS 繁體版
原文   原文链接

 

转载自：http://www.samirchen.com/ios-performance-optimization/html

程序性能优化不该该是一件放在功能完成以后的事，对性能的概念应该从咱们一开始写代码时就萦绕在咱们脑子里。了解 iOS 程序性能优化的相关知识点，从一开始就把它们落实到代码中是一种好的习惯。ios

在咱们使用 UITableView 和 UICollectionView 时咱们一般会遇到「复用 Cell」这个提法，所谓「复用 Cell」就是指当须要展现的数据条目较多时，只建立较少数量的 Cell 对象（通常是屏幕可显示的 Cell 数再加一）并经过复用它们的方式来展现数据的机制。这种机制不会为每一条数据都建立一个 Cell，因此能够节省内存，提高程序的效率和交互流畅性。git

从 iOS 6 之后，咱们在 UITableView 和 UICollectionView 中不光能够复用 Cell，还能够复用各个 Section 的 Header 和 Footer。github

在 UITableView 作复用的时候，会用到的 API：web

  1. // 复用 Cell：
  2. - [UITableView dequeueReusableCellWithIdentifier:];
  3. - [UITableView registerNib:forCellReuseIdentifier:];
  4. - [UITableView registerClass:forCellReuseIdentifier:];
  5. - [UITableView dequeueReusableCellWithIdentifier:forIndexPath:];
  7. // 复用 Section 的 Header/Footer：
  8. - [UITableView registerNib:forHeaderFooterViewReuseIdentifier:];
  9. - [UITableView registerClass:forHeaderFooterViewReuseIdentifier:];
  10. - [UITableView dequeueReusableHeaderFooterViewWithIdentifier:];

复用机制是一个很好的机制，可是不正确的使用却会给咱们的程序带来不少问题。下面拿 UITableView 复用 Cell 来举例：objective-c

  1. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
  2. static NSString *CellIdentifier = nil;
  3. UITableViewCell *cell = nil;
  5. CellIdentifier = @"UITableViewCell";
  6. cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
  7. if (!cell) {
  8. cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier];
  9. // 偶数行 Cell 的 textLabel 的文字颜色为红色。
  10. if (indexPath.row % 2 == 0) {
  11. [cell.textLabel setTextColor:[UIColor redColor]];
  12. }
  13. }
  15. cell.textLabel.text = @"Title";
  16. // 偶数行 Cell 的 detailTextLabel 显示 Detail 文字。
  17. if (indexPath.row % 2 == 0) {
  18. cell.detailTextLabel.text = @"Detail";
  19. }
  21. return cell;
  22. }

咱们原本是但愿只有偶数行的 textLabel 的文字颜色为红色，而且显示 Detail 文字，可是当你滑动 TableView 的时候发现不对了，有些奇数行的 textLabel 的文字颜色为红色，并且还显示了 Detail 文字，很奇怪。其实形成这个问题的缘由就是「复用」，当一个 Cell 被拿来复用时，它全部被设置的属性（包括样式和内容）都会被拿来复用，若是恰好某一个的 Cell 你没有显式地设置它的属性，那么它这些属性就直接复用别的 Cell 的了。就如上面的代码中，咱们并无显式地设置奇数行的 Cell 的 textLabel 的文字颜色以及 detailTextLabel 的文字，那么它就有可能复用别的 Cell 的这些属性了。此外，还有个问题，对偶数行 Cell 的 textLabel 的文字颜色的设置放在了初始一个 Cell 的 if 代码块里，这样在复用的时候，逻辑走不到这里去，那么也会出现复用问题。因此，上面的代码须要改为这样：数据库

  1. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
  2. static NSString *CellIdentifier = nil;
  3. UITableViewCell *cell = nil;
  5. CellIdentifier = @"UITableViewCell";
  6. cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
  7. if (!cell) {
  8. cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier];
  9. }
  11. cell.textLabel.text = @"Title";
  13. if (indexPath.row % 2 == 0) {
  14. [cell.textLabel setTextColor:[UIColor redColor]];
  15. cell.detailTextLabel.text = @"Detail";
  16. }
  17. else {
  18. [cell.textLabel setTextColor:[UIColor blackColor]];
  19. cell.detailTextLabel.text = nil;
  20. }
  22. return cell;
  23. }

总之在复用的时候须要记住：编程

  • 设置 Cell 的存在差别性的那些属性（包括样式和内容）时，有了 if 最好就要有 else，要显式的覆盖全部可能性。
  • 设置 Cell 的存在差别性的那些属性时，代码要放在初始化代码块的外部。

上面的代码中，咱们展现了 - [UITableView dequeueReusableCellWithIdentifier:]; 的用法。下面看看另几个 API 的用法：数组

  1. @property (weak, nonatomic) IBOutlet UITableView *myTableView;
  3. - (void)viewDidLoad {
  4. [super viewDidLoad];
  6. // Setup table view.
  7. self.myTableView.delegate = self;
  8. self.myTableView.dataSource = self;
  9. [self.myTableView registerClass:[MyTableViewCell class] forCellReuseIdentifier:@"MyTableViewCell"];
  10. }
  12. - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
  13. static NSString *CellIdentifier = nil;
  14. UITableViewCell *cell = nil;
  16. CellIdentifier = @"MyTableViewCell";
  17. cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
  19. cell.textLabel.text = @"Title";
  21. if (indexPath.row % 2 == 0) {
  22. [cell.textLabel setTextColor:[UIColor redColor]];
  23. }
  24. else {
  25. [cell.textLabel setTextColor:[UIColor blackColor]];
  26. }
  28. return cell;
  29. }

能够看到，- [UITableView dequeueReusableCellWithIdentifier:forIndexPath:]; 必须搭配 - [UITableView registerClass:forCellReuseIdentifier:]; 或者 - [UITableView registerNib:forCellReuseIdentifier:]; 使用。当有可重用的 Cell 时，前者直接拿来复用，并调用 - [UITableViewCell prepareForReuse] 方法；当没有时，前者会调用 Identifier 对应的那个注册的 UITableViewCell 类的 - [UITableViewCell initWithStyle:reuseIdentifier:] 方法来初始化一个，这里省去了你本身初始化的步骤。当你自定义了一个 UITableViewCell 的子类时，你能够这样来用。缓存

UIView 有一个 opaque 属性，在你不须要透明效果时，你应该尽可能设置它为 YES 能够提升绘图过程的效率。

在一个静态的视图里，这点可能影响不大，可是当在一个能够滚动的 Scroll View 中或是一个复杂的动画中，透明的效果可能会对程序的性能有较大的影响。

若是你压根不用 XIB，那就不须要看了。

在你须要重用某些自定义 View 或者由于历史兼容缘由用到 XIB 的时候，你须要注意：当你加载一个 XIB 时，它的全部内容都会被加载，若是这个 XIB 里面有个 View 你不会立刻就用到，你其实就是在浪费宝贵的内存。而加载 StoryBoard 时并不会把全部的 ViewController 都加载，只会按需加载。

基本上 UIKit 会把它全部的工做都放在主线程执行，好比：绘制界面、管理手势、响应输入等等。当你把全部代码逻辑都放在主线程时，有可能由于耗时太长卡住主线程形成程序没法响应、流畅性太差等问题。形成这种问题的大多数场景是由于你的程序把 I/O 操做放在了主线程，好比从硬盘或者网络读写数据等等。

你能够经过异步的方式来进行这些操做，把他们放在别的线程中处理。好比处理网络请求时，你可使用 NSURLConnection 的异步调用 API：

  1. + (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler;

或者使用第三方的类库，好比 AFNetworking。

当你作一些耗时比较长的操做时，你可使用 GCD、NSOperation、NSOperationQueue。好比 GCD 的常见使用方式：

  1. dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
  2. // switch to another thread and perform your expensive operation
  4. dispatch_async(dispatch_get_main_queue(), ^{
  5. // switch back to the main thread to update your UI
  7. });
  8. });

关于 GCD 更多的知识，你能够看看这篇文章：GCD。

当你从 App bundle 中加载图片到 UIImageView 中显示时，最好确保图片的尺寸可以和 UIImageView 的尺寸想匹配（固然，须要考虑 @2x @3x 的状况），不然会使得 UIImageView 在显示图片时须要作拉伸，这样会影响性能，尤为是在一个 UIScrollView 的容器里。

有时候，你的图片是从网络加载的，这时候你并不能控制图片的尺寸，不过你能够在图片下载下来后去手动 scale 一下它，固然，最好是在一个后台线程作这件事，而后在 UIImageView 中使用 resize 后的图片。

咱们常常须要用到容器来转载多个对象，咱们一般用到的包括：NSArray、NSDictionary、NSSet，它们的特性以下：

  • Array：数组。有序的，经过 index 查找很快，经过 value 查找很慢，插入和删除较慢。
  • Dictionary：字典。存储键值对，经过键查找很快。
  • Set：集合。无序的，经过 value 查找很快，插入和删除较快。

根据以上特性，在编程中须要选择适合的容器。更多内容请看：Collections Programming Topics

如今愈来愈多的应用须要跟服务器进行数据交互，当交互的数据量较大时，网络传输的时延就会较长，经过启动数据压缩功能，尤为是对于文本信息，能够下降网络传输的数据量，从而减短网络交互的时间。

一个好消息是当你使用 NSURLConnection 或者基于此的一些网络交互类库（好比 AFNetworking）时 iOS 已经默认支持 GZIP 压缩。而且，不少服务器已经支持发送压缩数据。

经过在服务器和客户端程序中启用对网络交互数据的压缩，是一条提升应用程序性能的途径。

在上面的内容里咱们介绍了一些显而易见的优化程序性能的途径，可是有时候，有些优化程序性能的方案并非那么明显，这些方案是否适用取决于你的代码状况。可是，若是在正确的场景下，这些方案能起到很显著的做用。

当你的程序中须要展现不少的 View 的时候，这就意味着须要更多的 CPU 处理时间和内存空间，这个状况对程序性能的影响在你使用 UIScrollView 来装载和呈现界面时会变得尤其显著。

处理这种状况的一种方案就是向 UITableView 和 UICollectionView 学习，不要一次性把全部的 subviews 都建立出来，而是在你须要他们的时候建立，而且用复用机制去复用他们。这样减小了内存分配的开销，节省了内存空间。

「懒加载机制」就是把建立对象的时机延后到不得不须要它们的时候。这个机制经常用在对一个类的属性的初始化上，好比：

  1. - (UITableView *)myTableView {
  2. if (!_myTableView) {
  3. CGRect viewBounds = self.view.bounds;
  5. _myTableView = [[UITableView alloc] initWithFrame:viewBounds style:UITableViewStylePlain];
  6. _myTableView.showsHorizontalScrollIndicator = NO;
  7. _myTableView.showsVerticalScrollIndicator = NO;
  8. _myTableView.backgroundColor = [UIColor whiteColor];
  9. [_myTableView setSeparatorStyle:UITableViewCellSeparatorStyleNone];
  11. _myTableView.dataSource = self;
  12. _myTableView.delegate = self;
  13. }
  15. return _myTableView;
  16. }

只有当咱们第一次用到 self.myTableView 的时候采起初始化和建立它。

可是，存在这样一种场景：你点击一个按钮的时候，你须要显示一个 View，这时候你有两种实现方案：

  • 1）在当前界面第一次加载的时候就建立出这个 View，只是把它隐藏起来，当你须要它的时候，只用显示它就好了。
  • 2）使用「懒加载机制」，在你须要这个 View 的时候才建立它，并展现它。

这两种方案都各有利弊。采用方案一，你在不须要这个 View 的时候显然白白地占用了更多的内存，可是当你点击按钮展现它的时候，你的程序能响应地相对较快，由于你只须要改变它的 hidden 属性。采用方案二，那么你获得的效果相反，你更准确的使用了内存，可是若是对这个 View 的初始化和建立比较耗时，那么响应性相对就没那么好了。

因此当你考虑使用何种方案时，你须要根据现实的状况来参考，去权衡到底哪一个因素才是影响性能的瓶颈，而后再作出选择。

在开发咱们的程序时，一个很重要的经验法则就是：对那些更新频度低，访问频度高的内容作缓存。

有哪些东西使咱们能够缓存的呢？好比下面这些：

  • 服务器的响应信息（response）。
  • 图片。
  • 计算值。好比：UITableView 的 row heights。

NSURLConnection 能够根据 HTTP 头部的设置来决定把资源内容缓存在磁盘或者内存，你甚至能够设置让它只加载缓存里的内容：

  1. + (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {
  2. NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
  4. request.cachePolicy = NSURLRequestReturnCacheDataElseLoad; // this will make sure the request always returns the cached image
  5. request.HTTPShouldHandleCookies = NO;
  6. request.HTTPShouldUsePipelining = YES;
  7. [request addValue:@"image/*" forHTTPHeaderField:@"Accept"];
  9. return request;
  10. }

关于 HTTP 缓存的更多内容能够关注 NSURLCache。关于缓存其余非 HTTP 请求的内容，能够关注 NSCache。对于图片缓存，能够关注一个第三方库 SDWebImage。

当咱们为一个 UIButton 设置背景图片时，对于这个背景图片的处理，咱们有不少种方案，你可使用全尺寸图片直接设置，还能够用 resizable images，或者使用 CALayer、CoreGraphics 甚至 OpenGL 来绘制。

固然，不一样的方案的编码复杂度不同，性能也不同。关于图形绘制的不一样方案的性能问题，能够看看：Designing for iOS: Graphics Performance

简而言之，使用 pre-rendered 的图片会更快，由于这样就不须要在程序中去建立一个图像，并在上面绘制各类形状了（Offscreen Rendering，离屏渲染）。可是缺点是你必须把这些图片资源打包到代码包，从而须要增长程序包的体积。这就是为何 resizable images 是一个很棒的选择：不须要全尺寸图，让 iOS 为你绘制图片中那些能够拉伸的部分，从而减少了图片体积；而且你不须要为不一样大小的控件准备不一样尺寸的图片。好比两个按钮的大小不同，可是他们的背景图样式是同样的，你只须要准备一个对应样式的 resizable image，而后在设置这两个按钮的背景图的时候分别作拉伸就能够了。

可是一味的使用使用预置的图片也会有一些缺点，好比你作一些简单的动画的时候各个帧都用图片叠加，这样就可能要使用大量图片。

总之，你须要去在图形绘制的性能和应用程序包的大小上作权衡，找到最合适的性能优化方案。

关于内存警告，苹果的官方文档是这样说的：

If your app receives this warning, it must free up as much memory as possible. The best way to do this is to remove strong references to caches, image objects, and other data objects that can be recreated later.

咱们能够经过这些方式来得到内存警告：

  • 在 AppDelegate 中实现 - [AppDelegate applicationDidReceiveMemoryWarning:] 代理方法。
  • 在 UIViewController 中重载 didReceiveMemoryWarning 方法。
  • 监听 UIApplicationDidReceiveMemoryWarningNotification 通知。

当经过这些方式监听到内存警告时，你须要立刻释放掉不须要的内存从而避免程序被系统杀掉。

好比，在一个 UIViewController 中，你能够清除那些当前不显示的 View，同时能够清除这些 View 对应的内存中的数据，而有图片缓存机制的话也能够在这时候释放掉不显示在屏幕上的图片资源。

可是须要注意的是，你这时清除的数据，必须是能够在从新获取到的，不然可能由于必要数据为空，形成程序出错。在开发的时候，可使用 iOS Simulator 的 Simulate memory warning 的功能来测试你处理内存警告的代码。

在 Objective-C 中有些对象的初始化过程很缓慢，好比：NSDateFormatter 和 NSCalendar，可是有些时候，你也不得不使用它们。为了这样的高开销的对象成为影响程序性能的重要因素，咱们能够复用它们。

好比，咱们在一个类里添加一个 NSDateFormatter 的对象，并使用懒加载机制来使用它，整个类只用到一个这样的对象，并只初始化一次：

  1. // in your .h or inside a class extension
  2. @property (nonatomic, strong) NSDateFormatter *dateFormatter;
  4. // inside the implementation (.m)
  5. // When you need, just use self.dateFormatter
  6. - (NSDateFormatter *)dateFormatter {
  7. if (! _dateFormatter) {
  8. _dateFormatter = [[NSDateFormatter alloc] init];
  9. [_dateFormatter setDateFormat:@"yyyy-MM-dd a HH:mm:ss EEEE"];
  10. }
  11. return _dateFormatter;
  12. }

可是上面的代码在多线程环境下会有问题，因此咱们能够改进以下：

  1. // no property is required anymore. The following code goes inside the implementation (.m)
  2. - (NSDateFormatter *)dateFormatter {
  3. static NSDateFormatter *dateFormatter;
  4. static dispatch_once_t onceToken;
  5. dispatch_once(&onceToken, ^{
  6. dateFormatter = [[NSDateFormatter alloc] init];
  7. [dateFormatter setDateFormat:@"yyyy-MM-dd a HH:mm:ss EEEE"];
  8. });
  9. return dateFormatter;
  10. }

这样就线程安全了。（关于多线程 GCD 的知识，能够看看这篇文章：GCD）

须要注意的是：设置 NSDateFormatter 的 date format 跟建立一个新的 NSDateFormatter 对象同样慢，所以当你的程序中要用到多种格式的 date format，而每种又会用到屡次的时候，你能够尝试为每种 date format 建立一个可复用的 NSDateFormatter 对象来提供程序的性能。

若是你是游戏开发者，使用 Sprite Sheet 能够帮助你比标准的绘图方法更快地绘制场景，甚至占用更少的内存。

固然这里有些地方也能够参考上面已经提到过的性能优化方案，好比你的游戏有不少 Sprites 时，你能够参考 UITableViewCell 的复用机制，而不是每次都建立它们。

在咱们开发应用时，常常会遇到要从服务器获取 JSON 或者 XML 数据来处理的状况，这时咱们一般都须要解析这些数据，通常会解析为 NSArray、NSDictionary 的对象。可是在咱们实际的开发中，咱们一般会为在界面上展现的那些数据定义一些数据结构（ViewModel）。这时候问题就来了，咱们须要把解析出来的 NSArray、NSDictionary 对象再倒腾成咱们定义的那些数据结构，从程序性能的角度来考虑，这是一项开销较大的操做。

为了不这样的状况成为影响程序性能的瓶颈，在设计客户端应用程序对应的数据结构时就须要作更细致的考虑，尽可能用 NSArray 去承接 NSArray，用 NSDictionary 去承接 NSDictionary，避免倒腾数据形成开销。

咱们的 iOS 应用程序与服务器进行交互时，一般采用的数据格式就是 JSON 和 XML 两种。那么在选择哪种时，须要考虑到它们的优缺点。

JSON 文件的优势是：

  • 可以更快的被解析。
  • 在承载相同的数据时，一般体积比 XML 更小，这意味着传输的数据量更小。

缺点是：

  • 须要整个 JSON 数据所有加载完成后才能开始解析。

而 XML 文件的优缺点则恰好反过来。 XML 的一个优势就是它可使用 SAX 来解析数据，从而能够边加载边解析，不用等全部数据都读取完成了才解析。这样在处理很大的数据集的时提升性能和下降内存消耗。

因此，你须要根据具体的应用场景来权衡使用何种数据格式。

咱们一般有两种方式来设置一个 View 的背景图片：

  • 经过 - [UIColor colorWithPatternImage:] 方法来设置 View 的 background color。
  • 经过给 View 添加一个 UIImageView 来设置其背景图片。

当你有一个全尺寸图片做为背景图时，你最好用 UIImageView 来，由于 - [UIColor colorWithPatternImage:] 是用来可重复填充的小的样式图片。这时对于全尺寸的图片，用 UIImageView 会节省大量的内存。

  1. // You could also achieve the same result in Interface Builder
  2. UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];
  3. [self.view addSubview:backgroundView];

可是，当你计划采用一个小块的模板样式图片，就像贴瓷砖那样来重复填充整个背景时，你应该用 - [UIColor colorWithPatternImage:] 这个方法，由于这时它可以绘制的更快，而且不会用到太多的内存。

  1. self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"backgroundPattern"]];

UIWebView 在咱们的应用程序中很是有用，它能够便捷的展现 Web 的内容，甚至作到你用标准的 UIKit 控件较难作到的视觉效果。可是，你应该注意到你在应用程序里使用的 UIWebView 组件不会比苹果的 Safari 更快。这是首先于 Webkit 的 Nitro Engine 引擎。因此，为了获得更好的性能，你须要优化你的网页内容。

优化第一步就是避免过量使用 Javascript，例如避免使用较大的 Javascript 框架，好比 jQuery。通常使用原生的 Javascript 而不是依赖于 Javascript 框架能够得到更好的性能。

优化第二步，若是可能的话，能够异步加载那些不影响页面行为的 Javascript 脚本，好比一些数据统计脚本。

优化第三步，老是关注你在页面中所使用的图片，根据具体的场景来显示正确尺寸的图片，同时也可使用上面提到的「使用 Sprites Sheets」的方案来在某些地方减小内存消耗和提升速度。

什么是「离屏渲染」？离屏渲染，即 Off-Screen Rendering。与之相对的是 On-Screen Rendering，即在当前屏幕渲染，意思是渲染操做是用于在当前屏幕显示的缓冲区进行。那么离屏渲染则是指图层在被显示以前是在当前屏幕缓冲区之外开辟的一个缓冲区进行渲染操做。

离屏渲染须要屡次切换上下文环境：先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束之后，将离屏缓冲区的渲染结果显示到屏幕上又须要将上下文环境从离屏切换到当前屏幕，而上下文环境的切换是一项高开销的动做。

一般图层的如下属性将会触发离屏渲染：

  • 阴影（UIView.layer.shadowOffset/shadowRadius/…）
  • 圆角（当 UIView.layer.cornerRadius 和 UIView.layer.maskToBounds 一块儿使用时）
  • 图层蒙板

在 iOS 开发中要给一个 View 添加阴影效果，有很简单快捷的作法：

  1. UIImageView *imageView = [[UIImageView alloc] initWithFrame:...];
  3. // Setup the shadow ...
  4. imageView.layer.shadowOffset = CGSizeMake(5.0f, 5.0f);
  5. imageView.layer.shadowRadius = 5.0f;
  6. imageView.layer.shadowOpacity = 0.6;

可是上面这样的作法有一个坏处是：将触发 Core Animation 作离屏渲染形成开销。

那要作到阴影图层效果，又想减小离屏渲染、提升性能的话要怎么作呢？一个好的建议是：设置 ShadowPath 属性。

  1. UIImageView *imageView = [[UIImageView alloc] initFrame:...];
  3. // Setup the shadow ...
  4. imageView.layer.shadowPath = [[UIBezierPath bezierPathWithRect:CGRectMake(imageView.bounds.origin.x+5, imageView.bounds.origin.y+5, imageView.bounds.size.width, imageView.bounds.size.height)] CGPath];
  5. imageView.layer.shadowOpacity = 0.6;

若是图层是一个简单几何图形如矩形或者圆角矩形（假设不包含任何透明部分或者子图层），经过设置 ShadowPath 属性来建立出一个对应形状的阴影路径就比较容易，并且 Core Animation 绘制这个阴影也至关简单，不会触发离屏渲染，这对性能来讲颇有帮助。若是你的图层是一个更复杂的图形，生成正确的阴影路径可能就比较难了，这样子的话你能够考虑用绘图软件预先生成一个阴影背景图。

CALayer 有一个属性是 shouldRasterize 经过设置这个属性为 YES 能够将图层绘制到一个屏幕外的图像，而后这个图像将会被缓存起来并绘制到实际图层的 contents 和子图层，若是很不少的子图层或者有复杂的效果应用，这样作就会比重绘全部事务的全部帧来更加高效。可是光栅化原始图像须要时间，并且会消耗额外的内存。这是须要根据实际场景权衡的地方。

当咱们使用得当时，光栅化能够提供很大的性能优点，可是必定要避免在内容不断变更的图层上使用，不然它缓存方面的好处就会消失，并且会让性能变的更糟。

为了检测你是否正确地使用了光栅化方式，能够用 Instrument 的 Core Animation Template 查看一下 Color Hits Green and Misses Red 项目，看看是否已光栅化图像被频繁地刷新（这样就说明图层并非光栅化的好选择，或则你无心间触发了没必要要的改变致使了重绘行为）。

若是你最后设置了 shouldRasterize 为 YES，那也要记住设置 rasterizationScale 为合适的值。在咱们使用 UITableView 和 UICollectionView 时常常会遇到各个 Cell 的样式是同样的，这时候咱们可使用这个属性提升性能：

  1. cell.layer.shouldRasterize = YES;
  2. cell.layer.rasterizationScale = [[UIScreen mainScreen] scale];

可是，若是你的 Cell 是样式不同，好比高度不定，排版多变，那就要慎重了。

UITableView 是咱们最经常使用来展现数据的控件之一，而且一般须要 UITableView 在承载较多内容的同时保证交互的流畅性，对 UITableView 的性能优化是咱们开发应用程序必备的技巧之一。

在前文「使用复用机制」一节，已经提到了 UITableView 的复用机制。如今就来看看 UITableView 在复用时最主要的两个回调方法：- [UITableView tableView:cellForRowAtIndexPath:] 和 - [UITableView tableView:heightForRowAtIndexPath:]。UITableView 是继承自 UIScrollView，因此在渲染的过程当中它会先肯定它的 contentSize 及每一个 Cell 的位置，而后才会把复用的 Cell 放置到对应的位置。好比如今一共有 50 个 Cell，当前屏幕上显示 5 个。那么在第一次建立或 reloadData 的时候， UITableView 会先调用 50 次 - [UITableView tableView:heightForRowAtIndexPath:]肯定 contentSize 及每一个 Cell 的位置，而后再调用 5 次 - [UITableView tableView:cellForRowAtIndexPath:] 来渲染当前屏幕的 Cell。在滑动屏幕的时候，每当一个 Cell 进入屏幕时，都须要调用一次 - [UITableView tableView:cellForRowAtIndexPath:]和 - [UITableView tableView:heightForRowAtIndexPath:] 方法。

了解了 UITableView 的复用机制以及相关回调方法的调用次序，这里就对 UITableView 的性能优化方案作一个总结：

  • 经过正确的设置 reuseIdentifier 来重用 Cell。
  • 尽可能减小没必要要的透明 View。
  • 尽可能避免渐变效果、图片拉伸和离屏渲染。
  • 当不一样的行的高度不同时，尽可能缓存它们的高度值。
  • 若是 Cell 展现的内容来自网络，确保用异步加载的方式来获取数据，而且缓存服务器的 response。
  • 使用 shadowPath 来设置阴影效果。
  • 尽可能减小 subview 的数量，对于 subview 较多而且样式多变的 Cell，能够考虑用异步绘制或重写 drawRect。
  • 尽可能优化 - [UITableView tableView:cellForRowAtIndexPath:] 方法中的处理逻辑，若是确实要作一些处理，能够考虑作一次，缓存结果。
  • 选择合适的数据结构来承载数据，不一样的数据结构对不一样操做的开销是存在差别的。
  • 对于 rowHeight、sectionFooterHeight、sectionHeaderHeight 尽可能使用常量。

在 iOS 中能够用来进行数据持有化的方案包括：

  • NSUserDefaults。只适合用来存小数据。
  • XML、JSON、Plist 等文件。JSON 和 XML 文件的差别在「选择正确的数据格式」已经说过了。
  • 使用 NSCoding 来存档。NSCoding 一样是对文件进行读写，因此它也会面临必须加载整个文件才能继续的问题。
  • 使用 SQLite 数据库。能够配合 FMDB 使用。数据的相对文件来讲仍是好处不少的，好比能够按需取数据、不用暴力查找等等。
  • 使用 CoreData。也是数据库技术，跟 SQLite 的性能差别比较小。可是 CoreData 是一个对象图谱模型，显得更面向对象；SQLite 就是常规的 DBMS。

下面介绍几个高级技巧。

快速启动应用对于用户来讲能够留下很好的印象。尤为是第一次使用时。

保证应用快速启动的指导原则：

  • 尽可能将启动过程当中的处理分拆成各个异步处理流，好比：网络请求、数据库访问、数据解析等等。
  • 避免臃肿的 XIB 文件，由于它们会在你的主线程中进行加载。重申：Storyboard 没这个问题，放心使用。

注意：在测试程序启动性能的时候，最好用与 Xcode 断开链接的设备进行测试。由于 watchdog 在使用 Xcode 进行调试的时候是不会启动的。

NSAutoreleasePool 是用来管理一个自动释放内存池的机制。在咱们的应用程序中一般都是 UIKit 隐式的自动使用 Autorelease Pool，可是有时候咱们也能够显式的来用它。

好比当你须要在代码中建立许多临时对象时，你会发现内存消耗激增直到这些对象被释放，一个问题是这些内存只会到 UIKit 销毁了它对应的 Autorelease Pool 后才会被释放，这就意味着这些内存没必要要地会空占一些时间。这时候就是咱们显式的使用 Autorelease Pool 的时候了，一个示例以下：

  1. NSArray *urls = <# An array of file URLs #>;
  2. for (NSURL *url in urls) {
  3. @autoreleasepool {
  4. NSError *error;
  5. NSString *fileContents = [NSString stringWithContentsOfURL:url
  6. encoding:NSUTF8StringEncoding error:&error];
  7. /* Process the string, creating and autoreleasing more objects. */
  8. }
  9. }

上面的代码在每一轮迭代中都会释放掉临时对象，从而缓解内存压力，提升性能。

关于 Autorelease Pool 你还能够看看：Using Autorelease Pool Blocks 和 iOS 中的 AutoreleasePool。

在 iOS 应用中加载图片一般有 - [UIImage imageNamed:] 和 -[UIImage imageWithContentsOfFile:] 两种方式。它们的不一样在于前者会对图片进行缓存，然后者只是简单的从文件加载文件。

  1. UIImage *img = [UIImage imageNamed:@"myImage"]; // caching
  2. // or
  3. UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"]; // no caching

在整个程序运行的过程当中，当你须要加载一张较大的图片，而且只会使用它一次，那么你就不必缓存这个图片，这时你可使用 -[UIImage imageWithContentsOfFile:]，这样系统也不会浪费内存来作缓存了。固然，若是你会屡次使用到一张图时，用 - [UIImage imageNamed:] 就会高效不少，由于这样就不用每次都从硬盘上加载图片了。

在前文中，咱们已经讲到了经过复用或者单例来提升 NSDateFormatter 这个高开销对象的使用效率。可是若是你要追求更快的速度，你能够直接使用 C 语言替代 NSDateFormatter 来解析 date，你能够看看这篇文章：link，其中展现了解析 ISO-8601 date string 的代码，你能够根据你的需求改写。完成的代码见：SSToolkit/NSDate+SSToolkitAdditions.m。

固然，若是你可以控制你接受到的 date 的参数的格式，你必定要尽可能选择 Unix timestamps格式，这样你可使用：

  1. - (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
  2. return [NSDate dateWithTimeIntervalSince1970:timestamp];
  3. }

这样你能够轻松的将时间戳转化为 NSDate 对象，而且效率甚至高于上面提到的 C 函数。

须要注意的是，不少 web API 返回的时间戳是以毫秒为单位的，由于这更利于 Javascript 去处理，可是上面代码用到的方法中 NSTimeInterval 的单位是秒，因此当你传参的时候，记得先除以 1000。

在 Objective-C 的消息分发过程当中，全部 [receiver message:…] 形式的方法调用最终都会被编译器转化为 obj_msgSend(recevier, @selector(message), …) 的形式调用。在运行时，Runtime 会去根据 selector 到对应方法列表中查找相应的 IMP 来调用，这是一个动态绑定的过程。为了加速消息的处理，Runtime 系统会缓存使用过的 selector 对应的 IMP 以便后面直接调用，这就是 IMP Caching。经过 IMP Caching 的方式，Rumtime 可以跳过 obj_msgSend 的过程直接调用方法的实现，从而提升方法调用效率。

下面看段示例代码：

  1. #define LOOP 1000000
  2. #define START { clock_t start, end; start = clock();
  3. #define END end = clock(); printf("Cost: %f ms\n", (double)(end - start) / CLOCKS_PER_SEC * 1000); }
  5. - (NSDateFormatter *)dateFormatter:(NSString *)format {
  6. NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
  7. [dateFormatter setDateFormat:format];
  9. return dateFormatter;
  10. }
  13. - (void)testIMPCaching {
  14. [self normalCall];
  16. [self impCachingCall];
  17. }
  19. - (void)normalCall {
  20. START
  22. for (int32_t i = 0; i < LOOP; i++) {
  23. NSDateFormatter *d =[self dateFormatter:@"yyyy-MM-dd a HH:mm:ss EEEE"];
  24. d = nil;
  25. }
  27. END
  28. // Print: Cost: 1328.845000 ms
  29. }
  31. - (void)impCachingCall {
  32. START
  34. SEL sel = @selector(dateFormatter:);
  35. NSDateFormatter *(*imp)(id, SEL, id) = (NSDateFormatter *(*)(id, SEL, id)) [self methodForSelector:sel];
  37. for (int32_t i = 0; i < LOOP; i++) {
  38. NSDateFormatter *d = imp(self, sel, @"yyyy-MM-dd a HH:mm:ss EEEE");
  39. d = nil;
  40. }
  42. END
  43. // Print: Cost: 1130.200000 ms
  44. }

代码打印结果以下：

  1. Cost: 1328.845000 ms
  2. Cost: 1130.200000 ms

可见相差并不太大，在 impCachingCall 中是直接手动作 IMP Caching 来跳过 obj_msgSend 调用方法的实现。normalCall 则是在 Runtime 经过系统本身的 IMP Caching 机制来运行。一般咱们不须要作 IMP Caching，可是若是有时候哪怕一点点的速度提高也是你须要的，你能够考虑考虑这点。

此外关于 Objective 运行时相关的知识，你能够看看这篇：Objective-C 的 Runtime

参考：

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程