近年来,移动设备的性能越来越强大。然而,同桌面电脑相比,性能上总还是有一段不小的差距。同时,用户界面和交互设计的要求也越来越高。所以,为移动设备编写内存高效的应用仍然很有必要。
通俗点讲,内存高效的应用是指:仅使用必要的内存消耗并尽量减少内存消耗;用户界面设计使用低内存消耗的框架。当然,一个复杂度更高的应用也肯定需要更高的内存消耗。
接下来我们首先来回顾一小段历史:
在早期的 iOS 开发中,内存管理扮演着非常重要的角色。因为传统的垃圾回收机制对于移动平台来说是非常低效的,所以苹果把内存管理的责任交给了开发者,你需要通过手动的方式来增加或减少一个对象的引用计数。
通过这种方式,你可以写出内存管理非常高效的应用,因为对象不再使用时就立刻被销毁了。但另一方面,很多时候手动管理内存并不容易,也经常产生一些不易被发现的bug。所以,这并不是解决内存管理问题的最好办法。
新的解决方案是在 iOS 5 中被提出的:自动引用计数(ARC)。从此之后,控制引用计数的命令会在编译期间被自动加入而无需手动编写。这样带来的好处是:一方面能编写出内存高效的代码,另一方面让开发者不用再关心内存管理问题。这个解决方案非常棒,以至于 Mac OS X 的应用程序也开始使用 ARC 来管理内存。
不过,尽管你不需要再关心引用计数了,但还是需要你去关心一些其他内存管理相关的知识点。
正如前文所说,不同的需求意味着应用的内存消耗也不尽相同,除此之外,不同的需求还意味着应用适应于不同的部署版本(应用运行所支持的最低系统版本)。举个栗子,如果你的部署版本是 iOS 5,那么你就不能忘了要支持第一代 iPad 产品,它的内存大小仅仅是 256 MB。虽然,支持尽可能多的版本是一种不错的选择,但是,在你所支持的版本上为用户带来良好的用户体验才是更重要的。所以,当你想支持一些旧设备的时候,在设计阶段就要仔细考虑内存消耗问题。
下面列举了不同系统版本所支持的一些旧设备:
由于苹果的生态系统更新速度比较快,所以支持最新的两代操作系统版本是一个很好的选择。除了内存方面的问题,支持过多的系统版本还会带来开发和测试等诸多方面的问题。
在移动应用中,图片是非常重要的资源。然而,图片也通常代表着高内存消耗。在处理图片资源的时候,有以下两点需要注意:
延迟加载技术的主旨就是尽可能晚地去加载资源,这样会带来以下两点优势:
那么在 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
。
内存管理在移动开发领域是一个非常重要的话题。如果你使用了过多的内存消耗,应用就会变慢甚至可能崩溃。相反,如果你认真对待内存管理问题,你就会构建出内存高效的应用。