苹果手机老用户担心会变卡？iOS10.3.3流畅度没下降苹果手机老用户担心会变卡？iOS10.3.3流畅度没下降有意思儿百家号手里的iPhone6s每次升级iOS系统时，我都会稍微犹豫那么一小会，相信不少苹果手机老用户都有这样的习惯。究其根本原因，主要在于老用户注意的不是iOS系统的新功能，而是该版本iOS是否还像正在使用的流畅、稳定、省电。特别是流畅和省电方面是大多数苹果手机用户关心的问题。无独有偶，昨天早晨苹果公司向包括iPhone6s在内的不少机型推送了iOS10.3.3版本的系统。和上文阐述的一样，当我收到更新提醒时确实又犹豫了，具体原因除了担心运行时卡顿外，还怕功耗严重电池掉电厉害。后来，终于禁不住好奇心给iPhone6s进行了新版迭代，不过需要注意的是升级过程时间较长，提示大家若要更新的话得保持充足电量。好了，言归正传。我们接着聊聊苹果手机用户最为担心的卡顿问题，iPhone6s升级至iOS10.3.3版本系统后并没有出现各位所顾虑的卡顿；根据个人实际使用测试，iPhone6s打开应用速度和之前iOS10.3.2版无较大差别，也就是说此次iOS10.3.3重点优化的不是在运行速度方面。但从部分网友反馈的情况来看有些iPhone机型升级完确实速度有改善，想必苹果公司应该对iOS10.3.3调试了过渡动画效果。当然，iOS10.3.3之所以能够让我有勇气去升级，源自于三个方面的因素：一是该版本极大可能是iPhone5、iPhone5C等机型的最后一个版本，想看看到底有什么新东西增加没有；二是iOS10.3.3经过六个beta版测试，其中必定涵盖较为重要的内容，譬如修复了许多系统漏洞，尤其是上个版本中存在的WiFi芯片组漏洞、Safari浏览器内核漏洞；三是个人习惯爱好，即有新版提示更新时若不升级，放在那里看着有点强迫症。综合以上内容，在我看来这次iOS10.3.3版本系统侧重点是在于安全方面的修复，跟iPhone手机是否会因升级后流畅度增加无太大关系。所以苹果手机老用户担心会变卡的现象也不用再顾虑了，进一步来说iOS10.3.3流畅度没下降，可以放心升。本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。有意思儿百家号最近更新：简介:爱生活、爱科技、爱分享。作者最新文章相关文章iOS开发——项目实战总结&UITableView性能优化与卡顿问题
时间： 18:10:25
&&&& 阅读：16802
&&&& 评论：
&&&& 收藏：0
标签：UITableView性能优化与卡顿问题
1.最常用的就是cell的重用， 注册重用标识符
如果不重用cell时，每当一个cell显示到屏幕上时，就会重新创建一个新的cell
如果有很多数据的时候，就会堆积很多cell。如果重用cell，为cell创建一个ID
每当需要显示cell 的时候，都会先去缓冲池中寻找可循环利用的cell，如果没有再重新创建cell
2.避免cell的重新布局
cell的布局填充等操作 比较耗时，一般创建时就布局好
如可以将cell单独放到一个自定义类，初始化时就布局好
3.提前计算并缓存cell的属性及内容
当我们创建cell的数据源方法时，编译器并不是先创建cell 再定cell的高度
而是先根据内容一次确定每一个cell的高度，高度确定后，再创建要显示的cell，滚动时，每当cell进入凭虚都会计算高度，提前估算高度告诉编译器，编译器知道高度后，紧接着就会创建cell，这时再调用高度的具体计算方法，这样可以方式浪费时间去计算显示以外的cell
4.减少cell中控件的数量
尽量使cell得布局大致相同，不同风格的cell可以使用不用的重用标识符，初始化时添加控件，
不适用的可以先隐藏
5.不要使用ClearColor，无背景色，透明度也不要设置为0
渲染耗时比较长
6.使用局部更新
如果只是更新某组的话，使用reloadSection进行局部更新
7.加载网络数据，下载图片，使用异步加载，并缓存
8.少使用addView 给cell动态添加view
9.按需加载cell，cell滚动很快时，只加载范围内的cell
10.不要实现无用的代理方法，tableView只遵守两个协议
11.缓存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在，这两者同时存在才会出现&窜动&的bug。所以我的建议是：只要是固定行高就写预估行高来减少行高调用次数提升性能。如果是动态行高就不要写预估方法了，用一个行高的缓存字典来减少代码的调用次数即可
有了上面的问题，我们在优化tableView的时候就能好解决一个卡顿的问题了。
在iOS应用中，UITableView应该是使用率最高的视图之一了。iPod、时钟、日历、备忘录、Mail、天气、照片、电话、短信、 Safari、App Store、iTunes、Game Center&几乎所有自带的应用中都能看到它的身影，可见它的重要性。
然而在使用第三方应用时，却经常遇到性能上的问题，普遍表现在滚动时比较卡，特别是table cell中包含图片的情况时。
实际上只要针对性地优化一下，这种问题就不会有了。有兴趣的可以看看 LazyTableImages这个官方的例子程序，虽然也要从网上下载图片并显示，但滚动时丝毫不卡。
下面就说说我对UITableView的了解。不过由于我也是初学者，或许会说错或遗漏一些，因此仅供参考。
首先说下UITableView的原理。有兴趣的可以看看 《About Table Views in iOS-Based Applications》。
UITableView是UIScrollView的子类，因此它可以自动响应滚动事件（一般为上下滚动）。
它 内部包含0到多个UITableViewCell对象，每个table cell展示各自的内容。当新cell需要被显示时，就会调用tableView:cellForRowAtIndexPath:方法来获取或创建一个 cell；而不可视时，它又会被释放。由此可见，同一时间其实只需要存在一屏幕的cell对象即可，不需要为每一行创建一个cell。
此 外，UITableView还可以分为多个sections，每个区段都可以有自己的head、foot和cells。而在定位一个cell时，就需要2 个字段了：在哪个section，以及在这个section的第几行。这在iOS SDK中是用NSIndexPath来表述的，UIKit为其添加了indexPathForRow:inSection:这个创建方法。
其他诸如编辑之类的就不提了，因为和本文无关。
介绍完原理，接下来就开始优化吧。&
使用不透明视图。
不透明的视图可以极大地提高渲染的速度。因此如非必要，可以将table cell及其子视图的opaque属性设为YES（默认值）。
其中的特例包括背景色，它的alpha值应该为1（例如不要使用clearColor）；图像的alpha值也应该为1，或者在画图时设为不透明。
不要重复创建不必要的table cell。
前面说了，UITableView只需要一屏幕的UITableViewCell对象即可。因此在cell不可见时，可以将其缓存起来，而在需要时继续使用它即可。
而UITableView也提供了这种机制，只需要简单地设置一个identifier即可：
static NSString *CellIdentifier = @"xxx";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
值得一提的是，cell被重用时，它内部绘制的内容并不会被自动清除，因此你可能需要调用setNeedsDisplayInRect:或setNeedsDisplay方法。
此 外，在添加table cell的时候，如果不需要动画效果，最好不要使用insertRowsAtIndexPaths:withRowAnimation:方法，而是直接调 用reloadData方法。因为前者会对所有indexPaths调用tableView:cellForRowAtIndexPath:方法，即便该 cell并不需要显示（不知道是不是bug），这就可能创建大量多余的cell。勘误：只是在模拟器上测试如此，真机调试时没有这种bug。
减少视图的数目。
UITableViewCell包含了textLabel、detailTextLabel和imageView等view，而你还可以自定义一些视图放在它的contentView里。然而view是很大的对象，创建它会消耗较多资源，并且也影响渲染的性能。
如果你的table cell包含图片，且数目较多，使用默认的UITableViewCell会非常影响性能。奇怪的是，使用自定义的view，而非预定义的view，明显会快些。
当然，最佳的解决办法还是继承UITableViewCell，并在其drawRect:中自行绘制：
- (void)drawRect:(CGRect)rect
if (image)
[image drawAtPoint:imagePoint];
self.image =
[placeHolder drawAtPoint:imagePoint];
[text drawInRect:textRect withFont:font lineBreakMode:UILineBreakModeTailTruncation];
不过这样一来，你会发现选中一行后，这个cell就变蓝了，其中的内容就被挡住了。最简单的方法就是将cell的selectionStyle属性设为UITableViewCellSelectionStyleNone，这样就不会被高亮了。
此 外还可以创建CALayer，将内容绘制到layer上，然后对cell的contentView.layer调用addSublayer:方法。这个例 子中，layer并不会显著影响性能，但如果layer透明，或者有圆角、变形等效果，就会影响到绘制速度了。解决办法可参见后面的预渲染图像。
不要做多余的绘制工作。
在实现drawRect:的时候，它的rect参数就是需要绘制的区域，这个区域之外的不需要进行绘制。
例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否需要绘制image和text，然后再调用绘制方法。
预渲染图像。
你会发现即使做到了上述几点，当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕，详细做法可见《利用预渲染加速iOS设备的图像显示》。
不要阻塞主线程。
做到前几点后，你的table view滚动时应该足够流畅了，不过你仍可能让用户感到不爽。常见的现象就是在更新数据时，整个界面卡住不动，完全不响应用户请求。
出现这种现象的原因就是主线程执行了耗时很长的函数或方法，在其执行完毕前，无法绘制屏幕和响应用户请求。其中最常见的就是网络请求了，它通常都需要花费数秒的时间，而你不应该让用户等待那么久。
解 决办法就是使用多线程，让子线程去执行这些函数或方法。这里面还有一个学问，当下载线程数超过2时，会显著影响主线程的性能。因此在使用 ASIHTTPRequest时，可以用一个NSOperationQueue来维护下载请求，并将其 maxConcurrentOperationCount设为2。而NSURLRequest则可以配合GCD来实现，或者使用NSURLConnection的setDelegateQueue:方法。
当然，在不需要响应用户请求时，也可以增加下载线程数，以加快下载速度：
1 - (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate { if (!decelerate) { queue.maxConcurrentOperationCount = 5; } } - (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView { queue.maxConcurrentOperationCount = 5; } - (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView { queue.maxConcurrentOperationCount = 2; }
此外，自动载入更新数据对用户来说也很友好，这减少了用户等待下载的时间。例如每次载入50条信息，那就可以在滚动到倒数第10条以内时，加载更多信息：
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath { if (count - indexPath.row & 10 && !updating) { updating = YES; [self update]; } }// update方法获取到结果后，设置updating为NO
还有一点要注意的就是当图片下载完成后，如果cell是可见的，还需要更新图像：
1 NSArray *indexPaths = [self.tableView indexPathsForVisibleRows];
2 for (NSIndexPath *visibleIndexPath in indexPaths) {
if (indexPath == visibleIndexPath) {
4 MyTableViewCell *cell = (MyTableViewCell *)[self.tableView cellForRowAtIndexPath:indexPath];
cell.image =
6 [cell setNeedsDisplayInRect:imageRect]; break;
}// 也可不遍历，直接与头尾相比较，看是否在中间即可。
最后还是前面所说过的insertRowsAtIndexPaths:withRowAnimation:方法，插入新行需要在主线程执行，而一次插入很多行的话（例如50行），会长时间阻塞主线程。而换成reloadData方法的话，瞬间就处理完了。
&标签：原文地址：http://www.cnblogs.com/iCocos/p/4988774.html
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！iOS&开发－解决页面卡顿的小技巧（常用）
1.为什么出现页面卡顿？<img TYPE="face" src="http://simg.sinajs.cn/blog7style/images/common/sg_trans.gif" real_src ="http://www.sinaimg.cn/uc/myshow/blog/misc/gif/E___6724EN00SIGG.gif"
ALT="iOS&开发－解决页面卡顿的小技巧（常用）"
TITLE="iOS&开发－解决页面卡顿的小技巧（常用）" /><img TYPE="face" src="http://simg.sinajs.cn/blog7style/images/common/sg_trans.gif" real_src ="http://www.sinaimg.cn/uc/myshow/blog/misc/gif/E___6724EN00SIGG.gif"
ALT="iOS&开发－解决页面卡顿的小技巧（常用）"
TITLE="iOS&开发－解决页面卡顿的小技巧（常用）" />
在开发中我们常常会遇到布局比较复杂的cell,在滑动的时候会导致界面不流畅，出现卡顿的现象，这是由于CPU计算和GPU渲染，之间未及时交换数据丢失帧导致的结果。
2.常见解决办法
1).UIImageView尽量设置为不透明
opque尽量设置为YES
当UIImageView的opque设置为YES的时候其alpha的属性就会无效，UIImageView的半透明取决于其图片半透明或者UIImageView本身的背景色合成的图层view是半透明的。
如果图片全部不是半透明就不会触发图层的blend操作，整个图层就会不透明。
如果叠加的图片有出现半透明的，就会立马触发图层的blend操作，整个图层不透明。
背景色尽可能设为alpha值为1
当某一块图层的alpha和其superView的背景色alpha不一样的时候会触发alpha合成操作，这是一项看似很简单但却是非常消耗CPU性能的操作。
2).UIView的背景色设置
UIView的背景色尽量不要设置为clearColor，这样也会触发alpha叠加，在UITableView滑动的时候是非常消耗性能的。子视图的背景色尽可能设置成其superView的背景色，这样图层合成的时候不会触发blend操作。
最好不使用带alpha通道的图片，如果有alpha尽量让UI设计人员取消alpha通道。
3).cell上layer尽量避免使用圆角
在工作中关于滑动界面我们会时常遇到cell行设置头像为圆角等需求，这时候我们尽量避免使用layder.cornerRadius，因为这会触发离屏渲染。离屏渲染很耗时间。
离屏渲染：是GPU渲染区的一个渲染缓冲区，我们所用的所有显示屏的图形图像都是通过GPU进行渲染，然后显示在屏幕上。GPU负责渲染会把渲染的图形放到缓冲区然后CPU就会发一个垂直信号显示到屏幕。
如果要使用圆角，我们可以设置为layer.shouldRasterize
YES，其实这个设置是触发光栅化，可以大大提高渲染的性能。我的理解光栅化就是类似于cell的重用机制。
光栅化：把第一次渲染好的图层放到缓冲区，那么下次不需要再离屏渲染直接就可以从缓冲区拿去使用。
4).优化图片的加载方式
图片的加载方式有两种形式：
UIImageView *image = [UIImageView imageView:@"1.png"];
UIImageView *image = [UIImageView
imageWithContentOfFile:@"1.png"];
两种加载图片方式的区别：
第一种：当我们经常需要这张图片并且仅仅是小图的时候，我们可以使用此种方式加载图片。
这种方式是把图片缓存在图片缓存区，当我们使用的时候会通过图片的名字也就是通过key的方式去查找图片在缓存区的内存地址。
当我们使用很多图片的时候系统就会开辟很多内存来存储图片，所以qq、微信我们很多时候都会去清除缓存操作。
第二种：当我们使用工程里面的一张大图并且使用次数很少甚至为1次的时候，我们优先会采用这种方式加载图片，这种方式当使用完图片的时候会立即丢弃释放资源，所以对性能不会带来负担。
5).尽量延迟图片的加载
当我们在滑动页面的时候尤其对于那种布局特别复杂的cell，滑动的时候不要加载图片，当滑动停止得时候再进行图片的加载。
我们都知道不管是UITableView还是UIScrollView在滚动的时候需要显示东西都是通过runLoop去拿。
当滚动的时候runLoop会处于NSRunLoopTrackingMode的模式，我们可以通过一个主线程队列dispatch_after或者selfPerformSelector设置runLoop的模式为NSDefaultRunLoopMode模式，就可以做到停止滚动再加载图片。
注：其实严格意义上selfPerformSelector的事件就是在主线程队列中等待。
优先加载理念
采用优先加载的理念，既先展示一部分，当滑动的时候再加载下面的一部分这样就保持流畅。
6).避免阻塞主线程
让图片的绘制、图片的下载、对象的创建、文本的渲染等这些耗时的操作尽可能采用子线程异步的方式去处理，对于layer及UI的操作不得不在主线程里面，只能想办法优化。
7).xib、storyBoard、纯代码的问题
苹果推出storyboard确实为开发者节省了大量的时间，提高了开发效率，但是对于那种
复杂的滑动界面，利用storyboard是非常消耗资源的，不信的可以试试用性能工具timeProfie看看CPU所占的性能百分比，其CPU的资源远远大于纯代码布局。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。大家都说10.3流畅了，我的为什么卡顿呢？？【ios10吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：155,682贴子：
大家都说10.3流畅了，我的为什么卡顿呢？？收藏
我的是iPadmini4，一开始是直接在iPad上ota升级的，结果升级完了感觉明显卡顿掉帧，自己玩的simcity这个游戏，感觉明显卡顿，使用了一天电也费的飞快之后自己逛贴吧，有人说得用iTunes升级，结果晚上到家就直接把pad恢复出厂设置了，然后又用iTunes刷了一遍可是装完软件后还是觉得有些卡顿，只是电量没有之前费的快了，可是还是不如10.2的时候，包括微博这些软件，游戏我只装一个simcity，都有不定时掉帧现象难道是我的设备落后了吗？但是mini4个人感觉还行啊哪位大神教教小弟怎么解决设备是mini4 64G
2017超火的三国策略游《极速体验入口》
我的iPhone6p也是刷了10.3后有些卡顿，就是用软件时不退出直接锁屏，然后再解锁，回软件界面时就卡顿一下。掉电和楼主一样非常速度。难道机器分体质？
可能降频了？
用段时间再说。
ios10.3以后的版本百度地图滑动掉帧.斗鱼直播弹幕掉帧.爱奇艺掉帧.总之各种掉帧.不信的你们自己试试吧.不知道为什么还有人说ios10.3流畅
检测一下是不是被降频了。。。不要人云亦云，有很多人卡都不知道为什么卡。10.21之后的系统会自动变频，主要是针对电池，电池有问题的机子会被降频所以有部分人说很卡，那是真的卡，还是你想象不出的那种卡都有可能。因为被降频。。。说流畅的自然是没被降频的，好了我说完了
我的也卡，10.3.2的时候不卡
登录百度帐号推荐应用在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
用xcode automatically manage signing 我用的是原来用的bundid，现在显示 The app ID "xxxxxxxxxxxxx" cannot be registered to your development team. Change your bundle identifier to a unique string to try again.非常奇怪啊...这个bundid 我不能随便的更换，请问有遇到这种情况解决的吗？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
出现该问题通常是app ID冲突，即该app ID已经有人注册过,你可以换一个app ID。 如果你以前在真机上运行过这个程序，app id没有改，出现的这个问题，把原来的程序彻底删除，再重新装了试试看看呢。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
查看你的证书状态，如果正常，清理项目，删掉app，重新运行。
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。