title: "构建内存高效的应用" --中文标题 date: 2015-09-21 10:00:00 --文章发布时间，由发布人员填写 tags: [Thomas Hanning] -- 原文title，对应tower.im授权网站列表右边那一列 categories: [Swift 进阶] --暂时只有进阶和入门2类 permalink: building-memory-efficient-apps --swift.gg上会生成的超链接，由发布人员填写即可
原文链接=http://www.thomashanning.com/building-memory-efficient-apps/ 作者=Thomas Hanning --对应tower.im授权网站列表右边那一列 原文日期=2015/08/06 --原文时间 译者=BridgeQ 校对=lfb-CD 定稿=shanks
近年来，移动设备的性能越来越强大。然而，同桌面电脑相比，性能上总还是有一段不小的差距。同时，用户界面和交互设计的要求也越来越高。所以，为移动设备编写内存高效的应用仍然很有必要。
通俗点讲，内存高效的应用是指：仅使用必要的内存消耗并尽量减少内存消耗；用户界面设计使用低内存消耗的框架。当然，一个复杂度更高的应用也肯定需要更高的内存消耗。
接下来我们首先来回顾一小段历史：
在早期的 iOS 开发中，内存管理扮演着非常重要的角色。因为传统的垃圾回收机制对于移动平台来说是非常低效的，所以苹果把内存管理的责任交给了开发者，你需要通过手动的方式来增加或减少一个对象的引用计数。
通过这种方式，你可以写出内存管理非常高效的应用，因为对象不再使用时就立刻被销毁了。但另一方面，很多时候手动管理内存并不容易，也经常产生一些不易被发现的bug。所以，这并不是解决内存管理问题的最好办法。
新的解决方案是在 iOS 5 中被提出的：自动引用计数（ARC）。从此之后，控制引用计数的命令会在编译期间被自动加入而无需手动编写。这样带来的好处是：一方面能编写出内存高效的代码，另一方面让开发者不用再关心内存管理问题。这个解决方案非常棒，以至于 Mac OS X 的应用程序也开始使用 ARC 来管理内存。
不过，尽管你不需要再关心引用计数了，但还是需要你去关心一些其他内存管理相关的知识点。
正如前文所说，不同的需求意味着应用的内存消耗也不尽相同，除此之外，不同的需求还意味着应用适应于不同的部署版本（应用运行所支持的最低系统版本）。举个栗子，如果你的部署版本是 iOS 5，那么你就不能忘了要支持第一代 iPad 产品，它的内存大小仅仅是 256 MB。虽然，支持尽可能多的版本是一种不错的选择，但是，在你所支持的版本上为用户带来良好的用户体验才是更重要的。所以，当你想支持一些旧设备的时候，在设计阶段就要仔细考虑内存消耗问题。
下面列举了不同系统版本所支持的一些旧设备：
- iOS 9: iPhone 4S / iPad 2 / iPad Mini 1
- iOS 8: iPhone 4S / iPad 2 / iPad Mini 1
- iOS 7: iPhone 4 / iPad 2 / iPad Mini 1
- iOS 6: iPhone 3GS / iPad 2/ iPad Mini 1
- iOS 5: iPhone 3GS / iPad 1 / –
由于苹果的生态系统更新速度比较快，所以支持最新的两代操作系统版本是一个很好的选择。除了内存方面的问题，支持过多的系统版本还会带来开发和测试等诸多方面的问题。
在移动应用中，图片是非常重要的资源。然而，图片也通常代表着高内存消耗。在处理图片资源的时候，有以下两点需要注意：
- 首先，图片应该有合适的尺寸。如果你有一个表格视图，上面需要 100 × 100 像素的图片，而你却使用 1000 × 1000 像素的图片，这一定是一个非常糟糕的作法，性能会受到非常大的影响。如果你是通过请求服务器获取的图片，那么服务器也应该进行处理以提供合适尺寸的图片。
- 其次，一定要保证图片只是在需要使用的时候才被加载。举个栗子，表格视图里的图片只有当单元格显示出来的时候才需要被加载，也就是说单元格是可以循环利用的。想象一下，如果你的表格视图有 5000 个单元格并在进入屏幕的时候全部被加载，这样的话，即使你的应用没有因为内存压力而崩溃，用户体验也一定会非常的糟糕。你自定义的视图也同样应该遵守这一原则。再举个栗子，如果你在开发一个相册类应用，不要一口气把所有图片都加载完，你只需加载显示在屏幕上的那些图片就够了。这种技术也通常被称作延迟加载（lazy loading）。
延迟加载技术的主旨就是尽可能晚地去加载资源，这样会带来以下两点优势：
- 可以更好地来分配不同的加载时间
- 可以避免加载那些可能不需要的资源
那么在 iOS 开发中如何使用延迟加载技术呢？正如前文提到的，表格视图就是一个很好的使用延迟加载技术的栗子。另一种使用延迟加载的方法是使用lazy关键字来修饰属性。想象一下你需要一个包含所有产品的数组，当用户进行一定交互时需要使用到它们。
var products: [Products] = modelClass.loadProducts()如上代码，这个数组即使在用户没有进行任何交互的情况下仍然会被加载，这是一种内存浪费。如果加上lazy关键字进行修饰，那么只有在用户第一次访问数组的时候它才会初始化。
lazy var products: [Products] = modelClass.loadProducts()即使只是一些小的数组和变量，合理地使用延迟加载技术也能节省很大一部分内存。
在所有内存问题中最坏的一种情况就是视图控制器不再需要的时候却没有被释放，出现这种情况最通常的原因是循环引用。试想一下，现在有一个控制器 A，它拥有一个控制器 B 作为它的子控制器，而且，控制器 B 还有一个指向控制器 A 的引用，这样它们都互相强引用着对方。
现在，即使控制器 A 从屏幕中离开，两个控制器也不会被释放，因为它们还都强引用着对方。要避免这种情况你可以使用weak关键字。举个栗子，想要将控制器 A 设置为控制器 B 的代理，正确的属性声明应该如下所示：
weak var delegate: DelegateType?如果想检查控制器是否被正确释放，可以在控制器的deinit方法中打印消息来查看，代码如下：
deinit {
println("deinit")
}接下来你就可以通过在控制台中观察，是否有输出来检查控制器对象是否被正确释放。比如说，当你的控制器是被导航控制器通过push方法展现出来的时候，如果你点击了导航条上的返回按钮，控制器应该被释放并且在控制台中输出信息。
我们通常是在项目开发的最后阶段才发现内存管理的很糟糕，不幸的是，这样已经太晚了。所以在项目开发过程中，经常对内存使用量进行监测是非常重要的。你只需在一台真机上运行你的应用，然后点击Xcode中调试选项卡下的Memory。
内存管理在移动开发领域是一个非常重要的话题。如果你使用了过多的内存消耗，应用就会变慢甚至可能崩溃。相反，如果你认真对待内存管理问题，你就会构建出内存高效的应用。