[ios代码释放内存]

1. 使用ARC管理内存

ARC（自动参考计数，自动参考计数）是随iOS 5一起发布的，它避免了由于我们忘记释放内存而经常引起的最常见的内存泄漏. 它会自动为您管理保留和释放的过程，因此您无需手动干预. 忘了在代码段末尾发布，就像记得吃饭一样简单. ARC会在底部自动为您执行此操作. 除了帮助您避免内存泄漏外，ARC还可以帮助您提高性能. 它可以保证释放不再需要的对象的内存.

2. 在正确的地方使用复用标识符

开发中的一个常见错误是UITableViewCells，UICollectionViewCells甚至UITableViewHeaderFooterViews都没有设置正确的redirectIdentifier.

为了性能优化，当表视图使用`tableView: cellForRowAtIndexPath: `为行分配单元格时，应从UITableViewCell中重用其数据. 表视图维护可重复使用的UITableViewCell对象的队列.

没有reuseIdentifier，每次显示表格视图时都必须设置一个全新的单元格. 这会对性能产生重大影响，尤其是应用程序的滚动体验.

从iOS6开始，除了UICollectionView单元格和补充视图之外，还应该在页眉和页脚视图中使用复用标识符.

如果要使用复用标识符，请在表视图中添加新单元格时将此方法添加到数据源对象中:

staticNSString * CellIdentifier = @“ Cell”;

UITableViewCell * cell = [tableView dequeueReusableCellWithIdentifier: CellIdentifier forIndexPath: indexPath];

此方法从队列中排除现有单元格，或在必要时使用先前注册的笔尖或类创建新单元格. 如果没有可重用的单元格，并且您尚未注册类或笔尖，则此方法将返回nil.

3. 使视图尽可能透明

如果您具有透明视图，则应将其不透明属性设置为“是”.

原因是，这将允许系统以最佳方式呈现这些视图. 可以用IB或代码设置此简单属性.

Apple的文档介绍了设置图像的透明属性:

（不透明）此属性为渲染系统提供有关如何处理此视图的提示. 如果设置为YES，则渲染系统认为该视图是完全不透明的，这使渲染系统可以优化某些渲染过程并提高性能. 如果设置为NO，则渲染系统通常会将此视图与其他内容一起形成. 默认值为是.

在相对静态的图片中，设置此属性不会有太大影响. 但是，当该视图嵌入滚动视图或作为复杂的一部分时，不设置此属性将极大地影响应用程序的性能.

您可以使用模拟器中的“ Debug \ Color Blended Layers”选项来发现哪些视图未设置为不透明. 目标是将所有内容设置为不透明！

4. 避免使用太大的XIB

iOS5中添加的故事板（点）正在迅速取代XIB. 但是，XIB在某些情况下仍然有用. 例如，您的应用需要适应iOS5之前的设备，或者如果您具有自定义的可重用视图，则不可避免地会使用它们.

如果必须使用XIB，请使其尽可能简单. 尝试为每个Controller配置一个单独的XIB，并将View Controller的视图层次结构尽可能分散到单独的XIB中.

请注意，加载XIB时，所有内容（包括所有图像）都将放置在内存中. 如果有一个视图不会立即被使用，则您正在浪费宝贵的内存资源. 故事板是另一个故事. 情节提要仅在需要时实例化视图控制器.

在XIB，所有图片都是chche. 如果要进行OS X开发，则声音文件也是如此. 苹果在相关文档中的描述是:

当您加载引用图像或声音资源的笔尖时，该笔尖加载代码会将图像和声音文件写入内存. 在OS X中，图像和声音资源被缓存在命名的缓存中以备将来使用. 在iOS中，仅图像资源存储在命名缓存中. 根据您的平台，使用NSImage或UIImage的`imageNamed: `方法来获取图像资源.

5. 不要阻塞主线程

切勿使主线程过载. 因为UIKit在主线程上完成了所有工作，所以渲染，管理触摸反应mcafee dlp 释放代码，响应输入等都需要在主线程上完成.

始终使用主线程的风险是，如果您的代码确实阻塞了主线程，则您的应用将无响应.

大多数阻碍主流程的情况是您的应用程序执行的I / O操作涉及读写存储，网络等外部资源.

您可以使用`NSURLConnection`异步执行网络操作:

（void）sendAsynchronousRequest: （NSURLRequest *）请求队列: （NSOperationQueue *）队列完成处理程序: （void（^）（NSURLResponse *，NSData *，NSError *））处理程序

或使用类似AFNetworking的框架来异步执行这些操作.

如果您需要执行其他需要大量资源的操作（例如对时间敏感的计算或存储读写操作），请使用Grand Central Dispatch或NSOperation和NSOperationQueues.

以下代码是使用GCD的模板

dispatch_async（dispatch_get_global_queue（DISPATCH_QUEUE_PRIORITY_DEFAULT，0），^ {

//切换到后台线程并执行昂贵的操作

dispatch_async（dispatch_get_main_queue（），^ {

//切换回主线程以更新您的UI

}）;

}）;

代码中是否有嵌套的`dispatch_async`？这是因为任何与UIKit相关的代码都需要在主线程上完成.

6. 在图像视图中调整图像大小

如果要在UIImageView中显示捆绑包中的图像，则应确保该图像的大小与UIImageView相同. 动态缩放图像会占用大量资源，尤其是如果UIScrollView中嵌套了UIImageView时.

如果图像是从远程服务加载的，则您无法控制图像的大小，例如在下载之前将其调整为合适的大小. 下载完成后，最好使用背景线程，一次缩放，然后在UIImageView Zoomed图片中使用它.

