[转]25个加强iOS应用程序性能的提示和技巧 — 初级篇

时间  2019-11-21
标签 加强 ios 应用 程序 性能 提示 技巧 初级 栏目 iOS 繁體版
原文   原文链接

_____________
转自：BeyondVincent的博客
_____________html

在开发iOS应用程序时，让程序具备良好的性能是很是关键的。这也是用户所指望的，若是你的程序运行迟钝或缓慢，会招致用户的差评。ios

然而因为iOS设备的局限性，有时候要想得到良好的性能，是很困难的。在开发过程当中，有许多事项须要记住，而且关于性能影响很容易就忘记。编程

这就是为何我要写这篇文章！本文收集了25个关于能够提高程序性能的提示和技巧。数组

目录

我把性能优化技巧分为3个不一样的等级：初级、中级和高级：缓存

初级性能优化

在开发过程当中，下面这些初级技巧须要时刻注意：服务器

  1. 使用ARC进行内存管理
  2. 在适当的状况下使用reuseIdentifier
  3. 尽量将View设置为不透明（Opaque）
  4. 避免臃肿的XIBs
  5. 不要阻塞主线程
  6. 让图片的大小跟UIImageView同样
  7. 选择正确的集合
  8. 使用GZIP压缩

 

初级性能提高

本部份内容介绍几本的程序性能提高技巧。其实全部级别的开发者都能从中获益。网络


1) 使用ARC进行内存管理多线程

ARC是在iOS 5中发布的，它解决了最多见的内存泄露问题——也是开发者最容易健忘的。app

ARC的全称是“Automatic Reference Counting”——自动引用计数，它会自动的在代码中作retain/release工做，开发者不用再手动处理。

下面是建立一个View通用的一些代码块：

UIView *view = [[UIView alloc] init];
// ...
[self.view addSubview:view];
[view release];

在上面代码结束的地方很容易会忘记调用release。不过当使用ARC时，ARC会在后台自动的帮你调用release。

ARC除了能避免内存泄露外，还有助于程序性能的提高：当程序中的对象再也不须要的时候，ARC会自动销毁对象。因此，你应该在工程中使用ARC。

下面是一些学习ARC很棒的一些资源：

值得注意的是，ARC并不能避免全部的内存泄露。使用ARC以后，工程中可能还会有内存泄露，不过引发这些内存泄露的主要缘由是：block，retain循环，对CoreFoundation对象（一般是C结构）管理不善，以及真的是代码没写好。

这里有一篇文章是介绍哪些问题是ARC不能解决的 — 以及如何处理这些问题。


2) 在适当的状况下使用reuseIdentifier

在适当的状况使用reuseIdentifier

在iOS程序开发中一个广泛性的错误就是没有正确的为UITableViewCells、UICollectionViewCells和UITableViewHeaderFooterViews设置reuseIdentifier。

为了得到最佳性能，当在tableView:cellForRowAtIndexPath:方法中返回cell时，table view的数据源通常会重用UITableViewCell对象。table view维护着UITableViewCell对象的一个队列或者列表，这些数据源已经被标记为重用了。

若是没有使用reuseIdentifier会发生什么？

若是你在程序中没有使用reuseIdentifier，table view每次显示一个row时，都会配置一个全新的cell。这实际上是一个很是消耗资源的操做，而且会影响程序中table view滚动的效率。

自iOS 6以来，你可能还但愿header和footer views，以及UICollectionView的cell和supplementary views。

为了使用reuseIdentifiers，在table view请求一个新的cell时，在数据源中调用下面的方法：

static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

若是table view维护的UITableViewCell队列或列表中有可用的cell，则从队列从移除一个已经存在的cell，若是没有的话，就从以前注册的nib文件或类中建立一个新的cell。若是没有能够重用的cell，而且没有注册nib文件或类，tableview的dequeueReusableCellWithIdentifier:方法会返回一个nil。


3) 尽量将View设置为不透明（Opaque）

尽可能将view设置为Opaque

 

若是view是不透明的，那么应该将其opaque属性设置为YES。

为何要这样作呢？这样设置可让系统以最优的方式来绘制view。opaque属性能够在Interface Builder或代码中设置。

苹果的官方文档对opaque属性有以下解释：

This property provides a hint to the drawing system as to how it should treat the view. If set to YES, the drawing system treats the view as fully opaque, which allows the drawing system to optimize some drawing operations and improve performance. If set to NO, the drawing system composites the view normally with other content. The default value of this property is YES.

