iOS 性能优化,被压测卡爆的语音房间(实践)

Posted 程序员大咖

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS 性能优化,被压测卡爆的语音房间(实践)相关的知识,希望对你有一定的参考价值。

????????关注后回复 “进群” ,拉你进程序员交流群????????

作者丨ZenonHuang

来源丨掘金

https://juejin.cn/post/6935830669549371423

背景

某天收到通知,有人气大主播要做语音房间活动,需要做质量保障工作。

因为房间已经借鉴了之前做 IM 的预排版经验,加上 iPhone 机器本身性能都不错,我以为稳如老狗...

然而 iPhone6 Plus 测试机随着压测数据上升到每秒上百条,直接卡爆了,整个屏幕没有任何响应。

问题定位

相信很多开发者都看过性能优化的文章,然而我们现在需要对症下药。

按着文章一顿操作猛如虎,低头一看零杠五。

关键问题的定位,并不是照猫画虎就能解决的,特别是在我们已经做了一些常规优化设计的情况下。

CPU or GPU

首先确定是属于哪种原因卡顿:

CPU 卡顿

GPU 卡顿

我们可以利用工具观察卡顿发生时 CPU / GPU 的情况,Xcode 也自带这些功能。

安利一下滴滴团队的 DoraemonKit ,集成了不少提升效率的开发工具,比如查看视图层级,网络请求,以及 CPU 变化等等..

因为工程本身已经有了,我直接用它来观察 CPU 变化情况,方便的一匹。

再次进行压测,CPU 的变化曲线一下子就升到 100%,肉眼可见的秒爆了。

其实 CPU 消耗大还有一个特征就是发热,但我们要用数据说话,做业务的抓手是什么?数据 :)

而关于卡顿发生的原因,这篇 《ios 保持界面流畅的技巧》是非常推荐阅读的,值得反复学习,确实是佳作。

哪些操作造成 CPU 卡顿问题?

既然已经定位到了 CPU ,那么是不是就马上找到答案呢?

答案是否定的,我们离问题仍然还有一段距离。

如果直接按照造成 CPU 消耗问题的操作去搜索答案,不外乎是下面这七项:

  • 对象创建

  • 对象调整

  • 对象销毁

  • 文本计算

  • 文本渲染

  • 图片解码

  • 图片绘制

实际上,真的一行行代码查看过去,你会发现几乎每行代码都被囊括在这七项当中:对象创建/调整/销毁,文本计算/渲染,图片/解码/绘制。

到底哪里一行才是真正的问题代码,接下来该怎么办呢?如果是有十分丰富经验的工程师,或许能一眼扫出问题代码所在。

如果不是大佬的话,显然我们还是需要一些方法。

整理业务流程

就像打仗一样,知己知彼才能百战百胜,我们要对问题的业务情况做掌握。

先整理出问题场景的业务流程,详细了解整个过程。

整理业务流程,比较建议的方式是画图,能直观看到业务里各部分的关系,处理流程,以及数据流向。

对于大而复杂的模块,大多数时候是很多人都经手或共同维护的。这时候一定要学会和团队成员合作,找来每个部分最了解的人,能尽可能快的完成整理的步骤。

针对这次出问题的语音房间/直播房间场景,就可以先做大的分类:礼物消息(带横幅动画,全屏动画等),图片消息,文字消息等几个大类型。

再分别对大类型做梳理,例如文字消息类型的大概流程:

当然上面的图只是一个比较粗略的例子????,真实场景里,光是 RoomChatHandle 里的处理流程都不少。

整理流程是理顺业务的好机会,同时也能发现一些设计问题:如本应是上下层的关系,却产生互相依赖。如果将业务关系画图表示,就可以很好的暴露出来。

总之,先把自己的业务思路理清。

控制变量法

整理完业务情况后,就可以开始真正动手了。

建议使用控制变量法,更通俗具体的说,就是排除法!

其实就是最简单的 Debug 方式了...大家只要中学做过一点实验,或者平时会 Debug 的应该都懂了。

例如:

a=白色
b=白色
c=蓝色
//实际预期 d=白色
d=a+b+c=蓝色

那么这时分别去除一次 a/b/c 的影响,最后发现:

d=a+b=白色
d=a+c=蓝色
d=b+c=蓝色

就很容易知道 c 这个变量出问题了,影响了我们的预期结果。

办法比较原始,毕竟最高端的食材往往需要最朴素的烹饪方法,高端的问题只需要最朴素的 Debug 功夫!

利用控制变量来发现问题,确实也很像做饭,找问题的速度在于掌握火候,也就是粒度问题:

每次做排除的是一行代码?还是1 个方法调用?还是好几个方法调用?

通过逐渐缩小问题范围,然后一步步推进。

说起来很轻松,其实整个过程也是比较枯燥,越复杂越大的模块越辛苦。

最终发现了问题的关键代码:

[tableView reload]

对于原来的方式来说,来 1 条数据就会去刷 1 次 UI,1 秒 100 条数据就刷 100 次 UI。刷新频率过高,服务器来的数据很多,那么刷新的频繁,负荷太大直接造成卡死。

解决问题

定位问题之后,就可以针对性解决,目前核心问题在于:

短时间内 UI 刷新次数过多,造成 CPU 压力过大

那第一步要做的就是控制频率。

控制频率

很显然目标是尽可能减少刷新次数,不过仍然涉及到 2 个问题:

  • 控频策略

  • 取阈值

关于控频策略,在 《iOS 上的函数防抖与节流》 有过说明,主要就是 Throttle / Debounce:

  • Throttle ,单位时间内只执行一次方法。

  • Debounce,单位时间内只要有方法调用,就再等一个周期,直到没有新调用,则执行方法。