7. 选择合适的收藏

学会选择最适合业务场景的类或对象是编写节能代码的基础. 在处理集合时尤其如此.

一些常见收藏的摘要:

·数组: 一组有序的值. 使用索引查找速度很快，使用值查找速度很慢mcafee dlp 释放代码，插入/删除速度很慢.

·词典: 存储键值对. 找钥匙的速度更快.

·集合: 一组无序的值. 快速按值查找，快速插入/删除.

8. 打开gzip压缩

大量应用程序都依赖于远程资源和第三方API. 您可能会开发一个需要从远程站点下载XML，JSON，HTML或其他格式的应用.

问题在于我们的目标是移动设备，因此您不能指望网络的性能如何. 用户仍在边缘网络上，可能在下一分钟切换到3G. 无论哪种情况，您都绝对不希望用户等待太久.

减小文件大小的一种方法是在服务器上和应用程序中打开gzip. 这将对诸如文本之类的数据产生更大的影响，而这些数据可能具有更高的压缩率.

好消息是，默认情况下，iOS已默认在NSURLConnection中支持gzip压缩，当然还有基于它的AFNetworking框架. 诸如Google App Engine之类的云服务提供商也支持压缩输出.

9. 重用和延迟加载视图

更多视图意味着更多渲染，即更多CPU和内存消耗，尤其是对于在UIScrollView中嵌套了许多视图的应用程序而言.

我们在这里使用的技术是模仿UITableView和UICollectionView的操作: 不要一次创建所有子视图，而仅在需要时创建它们，并且当它们完成任务时，将它们放入可重用的环境中. 在队列中.

通过这种方式，您只需要在滚动时创建视图即可，从而避免了不经济的内存分配.

创建视图的能源效率问题也适用于您应用的其他方面. 想象一下一个场景，用户单击按钮时需要显示视图. 有两种方法可以实现此目的:

1. 加载屏幕后创建并隐藏此视图，并在需要时显示它；

2. 在需要时创建并显示.

每个计划都有其优点和缺点. 对于第一种解决方案，因为您需要在开始时创建一个视图并将其保留直到不再使用它，这将消耗更多的内存. 但是，这也会使您的应用更加敏感，因为当用户单击按钮时，只需要更改此视图的可见性即可.

第二个选项是相反的-它消耗更少的内存，但是单击按钮时它会比第一个慢一些.

10. 缓存，缓存或缓存！

一个很好的原则是缓存需要什么，即那些不太可能改变但需要经常阅读的东西.

我们可以缓存什么？一些选项是来自远程服务器的响应，图片，甚至是计算结果，例如UITableView的行高.

NSURLConnection默认根据加载的HTTP标头在内存或存储中缓存资源. 您甚至可以手动创建NSURLRequest，然后使其仅加载缓存的值.

这是一个代码片段，您可以使用该代码片段为不会更改并缓存它的图像创建NSURLRequest:

（NSMutableURLRequest *）imageRequestWithURL: （NSURL *）url {

NSMutableURLRequest *请求= [NSMutableURLRequest requestWithURL: url];

request.cachePolicy = NSURLRequestReturnCacheDataElseLoad; //这样可以确保请求始终返回缓存的图片

request.HTTPShouldHandleCookies = NO;

request.HTTPShouldUsePipelining = YES;

[请求addValue: @“ image

}

}

此代码在每次遍历后都会释放所有自动释放对象

24. 选择是否缓存图片

有两种常见的方式从捆绑包中加载图像. 一种使用“ imageNamed”，另一种使用“ imageWithContentsOfFile”.

由于有两种相似的方法可以实现相同的目标，所以它们之间有什么区别？

的优势

`imageNamed`是图像在加载时被缓存. 这就是imageNamed文档所说的: 此方法使用指定的名称查找系统缓存，并返回图像对象（如果存在）. 如果在缓存中找不到对应的图片，则此方法从指定的文档加载，然后缓存并返回此对象.

相反，`imageWithContentsOfFile`仅加载图像.

以下代码说明了这两种方法的使用:

UIImage * img = [UIImage imageNamed: @“ myImage”]; //缓存

//或

UIImage * img = [UIImage imageWithContentsOfFile: @“ myImage”]; //没有缓存

那我们应该如何选择？

如果要加载大图像并且仅使用一次，则无需缓存该图像. 使用`imageWithContentsOfFile`就足够了，这样就不会浪费内存来缓存它.

但是，当图像被重复使用时，`imageNamed`是一个更好的选择.

25. 避免日期格式转换

如果要使用`NSDateFormatter`处理许多日期格式，则应小心. 如前所述，在任何时候都可以重用`NSDateFormatters`.

但是，如果您需要更高的速度，那么直接使用C是一个很好的解决方案. Sam Soffes有一个不错的post（），其中包含一些可用于解析ISO-8601日期字符串的代码. 可以使用简单的重写.

好吧，直接使用C看起来不错，但是您认为我们有更好的解决方案！

如果可以控制要处理的日期格式，请尝试选择Unix时间戳. 您可以轻松地从时间戳转换为NSDate:

-（NSDate *）dateFromUnixTimestamp: （NSTimeInterval）时间戳{

返回[NSDate dateWithTimeIntervalSince1970: timestamp];

}

这比用C解析日期字符串要快！应该注意的是，许多Web API都以微秒为单位返回时间戳，因为这种格式更易于在JavaScript中使用. 请记住在“ dateFromUnixTimestamp”之前除以1000.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-162223-1.html