（opaque属性提示绘制系统如何处理view。若是opaque设置为YES，绘图系统会将view看为彻底不透明，这样绘图系统就能够优化一些绘制操做以提高性能。若是设置为NO，那么绘图系统结合其它内容来处理view。默认状况下，这个属性是YES。）

 

若是屏幕是静止的，那么这个opaque属性的设置与否不是一个大问题。可是，若是view是嵌入到scroll view中的，或者是复杂动画的一部分，不将设置这个属性的话确定会影响程序的性能！

能够经过模拟器的Debug\Color Blended Layers选项来查看哪些view没有设置为不透明。为了程序的性能，尽量的将view设置为不透明！

 


4) 避免臃肿的XIBs

避免臃肿的XIBs

 

在iOS 5中开始使用Storyboards，而且将替代XIBs。不过在有些状况下XIBs仍然有用。若是你的程序须要运行在装有iOS 5以前版本的设备上，或者要自定义可重用的view，那么是避免不了要使用XIBs的。

若是必需要使用XIBs的话，尽可能让XIBs文件简单。而且每一个view controller对于一个XIB文件，若是能够的话，把一个view controller的view不一样的层次单独分到一个XIBs文件中。

注意：当把一个XIB文件加载到内存时，XIB文件中的全部内容都将被加载到内存中，包括图片。若是有一个view还不当即使用的话，就会形成内存的浪费。而这在storyboard中是不会发生的，由于storyboard还在须要的时候才实例化一个view controller。

当加载XIB时，全部涉及到的图片都将被缓存，而且若是是开发的程序是针对OS X的话，声音文件也会被加载。苹果的官方文档这样说：

When you load a nib file that contains references to image or sound resources, the nib-loading code reads the actual image or sound file into memory and and caches it. In OS X, image and sound resources are stored in named caches so that you can access them later if needed. In iOS, only image resources are stored in named caches. To access images, you use the imageNamed: method of NSImage or UIImage, depending on your platform.

（当加载一个nib文件时，也会将nib文件涉及到的图片或声音资源加载到内存中，nib-loading代码会将实际的图片或声音文件读取到内存中，并一直缓存着。在OS X中，图片和声音资源都存储在命名缓存中，这样以后若是须要的话，能够对其进行访问。在iOS中，只有图片资源被存储到命名缓存中。要访问图片的话，使用NSImage或UIImage（根据不一样的系统）的imageNamed:方法便可。）

显然，在使用storyboard时也会发生相似的缓存操做；不过我没有找到相关内容的任何资料。若是你知道的话，能够告诉我哦！

想要学习storyboard的更多知识吗？能够看看Matthijs Hollemans写的iOS 5中：初级Storyboard Part 1和Part2。

5) 不要阻塞主线程

不要阻塞主线程

 

永远都不要在主线程作繁重的任务。由于UIKit的任务都在主线程中进行，例如绘制、触摸管理和输入响应。

在主线程作全部任务的风险是：若是你的代码阻塞了主线程，那么程序将出现反应迟钝。这回招致用户在App Store上对程序的差评！

在执行I/O操做中，大多数状况下都会祖塞主线程，这些操做须要从读写外部资源，例如磁盘或者网络。

关于网络操做可使用NSURLConnection的以下方法，以异步的方式来执行：

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

或者使用第三方框架，例如AFNetworking。

若是你须要作一些其它类型开销很大的操做（例如执行一个时间密集型的计算或者对磁盘进行读写），那么就使用GCD（Grand Central Dispatch），或NSOperations 和 NSOperationQueues。

下面的代码是使用GCD的一个模板：

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // switch to a background thread and perform your expensive operation

    dispatch_async(dispatch_get_main_queue(), ^{
        // switch back to the main thread to update your UI

    });
});

如上代码，为何在第一个dispatch_async里面还嵌套了一个dispatch_async呢？这是由于关于UIKit相关的代码须要在主线程里面执行。

对NSOperation和GCD感到好奇吗？能够看看Ray Wenderlich中的教程：iOS中多线程和GCD—初级，以及Soheil Azarpour的如何使用NSOperations和NSOperationQueues教程。

 


6) 让图片的大小跟UIImageView同样

确保图片和UIImageView大小一致