由于是刷新方法,如果消息一直不停过来刷,按照 Debounce 的方式,很可能会一直被推迟执行,UI 也就得不到刷新了。

所以在控制频率上选择 Throttle 的话是比较合适的,单位时间内执行一次。

经过实验,如果普通文本消息类型修改为 1 秒 1次 ,CPU 直接就减少了 30-40% 的压力。

高/低性能机器区分

通过控制刷新频率,已经非常有成效,然而粒度还是太粗了。

出现卡死的机器都是低性能机器,对于高性能机器的话用一样的策略就不够好了。

对于高性能机器要充分利用,适当放开限制数据处理,提高用户体验。

所以可以用更精细的阀值来测试,对高性能机器选择合适的值,甚至部分强大的 CPU 可以放开管控,在 CPU 使用率到达一定临界点开启控制策略。

数据的分发&处理

数据批量分发

虽然已经解决了主要问题,但发现原来的分发策略也比较直接:

来 1 条数据,就直接传递 1 条,来 100 条数据就抛 100 次。

对于数据做一个合并分发的策略,或者说是批量分发,例如:

0.5 秒内,只来 1 条数据就传递 1 条,如果连续来 100 条,就等到最后一次,直接全部发出。

这样也能大大减少分发的成本,将多次合并为 1 次,和上面 UI 刷新控制频率是相同的思想,不过现在是数据层面做控制。

淘汰策略

批量分发还存在一个问题:

因为批量分发数据,中间到的数据会被存起来。

如果到的数据太多,比如我们 1 秒处理 300 条,但是来了 500 条,随着时间过去,就会不断积压消息,甚至引发新的内存问题(OOM)。

为了避免出现积压过多的消息,我们还需要做一个 淘汰策略 ,简单的说,就是丢弃一部分数据。

丢弃不必要的消息,就涉及到产品上的问题,需要去与产品或者运营同学确认,哪些是不重要的:比如进出房间消息,普通聊天消息...

当然我相信也有什么都不愿意舍弃的产品:全部都给我一次性刷出来!

技术的提升,往往来源于业务的推动,变态的产品会对技术提出更高的要求。

异步多线程处理

原来处理数据也没有使用异步多线程,所以关于数据的处理,还能再做一次异步处理优化。

异步多线程处理,利用 GCD 就可以了。

看起来简单,其实也有坑,不断的开线程也会产生线程爆炸的问题,线程太多不一定就好。

而且机器的核数也是有限的 ,真正能利用起来的线程数量也有限。简单的说,如果机器是双核的,那么我同时 2 个线程, 处理数据就很舒服,如果开 4 个线程,其实就是通过线程调度,来回不断的切换任务,并非真正的多线程。其实就是 并发 和 并行 的区别。

我们可以直接站在前人的肩膀上,使用或仿照 YYKit 里的 YYDispatchQueuePool ,将处理数据的任务统一放到某个需要的优先级队列上。

除了线程数量之外,还要注意处理死锁的问题。

进一步思考

做完上面的优化后,不仅是 iPhone6 Plus ,甚至 iPhone6 面对狂风暴雨的服务器消息也毫无波澜。

在此基础上继续思考,如果数据量不断增大,并出现一个棘手的情况:剩下的重要消息,也超过我们的极限,例如全部都是 500 元以上的礼物消息,不能丢弃,全部展示,我们该怎么优化?

协程

在处理数据上,有没有比用多线程处理更好的方案呢?那可能就是协程了。

查看阿里巴巴的 coobjc 这么介绍协程对于多线程的性能优势:

  • 调度性能更快:协程本身不需要进行内核级线程的切换,调度性能快,即使创建上万个协程也毫无压力

  • 减少卡顿卡死:协程的使用以帮助开发减少锁、信号量的滥用,通过封装会引起阻塞的 IO 等协程接口,可以从根源上减少卡顿、卡死,提升应用整体的性能

异步绘制

在 UI 显示上,再更进一步,采用异步绘制的方式,如 YYAsyncLayer 或者 Texture 都是可以借鉴的。

由于我们本身也使用了 YYLabel,开启异步绘制后,会空白一阵后再显示,比较明显的滞后显示体验并不是太好,建议还是极端情况再选择性的开启。

这也是一种性能与体验的取舍问题。

总结

虽然是一篇关于性能优化的文章,仍然要说一句:过度过早的优化是万恶之源。

例如提到的多线程和异步绘制,可能优化后会带来别的体验问题。避免多线程问题的一个最好办法,就是不使用多线程。

进行性能优化,更多的是得到查问题/改问题的经验,也掌握了一些方法与思考。

最重要的是找问题的过程,往往可能就一行或者几行代码导致了影响,定位到却要花费不菲的时间。

希望大家有更好的思考和经验多多交流!

-End-

最近有一些小伙伴,让我帮忙找一些 面试题 资料,于是我翻遍了收藏的 5T 资料后,汇总整理出来,可以说是程序员面试必备!所有资料都整理到网盘了,欢迎下载!

点击????卡片,关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓

以上是关于iOS 性能优化,被压测卡爆的语音房间(实践)的主要内容,如果未能解决你的问题,请参考以下文章

MeterSphere在开源压测工具JMeter上的分布式优化和实践

性能测试的一些资料

记一次Grpc接口压力测试&性能调优

利用火焰图优化基于openresty服务的性能

怎么判断自己的服务器是被压测还是被DDOS攻击?

后端服务性能压测实践