OS的多核编程和内存管理
隔上一次写iPadapp开发文章已经是10个月，那篇iPadapp开发概述还不错，曾经成为了Google关键字“iPadapp开发”搜索的第一位，可能是大牛们都太忙于赚appstore的钱了，留下我这个小虾来写文章。这次的文章集中与iOS的多核编程和内存管理，为什么？因为iPad2已经是双核cpu了！虽然iPad1的应用已经不慢了，但大家完全可以使用苹果的多核编程框架来写出更加responsive的应用。多核运算在iOS中concurrency编程的框架就是**(GrandCentraldispatch)，**的使用非常简单。它把任务分派到不同的queue队列来处理。开发者把任务代码装到一个个block里面， *** 作系统把这些任务代码分派到不同的资源里去处理，一个简单的例子来说，为什么初学者写tablevIEw的时候，滑动列表时总会很卡，因为很多初学者把图片装载放到mainthread主线程去执行，例如我们要滑动畅顺的话，iOS最快可以1秒内刷新60次，如何你的一个cell的文字和图片装载超过1/60秒的话，自然就会卡。所以一般我们会把图片装载这些需要多点时间的移出mainthread来处理，对于用**来说，就是把图片载入放到另外一个queue队列中来异步执行，当资源准备好了后，放回到mainthread中显示出来。mainthread在**中就是mainqueue。创建一个新queue队列的代码：
C代码
dispatch_queue_tnetwork_queue;
network_queue=dispatch_queue_create("com.myapp.network",nill);
例如，我们图片读取放到network_queue来进行异步执行
C代码
dispatch_async(network_queue,^{
UIImage*cellimage=[selfloadMyImageFromNetwork:image_url];
//将图片cache到本地
[selfcacheImage:cellimage];
.....
});
dispatch_async的意思就是将任务进行异步并行处理，不一定需要一个任务处理完后才能处理下一个。以上代码loadMyImageFromNetwork的意思就是从网络中读取图片，这个任务交给network_queue来处理。这样读取图片的时间过长也不会阻塞主线程界面的处理。当我们处理完图片后，应该更新界面，从queue的概念去设计，就是要将更新界面的代码放到mainqueue中去，因为iOS里面永远是主线程来刷新重画UI。所以代码应该为，
C代码
dispatch_async(network_queue,^{
UIImage*cellimage=[selfloadMyImageFromNetwork:image_url];
//将图片cache到本地
[selfcacheImage:cellimage];
//回到主线程
dispatch_async(dispatch_get_main_queue(),^{
//显示图片到界面
[selfdisplayImagetotableVIEw:cellimage];
}];
});
dispatch_get_main_queue()函数就是返回主线程，^{}封装的就是任务代码，这样嵌套方式就可以从一个队列queue，跳到另一个queue，就是这么简单。我们一般可以把networking有关的代码放到一个queue，把图片resize的代码放到另外一个queue，处理完后更新界面，只需要嵌套跳回到mainqueue。这样加上几行代码，你的程序就可以利用到系统多核资源，把具体的调度工作交给了 *** 作系统自己来分配。有了这样的代码，不管你的硬件是单核，双核还是iMac的4核，甚至8核，都可以非常好地并行处理。内存管理我一直惊叹iOS和Objective-C内存处理能力，例如iPad版本的iWork，Pages应用就是一个内存处理技术应用的鬼斧神工之作。想想256M内存的iPad，可以带来如此的华丽的界面同时获得如此流畅的用户体验，真是不简单。原因就是iOS一直提倡开发者在有限硬件资源内写出最优化的代码，使用cpu最少，占用内存最小。（以下代码适用于iOSSDK4.1,由于新SDK4.2对内存使用有新改动，所以可能有不同。。。）1.尽量少的UIVIEw层通常我们喜欢把很多控件层（UILabel，UIbutton，UIVIEw等）一起放到一个大的UIVIEw容器来显示我们的内容，这个方法一般是可以的，但是如果要经常重新刷新内容的大区域界面，多数发生在iPad的应用中，这个方法会带来过多的内存使用和动画的延迟（比较卡），例如，scrollvIEw的动画比较卡，又或者，经常收到内存警告。其中一个重要原因是每个控件，特别是透明底的，会多次重新绘制（drawRect）过多。其解决办法是，尽量将几个控件合并到一个层上来显示，这样系统会减少系统调用drawRect，从而带来性能上的提升。很简单的一个例子，就是iNotes提供手写功能，用户可以在iPad屏幕上写出不同的笔画，开始的设计是，用户每写一划，iNotes就会生成一个新的透明底UIVIEw来保持这个笔画，用户写了10笔，系统就生产了10个UIVIEw，每个vIEw的大小都是整个屏幕的，以便用户的undo *** 作。这个方案带来严重的内存问题，因为系统将每个层都保持一个bitmap图，一个像素需要4bit来算，一个层的大小就是4x1024x768~3M,10个层就是10x3M=30M，很明显，iPad很快爆出内存警告。这个例子最后的方案是，所有笔画都画在同一个层，iNotes可以保存笔画的点进行undo *** 作。这样的方案就是无论用户画多少笔画，界面重画需要的资源都是一样的。2.显示最佳尺寸的图片很多程序员比较懒，网络上拿下来的图片，直接就用UIImageVIEw将其显示给用户，这样的后果就是，程序需要一直保存着大尺寸的图片到内存。解决办法应该是先将图片缩小到需要显示的尺寸，释放大尺寸图片的内存，然后再显示到界面给用户。3.尽量使用图片pattern，而不是一张大的图片例如，很多界面设计者喜欢在界面上放一个大底图，但这个底图是老是占用着内存的，最佳方案是，设计出一个小的pattern图，然后用这个方案显示成底图。
C代码
UIImage*smallimage=[[UIImagealloc]initWithContentsOffile:path];
backgroundVIEw.backgroundcolor=[UIcolorcolorWithPatternImage:smallimage];
[smallimagerelease];
4.使用完资源后，立即释放一般objective-c的习惯是，用完的资源要立即释放，因为明白什么时候用完某个资源的是程序员你自己。例如，我们要读较大的图片，把它缩小后，显示到界面去。当大图片使用完成后，应该立即释放。代码如下：
C代码
UIImage*fullscreenImage=[[UIImagealloc]initWithContentOffile:path];
UIImage*smallimage=[selfresizeImage:fullscreenImage];
[fullscreenImagerelease];
imageVIEw.image=smallimage;
......
5.循环中大量生成的自动释放autorelease对象，可以考虑使用autoreleasepool封装代码范例：
C代码
for(UIVIEw*subvIEwinbigVIEw.subvIEws){
//使用autoreleasepool自动释放对象池
NSautoreleasePool*pool=[[NSautoreleasePoolalloc]init];
UIImageVIEw*imageVIEw=(UIImageVIEw*)subvIEw;
//subvIEw处理代码
.......
//销毁自动释放对象
[pooldrain];
}
自动释放对象池把每个循环内生成的临时对象使用完后立即释放以上的意见是本人多年来编写iPad/iPhone程序的经验，另外iOS4.0的multi-tasking特性发布后，程序可以被调入后台运行，苹果工程师的意见是，进入后台运行时，你的应用应该释放掉能释放的对象，尽量保持在16M左右，这样别的程序运行时才不容易把你的应用挤掉。
总结以上是内存溢出为你收集整理的iOS的多核编程和内存管理全部内容，希望文章能够帮你解决iOS的多核编程和内存管理所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）