先弄清楚这里的学问,再来谈iOS内存管理与优化(二)

上篇文章讲述了iOS内存管理的基本概念,这里是一些内存优化的小技巧

Strong Weak Dance

这个大家都知道,就是处理循环引用,合理使用weakunowned

降低内存峰值

Lazy Allocation

延时加载是很常用的一种优化方法,如果有些情况我们不会立即使用某一对象和某些资源,我们完全可以在使用的时候再进行加载,这些就可以避免初次运行程序的时候内存消耗严重。

喵神的博客中,也发现了很好玩的地方,Swift标准库中,定义了一些Lazy方法,可以配合像 map或是 filter 这类接受闭包并进行运行的方法一起,让整个行为变成延时进行。

运行结果为:

图片的读取

相信写代码的时候都会涉及到图片的读取,我们经常使用的方法

  • 对于第一种,是带缓存机制的,如果频繁读取小文件,用它就只需要读取一次就好,但是缺点就是如果使用大图片会常驻内存,对于降低内存峰值是不利的。
  • 对于第二种方法,不带缓存机制,适合使用大图片,使用完就释放

NSData & 内存映射文件

在我们经常使用NSData时,出镜率很高的两个方法

第二种比第一个多一个Options,第二种方式是创建了一个内存映射文件,把内容放在虚拟内存中,只有读取操作的时候才会读到相对应页的物理内存页中。所以后者,对于大文件是很划算的,推荐使用第二种。对于可选的方式如下:

映射

其他方式

在庄延军老师的分享中,还有其他一些技巧,但是对于只懂Swift的我,实在没接触过哪些方案,等我接触之后,再来写第三个分享。下面简单列举一下:

  • calloc VS malloc + memset
  • 栈内存分配

NSAutoReleasePool

MRC时代说起,当需要我们手动来管理对象引用计数的时候,我们需要RetainRelease方法,那么可能一个线程中有大量的RetainRelease方法,这个时候使用一个池一起管理他们是不是方便很多,将线程中要执行的任务都放在自动释放池中,自动释放池会捕获所有任务中的对象,在任务结束或线程关闭之时自动释放这些对象。

当然自动释放池都会使用NSAutoreleasePool类创建,并在自动释放池收到 drain消息时将这些对象的引用计数减一,然后将它们从池子中移除 (这一过程形象地称为“抽干池子”)。

ARC时代,不再使用NSAutoreleasePool来创建自动释放池,而是使用@autoreleasepool代码块,新建Objective-C工程的时候,会帮我们创建一个main.m文件,已经帮我们在主线程创建了一个自动释放池。

}

更进一步,其实@autoreleasepool 在编译时会被展开为 NSAutoreleasePool,并且在每个主Runloop结束时进行drain操作。

那么到了Swift时代,又具有了新的变化,不需要手动地调用autorelease 这样的方法来管理引用计数,但是这些方法还是都会被调用的,只不过是编译器在编译时在合适的地方帮我们加入了而已。

在Swift标准库中可以发现:

那么我们就可以利用闭包的特点,在需要的时候非常简便的使用它

AutoReleasePool

为什么在ARC时代还需要使用自动释放池呢?其原因就是为了避免内存峰值,那比如说我有一个很大的For循环,里面不断读入较大的文件。其实每迭代一次,资源都已经用完了(就是说我用好了,还你),不需要再用了,这个时候就可以释放了,但是程序需要等到Runloop结束的时候才可以释放,这就增大了内存的峰值。

上面的话有点绕,但是真心非常重要。

那么怎么做,可以减小内存峰值呢?我们可以在For循环中添加autoreleasepool,这样就可以保证每次迭代完毕一次就可以释放点内存。

简单总结

上面的阐述了多种方法,其中对于降低内存峰值有作用的是:

  • Lazy Allocation
  • 图片的读取的正确方式
  • NSData & 内存映射文件
  • callocVS malloc + memset
  • 栈内存分配
  • autoReleasePool

内存警告处理

到收到内存警告的时候,所要做的:

  • 尽可能多的释放资源,尤其是图片等占用内存多的资源,等需要的时候再进行重建
  • 单例模式的滥用,会导致单例对象一直持有资源,在内存紧张的时候要进行释放,当然我也在其他博客中看到一些单例模式的替换方案
1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部