ios app性能分析

苹果app的流畅性一般比安卓的要好的多。应该是和苹果系统的设计理念同样，早期的iphone4曾经是绝对单任务，仅仅能做一件事情，尽管添加了后台能够。音乐播放，定位等有限的服务。可是大多数普通应用切换到后台就别挂起，直到被系统杀死（10－－15分钟）。一个任务当然内存利用率和cpu调度管理就要好管理多了，效率也高。app也不作为server。也不存在超多个socket链接的问题。当然app的性能问题和pc的应用性能问题全然不同。
app主要负责的是数据请求与展示，所以app主要是表如今数据请求方面，展示方面的也有，可是不多。
影响app性能的详细情况分以下几类情况：
1.server须要查询数据库。比較费时间。

通常有这几种情况：server数据量较大。数据库的表分类不合理。数据库中的表索引设置不够好，数据库查询语句不够优化，数据库中有脏数据。
2.client反复发送大量反复的请求，如图片下载过程中的反复下载和代码逻辑有问题。

3.大量并发发送请求，导致部分请求超时。如有的登录成功后发送上下班状态请求。消息数量请求。金额请求等。

4.用百度代理函数批量解析步行距离，经纬度。
5.把大图片内存直接搬入内存并显示。大数据搬入内存。

6.程序出现死循环和常常刷新整个表格。
7.把全部的请求发送到一个server地址进行数据请求。导致server的处理性能下降，进而影响client的性能。
8.短期内收到大量push消息，不断中断用户操作。甚至导致用户短期内不能操作app。

9.由于发送请求较慢，请求页面的数据不确定。载入页面周期长，用户长时间看不到完整的页面，在切换页面前发送请求，发送成功才切换到相应页面。
以下是对以上性能问题的解决方式。

对于情况1，当然优化数据库中各个表格，对全部表格设置索引（表的索引对数据的查询影响超大），优化查询语句，抽象出查询高频率的表进行优化。去除脏数据。

情况2，用charles抓包和打印日志哪些请求出现了反复发送，消除这种不合理的逻辑和错误。
情况3。尽量或避免并发请求。能合并的请求尽量合并，如登录后须要发送的大量的请求，直接在登录时就把參数写上，登录的成功响应消息里把你须要各种结果都返回就能够了。
情况4，百度的步行距离计算代理和地址经纬解析代理都不支持瞬时大批量解析，轻者解析非常费时间才得到结果，重者server拒绝解析或仅仅解析一部分。所以要採用解析一个再去解析还有一个的事件方式解析，防止一窝峰的整个表格的有关步行距离和地址解析的请求都一次性交给百度哥。

当然也存在刚开断网进入应用，网络恢复，收到网络正常通知后立刻自己主动登录成功后立刻去解析步行距离。百度哥告诉你联网成功，授权成功，实际上你会解析失败，只是你再去解析一次一般都能够解析成功。
情况5。你能够用UIImage *image = [AppManager resizeImage:[UIImage imageNamed:@”my_backgroud_up_6.png”] toSize:CGSizeMake(WINDOW_WIDTH, 64) scale:1];这种方式压缩显示在内存中。

当然也有把大数据搬入内存的情况。一般仅仅须要读取你用到的部分的数据就能够。仅仅是我没有这方面的详细样例。这样就防止app内存暴涨了，当然你用完后不在使用它了把这类大的对象指针置空，让系统自己去回收预计效果更好些。
情况6，死循环要不得。进入死循环若没有能符合的跳出条件。app相当于隔屁了。所以尽量别设计这类的循环等待，若是全然的死循环，尽量用单元測试发现，解决掉它。

循环刷表格要不得。要等全部数据处理完再刷整个表格([self.tableView reloadData])，当然你仅仅是刷一行表格（如一行表格的高度和内容变更）能够用[self.tableView reloadRowsAtIndexPaths:@[[NSIndexPath indexPathForRow:self.selectedIndex inSection:0]] withRowAnimation:UITableViewRowAnimationNone];这种刷新一行表格的局部表格刷新。若你仅仅改变一个页面的一个内容（图像变换，标签内容）而且不影响表格。直接把它的指针设置成本面的全局变量。直接改动就能够了，也不须要刷新整个表格或单元格。若死循环刷新表格。整个程序也完了。肯本不能有这种逻辑。发现一个干死一个。可是必定谁也不想写这种代码，这就是写代码的目的和实际实现的处理不一致，单元測试測试达到分支覆盖就非常easy发现这种严重的bug。这类问题仅仅所以出现，可能是逻辑设计错误，也可能是拼写错误。也可能是从其他代码拷贝来的代码没有改动或改动的不全然对。当把每一个函数的圈复杂度减少到15以下，再编写測试測试用例就非常easy。若一个主函数上千行。谈何单元測试。
情况7，每一个请求相应一个请求网页地址，用AFNetworking发送http请求。把请求的參数拼接到请求中如，http://test.zuixiandao.cn/fhl/phone/psy/startWorkJsonPhone.htm?cmdCode=0003&key=BF233049EC74B822EB5520A6ADA30A76&phoneId=ios_120e438f-9757-451d-b980-0d87824b02eb&visitTime=1437550879&workKey=1。

server一个页面处理。当大量用户訪问时easy出现性能问题。而且也不easy区分各个请求。导致内部逻辑超复杂。server的性能受到影响，当然也影响client的请求响应时间必定受到影响。这种每一个请求相应一个子页面的方式也对各个页面状态的同步要求非常高，操作数据库的并发也要控制好。幸亏有会话信息能够放在cookies里。
情况8。server的push分为不同类型，每次把push消息的类型发过来。client对高频发的消息进行按时间和类型的进行适当舍弃，如3秒内最多才干弹出一个新订单消息。

若你的push录音播放非常长。不拦截可能出现声音叠加的问题。还好苹果对每分钟向一个app最多推送消息有限时，导致不非常明显，可是安卓这类现象是否严重。就由于苹果对每分钟push消息个数的限制，所以导致有部分push消息可能丢失。
情况9，最好先切换页面后发送请求。除非有特别的需求才须要这样做，不让让人有感觉处理慢的性能问题。

当然跳到一个页面时要一个数据载入进度的动画效果，如一个人型图案的载入过程。进页面就显示一个菊花那样太不友好。

最app影响性能的都和server方面有关，弱网络登录这个最烦人了，所以要有自己主动登录超时也能进入首页，无网络也能进首页弹出黄条就能够。自己主动登录要依据网络通知事件来触发登录，没有网络还向服务发什么，当然发也是失败，还存在正在发送中网络正常的情况。这样也不可控。也不用浪费电量的起个定时器傻傻的等待网络事件的事情，尽管正常网络网络通知在1秒内能够收到。有的弱网络比較慢，何不由网络通知事件触发登录呢？所以收到网络通知才发起自己主动登录是最好的选择。

这样在自己主动登录方面也提高性能，让用户app启动非常快。