最近后台收到好几条几乎一样的求助M1或者M2芯片的Mac上跑Flutter项目flutter run进行到一半模拟器要么起不来要么刚起来就退出终端最后甩给你一句冷冰冰的No such process。说实话第一次遇到这个报错我也懵了一下因为字面意思太宽泛了——哪个进程为什么找不到是我代码的问题还是模拟器的问题排查了一下午翻了系统日志、试了各种清理命令最后发现大部分情况根本不是代码的锅而是Apple Silicon环境下模拟器进程管理、缓存、以及终端运行架构这三者之间打架。这篇文章就把我实际排查过的几种典型场景、每一步的判断依据和最终解决方案完整记录下来给遇到同样问题的朋友一条可复现的排查路径。1. 先认清现实No such process 到底在说谁这个报错全称是The application could not be launched because of an error: No such process很多时候下面还会跟着一小段Could not send launchd signal之类的补充说明。它对应的系统调用错误是ESRCH意思是“某个PID对应的进程不存在了”。但难点在于是哪个PID对应的进程不存在Flutter在启动iOS模拟器应用时背后牵扯了一长串进程链。任何一个环节出问题最终都可能以No such process的形式报出来。我把实际项目里遇到过的几种现象归了下类现象A模拟器完全打不开。执行open -a Simulator没反应或者打开后一直白屏Dock栏图标跳两下就消失。终端报错直接指向CoreSimulator服务。现象B模拟器能打开但flutter run卡在启动阶段。日志里能看到Xcode build成功但安装App到模拟器时失败报No such process。现象CApp能装上但启动瞬间崩溃。报错出现在连接Dart VM、等待debugger attach的阶段。这种一般最坑因为代码本身完全没问题跑真机就正常。这三种现象背后对应着完全不同的原因。现象A大概率是CoreSimulatorService这个后台服务没有正常启动或者它管理的某个模拟器运行时进程死了现象B多是模拟器设备本身处于异常状态launchd无法正确派发信号现象C则通常是Flutter工具链与模拟器架构不匹配或者缓存损坏导致二进制加载不到。我见过不少人一看到No such process就开始重装Flutter、重装Xcode属于典型的浪费几个小时的大动作。实际上这个错误在M系列芯片上高发很大程度是“环境兼容性”问题而不是“代码正确性”问题。所以第一步不是动代码而是确认你具体踩的是哪一种现象。2. 核心原因拆解Apple Silicon 模拟器背后的三组进程关系要真正绕过这个坑不能只会抄命令得明白M1/M2上的iOS模拟器和Intel时代的差异。过去Intel Mac上跑iOS模拟器模拟器进程是x86_64架构的二进制和Xcode工具链、Flutter引擎的通讯方式已经磨合了很多年。到了Apple Silicon模拟器变成了arm64架构的原生进程同时还能通过Rosetta 2兼容运行x86_64的App。这种“双架构并存”的能力反而成了新问题的温床。具体来说有三组进程关系最容易出问题第一组是CoreSimulatorService 与模拟器运行时Runtime进程。模拟器本质上不是普通App而是由com.apple.CoreSimulator.CoreSimulatorService统一管理的。所有模拟器设备iPhone 15、iPhone 14等的启动、关闭、App安装都要通过这个服务转发。如果服务本身处于僵尸状态——进程还在但内部事件循环死掉了——那么任何启动请求都会超时或直接返回错误。而No such process经常是它在尝试向某个已经不存在的runtime进程发送信号时产生的。第二组是启动模拟器App后launchd 与调试进程的关系。flutter run在Debug模式下启动App时需要launchd先拉起应用进程然后Flutter的Dart VM通过一个调试端口attach上去。如果launchd在拉起过程中失败了比如签名问题、Info.plist错误、或者二进制格式不对调试器自然找不到目标进程于是抛出No such process。这种情况下真正的原因往往是模拟器设备缓存了旧的、损坏的安装信息。第三组是终端Shell的架构与Flutter工具链的架构匹配问题。这是Apple Silicon时代特有的坑如果你终端是用Rosetta模式打开的比如通过某些第三方终端App的“使用Rosetta打开”选项或者直接从旧Intel Mac迁移了环境那么你在终端里执行的所有命令——包括flutter、pod、xcodebuild——都会以x86_64架构运行。而模拟器是arm64原生进程。x86_64的工具链尝试去控制arm64的模拟器时某些系统调用和进程间通信方式会异常No such process就是这么来的。理解了这三组关系后面所有的排查和修复步骤就都清晰了我们其实是在做一件事——确认是“服务死了”、“设备状态脏了”还是“架构不匹配”。3. 完整排查链路从现象定位到根因确认先说结论下面这套排查顺序是我多次验证过的能从最省时间的操作开始逐步深入到更底层的修复。请按顺序执行每步都能确认一部分根因不要一上来就重装。3.1 第一步检查终端架构和模拟器架构是否一致打开终端执行uname -m如果你看到的是x86_64而你的机器是M1/M2/M3说明终端正运行在Rosetta翻译模式下。这会直接影响flutter工具的进程间通信。你可以打开终端的“显示简介”或者“设置”检查是否勾选了“使用Rosetta打开”。很多第三方终端App是有这个选项的。如果确认是这个问题请关闭终端用原生arm64模式重新打开再执行一次uname -m这次应该显示arm64。继续往下排查前请务必保证你后面的所有命令都在arm64模式下执行。3.2 第二步检查CoreSimulatorService是否存活执行ps aux | grep -i coresimulator正常情况下你至少能看到一个CoreSimulatorService进程。如果在列表里完全找不到说明服务没有启动那启动模拟器肯定失败。试着手动启动它killall -9 com.apple.CoreSimulator.CoreSimulatorService 2/dev/null; open -a Simulator注意这个命令是先杀掉旧的如果存在再重新拉起。等3-5秒再看进程列表。如果服务起来了模拟器窗口也正常弹出问题就解决了一半。如果模拟器还是不弹出来继续看第三步。3.3 第三步检查模拟器设备是否处于异常状态执行xcrun simctl list devices注意看输出里面每个设备的状态。有些设备会显示(Shutdown)有些是(Booted)。正常的模拟器设备可以处于关机或开机状态但如果某一个设备显示状态异常比如一直卡在某个中间状态flutter run在安装App时就会找不到目标进程。我的处理方法是把所有异常状态的设备先关掉再删除异常设备的旧安装缓存。如果你是直接在命令行启动模拟器的可以这样重置xcrun simctl shutdown all然后重新打开Simulator选择出现问题的那台设备再跑一次xcrun simctl boot 设备名称。如果boot过程就报错或者超时说明设备UDID对应的运行时文件很可能损坏了。3.4 第四步查看系统日志定位具体崩溃点到了这一步如果问题还在就必须看日志了。No such process太笼统系统日志能告诉我们到底是哪一步断了。log show --last 5m --predicate process launchd_sim OR process Simulator OR eventMessage CONTAINS No such process --style compact这里我解释一下这个命令的作用launchd_sim是模拟器内的launchd进程负责管理模拟器里所有App进程的生命周期。如果No such process是它的启动日志里报的那后面的eventMessage通常会更具体比如会提到某个路径的二进制文件访问不了、某个签名校验失败、或者某个插件加载失败。我在实际项目中遇到过一例日志明确写着某个Framework路径找不到原因是Project build阶段把Framework输出到了DerivedData的一个临时目录模拟器启动时这个临时目录已经被系统清理了。这种情况下的No such process其实是在告诉我们“可执行文件不在了”。解决办法就是清理并重建DerivedData后面会讲。3.5 第五步用最简Flutter项目做对照实验我排查这类问题时有个习惯如果项目代码复杂先创建一个全新的Flutter项目跑一下看看能不能在模拟器上正常启动。flutter create probe_demo cd probe_demo flutter run如果这个空项目也报No such process那基本可以排除你的App代码、第三方插件的问题问题焦点锁定在模拟器环境或Flutter工具链本身。如果空项目正常但你自己的项目报错那就要考虑是不是某个插件的原生代码在M系列芯片下编译出来的二进制有问题比如某些插件没有更新到支持arm64模拟器的版本。这一步能帮你节省大量在业务代码里找问题的时间。我记得有个团队排查了一整天最后发现是内部封装的某个基础库在Release模式下编译正常但Debug模式下和模拟器的JIT机制冲突导致启动即崩报错恰好是No such process。这种情况不属于环境问题需要单独处理。4. 对症下药三套我实测有效的修复方案根据上面的排查结果问题基本可以归入三类每一类有对应的完整修复手段。4.1 场景一CoreSimulator服务异常——重启服务链路如果你在第二步确认CoreSimulatorService没起来或者模拟器启动后状态一直不正常走这条修复路线。我的经验是光执行killall -9open -a Simulator不一定够因为SimulatorApp本身也有缓存。更稳的做法是一套组合命令# 1. 杀掉所有模拟器和相关服务 killall -9 Simulator 2/dev/null killall -9 com.apple.CoreSimulator.CoreSimulatorService 2/dev/null # 2. 删除模拟器缓存注意不会删除已安装的模拟器设备 rm -rf ~/Library/Developer/CoreSimulator/Caches # 3. 重新启动 open -a Simulator这里解释下为什么删除Caches有奇效CoreSimulator会把运行时状态、launchd的预置数据、设备状态快照都放在缓存里。如果上次模拟器异常退出时没有正确写回状态缓存里记录的就是一个“半死”的设备状态。下次启动时服务根据缓存去恢复设备但对应的进程实际已不存在就会出现No such process。删缓存就是强迫系统以全新状态重建。执行完后再验证xcrun simctl list devices所有设备应该都显示(Shutdown)而不是其他异常状态然后你再启动一个设备试试。4.2 场景二DerivedData和构建缓存损坏——重建构建产物如果问题发生在flutter run构建完成、即将安装到模拟器的阶段或者你看系统日志定位到了DerivedData目录下的二进制缺失那就得清构建缓存。执行rm -rf ~/Library/Developer/Xcode/DerivedData cd 你的Flutter项目目录 flutter clean rm -rf ios/Pods ios/Podfile.lock cd ios pod install --repo-update cd .. flutter run解释一下为什么这几步都要做DerivedData是Xcode存放构建产物、索引、预编译头的目录。在Apple Silicon上Xcode有时候会错误地复用Intel架构的缓存导致生成的二进制架构不对。删掉它Xcode下次构建会全量重新生成。flutter clean清理的是Flutter工具链生成的文件和部分原生工程状态。而pod install --repo-update是为了让CocoaPods在arm64模式下重新解析依赖避免之前用Rosetta环境安装的Pod产物某些Pod会有编译时生成的架构相关配置残留影响。这里有一个细节值得注意执行pod install前确认你当前的Terminal是arm64模式并且CocoaPods的路由正确。怎么看Pod装的是哪个架构你可以执行file $(which pod)如果输出里写的是x86_64说明CocoaPods本身还是Intel版。这种情况建议直接用sudo gem install cocoapods重新装或者如果你用的是Homebrew的Ruby环境用brew install cocoapods安装原生版本。4.3 场景三Rosetta架构干扰——统一为arm64环境这是M系列芯片特有、且很多人浑然不觉的坑。如果你的uname -m显示x86_64或者你能确定自己的flutter、pod等工具都是通过Rosetta安装的那么强烈建议统一到arm64原生环境下# 检查flutter本身架构可选步骤 file $(which flutter)如果flutter命令是x86_64的建议直接去官网下载最新版本官网提供的Mac版默认支持arm64或者通过你的版本管理工具重新安装。我自己遇到过一种更隐蔽的情况.zshrc里通过某个路径导入了旧Intel环境的工具链而这些工具和系统里新的Xcode共存导致每次执行flutter时调用的其实是一个和模拟器不兼容的中间层。这种问题你光看file $(which flutter)都不一定看得出来——包装脚本本身是文本文件要看它实际调用的二进制。最彻底的排查办法是在全新的终端标签页里用export PATH/opt/homebrew/bin:$PATH只保留Homebrew的路径如果你用的是Homebrew管理工具再检查which flutterwhich pod确保它们都指向/opt/homebrew/下的路径而不是/usr/local/下的Intel路径。如果项目里还用了CocoaPods的本地私有源或者一些需要编译的FFI插件架构就更加敏感。统一到arm64之后很多偶发的崩溃、No such process都会自行消失。5. 场景C的进阶排查Debug模式下App启动即崩溃的No such process这一节单独拎出来说因为场景CApp能装上但启动瞬间被杀死最让人头秃而且它和我们前面说的环境问题可能并存又可能无关。如果你已经清理了CoreSimulator缓存、也统一了架构空项目跑得好好的但业务项目一跑就崩且报No such process——请按下面顺序排查两层第一层检查第三方插件是否包含不兼容模拟器的原生代码。具体做法是在Xcode里打开项目而不是用VSCode选择好模拟器直接构建运行一次不是flutter run。Xcode的控制台会给出更详细的信息。如果某个插件用了Kotlin/Native、或者是通过CocoaPods引入的静态库看它的Build Settings里的VALID_ARCHS和EXCLUDED_ARCHS是否包含arm64。有时候插件开发者只排除x86_64或者在模拟器环境下没有正确配置就会导致模拟器得出一个奇怪的可执行文件launchd无法正常spawn进程最终报No such process。第二层验证是不是App的启动参数或Debug配置导致JIT无法工作。Flutter Debug模式下Dart代码是通过JIT即时编译在模拟器上跑的。模拟器App启动时会在一个非常早的阶段尝试连接Dart VM Service。你可以检查一下ios/Runner/Info.plist里是否配置了NSMicrophoneUsageDescription这类权限——不要笑这看起来无关但我遇到过一次App启动的第一个页面访问了相册权限而Info.plist里没有声明系统在执行到这个权限检查时会直接终止进程。Flutter这边看起来就是“等待VM Service连接超时进程不存在”报No such process。这种场景下建议的排查动作是在App的启动函数最前面加一个很早的日志输出比如在main()之前用print或写入一个本地文件看模拟器里有没有这个日志。如果没有说明App根本没跑到Dart代码就崩了集中在原生环境和Info.plist配置里找原因如果有日志说明Dart已经起来那可能是Flutter工具链版本的问题升级Flutter或者禁用某种实验性特性试试。我通常还会执行flutter upgrade升级完再跑。虽然听起来很粗暴但Flutter SDK在Apple Silicon上的支持是逐步完善的某些旧版本确实存在和Xcode新版本不匹配的已知问题报错表现也可能是No such process。6. 日常预防让No such process不再反复出现摸了这么多次坑之后我现在处理模拟器问题的频率已经大大降低了。除了遇到问题时按上面步骤修复还有一些日常习惯可以有效预防长期用M系列芯片开发的话环境全部用arm64原生版本。包括你的终端App、Homebrew、CocoaPods、Flutter SDK、Ruby环境。不要图省事直接迁移旧Intel Mac的整个Homebrew目录。迁移过来的工具链不知道什么时候就会在某个关键时刻给你来一次架构不匹配。不要让模拟器设备长期处于“半开”状态。不用的模拟器直接关机而不是让它在后台挂着。我观察下来模拟器长时间不关、反复从关机状态唤醒CoreSimulatorService积累的缓存问题概率明显增加。定期清理模拟器缓存是低成本高收益的操作。也可以在主机关机时彻底退出模拟器App不要用“关闭窗口”代替“退出应用”。Xcode升级后务必重新构建整个模拟器环境。Xcode大版本更新尤其是从14升到15再到16会改变CoreSimulator的内部接口。旧缓存没有及时失效时最容易出现No such process。升级后先执行一次xcrun simctl erase all这会清掉所有模拟器上的数据然后重新启动。建立自己的“模拟器急救”脚本。把4.1节的方法封装成一个shell脚本遇到问题先跑一遍很多情况几秒钟就解决了不需要重装任何东西。我自己的急救脚本大致长这样#!/bin/bash echo Killing stale simulator processes... killall -9 Simulator 2/dev/null killall -9 com.apple.CoreSimulator.CoreSimulatorService 2/dev/null sleep 2 echo Clearing CoreSimulator caches... rm -rf ~/Library/Developer/CoreSimulator/Caches echo Restarting Simulator... open -a Simulator sleep 5 xcrun simctl list devices echo Done.注意这个脚本不会删除模拟器设备本身那需要单独执行xcrun simctl delete不会影响你已安装的模拟器系统和已有的App数据主要是清理服务状态所以可以放心用。回到最开始的问题M1/M2 Mac上跑iOS模拟器报No such process十次里有八次不是你的代码有问题而是模拟器的后台服务状态、构建缓存或者终端架构环境出了问题。按照我从“现象分类 - 进程关系理解 - 逐步排查 - 对症修复”这条路线走下来绝大多数情况都能在半小时内解决。如果你的现象不在我列的三类里或者按步骤操作后仍然报同样的错那大概率是某个插件或依赖与当前Xcode版本不兼容可以试试升级所有依赖链Flutter、CocoaPods、Xcode到最新版本然后再走一遍上面的排查流程。
