编辑:[db:作者] 时间:2024-08-25 08:24:19
Apple 文档
运用性能是用户体验不可或缺的一部分。随意马虎卡顿或启动韶光较长的运用无法让客户满意。如果加载搜索结果或酒店详情屏幕的等待韶光过长,可能会影响方案即将到来的假期的愉快感。这是我们绝对希望避免的事情。然而,每一项新功能都可能略微降落运用性能,某些变动可能会产生更大的影响,从而导致失落控。
缓解移动运用程序性能问题的关键在于适当的监控;否则,任何改进或保持性能的努力都会陷入困境。
运用性能团队简史在 Booking.com,我们已经监控运用性能指标很永劫光了。例如,第一个 iOS 启动韶光指标是在 2016 年推出的。2019 年旁边,卖力监控和改进性能的团队成立了。
到 2021 年,团队意识到现有的性能监控设置相称过期、不可靠并且不完备符合我们的哀求,因此须要进行修正。
在办理指标功能改进问题的同时,我们还决定彻底重写性能库,同时从较旧的 Objective-C/Java 过渡到当代 Swift/Kotlin 措辞。在此过程中,我们将库设计为完备独立于其他 Booking 根本架构,并注入实验、存储和网络等外部依赖项。
为什么不该用现有的第三方工具监控运用性能的免费或付费工具不胜列举。Apple 和 Google 供应了一些现成的监控办理方案,还有一些大型第三方公司,例如Firebase Performance。
然而,我们的监控工具有三个紧张哀求,所有这些哀求都与与 Booking 根本举动步伐集成以及涵盖我们开拓文化的详细内容有关:
实验:鉴于公司强大的实验文化,最关键的哀求是确保与我们内部实验根本举动步伐可靠、大略地集成。警报:我们须要一个灵巧的警报/SLA 系统,可以及时关照不同团队有关性能低落的情形。指标应尽快来自真实设备,以确保及时发出警报。灵巧性:我们希望能够自定义 Apple 和 Google 定义的现有指标。例如,在 iOS 上,我们的目标是区分运用启动韶光和首屏启动韶光。这意味着我们比 Apple 的默认监控系统更早结束启动韶光丈量。遗憾的是,没有第三方办理方案能够知足我们三个标准中的两个。因此,我们须要履行自己的办理方案。
我们丈量什么在认识到须要进行性能监控后,我们必须确定要跟踪的指标。每个指标都应办理用户的痛点。我们确定了两个紧张用户关注点:等待韶光和界面流畅度。这让我们专注于三个紧张指标:
运用程序启动韶光屏幕交互韶光 (TTI)帧渲染性能我们公司的核心业务是供应快速可靠的搜索和预订做事。因此,我们从真实用户那里网络了足够的数据,以验证这些指标的大幅低落常日会影响转化率,并且险些总是会对用户参与度指标产生负面影响。
运用程序启动韶光运用程序启动韶光指标以毫秒 (ms) 为单位丈量从用户点击主屏幕上的运用程序图标到运用程序绘制第一帧的韶光。
两个平台还区分了“冷”和“热”运用启动,但我们的紧张重点是改进“冷”启动,即系统无法从之前缓存在内存中的运用状态中获益的情形。这是由于“热”启动紧张取决于用户返回运用时首先打开的特定屏幕的性能(正如您将不才一节中看到的那样,我们无论如何都会单独丈量这个指标)。
您可以在官方开拓者文档(iOS和Android)中找到有关每个平台的运用程序启动过程的更多详细信息和官方建议。
交互韶光 (TTI)交互韶光 (TTI) 是从屏幕创建开始到渲染第一帧故意义的内容所花费的韶光(以毫秒 (ms) 为单位),确保:
所有内部设置均已准备就绪UI 布局和渲染最主要的数据已经到达并显示给用户主线程已准备好处理传入事宜TTI 始终包含原生运用性能,对付某些特定屏幕,它还可能取决于网络或存储性能。此指标使我们能够监控客户实际开始利用屏幕进行紧张用场的速率。
最初,这个指标是由 Google 为网络开拓定义的,但我们创造它非常有用,也非常适宜移动运用程序。
要调查 TTI 的性能低落,我们须要理解其背后的缘故原由。为此,我们利用支持性指标。我们监控与屏幕加载干系的每个网络要求的挂钟韶光和延迟,这有助于我们识别由后端引起的性能低落。对付涉及大量读/写存储操作的屏幕,单独监控存储性能也是故意义的。
此外,我们利用首次渲染韶光指标来查明由屏幕创建和渲染造成的性能低落(拜会下一部分)。
首次渲染韶光 (TTFR)首次渲染韶光 (TTFR) 是从屏幕创建开始到屏幕渲染其第一帧所花费的韶光(以毫秒 (ms) 为单位)。
它与一样平常的 TTI 丈量同时开始,但可能更早停滞。在最常见的情形下,屏幕该当尽快准备好绘制,但它不一定立即显示故意义的内容。常日,屏幕可以显示一些“进度指示器”并在后台进行一些繁重的初始化。我们在绘制第一帧后停滞 TTFR 跟踪,因此该指标非常靠近丈量屏幕的创建韶光。它使我们能够防止 UI 线程在创建过程中冻结,从而带来更好的用户体验。
该指标直接影响 TTI,也可能影响渲染性能。
渲染性能
为了确保用户与运用的交互流畅,运用应在 16 毫秒内渲染帧,以实现每秒 60 帧(把稳:在许多当代设备上,由于显示帧速率更高,目标可能设置为 90 或 120 fps,但在本文中我们将参考 60 fps)。如果帧渲染韶光超过 16 毫秒,则系统将被迫跳过帧,用户将觉得到运用中的卡顿。
让我们考试测验想象一下运用程序如何在韶光线上渲染帧:
有两个紧张成分会影响渲染性能的差劲程度:
冻结持续韶光:确定渲染单个慢帧所需的韶光。韶光越长,性能问题越明显(例如,渲染 500ms 的帧看起来比渲染 32ms 的帧差得多)。冻结次数或冻结频率:确定用户碰着慢帧的次数或频率。用户碰着相同慢帧且冻结持续韶光相同的次数越多,情形就越糟糕。考虑到这两个成分,我们可以得出相称准确地表示渲染性能的指标定义:
冻结韶光:每个屏幕(或运用程序)会话中由于渲染帧缓慢而导致的 UI 冻结的总韶光。在上图中,我们看到 6 帧:3 帧良好,3 帧涌现冻结。这意味着 3 个良好帧在 16 毫秒内渲染完成,而其他 3 帧涌现不同持续韶光的冻结。我们将冻结持续韶光打算为实际帧持续韶光与目标帧持续韶光 16 毫秒之间的差值。要打算总冻结韶光,我们须要汇总屏幕上发生的所有冻结的持续韶光。
冻结韶光可以相同,但模式不同:1 次冻结为 1000 毫秒,100 次冻结为 10 毫秒。此外,冻结韶光可以不通过任何额外变动而增加,只需增加会话持续韶光即可(例如,当可滚动列表的每个项目都会天生一些慢帧并且用户开始滚动更多时,这会导致总冻结韶光更长)。
为了捕捉这种情形,我们还利用了其余两个指标:
冻结计数:屏幕会话期间慢帧(慢于 16 毫秒)的总数。查看冻结模式是否发生变革。会话持续韶光:屏幕会话持续韶光。查看会话持续韶光是否发生变革,这可能会导致冻结韶光发生变革。选择冻结韶光指标的情由Google 和 Apple 都供应了评估渲染性能的指标。最初,我们采取了Firebase 实现的方法来监控渲染性能,个中包括跟踪慢帧(渲染韶光 > 16 毫秒)和冻结帧(> 700 毫秒)。但是,我们创造这些指标无法充分反响渲染性能低落的情形。
例如,假设列表中的视图已经很慢,须要 20 毫秒才能渲染。如果渲染韶光增加到 300 毫秒,指标仍会报告每个视图有一个慢帧,而没有任何冻结帧,无法表明渲染韶光明显恶化。
此外,性能变革的反响办法也不一致。视图渲染韶光从 15 毫秒增加到 20 毫秒与从 15 毫秒增加到 300 毫秒记录的指标变革相同,这不能准确反响性能低落的严重程度。
Apple 的“挂机率”指标以每小时挂机韶光的秒数打算,彷佛更符合我们的须要。它类似于我们的冻结韶光指标,但通过将总冻结韶光除以会话持续韶光进行标准化。然而,这种标准化导致该指标对用户行为的变革过于敏感。
例如,如果某个产品功能导致用户花费更多韶光滚动浏览缓慢的列表,则挂起率可能会因会话持续韶光增加而得到改进,纵然由于更多冻结而导致用户体验低落。
在碰着各种相对指标无法清晰反响性能的情形后,我们决定改用绝对指标。这使我们能够更准确地丈量渲染性能,不仅是全体运用程序,而且是每个屏幕会话,而且结果不会受到用户行为或会话长度的影响。
绝对指标也有一定的局限性。例如,我们可以举同样的例子:如果某项产品功能导致用户更频繁地滚动浏览缓慢的列表,纵然性能没有涌现技能低落,渲染指标也会恶化。但是,加入补充指标“会话时长”可以让我们有效地管理这些情形。
其背后的紧张思想是,无论出于何种缘故原由,我们都将冻结韶光的任何增加视为负面性能变革(尽管理想情形下,用户根本不应该看到任何冻结)。当然,对新功能引起的新性能问题做出反应很主要,但检测旧屏幕产生更多冻结也很主要,由于用户开始更积极地与其交互。
给我看代码!总结所有的理论知识和明确的指标定义,我们终于可以履行网络这些指标的有效办理方案。我们最近为这两个平台开源了性能跟踪库,您可以在 GitHub 上找到:
适用于 iOS 的 PerformanceSuiteAndroid 版 PerformanceSuite这些轻量级库有助于网络上述指标,并许可您将其报告给任何剖析系统。我们正在积极致力于进一步改进和新功能(例如终止监控),但它已经在两个平台的紧张预订运用程序中利用。iOS 库还用于我们为业主开拓的Pulse运用程序和我们姊妹公司的Agoda运用程序。
作者:Gleb Tarasov
出处:https://medium.com/booking-com-development/measuring-mobile-apps-performance-in-production-726e7e84072f
本站所发布的文字与图片素材为非商业目的改编或整理,版权归原作者所有,如侵权或涉及违法,请联系我们删除,如需转载请保留原文地址:http://www.baanla.com/rsq/194321.html
下一篇:返回列表
Copyright 2005-20203 www.baidu.com 版权所有 | 琼ICP备2023011765号-4 | 统计代码
声明:本站所有内容均只可用于学习参考,信息与图片素材来源于互联网,如内容侵权与违规,请与本站联系,将在三个工作日内处理,联系邮箱:123456789@qq.com