Akshay Garg, Rishika Idnani, Michael James, Ashwin Kumar Valliammal

考虑一个场景，你在电视上使用Netflix应用观看你最喜欢的节目。突然，在内容流媒体播放的过程中，你看到了一个黑屏，并且控制跳回了电视的主屏幕。发生了什么？这种意外的过渡是与Netflix客户端应用崩溃相关的用户界面体验。应用崩溃是指由于各种原因（如应用中的错误、电视系统内存不足或电视在处理应用请求的功能时出现错误）导致应用意外终止。在用户使用应用的过程中发生的应用崩溃被归类为高用户影响崩溃。

但是是否存在低用户影响的应用程序崩溃呢？有的，这种情况可以考虑一下：当用户想要从Netflix应用切换出去时，他们按下了电视遥控器上的主页按钮。在这种情况下，通常情况下，应用程序会移动到一个不可见的后台状态。然而，如果Netflix应用程序在切换到电视主页界面的过程中或之后崩溃了，这种崩溃对用户体验的影响就不会像用户正在流媒体播放Netflix内容时发生的崩溃那样显著。在本文的背景下，让我们将这种应用程序崩溃的情况称为低用户影响的崩溃。

本文的主要目的是捕捉准确分类应用程序崩溃严重程度相关的细微差别，这对于确定解决这些问题的优先级至关重要。

为了理解Netflix应用崩溃严重程度识别规则，我们需要的第一个背景信息是，在像电视、机顶盒或流媒体棒这样的流媒体设备上，Netflix客户端应用的状态分类。在任何时刻，运行在这些设备上的Netflix客户端应用可以处于以下状态之一：

1. 在前台，并且正在使用: 用户正在积极地流媒体播放Netflix内容或浏览Netflix UI。
2. 在前台，正在使用但失去焦点: 用户激活了设备上的语音助手，将焦点转移到语音助手UI上，这会覆盖Netflix UI。Netflix应用程序不再处于焦点状态，但它仍然是可见的。
3. 正在过渡到前台: 用户按下了电视遥控器上的Netflix按钮或点击了Netflix图标，Netflix应用程序正在启动。
4. 在后台，或未运行: 用户正在流媒体设备上使用其他应用程序。
5. 正在过渡到后台: 用户采取了退出Netflix应用程序的操作，例如按下了Home按钮或另一个应用程序的入口按钮。

Netflix应用在流媒体设备上的状态和过渡

虽然将发生在前三种状态（1、2 和 3）中的应用崩溃归类为高用户影响，而将第四种状态（4）归类为低用户影响很容易，但第五种状态（5）则相对复杂。下一节将深入探讨 Netflix 应用资源 的基础概念。理解这一点对于探索在状态 5 发生的崩溃的严重性分类至关重要。

与任何其他流媒体应用程序类似，Netflix 需要从流媒体设备获取一组基本功能（也称为“平台资源”）。这些资源可以大致分为以下逻辑类别：

• 播放 : 音视频解码器、内容存储内存、播放控制等
• 图形 : 图形元素渲染及其相关内存
• 可见性 : Netflix 应用程序在屏幕上的可见性
• 焦点 : Netflix 应用程序是否处于焦点状态，即按键是否控制 Netflix 应用程序？
• 数字版权管理 (DRM) : 内容解密功能
• 文本转语音 : 提高可访问性的文本转语音音频
• UI 音频 : 按钮点击的音频
• CPU : 应用程序代码处理周期
• 网络 : 下载 Netflix 内容、UI 和其他资产的网络访问

在前台状态下，Netflix应用程序“获取”了所有这些资源，除了“文本转语音”功能，该功能仅在流媒体设备上启用时才会被获取。然而，在后台状态下，它只需要“CPU”和“网络”来更新Netflix用户界面和保持连接的消息。

此外，在不同的状态转换期间，Netflix 应用程序可能会释放或获取各种平台资源。例如：

1. 当用户在设备界面上切换TTS（文本转语音）设置时，设备请求Netflix应用获取“Text To Speech”资源并启用TTS功能。
2. 当用户在Netflix应用上激活设备的语音助手时，设备请求Netflix应用释放“Focus”资源，即不再占用所有关键输入事件。
3. 当用户操作将Netflix应用切换到后台时，设备请求Netflix应用释放所有资源，除了“CPU”和“Network”，即释放所有内容和图形内存，释放DRM资源，释放图形上下文，释放AV解码器等。这种转换就是我们在上一节中提到的State 5状态。

