iOS内存的使用和优化的注意事项
-
重用问题：
如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews
设置正确的reuseIdentifier，充分重用；
尽量把views设置为不透明：
当opque为NO的时候，图层的半透明取决于图片和其本身合成的图层为结果，可提高性能；
不要使用太复杂的XIB/Storyboard：
载入时就会将XIB/storyboard需要的所有资源，
包括图片全部载入内存，即使未来很久才会使用。
那些相比纯代码写的延迟加载，性能及内存就差了很多；
选择正确的数据结构：
学会选择对业务场景最合适的数组结构是写出高效代码的基础。
比如，数组: 有序的一组值。
使用索引来查询很快，使用值查询很慢，插入/删除很慢。
字典: 存储键值对，用键来查找比较快。
集合: 无序的一组值，用值来查找很快，插入/删除很快。
gzip/zip压缩：
当从服务端下载相关附件时，可以通过gzip/zip压缩后再下载，使得内存更小，下载速度也更快。
延迟加载：
对于不应该使用的数据，使用延迟加载方式。
对于不需要马上显示的视图，使用延迟加载方式。
比如，网络请求失败时显示的提示界面，可能一直都不会使用到，因此应该使用延迟加载。
数据缓存：
对于cell的行高要缓存起来，使得reload数据时，效率也极高。
而对于那些网络数据，不需要每次都请求的，应该缓存起来，
可以写入数据库，也可以通过plist文件存储。
处理内存警告：
一般在基类统一处理内存警告，将相关不用资源立即释放掉
重用大开销对象：
一些objects的初始化很慢，
比如NSDateFormatter和NSCalendar，但又不可避免地需要使用它们。
通常是作为属性存储起来，防止反复创建。
避免反复处理数据：
许多应用需要从服务器加载功能所需的常为JSON或者XML格式的数据。
在服务器端和客户端使用相同的数据结构很重要;
使用Autorelease Pool：
在某些循环创建临时变量处理数据时，自动释放池以保证能及时释放内存;
正确选择图片加载方式：详情阅读细读UIImage加载方式
-
重用问题：
如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews
设置正确的reuseIdentifier，充分重用；
尽量把views设置为不透明：
当opque为NO的时候，图层的半透明取决于图片和其本身合成的图层为结果，可提高性能；
不要使用太复杂的XIB/Storyboard：
载入时就会将XIB/storyboard需要的所有资源，
包括图片全部载入内存，即使未来很久才会使用。
那些相比纯代码写的延迟加载，性能及内存就差了很多；
选择正确的数据结构：
学会选择对业务场景最合适的数组结构是写出高效代码的基础。
比如，数组: 有序的一组值。
使用索引来查询很快，使用值查询很慢，插入/删除很慢。
字典: 存储键值对，用键来查找比较快。
集合: 无序的一组值，用值来查找很快，插入/删除很快。
gzip/zip压缩：
当从服务端下载相关附件时，可以通过gzip/zip压缩后再下载，使得内存更小，下载速度也更快。
延迟加载：
对于不应该使用的数据，使用延迟加载方式。
对于不需要马上显示的视图，使用延迟加载方式。
比如，网络请求失败时显示的提示界面，可能一直都不会使用到，因此应该使用延迟加载。
数据缓存：
对于cell的行高要缓存起来，使得reload数据时，效率也极高。
而对于那些网络数据，不需要每次都请求的，应该缓存起来，
可以写入数据库，也可以通过plist文件存储。
处理内存警告：
一般在基类统一处理内存警告，将相关不用资源立即释放掉
重用大开销对象：
一些objects的初始化很慢，
比如NSDateFormatter和NSCalendar，但又不可避免地需要使用它们。
通常是作为属性存储起来，防止反复创建。
避免反复处理数据：
许多应用需要从服务器加载功能所需的常为JSON或者XML格式的数据。
在服务器端和客户端使用相同的数据结构很重要;
使用Autorelease Pool：
在某些循环创建临时变量处理数据时，自动释放池以保证能及时释放内存;
正确选择图片加载方式：详情阅读细读UIImage加载方式