若是须要将程序bundle中的图片显示到UIImageView中，请确保图片和UIImageView的大小是同样的。由于图片的缩放很是耗费资源，特别是将UIImageView嵌入到UIScrollView中。

若是是从远程服务中下载图片，有时候你控制不了图片的尺寸，或者在下载以前没法在服务器上进行图片的缩放。这种状况，当图片下载完以后，你能够手动进行图片的缩放——作好是在后台线程中！——而后再在UIImageView中使用缩放过的图片。

 


7) 选择正确的集合

选择正确的集合

学习使用最适合的类或对象是编写高效代码的基础。特别是在处理集合数据时，尤其重要。

苹果的官网上有一篇文章：集合编程主题(Collections Programming Topics)——详细的介绍了在集合数据中可使用的类，以及什么状况下使用哪一个类。在使用集合时，每一个开发者都应该阅读一下这个文档。

太长，不想阅读(TLDR)？下面是常见集合类型的一个简介：

  • 数组：是一个值按顺序排列的一个列表。根据索引能够快速查找，不过根据值进行查找就比较慢，另外插入和删除也比较慢。
  • 字典:  存储键/值对。根据键能够快速查找。
  • Sets:  是一个值无序排列的列表，根据值能够快速查找，另外插入和删除也比较快。


8) 使用GZIP压缩

使用GZIP压缩

愈来愈多的程序依赖于外部数据，这些数据通常来自远程服务器或者其它的外部APIs。有时候你须要开发一个程序来下载一些数据，这些数据能够是XML，JSON，HTML或者其它一些文本格式。

问题是在移动设备上的网络是不肯定的。用户的设备可能在EDGE网络一分钟，而后接着又在3G网络中。无论在什么状况下，都不要让用户等待。

有一个能够优化的选择：使用GZIP对网络传输中的数据进行压缩，这样能够减少文件的大小，并加快下载的速度。压缩对于文本数据特别有用，由于文本具备很高的压缩比。

iOS中，若是使用NSURLConnection，那么默认状况下已经支持GZIP压缩了，而且基于NSURLConnection的框架页支持GZIP压缩，如AFNetworking。甚至有些云服务提供商已经提供发送经压缩过的响应内容，例如 Google App Engine。

这里有一篇关于GZIP压缩很好的文章，介绍了如何在Apache活IIS服务器中开启支持GZIP压缩。

_____________
转载请注明出处：BeyondVincent的博客
_____________

在开发iOS应用程序时，让程序具备良好的性能是很是关键的。这也是用户所指望的，若是你的程序运行迟钝或缓慢，会招致用户的差评。

然而因为iOS设备的局限性，有时候要想得到良好的性能，是很困难的。在开发过程当中，有许多事项须要记住，而且关于性能影响很容易就忘记。

这就是为何我要写这篇文章！本文收集了25个关于能够提高程序性能的提示和技巧。

目录

我把性能优化技巧分为3个不一样的等级：初级、中级和高级：

初级

在开发过程当中，下面这些初级技巧须要时刻注意：

  1. 使用ARC进行内存管理
  2. 在适当的状况下使用reuseIdentifier
  3. 尽量将View设置为不透明（Opaque）
  4. 避免臃肿的XIBs
  5. 不要阻塞主线程
  6. 让图片的大小跟UIImageView同样
  7. 选择正确的集合
  8. 使用GZIP压缩

 

初级性能提高

本部份内容介绍几本的程序性能提高技巧。其实全部级别的开发者都能从中获益。


1) 使用ARC进行内存管理

ARC是在iOS 5中发布的，它解决了最多见的内存泄露问题——也是开发者最容易健忘的。

ARC的全称是“Automatic Reference Counting”——自动引用计数，它会自动的在代码中作retain/release工做，开发者不用再手动处理。

下面是建立一个View通用的一些代码块：

UIView *view = [[UIView alloc] init];
// ...
[self.view addSubview:view];
[view release];

在上面代码结束的地方很容易会忘记调用release。不过当使用ARC时，ARC会在后台自动的帮你调用release。

ARC除了能避免内存泄露外，还有助于程序性能的提高：当程序中的对象再也不须要的时候，ARC会自动销毁对象。因此，你应该在工程中使用ARC。

下面是一些学习ARC很棒的一些资源：