为了准确识别Netflix应用崩溃是否影响用户，我们必须区分示例1和示例2中的过渡与示例3中的过渡。在示例1和示例2中，用户期望Netflix应用稳定运行，因此这些场景中的崩溃会显著影响用户体验。相反，在示例3中，当应用切换到后台时，崩溃不会显著影响用户。

为了实现这一区分，我们可以将上述列出的平台资源分类为“背景过渡触发资源”或“非背景过渡触发资源”：

1. 后台过渡触发资源: 这些资源的释放仅在应用程序过渡到后台模式时发生。这些资源包括：播放、图形、可见性、数字版权管理（DRM）、CPU、网络。

2. 非后台过渡触发资源: 这些资源的释放也可能在应用程序不过渡到后台时发生。这些资源包括 焦点、用户界面音频和文本转语音。

现在我们已经对Netflix应用程序状态有了基本的了解，以及流媒体设备平台资源是如何映射到这些状态的，我们可以列出一些基本规则来区分Netflix应用程序崩溃是影响用户还是不影响用户：

• 规则 #1 — 高用户影响崩溃: 如果Netflix应用崩溃发生在所有Background Transition Triggering Resources 资源都被Netflix应用处于“获取” 状态，并且设备平台没有请求释放这些资源中的任何一项，那么这种崩溃将被归类为高用户影响崩溃。
• 规则 #2 — 低用户影响崩溃: 如果设备平台向Netflix应用发出请求，要求释放任何Background Transition Triggering Resources，那么无论Netflix应用是否完成了该请求，从设备平台生成此初始请求后发生的任何崩溃都将被归类为低用户影响崩溃。换句话说，如果Netflix应用已经开始从前景到背景的转换，那么在此转换开始后发生的任何崩溃都将被视为低用户影响崩溃。

高影响用户和低影响用户崩溃的分类逻辑

请注意，解决低用户影响的崩溃仍然非常重要，因为它们会影响应用程序下次启动的性能。然而，它们的严重程度并不像应用程序在活跃使用期间发生的崩溃那样严重。

有一个需要注意的地方，上述两条规则假设底层设备平台行为正确，并且不会在Netflix应用未完成释放平台请求资源的信号之前，从Netflix应用中拿走这些资源。

然而，在实际操作中并不总是如此。例如，当用户在电视遥控器上按下Home键时，为了尽快响应用户请求，设备平台可能会先显示Home屏幕，甚至在请求释放任何“释放”的背景触发资源之前就显示。如果在这些背景触发资源释放请求之前发生了Netflix应用崩溃，我们可能会错误地将其归类为高用户影响的崩溃。

为了应对这种情况，在应用崩溃后，我们会查询设备平台，以确定根据平台逻辑，最后一个Netflix应用是否处于用户可见状态。由于设备平台知道用户想要离开Netflix应用，它会将崩溃类型标记为后台崩溃，表明这次崩溃对用户没有影响。

现在有人可能会问，为什么不直接让设备平台来分类并判断崩溃是高用户影响还是低用户影响呢？这是一个合理的问题。但实际上，并非所有设备平台都能达到这种一致的分类水平。只有某些设备平台具备管理复杂应用状态的能力，才能提供这种细致的信息。因此，Netflix 内部的崩溃分类规则对于一个“尽力而为”的通用方法是必要的，这个方法适用于我们多样化的设备基础。

尽管上述部分描述了我们当前的崩溃分类逻辑，但我们直到最近才开始遵循这一规则集。在此之前，我们一直将任何在“visibility”（可见性）资源发布后发生的应用崩溃归类为低用户影响。但这会导致误报，即将低用户影响的崩溃误标记为高用户影响的崩溃，因为应用程序后台状态转换从设备平台请求第一个后台转换触发资源开始，而这个资源可能或可能不是“visibility”。

为了实现这一过渡，我们在客户端应用程序中添加了两个新的标记日志：““Background Transition _Start” 和 **“Background_ Transition _End”**。”客户端应用程序在接收到设备平台请求释放任何触发后台资源的资源时发送第一个日志事件。当所有请求的触发后台资源的资源都被释放后，发送第二个日志事件。

