React Native 在生产中崩溃

Posted 2023-03-15

技术标签:

【中文标题】React Native 在生产中崩溃【英文标题】：React Native crashing in production 【发布时间】：2016-11-21 19:30:50 【问题描述】：

我们使用 React Native 构建了一个应用程序，以改进我们之前的 Cordova 应用程序的用户体验和功能。

一切都很顺利。经过几个月的开发、QA、App 审查，然后我们发布到 App Store。它适用于我们尝试过的所有设备，从 iPhone 4s 到 iPhone 6s+，我们在 ios 8.3（您可以通过 xCode 下载的最早的模拟器）到 10.0 上进行了测试。

发布后，许多用户开始报告应用在启动画面消失之前就崩溃了。我们从未在应用审核、测试或其他任何地方看到过的行为。

我们调查了 xCode 中的“崩溃”，但它们显然没有出现，因为数百名用户经历了崩溃，而我们只能看到少数——这似乎与启动无关。

我们发布了一个集成了 Crashlytics 的更新版本，但这也无济于事。我们也没有收到针对此特定问题的 Crashlytics 错误，这意味着该问题可能发生在之前

我接下来应该去哪里看看有什么想法吗？我们真的不想恢复到旧版本并失去几个月的工作。

加载所有内容时，该应用程序使用大约 100MB 的内存，所以我认为这应该不是问题。它发生在所有设备的所有 iOS 版本上。我们不能只将错误隔离到特定用户。

【问题讨论】：

Crashlytics 是否为您提供了崩溃堆栈跟踪，还是您的崩溃没有得到任何回报？如果您根本看不到任何东西，那么它甚至可能在 Crashlytics 初始化发生之前就崩溃了。这里缺少一些信息，我们需要这些信息来帮助您：首先，crashlytics 为您提供什么？其次，您能否隔离正在执行此操作的设备（这将是最重要的）。好消息是，一旦您获得执行此操作的设备，您通常可以在本地发布到设备并进行复制。一旦你有了上述，我觉得这个问题会很快得到解决。医生不能不看病人就治病。必须在 Crashlytics 初始化之前发生崩溃。我无法隔离正在发生的设备。我会相应地更新问题。如果您的 iOS 设备发生崩溃，请从该设备获取崩溃日志。否则，应用程序的链接可能会有所帮助，因此这里的某人可以测试并提供故障转储。一旦你有了它，使用你的应用程序调试符号来获得崩溃功能。 【参考方案1】：

当似乎没有任何其他分析途径时，我会求助于日志记录这一卑微的后备方式。

我以前在生产 iOS 应用程序中使用过以下技术。这是一项设置工作，但一旦完成，它将对未来的许多其他问题非常有用。不仅仅是崩溃，还有用户报告的任何其他您无法在测试环境中复制的奇怪行为。

NSLog()

这方面的许多变化是可能的。包括仅在用户为其配置设置时才启用日志记录之类的内容。有时当用户报告特定问题时，您可能必须围绕特定代码区域添加大量日志记录，然后在问题解决后再次将其删除（如果您担心日志记录的性能/存储问题）。

对于我的（Objective-C）应用程序，包含我的代码以将启动状态写入默认值的位置如下（可能有更好的地方更适合您的应用程序）：

“startupBegan”早在应用委托的application:didFinishLaunchingWithOptions: “startupCompleted”在视图控制器的 viewDidAppear 末尾（不是 viewWillAppear！这两个发送之间可能会出错）

PS。我的旧日志重定向和轮换方法是这样的（Objective-C）：

- (void)logRedirectRotate 
    // If stderr not going to an XCode console (then running in production)
    if ( ! isatty(STDERR_FILENO) ) 
        // Rotate logs

        int rotationsCount = 3;
        NSMutableArray *logRotations = [NSMutableArray array];

        for ( int i = 0; i < rotationsCount; i++ ) 
            [logRotations addObject:[pathToLogsDir stringByAppendingPathComponent:[NSString stringWithFormat:@"appnameorbundleid.%d.log", i]]];
        

        [[NSFileManager defaultManager] removeItemAtPath:[logRotations lastObject] error:nil];

        for ( int i = rotationsCount - 1; i > 0; i-- ) 
            [[NSFileManager defaultManager] moveItemAtPath:[logRotations objectAtIndex:i - 1] toPath:[logRotations objectAtIndex:i] error:nil];
        

        //  Redirect stderr to current log file rotation
        freopen([[logRotations objectAtIndex:0] cStringUsingEncoding:NSASCIIStringEncoding],"a+",stderr);

【讨论】：

非常感谢您的建议。我开始实施，但在我完成之前我们就走上了正轨。我会给你赏金，因为我从你的回答中得到了一些对未来可能有帮助的好主意。谢谢！嘿，谢谢！很高兴听到你解决了它。我很想知道实际发生了什么，所以阅读你自己的答案很有趣。【参考方案2】：

由于我们与用户之间的沟通不畅，问题花了很长时间才解决。应用实际上没有崩溃，只是没有启动（在某些用户看来也是如此）。

在我们发现这一点后，我们意识到其中一个事件没有触发（隐藏扩展启动画面的那个），这就是用户卡住的地方。我们使用的其中一个库没有正确处理错误情况，这使我们的工作变得更加困难。我很幸运在测试时进入了那个状态，我可以从那里继续。

我更新了代码来处理这种情况，现在问题已经解决了。

【讨论】：

我有这个问题。应该触发哪个事件？你是如何解决这个问题的？【参考方案3】：

我遇到了这个问题，我的情况可能非常具体，但无论如何我都会分享我的经验。

这里的重点是应用程序只会在生产环境中崩溃，因此它只会在生产环境中触发，从而导致构建混乱。在我们的例子中，罪魁祸首是进行缩小的React's dependencies 之一。

要带走的东西：

密切关注依赖项的任何更新使用崩溃日志

【讨论】：