各类网站推广,安阳县有几个乡镇,网站空间申请,宁波网站建设seo在之前的 《Flutter 又双叒叕可以在 iOS 26 的真机上 hotload》 和 《Flutter 在 iOS 真机 Debug 运行出现 Timed out *** to update》 我们聊过#xff0c;由于 iOS 26 开始#xff0c;Apple 正式禁止了 Debug 时 mprotect 的 RX 权限#xff0c;导致了 Flutter 在 Debug 运…在之前的 《Flutter 又双叒叕可以在 iOS 26 的真机上 hotload》 和 《Flutter 在 iOS 真机 Debug 运行出现 Timed out *** to update》 我们聊过由于 iOS 26 开始Apple 正式禁止了 Debug 时 mprotect 的 RX 权限导致了 Flutter 在 Debug 运行到 iOS 26 真机时会有 mprotect failed: Permission denied 的问题 。 在 iOS 上 Dart 不管是 JIT 运行还是进行 hotload 的时候都需要涉及代码在内存从 RW 变成 RWX 的调整 而为了快速解决这一问题Flutter 官方之前临时实现了一个过度方案
让 Flutter 应用在需要执行 JIT 新代码时“暂停下来”断点主动通知旁边的调试器让调试器利用它的特权来帮忙把代码设置为“可执行”然后再继续运行通过「双地址映射」让两个地址指向一个内存一个写入一个执行然后利用 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 的断点让 lldb 执行授权赋予 RX 做到在用一块内存上实现 Debug 时具备 RWX 的效果
对详细实现感兴趣的可以看之前的 《Flutter 又双叒叕可以在 iOS 26 的真机上 hotload》 而从临时实现方案就可以看出来这一个非常 hack 补丁并且这个方案预计会为每个代码空间页的分配增加约 500 毫秒的延迟在加上实际工作中和 debugserver 还有等待 Xcode 建立调试会话的时间让 iOS 在 Debug 开发中十分容易出现 Timed out *** to update 等问题。 事实上针对这类问题苹果也发现了“盲点”特别还需要 Xcode 启动配合等繁琐操作所以在 Xcode 16 增加了 devicectl 和 Xcode 的命令行调试器 lldb 协同工作的支持 而针对这个问题Flutter 在 Xcode 16 也终于实现了新的调整#173443通过新的 devicectl lldb 集成到 flutter run 命令来回归 Apple 官方的 debug 体系
通过 devicectl 实现安装启动 devicectl 作为在 Xcode 15 中引入的控制工具它主要负责将编译好的应用包.app安装到物理设备上并负责启动应用进程通过 lldb 实现 JIT 和调试运行作为 LLVM 项目的一部分lldb 是 Apple 标准的底层调试器在新架构中它将作为核心的调试传输层负责附加到由 devicectl 启动的应用进程并建立起和 Dart VM 进行通信的桥梁
具体可以在 flutter_tools 的 lldb.dart 看到launchAppWithLLDBDebugger 启动之后就会执行 lldb 的 attachAndStart 而对于 attachAndStart 主要核心就有
启动一个定时器如果一分钟内没有成功提示超时设置一个断点 _setBreakpoint依附进程 _attachToAppProcess
那为什么需要在执行 lldb 的时候通过 _setBreakpoint 添加一个断点呢实际上这就是在前面临时方案基础上的完善 _setBreakpoint 的主要目的就是 设置 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 作为 lldb 的断点 写入一个 _pythonScript 脚本当断点触发时利用 lldb 的权限执行脚本创建一个新的 rx 内存 关于 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 作为断点我们在之前讲过它是 Dart VM 在 VirtualMemory::AllocateAligned 时会通过 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 触发去让 lldb 用它的权限申请执行 而对于在 lldb 里执行的 py 脚本它主要是 当 Flutter 应用的 Dart VM 需要一块新的内存用于 JIT 编译时调用这个名为 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 的函数这个调用会触发预设的断点 断点触发后_pythonScript 的代码立即被执行 从寄存器 (x0, x1) 读取 Dart VM 请求的内存地址和长度 利用 lldb 的 WriteMemory 向该内存地址写入数据这个“写入”动作是关键它会强制 iOS 系统为这块内存做好准备 写入一个 bIHELPED! 的“回执”信号以便 Dart VM 确认操作已成功 执行完毕后它返回 False告诉 lldb “任务完成请立即让应用继续运行” 之后通过 lldb device process attach --pid 的方式让进程被纳入“开发者调试上下文”从而支持 JIT 权限 前面说起来比较抽象具体可以理解为
_attachToAppProcess 获取“权限”
因为系统的 W^X 安全策略_attachToAppProcess 的核心作用就是利用 lldb 附加的特权为整个应用进程解锁了这个限制。
在这一步完成之后应用进程的状态从“不允许 JIT”变成了“理论上可以 JIT”它获得了让内存页变为可读、可写、可执行 (RWX) 的可能性。
但是仅仅有可能性是不够的 因为Dart VM 在运行时和 hotload 是动态地、按需地需要新的可执行内页 page它需要一个“机制”来实现在需要的时候真正地去执行这个“将内存页变为 RWX”的操作而 App 本身的 Dart VM 本身没有这个权限所以它无法自己完成这个操作。 这时它就像一个身处大楼内、知道自己需要打开一扇门但自己手上没有钥匙的住户。 _setBreakpoint 建立“通信与执行机制”
_setBreakpoint 的作用就是建立这个缺失的机制类似于 建立通信渠道Dart VM 被设计成在需要新内存页时会去调用 NOTIFY_DEBUGGER_ABOUT_RX_PAGES 函数这就像住户去按下一个特定的“求助”门铃 部署执行者_setBreakpoint 告诉 lldb “请一直监听这个‘求助’门铃 (NOTIFY_DEBUGGER_ABOUT_RX_PAGES)”这就相当于雇佣了一位管家让他守在门铃旁边 下达具体指令_setBreakpoint 还通过 _pythonScript 告诉管家“一旦门铃响起你就用你手上的万能钥匙 (WriteMemory特权)去帮住户打开他指定的那扇门 (在指定地址和长度的内存上执行操作)。”
所以完整的流程是这样的 _attachToAppProcess授予 lldb 大楼的安全限制被解除了你可以走进去但是你没有钥匙这是前提条件。 _setBreakpoint管家 (_pythonScript) 被部署到位并且明确了工作指令监听门铃并开门这是执行机制当你需要 JIT 的时候就去按下门铃
所以 _pythonScript 是 Flutter lldb 架构的连接点它作为一个实时协议适配器在 lldb 的原生世界和 Dart VM 服务的托管世界之间进行翻译。
自此 lldb attach 成功后Dart VM 在启动时会尝试打开 JIT Compiler 当然如果 lldb 失败它将回退到使用过去的 Xcode 自动化支持 所以随着全新的 iOS 26 稳定版即将发布Flutter 也完成了它全新 LLDB 调试的适配迁移不过也可以看出iOS 上的 JIT 持续支持确实不是一件容易的事情。