鉴于我们能够正确地将上述两个日志与来自Netflix客户端应用的崩溃事件日志在我们后台数据分析框架中进行排序，我们现在能够将大量“假阳性高用户影响崩溃”重新分类为低用户影响。以下是一个具有此类分类的日志序列样本：

假阳性高用户影响崩溃的事件序列

以下部分侧重于此工作流中的数据分析方面及最终结果。

从数据角度来看，我们现在计算一个额外的中间标志，然后将其存储在我们的崩溃数据表中。这个标志对于最终规则集至关重要，它决定了一个崩溃是否为高用户影响的崩溃。这个中间标志被称为 Crash After Background Transition Start (CABTS)。

CABTS 标志是一个布尔指示器，用于指定应用程序崩溃是否发生在应用程序已经开始 转入后台 之后。在一个崩溃会话中，如果崩溃发生在最近一次后台转换开始之后，那么此标志将被设置为 true；否则，将被设置为 false。此标志为 true 表示崩溃不会显著影响用户体验，因为后台转换动作会掩盖崩溃。

虽然这个概念看起来很简单，但在崩溃会话中发生恢复事件时就会变得更复杂。

不同场景下的CABTS计算：原始情况

上述场景涉及一个崩溃会话，在该会话中，多个事件（如后台过渡开始、恢复和崩溃）以特定顺序发生。

在第一种情况下，即使崩溃发生在最新的后台过渡开始之后，但在崩溃之前存在一个恢复事件，这意味着 CABTS 标志被设置为 false。这是因为恢复事件会将应用带到前台，使崩溃对用户可见。

在第二种情况下，由于在最后一次后台转换开始和崩溃之间没有恢复事件，CABTS 标志被设置为 true。这表明崩溃发生在应用过渡到后台的过程中，因此它不是高用户影响的崩溃。

为了规范化这些不同的序列并创建一个可操作的数据集，我们移除了所有在崩溃会话中最新恢复事件之前发生的事件。在最后一次恢复事件之前的事件与确定 CABTS 标志无关，也不会影响决策过程。这创建了如下的简单情况：

不同场景下的CABTS计算：更新情况

以下是我们用来识别应用崩溃是否为高用户影响的最终规则集及其执行顺序：

• 如果设备平台表明最后一次崩溃是由用户操作或系统更新触发的，则 High-User-Impacting Crash = False。
• 如果设备平台没有提供崩溃严重程度，并且所有背景触发资源都处于 Acquired 状态，即应用程序处于前台，并且在此状态下发生崩溃，则 High-User-Impacting Crash = True。
• 如果所有背景触发资源都处于 Acquired 状态，即应用程序处于前台，并且在此状态下发生崩溃，则 High-User-Impacting Crash = True。
• 如果在后台转换开始后发生崩溃，即 CABTS = true，则 High-User-Impacting Crash = False。

现在，让我们进入令人兴奋的部分。到目前为止，我们讨论了框架更改以增强检测高用户影响崩溃的准确性，但实际部署后的结果如何呢？

如下面的图表所示，实施更新后的崩溃检测逻辑后，Netflix 应用程序的关键设备平台上（由我们检测到的）高用户影响的崩溃率大约降低了 25%。这一改进有效地过滤掉了应用程序从前台切换到后台时发生的假阳性高用户影响的崩溃。

此外，我们还观察到此次推出带来的其他好处，包括更准确的现场AB测试结果、减少监控警报以及与客户服务数据更好的关联性。

高用户影响崩溃率降低现场

在本文中，我们概述了一种提高Netflix应用程序中高用户影响崩溃检测准确性的方法。虽然我们的重点是应用程序崩溃，但这种分类方法具有灵活性，可以应用于我们客户端应用程序监控和报告的任何用户界面问题。例如，它可以用于精确分析播放错误、播放质量下降、应用程序导航问题等对用户的影响。尽管这种内部分析尚未直接改善用户体验，但它为我们的开发团队提供了准确的见解，这些见解将用于衡量未来功能和调整在实际世界中的影响，最终帮助我们创造积极的用户体验。