【问题标题】:Suddenly getting many Fabric Out of Memory sessions: Can Fabric OOM Reports ever be false alarms?突然出现许多 Fabric Out of Memory 会话:Fabric OOM 报告会是误报吗?
【发布时间】:2018-06-15 18:03:27
【问题描述】:

我最近在我的应用程序中添加了后台提取,它运行良好。我最近在 Fabric 中注意到,OOM 免费会话的数量逐渐从 100% 变为青少年的每日平均水平低至 14%。我只看到这里和那里报告了几起崩溃,没有其他证据表明用户报告了崩溃。

看了how OOM sessions are detected之后,好像有可能是虚假报道。用户启动应用程序,然后它进入后台状态。然后,应用程序会启动以进行后台提取、执行提取并终止——这在操作系统允许的情况下经常发生。

Fabric 的 OOM 检测器是否可能由于重复的后台获取启动和终止发生的方式而错误地检测 OOM?

【问题讨论】:

    标签: ios google-fabric background-fetch


    【解决方案1】:

    是的,在某些情况下,由于当前的 OOM 启发式算法会错误地检测到 OOM。后台抓取可能会误报 OOM。

    【讨论】:

    • 我们看到与@Barrett 相同的症状,但由于后台位置更新(地理围栏)。我们是否可以通过检测 didFinishLaunchingWithOptions 中的 UIApplicationLaunchOptionsLocationKey 并在这种情况下避免 Fabric 初始化来解决?
    • 谢谢。您可以,但这可能会在其他情况下导致报告出现一些问题。随意测试一下,让我知道它是怎么回事:)
    • 您好,您可以尝试使用上述方法并成功吗?
    • 目标 OOM 空闲会话 % 应该是什么样的?我的意思是,这听起来并不完全在开发人员手中。如果用户打开了其他几个应用程序,最终未打开的应用程序将关闭。话虽如此,我的 OOM 免费会话百分比非常低,这可能也是由于后台位置似乎刷新了。
    • 也看到 OOM 报告,但显然是由于后台提取。太令人沮丧了——因为这个误报,过去两个小时都在监控内存使用情况。
    【解决方案2】:

    这很可能是因为后台获取和测试它的一种方法是在禁用 BG 获取的情况下在测试飞行中推送构建,并为某些用户测试几天。如果您的数字没有因该特定构建而下降,您可以确定这是因为织物的虚假报告并继续前进。如果您仍然面临这个问题,那么您将不得不拿出您的仪器并检查。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-11-07
      • 1970-01-01
      • 1970-01-01
      • 2019-03-25
      • 1970-01-01
      • 2011-04-23
      • 2019-11-30
      • 1970-01-01
      相关资源
      最近更新 更多