值得注意的是，ARC并不能避免全部的内存泄露。使用ARC以后，工程中可能还会有内存泄露，不过引发这些内存泄露的主要缘由是：block，retain循环，对CoreFoundation对象（一般是C结构）管理不善，以及真的是代码没写好。

这里有一篇文章是介绍哪些问题是ARC不能解决的 — 以及如何处理这些问题。


2) 在适当的状况下使用reuseIdentifier

在适当的状况使用reuseIdentifier

在iOS程序开发中一个广泛性的错误就是没有正确的为UITableViewCells、UICollectionViewCells和UITableViewHeaderFooterViews设置reuseIdentifier。

为了得到最佳性能，当在tableView:cellForRowAtIndexPath:方法中返回cell时，table view的数据源通常会重用UITableViewCell对象。table view维护着UITableViewCell对象的一个队列或者列表，这些数据源已经被标记为重用了。

若是没有使用reuseIdentifier会发生什么？

若是你在程序中没有使用reuseIdentifier，table view每次显示一个row时，都会配置一个全新的cell。这实际上是一个很是消耗资源的操做，而且会影响程序中table view滚动的效率。

自iOS 6以来，你可能还但愿header和footer views，以及UICollectionView的cell和supplementary views。

为了使用reuseIdentifiers，在table view请求一个新的cell时，在数据源中调用下面的方法：

static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

若是table view维护的UITableViewCell队列或列表中有可用的cell，则从队列从移除一个已经存在的cell，若是没有的话，就从以前注册的nib文件或类中建立一个新的cell。若是没有能够重用的cell，而且没有注册nib文件或类，tableview的dequeueReusableCellWithIdentifier:方法会返回一个nil。


3) 尽量将View设置为不透明（Opaque）

尽可能将view设置为Opaque

 

若是view是不透明的，那么应该将其opaque属性设置为YES。

为何要这样作呢？这样设置可让系统以最优的方式来绘制view。opaque属性能够在Interface Builder或代码中设置。

苹果的官方文档对opaque属性有以下解释：

This property provides a hint to the drawing system as to how it should treat the view. If set to YES, the drawing system treats the view as fully opaque, which allows the drawing system to optimize some drawing operations and improve performance. If set to NO, the drawing system composites the view normally with other content. The default value of this property is YES.

（opaque属性提示绘制系统如何处理view。若是opaque设置为YES，绘图系统会将view看为彻底不透明，这样绘图系统就能够优化一些绘制操做以提高性能。若是设置为NO，那么绘图系统结合其它内容来处理view。默认状况下，这个属性是YES。）

 

若是屏幕是静止的，那么这个opaque属性的设置与否不是一个大问题。可是，若是view是嵌入到scroll view中的，或者是复杂动画的一部分，不将设置这个属性的话确定会影响程序的性能！

能够经过模拟器的Debug\Color Blended Layers选项来查看哪些view没有设置为不透明。为了程序的性能，尽量的将view设置为不透明！

 


4) 避免臃肿的XIBs

避免臃肿的XIBs

 

在iOS 5中开始使用Storyboards，而且将替代XIBs。不过在有些状况下XIBs仍然有用。若是你的程序须要运行在装有iOS 5以前版本的设备上，或者要自定义可重用的view，那么是避免不了要使用XIBs的。

若是必需要使用XIBs的话，尽可能让XIBs文件简单。而且每一个view controller对于一个XIB文件，若是能够的话，把一个view controller的view不一样的层次单独分到一个XIBs文件中。

注意：当把一个XIB文件加载到内存时，XIB文件中的全部内容都将被加载到内存中，包括图片。若是有一个view还不当即使用的话，就会形成内存的浪费。而这在storyboard中是不会发生的，由于storyboard还在须要的时候才实例化一个view controller。

当加载XIB时，全部涉及到的图片都将被缓存，而且若是是开发的程序是针对OS X的话，声音文件也会被加载。苹果的官方文档这样说：

When you load a nib file that contains references to image or sound resources, the nib-loading code reads the actual image or sound file into memory and and caches it. In OS X, image and sound resources are stored in named caches so that you can access them later if needed. In iOS, only image resources are stored in named caches. To access images, you use the imageNamed: method of NSImage or UIImage, depending on your platform.

（当加载一个nib文件时，也会将nib文件涉及到的图片或声音资源加载到内存中，nib-loading代码会将实际的图片或声音文件读取到内存中，并一直缓存着。在OS X中，图片和声音资源都存储在命名缓存中，这样以后若是须要的话，能够对其进行访问。在iOS中，只有图片资源被存储到命名缓存中。要访问图片的话，使用NSImage或UIImage（根据不一样的系统）的imageNamed:方法便可。）

