在 iOS 模拟器上运行 React Native 应用程序时诊断进程的高 CPU 负载

Posted 2023-02-23

【中文标题】在 iOS 模拟器上运行 React Native 应用程序时诊断进程的高 CPU 负载

【英文标题】：High CPU load of diagnosticd process while running React Native app on iOS simulator

【发布时间】：2020-07-08 03:11:12

【问题描述】：

我已经使用 React Native 开发了好几年了，但是最近才开始出现以下行为。在 ios 模拟器上运行任何 React Native 应用程序（直接从 Xcode 或通过react-native run-ios）后，诊断过程会在几分钟后缓慢地将 CPU 使用率增加到 150%。我的笔记本电脑变得无法使用，因为该进程还占用了操作系统的所有文件句柄。谷歌搜索只会指出过度的日志记录，但要么我没有找到正确的位置，要么没有发生大量的日志记录。

在模拟器中按下 Home 按钮关闭应用程序会立即停止高 CPU 负载。

有没有人也遇到过这种情况？我怎样才能找出造成这种情况的原因？

MacOS Catalina 版本 10.15.3、Xcode 版本 11.4、React 版本 16.9.0、React Native 版本 0.61.5、模拟器 iPhone 11 (iOS 13.4)

【参考方案1】：

我想我找到了解决方案。 Xcode 记录了很多行，其中包含：xcode nw_connection_get_connected_socket Client called nw_connection_get_connected_socket on unconnected nw_connection。这是在几个月前对 Xcode 进行了一些更新之后开始的。禁用日志记录已停止诊断进程消耗所有操作系统资源。我按照以下说明操作：Hide strange unwanted Xcode logs

基本上归结为将值为disable 的环境变量OS_ACTIVITY_MODE 添加到Scheme（运行）。

记录的真正原因是我仍然不知道。它看起来像是来自 React Native 的某种轮询。

【讨论】：

糟糕。我说得太早了。诊断过程现在运行良好，但有些东西仍在消耗资源，所以几分钟后我的系统仍然变得不稳定。 Chrome 崩溃等。可能是由于可用文件（网络套接字？）句柄耗尽。

找到了解决办法，看我的其他答案！

【参考方案2】：

与其说是解决方案，不如说是一种解决方法，但似乎将模拟器重置为出厂默认设置可以临时解决这个问题（至少在我的情况下）。

看起来 diagnosticd 正在处理一些可能位于模拟器内存​​中的文件，因此随着文件的增长，它可能会占用越来越多的 cpu？

无论如何尝试进入模拟器菜单：Hardware -> Erase All Content and Settings 然后关闭模拟器并从 XCode 重新启动它，以便在其上复制您的应用程序。

【讨论】：

在模拟器上杀死应用程序本身并重新启动它似乎对我做同样的事情，但作为一种解决方法，它只持续几分钟。我在其他一些正在运行的应用程序中也遇到错误，操作系统没有文件描述符，所以我猜这不是模拟器上的一些大文件，而是随着时间的推移打开了大量的小文件（可能不是由于cpu使用率高而关闭？）。我希望对操作系统有更多了解的人可以找出这些是哪些文件以及其中的内容。

在这种情况下，您肯定遇到了与我完全不同的问题。 diagnosticd 也在消耗 CPU，但没有你那么多，并重置了擦除模拟器修复那个临时的（我不知道多久了，虽然已经两天了，问题仍然没有出现）。

我对你的问题很感兴趣，因为它离我的不远。当 cpu 使用率很高时，尝试猜测 diagnosticd 实际在做什么会很有趣（我不能在我的计算机上这样做，因为我不再有问题了）。使用终端，您可以使用 lsof 查看所有进程的打开文件列表，如果您键入 lsof | grep diagnosticd 您将看到由 diagnosticd 打开的每个文件及其进程 id pid。 dtruss -p PID_Number 命令也可以查看所有系统调用，cpu使用率高的时候可以试试吗？

感谢您的建议。我已经尝试过，但无法理解输出。我已经贴在聊天室里了，让我们在那边继续。 chat.***.com/rooms/212792/…

我的聊天室好像被版主删除了。请告诉我如何联系您

【参考方案3】：

Xcode 9.3 Playground - diagnosticd 的解决方法，

kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk ' print $2 ')

我觉得这很有用

【讨论】：

谢谢你的建议，我试过了。杀死诊断过程无济于事。它立即以相同的高 CPU 使用率返回。我还尝试过使用/bin/launchctl list | grep SimDevice | awk 'print $3' | xargs -I %s /bin/launchctl stop %s 的另一种方法。这肯定会杀死诊断过程，但不幸的是，它也会杀死完整的模拟器。

是的，launchctl 最终也为我工作，但有点不同，sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist。但是，这可能需要您关闭 SIP...祝您好运！

我找到了从 Xcode 禁用日志记录的解决方案。有关详细信息，请参阅我自己的答案。感谢您的帮助！

【参考方案4】：

终于找到解决办法了！我一直想知道为什么 AppDelegate.m 中的默认 url 不起作用。所以我开始专注于此。事实证明，我巨大的广告拦截主机文件是造成这种情况的原因。恢复原来的 /etc/hosts 文件解决了这两个问题！ ?

【参考方案5】：

您还可以尝试另一件事，这是一项非常严厉的措施，您需要自行承担风险，

先试试这个，

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist

如果您收到有关系统保护 (SIP) 的消息，

您可以尝试关闭 SIP，然后再次运行该命令，

这几乎可以保证 diagnosticd 永远不会再运行...虽然不知道这意味着什么...

在此处阅读有关这两件事的更多信息，

https://makandracards.com/dev/16439-disable-daemons-services-in-mac-os-x

https://www.imore.com/how-turn-system-integrity-protection-macos

*免责声明，这可能不是解决 SIP 问题的最安全解决方案，但我是在我的 2015 年 i5 旧 macbook 上完成的，因为我已经绝望了，而且在具有诊断错误的模拟器上实际上无法做任何工作。

到目前为止，一切似乎都很开心......

【讨论】：

感谢您的建议。我之前尝试过重命名诊断应用程序，但没有它模拟器将无法启动。你确定它在被launchctl禁用时启动吗？那么从 Xcode 调试呢？这还有效吗？

是的，对我来说，sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.diagnosticd.plist 之后一切仍然有效仍在旋转的一个是 2 中较轻的一个，当应用程序打开时仅占用一个内核的 50%。占用 150% 以上的诊断程序现在对我来说已经消失了，这使我的系统更加稳定。日志记录似乎也很好，至少我查看的日志是底部选项卡中的日志。

我找到了从 Xcode 禁用日志记录的解决方案。有关详细信息，请参阅我自己的答案。感谢您的帮助！