ios app性能分析

苹果app的流畅性一般比安卓的要好的多，应该是和苹果系统的设计理念相同，早期的iphone4以前是绝对单任务，只能做一件事情，虽然增加了后台可以，音乐播放，定位等有限的服务，但是大多数普通应用切换到后台就别挂起，直到被系统杀死（10－－15分钟）。一个任务当然内存利用率和cpu调度管理就要好管理多了，效率也高。app也不作为服务器，也不存在超多个socket链接的问题。当然app的性能问题和pc的应用性能问题完全不同。
app主要负责的是数据请求与展示，所以app主要是表现在数据请求方面，展示方面的也有，但是不多。
影响app性能的具体情况分下面几类情况：
1.服务器需要查询数据库，比较费时间。通常有这几种情况：服务器数据量较大，数据库的表分类不合理，数据库中的表索引设置不够好，数据库查询语句不够优化，数据库中有脏数据。
2.客户端重复发送大量重复的请求，如图片下载过程中的重复下载和代码逻辑有问题。
3.大量并发发送请求，导致部分请求超时，如有的登录成功后发送上下班状态请求，消息数量请求，金额请求等。
4.用百度代理函数批量解析步行距离，经纬度。
5.把大图片内存直接搬入内存并显示，大数据搬入内存。
6.程序出现死循环和经常刷新整个表格。
7.把所有的请求发送到一个服务器地址进行数据请求，导致服务器的处理性能下降，进而影响客户端的性能。
8.短期内收到大量push消息，不断中断用户操作，甚至导致用户短期内不能操作app。
9.由于发送请求较慢，请求页面的数据不确定，加载页面周期长，用户长时间看不到完整的页面，在切换页面前发送请求，发送成功才切换到对应页面。
下面是对以上性能问题的解决方案。
对于情况1，当然优化数据库中各个表格，对所有表格设置索引（表的索引对数据的查询影响超大），优化查询语句，抽象出查询高频率的表进行优化，去除脏数据。
情况2，用charles抓包和打印日志哪些请求出现了重复发送，消除这种不合理的逻辑和错误。
情况3，尽量或避免并发请求，能合并的请求尽量合并，如登录后需要发送的大量的请求，直接在登录时就把参数写上，登录的成功响应消息里把你需要各种结果都返回就可以了。
情况4，百度的步行距离计算代理和地址经纬解析代理都不支持瞬时大批量解析，轻者解析很费时间才得到结果，重者服务器拒绝解析或只解析一部分，所以要采用解析一个再去解析另一个的事件方式解析，防止一窝峰的整个表格的有关步行距离和地址解析的请求都一次性交给百度哥。当然也存在刚开断网进入应用，网络恢复，收到网络正常通知后立刻自动登录成功后立马去解析步行距离，百度哥告诉你联网成功，授权成功，实际上你会解析失败，不过你再去解析一次一般都可以解析成功。
情况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];这样的刷新一行表格的局部表格刷新。若你只改变一个页面的一个内容（图像变换，标签内容）并且不影响表格，直接把它的指针设置成本面的全局变量，直接修改就可以了，也不需要刷新整个表格或单元格。若死循环刷新表格，整个程序也完了，肯本不能有这样的逻辑。

最app影响性能的都和服务器方面有关，弱网络登录这个最烦人了。