卡卡卡，小萝莉告诉你开发iOS应用如何避免卡顿
发布网友
发布时间：2022-04-22 17:13
共1个回答
热心网友
时间：2023-09-27 10:46
作为一名有态度、充满情怀的开发者，当然就是立马撸起袖子准备修复了。那么问题来了，我们要从哪下手呢?
俗话说“治病先治根”，那么就要了解到卡顿是怎样产生的了。
创建一个UI Button，当用户点击的时候，主线程会响应及处理点击事件，这里是执行handleButtonAction方法。handleButtonAction方法发起了一个网络请求下载图片。必然的，这是一个耗时的操作。
在iOS应用中，所有的UI操作及更新都是在主线程完成，并且主线程的runloop是逐个处理用户事件的(当然其他的runloop也一样)，所以主线程必须等待上一次事件处理完成后才能继续响应下一次事件。
由于在主线程内发起耗时网络请求，主线程只能停止响应接下来的所有用户事件，等待网络请求结束。在等待的这个过程中，应用就停止响应了，也就是出现卡顿现象。
为了更好的理解主线程的runloop，我们来看看iOS应用的运行机制。
在 iOS 应用启动后，系统会自动创建主线程并开始运行它的 runloop，监听处理分发事件，当没有事件发生时进入休眠状态，有事件发生时系统会将接收到的事件放在一个队列里，然后唤醒 runloop 依次处理事件。
绝大部分用户感知到的卡顿就是由于主线程阻塞了，在处理某次事件消耗了过长的时间，导致主线程处于等待状态，无法及时响应用户的下一次输入事件。
由于iOS 上的 UIKit 只能在主线程进行处理，导致开发者在开发过程中不经意间在主线程做了一些消耗时间的工作，导致了应用卡顿。
根据上述内容我们了解到了是什么原因导致卡顿的，接下来就是如何避免卡顿的问题了，友盟+u-apm监控平台可帮助到大家！
避免卡顿的黄金法则就是不要让主线程干重活，例如网络请求，读写大文件，复杂的运算等一些耗费大量系统资源及时间的任务。
充分利用好 iOS 的多线程，如 NSThread、NSO peration Queue，GCD 等干脏活、累活，让主线程能及时迅速的响应用户事件。
主线程轻松了，应用就流畅了，用户也就会越来越多，用户的使用感爽了，就不用担心差评的问题了，五星评价也就越来越多喽~
那么我们根据上面的黄金法则修改下handle Button Action方法，用GCD 来进行网络请求。经过修改之后，现在主线程就不会发生阻塞了，迅速的执行完用户的点击事件后，然后等待响应用户的下一次事件。
除了在开发过程中开发者需要时刻牢记黄金法则，避免写出阻塞主线程的代码，我们还需要一套监测机制，来帮助我们及时的发现应用卡顿，第一时间定位并修复，给用户如丝般顺滑的操作体验。
应用发布后如果碰到用户反馈卡顿，我们又该如何去定位解决问题?
一个比较常见的场景：用户反馈应用卡顿，客服人员反馈给开发者，开发者要求用户提供更加详细的信息以定位问题，但是问题又来了，很多时候我们联系不上用户啊！怎么办？熬夜加班逐行检查代码，说多了都是泪。
那么，友盟+U-APM作为一款应用性能监控平台，这不就派到用场了嘛~不仅可以解决开发者对iOS卡顿问题的烦恼，还可以协助APP应用，让用户体验到APP的流畅性。友盟+U-APM同时提供云真机测试能力，助力开发者从研发测试质量验收到线上问题复现排查，保障应用品质，提升测试效率。在云真机测试期间自动采集崩溃信息，提供详尽的崩溃报告协助筛查，真正实现监控测试全流程深度打通。
U-APM应用性能监控平台，通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力，及卡顿、启动分析、内存分析、网络分析等性能监测能力，支持多场景、多通道智能告警监测，帮助开发者高效还原异常、卡顿用户的访问路径和业务现场，缩短故障排查时间。这一块的功能是我比较喜欢的，建议各位开开者有以上这些烦恼时，都可以试试运用上U-APM的功能，你会发现不一样的使用和便捷。