显然，在使用storyboard时也会发生相似的缓存操做；不过我没有找到相关内容的任何资料。若是你知道的话，能够告诉我哦！

想要学习storyboard的更多知识吗？能够看看Matthijs Hollemans写的iOS 5中：初级Storyboard Part 1和Part2。

5) 不要阻塞主线程

不要阻塞主线程

 

永远都不要在主线程作繁重的任务。由于UIKit的任务都在主线程中进行，例如绘制、触摸管理和输入响应。

在主线程作全部任务的风险是：若是你的代码阻塞了主线程，那么程序将出现反应迟钝。这回招致用户在App Store上对程序的差评！

在执行I/O操做中，大多数状况下都会祖塞主线程，这些操做须要从读写外部资源，例如磁盘或者网络。

关于网络操做可使用NSURLConnection的以下方法，以异步的方式来执行：

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

或者使用第三方框架，例如AFNetworking。

若是你须要作一些其它类型开销很大的操做（例如执行一个时间密集型的计算或者对磁盘进行读写），那么就使用GCD（Grand Central Dispatch），或NSOperations 和 NSOperationQueues。

下面的代码是使用GCD的一个模板：

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    // switch to a background thread and perform your expensive operation

    dispatch_async(dispatch_get_main_queue(), ^{
        // switch back to the main thread to update your UI

    });
});

如上代码，为何在第一个dispatch_async里面还嵌套了一个dispatch_async呢？这是由于关于UIKit相关的代码须要在主线程里面执行。

对NSOperation和GCD感到好奇吗？能够看看Ray Wenderlich中的教程：iOS中多线程和GCD—初级，以及Soheil Azarpour的如何使用NSOperations和NSOperationQueues教程。

 


6) 让图片的大小跟UIImageView同样

确保图片和UIImageView大小一致

若是须要将程序bundle中的图片显示到UIImageView中，请确保图片和UIImageView的大小是同样的。由于图片的缩放很是耗费资源，特别是将UIImageView嵌入到UIScrollView中。

若是是从远程服务中下载图片，有时候你控制不了图片的尺寸，或者在下载以前没法在服务器上进行图片的缩放。这种状况，当图片下载完以后，你能够手动进行图片的缩放——作好是在后台线程中！——而后再在UIImageView中使用缩放过的图片。

 


7) 选择正确的集合

选择正确的集合

学习使用最适合的类或对象是编写高效代码的基础。特别是在处理集合数据时，尤其重要。

苹果的官网上有一篇文章：集合编程主题(Collections Programming Topics)——详细的介绍了在集合数据中可使用的类，以及什么状况下使用哪一个类。在使用集合时，每一个开发者都应该阅读一下这个文档。

太长，不想阅读(TLDR)？下面是常见集合类型的一个简介：

  • 数组：是一个值按顺序排列的一个列表。根据索引能够快速查找，不过根据值进行查找就比较慢，另外插入和删除也比较慢。
  • 字典:  存储键/值对。根据键能够快速查找。
  • Sets:  是一个值无序排列的列表，根据值能够快速查找，另外插入和删除也比较快。


8) 使用GZIP压缩

使用GZIP压缩

愈来愈多的程序依赖于外部数据，这些数据通常来自远程服务器或者其它的外部APIs。有时候你须要开发一个程序来下载一些数据，这些数据能够是XML，JSON，HTML或者其它一些文本格式。

问题是在移动设备上的网络是不肯定的。用户的设备可能在EDGE网络一分钟，而后接着又在3G网络中。无论在什么状况下，都不要让用户等待。

有一个能够优化的选择：使用GZIP对网络传输中的数据进行压缩，这样能够减少文件的大小，并加快下载的速度。压缩对于文本数据特别有用，由于文本具备很高的压缩比。

iOS中，若是使用NSURLConnection，那么默认状况下已经支持GZIP压缩了，而且基于NSURLConnection的框架页支持GZIP压缩，如AFNetworking。甚至有些云服务提供商已经提供发送经压缩过的响应内容，例如 Google App Engine。

这里有一篇关于GZIP压缩很好的文章，介绍了如何在Apache活IIS服务器中开启支持GZIP压缩。

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