我一直在iOS生态里折腾脚本引擎，从最早的JavaScriptCore，到后来的Python、Lua，踩过的坑能装满一卡车。前阵子有个项目需要在iOS沙盒里跑完整的Python运行时，用来执行量化策略回测、数据爬虫和运维自动化脚本，需求从“能跑起来”一路升级到“稳定运行不闪退”，这过程让我把iOS沙盒Python适配从静态兼容层面，真正推进到了自适应运行体系。这篇就聊聊我在这个项目里的完整思路、踩过的坑，以及最后的落地实现。

如果你正在做以下任意一类事情，这篇内容都对你有参考价值：在iOS App里集成Python解释器做脚本化扩展、给App做热更新能力评估、为内部工具App注入自动化能力、或者单纯想在移动端跑通Python生态。我会从沙盒机制讲起，再到静态兼容层的搭建，最后展开自适应运行体系的核心设计和实操细节。

1. 项目背景与核心痛点：为什么iOS上跑Python这么折腾

1.1 沙盒机制对Python运行时的天然限制

先说最根本的问题：iOS的沙盒机制本质上是一个“囚笼”，每个App只能访问自己的容器目录，不能碰系统其他区域，更不能像桌面环境那样随意读取文件、加载动态库、修改环境变量。对Python这种依赖文件系统、动态加载、多线程调度的运行时来说，沙盒带来的限制几乎是全方位的。

具体拆解一下，主要有三大难题：

• 文件系统路径映射：Python运行时默认会找/usr/lib/python3.x这类系统路径，但在iOS上根本没有这种目录。它需要把标准库、site-packages、临时文件全部重定向到App的沙盒容器内，比如Documents、Library/Caches、tmp。
• 动态库加载机制：CPython在启动时会加载大量.so动态模块，如_socket、_ssl、hashlib这些核心扩展模块。在iOS上，系统不允许App在运行时从任意路径加载未签名的动态库（除非通过dlopen且路径经过特殊处理），所以你必须把解释器、标准库和所有扩展模块静态链接进App的二进制里。
• 内存和进程模型：iOS对单进程内存使用有硬性限制（不同机型差异很大，老机型可能只有1GB物理内存，App实际可用更少），Python解释器本身的常驻内存加上业务数据、脚本运行时产生的临时对象，很容易触发内存警告甚至被系统直接杀掉。

这些限制决定了你不能像在Linux服务器上那样“装个Python就完事”，必须做完整的适配工程。

1.2 “静态兼容”解决了什么，又留下了什么

我最初期的方案，业内通常叫“静态兼容”——就是把Python解释器以静态库形式编进App，标准库打包到Bundle内，在启动时通过C API初始化解释器，然后执行预先写死或者内嵌在App里的固定脚本。

这种方案的优点是简单、可控、不依赖网络，适合脚本内容固定、更新频率极低的场景。比如我在项目早期做的“离线规则引擎”，就是把一串预先编译好的策略脚本塞进去，App启动时直接跑，跑完就退出解释器。这种模式下，沙盒几乎不怎么参与适配工作，只要把解释器编进去了，脚本是死的，路径是写死的，访问范围是固定的，确实能稳定运行。

但静态兼容的致命问题是：脚本一变，就要重新发版。App Store审核流程一周起步，热更新机制又因为种种原因被限制得越来越死，一旦线上策略需要修个bug、加个参数，就只能干瞪眼。而且静态兼容没有解决沙盒资源动态变化的问题——用户的存储空间、可用内存、系统版本、机型性能各有不同，写死的策略只会导致一部分用户跑得飞快、另一部分直接崩溃。

1.3 自适应运行体系的目标定义

后来业务方提出需求：“脚本要支持远程下发的Python代码，要在不同机型上稳定执行，还要能监控运行性能并自动降级。”这就意味着我不能再把脚本写死，必须把Python运行时的初始化、文件系统、内存策略、执行调度全部做成动态可配置、可感知、可调整的体系。

我给这套体系定的核心目标有三条：

1. 解释器层自适应：根据系统版本、机型性能选择不同的解释器初始化参数（GC阈值、线程栈大小、内存池策略）。
2. 沙盒容量自适应：动态感知沙盒内可用空间、剩余内存，自动调整临时文件策略、缓存清理策略。
3. 执行调度自适应：根据当前App的状态（前台/后台）、系统内存压力、脚本复杂度，自动调整执行方式（同步/异步、分片执行、定时挂起恢复）。

这套体系跑通之后，同一个Python脚本，在iPhone 8和iPhone 15 Pro上能获得差异化的执行参数，在App处于后台时会自动降低优先级，在内存紧张时自动触发GC回收或者暂停非关键任务——这才是“自适应”的真正含义。

2. 核心技术选型与静态兼容层的完整搭建

2.1 解释器集成方案：PythonKit vs 自编译静态库

一开始我调研了Swift界最流行的方案：PythonKit。PythonKit的本质是用Python的C API封装了一层Swift接口，前提还是系统里有Python运行时。意味着在Mac上开发调试很方便，但放到iOS上就麻烦了——iOS系统本身没有Python，你得先自己把Python编译成iOS能用的静态库，让PythonKit有“东西”可以链接。

所以真正的工作量不在PythonKit上，而在**“编译Python静态库”**这一步。

这里有个关键经验：不要自己从零写编译配置，直接用开源项目python-ios-build或者参考Kivy iOS的构建脚本。我自己手写过一版，折腾了两天，链接阶段各种符号找不到，后来老老实实改用现成脚本，不到半小时编出了Python 3.11的iOS版本，包含_ssl、_socket、zlib、sqlite3等核心扩展模块。

编译时几个关键参数必须注意：

链接阶段最常翻车的几个符号是_PyArg_ParseTuple_SizeT、_PyLong_AsSize_t这类与系统库冲突的符号。解决方案是给链接器加-Wl,-force_load强制加载Python静态库，同时移除系统自带的libpython相关符号。

2.2 沙盒文件系统映射：标准库与站点包目录的落位

Python解释器启动后第一件事就是找标准库和site-packages目录，在iOS上必须手动告诉解释器“东西都在沙盒里”。

我在App启动时做了一套路径映射逻辑，核心代码长这样：

func setupPythonHome(containerURL: URL) { // 把Bundle里的Python标准库复制到沙盒可写目录 // 避免直接把Bundle作为PythonHome，因为Bundle是只读的， // Python运行时要写.pyc缓存，会出问题 let bundlePyLib = Bundle.main.url(forResource: "python-stdlib", withExtension: nil)! let containerPyLib = containerURL.appendingPathComponent("Library/Application Support/Python") // 首次启动时复制，后续启动直接复用 if !FileManager.default.fileExists(atPath: containerPyLib.path) { try? FileManager.default.copyItem(at: bundlePyLib, to: containerPyLib) } // 设置PYTHONHOME环境变量给解释器 setenv("PYTHONHOME", containerPyLib.path, 1) setenv("PYTHONPATH", containerPyLib.appendingPathComponent("site-packages").path, 1) }

这一块有个容易忽略的细节：把PyLib复制到可写目录不是一次性的，而是要监控缓存膨胀。Python标准库加上site-packages里装上numpy、pandas这类重武器之后，目录体积可以轻松超过800MB。如果用户存储空间不足，App下载这些内容会失败，运行时的.pyc缓存也会把空间吃干。所以我在自适应体系里专门做了存储监控（后面会展开）。

2.3 解释器初始化与安全配置

解释器初始化也有讲究，不能裸奔。我在初始化时做了几件额外的事情：

// C侧初始化代码 void initializePython() { // 关闭字节码写入，防止生成__pycache__占用空间 // 但这样每次启动会重新编译，首次执行会变慢 Py_IgnoreEnvironmentFlag = 1; Py_DontWriteBytecodeFlag = 1; // 配置线程池，iOS主线程栈大小默认限制比较严格 PyThreadState *_save = PyEval_SaveThread(); // 初始化解释器 Py_Initialize(); // 强制使用utf-8编码，避免系统locale问题 Py_SetStandardStreamEncoding("utf-8", "utf-8"); // 运行基础导入，验证标准库完整性 PyRun_SimpleString("import sys; print(sys.version)"); }

这里有个重要取舍：Py_DontWriteBytecodeFlag关了字节码写入，好处是不用每次启动清理.pyc缓存，坏处是每次启动首次执行大模块（比如numpy）会明显变慢。我最终改成自适应策略，只在存储空间低于某个阈值时才关闭字节码写入，空间充足时正常写缓存，这样兼顾了启动速度和长期存储健康。

2.4 静态兼容层的边界与瓶颈

静态兼容层做完后，架构长这样：解释器静态链接、标准库内置、初始化固定、脚本由App调用执行。这套东西在演示Demo时一切完美，一旦丢到真实用户手里，问题就出来了：

• 用户A的iPhone存储只剩300MB，我的Python环境占了800MB，App直接装不上或者运行中崩溃。
• 用户B在弱网环境下下载了一个需要requests库的脚本，但site-packages里根本没装这个库。
• 用户C的iPhone是4GB内存的老机型，跑一个正则密集型爬虫脚本，App直接被系统杀掉。
• 用户D反馈“App启动后脚本执行特别慢”，我一看日志，他的沙盒里空间不足，Python的临时文件写到一半失败，脚本反复重试。

这些问题没有一个是靠静态兼容能解决的——它们都指向同一个方向：运行时必须具备感知和调整能力。

3. 自适应运行体系的核心设计与分层架构

3.1 为什么“感知”是自适应的基础

我给自适应运行体系定的第一原则是：所有决策都基于运行时数据，不预设任何固定值。解释器的GC阈值、线程池大小、临时目录策略、缓存清理策略，全部从“当前设备的实际状态”推导出来。

核心感知指标有三个维度：

• 系统维度：系统版本、机型、物理内存大小、当前可用内存、CPU核数。
• 沙盒维度：容器内总空间、剩余空间、Python目录占用体积、缓存膨胀速率。
• 运行时维度：脚本执行耗时、内存峰值增长、线程活跃数、最近一次GC耗时。

这些数据在Swift侧统一采集，通过C接口注入Python环境，形成运行时上下文。举个例子：

struct RuntimeContext { let systemVersion: String let physicalMemory: UInt64 let availableMemory: UInt64 let freeDiskSpace: Int64 let cpuCoreCount: Int let isInBackground: Bool let isLowPowerMode: Bool let pythonDirSize: Int64 }

拿到这些数据后，Python侧可以直接读取上下文做决策。比如：

# Python侧读取注入的运行上下文 import runtime_context ctx = runtime_context.get() if ctx['freeDiskSpace'] < 500 * 1024 * 1024: # 空间紧张时启用紧凑临时文件策略 configure_tmp_strategy('compact') else: configure_tmp_strategy('default')

3.2 分层架构：Swift宿主层与Python运行层的职责边界

整个自适应体系我拆成了三层，每层各司其职，层与层之间通过明确的接口通信：

第一层是Swift宿主层，负责生命周期管理、资源监控、策略判定。它决定“什么时候运行Python”、“运行多久”、“脚本执行资质够不够”。这层不能写太复杂，因为Swift调Python跨语言存在桥接开销，每次调用都伴随着类型转换和状态保存。

第二层是Python运行层，负责脚本本身执行、库的加载、异常处理。这一层只聚焦“把脚本跑对”，不做系统级决策。脚本内部需要访问设备信息、读取沙盒状态时，通过宿主层注入的API获取，不直接走系统调用。

第三层是适配策略层，这是自适应体系的关键引擎。它既不在Swift侧，也不在Python侧，而是以配置文件加策略函数的形式存在。策略层读取Swift采集的环境数据和Python运行后回报的性能数据，按照预设的优先级做动态调整。

举一个实际场景：用户触发一个需要网络请求的爬虫脚本，Swift层检测到当前App处于前台但内存压力偏高，策略层判定“将脚本的线程优先级降低、超时时间拉长、内存GC频率提高”，Python层收到策略后，在执行爬虫脚本时自动调整了grequests的并发数和timeout参数。整个链路全部自动完成，用户无感知。

3.3 自适应策略的具体实现：一种可落地的配置体系

我最终把策略层做成了一个基于阈值的规则引擎，规则以JSON配置文件形式下发，可在后台动态更新，不用重新发版。

配置文件长这样：

{ "memory_strategy": { "available_memory_high": { "threshold_mb": 1024, "gc_interval": 3.0, "max_threads": 8, "cache_enabled": true }, "available_memory_low": { "threshold_mb": 256, "gc_interval": 1.0, "max_threads": 2, "cache_enabled": false } }, "disk_strategy": { "min_free_space_mb": 300, "cleanup_target": "python_cache", "enable_bytecode_cache": true }, "background_strategy": { "is_in_background": true, "pause_script": true, "resume_on_foreground": true } }

Swift侧启动时读取策略文件，初始化RuntimeContext，然后解析成一个策略对象，在每次执行Python脚本前调用：

func resolveExecutionPlan(context: RuntimeContext) -> ExecutionPlan { var plan = ExecutionPlan() if context.availableMemory < 256 * 1024 * 1024 { plan.gcInterval = 1.0 plan.maxThreads = 2 plan.shouldDisableCache = true } else { plan.gcInterval = 3.0 plan.maxThreads = 8 plan.shouldDisableCache = false } return plan }

这份计划随后通过C接口传给Python运行时。实现这套逻辑最大的坑是策略规则的粒度——太粗了无法处理复杂场景，太细了规则爆炸且互相冲突。我折中后定为“三档策略”：高性能档、均衡档、省资源档，再叠加“后台模式”“低电量模式”两个修饰条件。复杂的组合全部收敛在这三档内，组合数量可控，测试覆盖也容易做全。

4. 实操过程与关键代码：从静态兼容到自适应的完整实现

4.1 环境准备与Python静态库编译

开始动手前，先把基础环境备齐：

• Xcode 15+，命令行工具集
• Python 3.11源码包（推荐官方python.org下载）
• python-ios-build脚本
• iOS真机（模拟器很多沙盒行为模拟不了，别图省事）

编译命令直接按项目README跑就行，关键步骤就三步：

# 克隆构建脚本 git clone https://github.com/beeware/Python-Apple-support cd Python-Apple-support # 编译指定版本，输出产物在 dist/ 下 make python-3.11 # 编译完成后check产物 ls dist/

编出来的产物包含libPython.a和Python.xcframework两种形式。我建议直接用.xcframework，省得自己处理多架构合并的问题。

4.2 把Python嵌入iOS工程

拿到架构文件后，在Xcode里做四件事：

1. 把Python.xcframework拖进项目的Frameworks目录
2. 引入依赖的系统库：libz.tbd、libsqlite3.tbd、libbz2.tbd、libiconv.tbd（别漏了libffi，部分版本需要）
3. 在Build Settings里设置Other Linker Flags加-Wl,-force_load,$(BUILT_PRODUCTS_DIR)/libPython.a（如果用.a而非framework）
4. 把Python标准库目录Lib作为资源打进Bundle

这里最大的坑是链接顺序。如果省略第三步的force_load，链接器会认为某些Python符号没用直接裁掉，运行时会报错。

4.3 宿主层完整初始化代码

封装一个Swift管理器，负责Python从初始化到销毁的完整生命周期：

final class PythonRuntimeManager { static let shared = PythonRuntimeManager() private var runtimeContext: RuntimeContext? func boostrap(containerURL: URL) { // 1. 设置Python Home setupPythonHome(containerURL: containerURL) // 2. 注册运行时监控 startResourceMonitoring() // 3. 初始化解释器 Py_Initialize() // 4. 注入运行时上下文到Python环境 injectRuntimeContext() // 5. 加载自适应策略 loadAdaptivePolicies() } private func startResourceMonitoring() { // 每秒采集一次内存和磁盘状态 resourceTimer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { [weak self] _ in guard let self = self else { return } let mem = self.getAvailableMemory() let disk = self.getFreeDiskSpace() self.runtimeContext = RuntimeContext( systemVersion: UIDevice.current.systemVersion, physicalMemory: mem.physical, availableMemory: mem.available, freeDiskSpace: disk, cpuCoreCount: ProcessInfo.processInfo.activeProcessorCount, isInBackground: UIApplication.shared.applicationState == .background, isLowPowerMode: ProcessInfo.processInfo.isLowPowerModeEnabled, pythonDirSize: self.getPythonDirSize() ) // 每次采集后同步到Python侧 self.updatePythonContext() } } }

注意Timer的循环引用了，记得用[weak self]，不然内存泄漏教做人。

4.4 Python侧自适应处理模块

在Swift侧把策略传进去后，Python这边的核心模块结构长这样：

# adaptive_runtime.py import json import gc import threading import tempfile import os class AdaptiveRuntime: def __init__(self): self.context = {} self.strategy = {} def update_context(self, context: dict): self.context = context self._apply_strategy() def _apply_strategy(self): # 根据上下文动态调整运行时行为 if self.context['available_memory'] < 256 * 1024 * 1024: # 低内存策略：降低GC阈值、限制并发 gc.set_threshold(700, 10, 10) threading.stack_size(512 * 1024) else: gc.set_threshold(700, 10, 10) threading.stack_size(1024 * 1024) # 空间紧张时切换临时文件策略 if self.context['free_disk_space'] < 500 * 1024 * 1024: tempfile.tempdir = os.path.join(self.context['container'], 'tmp_compact') else: tempfile.tempdir = None # 使用默认tmp runtime = AdaptiveRuntime()

这套模块的核心思路是：Python侧不主动做全局决策，而是被动接收配置并立即生效。这样所有策略逻辑都收敛在Swift宿主层，Python只负责快速执行，两边职责清晰，调试起来也方便。

4.5 远程脚本执行与结果回传

自适应的最终目的是让远程下发的脚本能安全稳定地执行。我的执行框架分三步：

第一步：脚本合法性校验。在Python侧做AST级别的安全检查，禁止import os.system、禁止访问/etc这类绝对路径，只允许白名单内的模块和API。

第二步：通过沙盒网络模块下载脚本内容，校验哈希签名。

第三步：在单独的线程中执行脚本，并且——这是关键——设置超时机制。

远程脚本最大的风险是死循环或长时间无响应。我用Python侧的信号机制做超时控制：

import signal class TimeoutException(Exception): pass def run_with_timeout(func, timeout_seconds): def handler(signum, frame): raise TimeoutException("Script execution timed out") signal.signal(signal.SIGALRM, handler) signal.alarm(timeout_seconds) try: result = func() finally: signal.alarm(0) return result

但注意，iOS主线程上跑Python脚本时信号处理并不可靠。更稳妥的方案是用Swift侧的DispatchWorkItem配合超时回调，超时后强制清理Python线程状态。这里有个妥协：脚本无法被立即强制终止，只能等它自己退出或崩溃。所以我的策略是超时后隔离，也就是超时后标记该脚本执行环境不可信，后续请求切换到新的干净环境中执行。

4.6 执行结果与业务层联动

脚本执行完成后，结果通过PythonKit或C API回传Swift侧：

func executeRemoteScript(_ script: String) -> ScriptResult { let resultLock = NSConditionLock(condition: 0) var returnValue: String? DispatchQueue.global(qos: .userInitiated).async { // Python侧执行 if let pythonResult = runPythonScript(script) { returnValue = pythonResult } resultLock.unlock(withCondition: 1) } // 等待结果或超时 if resultLock.lock(whenCondition: 1, before: Date().addingTimeInterval(30)) { return .success(returnValue ?? "") } else { return .timeout } }

这类跨线程交互要极度小心：不要在主线程上等待Python结果，否则卡UI用户体验极差。QQ群里的场景是这样，用户点了一个“运行Python脚本”，结果在Swift侧等待过程中如果App恰好进入后台，等待锁会一直挂着，Python侧线程执行完毕后才能解锁，这时候用户已经切了别的App。

所以我的最终方案是：执行请求丢后台队列，通过回调通知结果，不阻塞任何用户可感知的线程。

5. 常见问题与实战排查：我在这个项目里踩过的坑

5.1 链接失败与符号冲突问题

这是最一开始就会撞上的。症状是Xcode编译报错，显示类似Undefined symbols for architecture arm64: “_PyArg_ParseTuple_SizeT”。

排查思路：

• 确认libPython.a确实被链接了（在Build Phases里查看实际链接的库）
• 确认没有同时链接多个版本的Python（比如系统自带的和静态库里的冲突）
• 确认架构一致，.a文件里必须有arm64切片，用lipo -info libPython.a查看

我遇到过最阴间的坑是：编译脚本默认生成了模拟器和真机的双架构版本，Xcode自动选了模拟器架构跑在真机上，运行时崩溃但编译期正常。排查了半天才发现选错了framework slice。解决方案是确保工程配置里只暴露真机架构。

5.2 内存警告与线程崩溃问题

Python执行过程中，尤其在循环处理大数据时，内存峰值会迅速膨胀。iOS在内存紧张时会先发didReceiveMemoryWarning，然后有概率直接强杀进程。

我加了好几道防线：

1. 启动前置检查：App启动时先检查可用内存，低于200MB就不初始化Python解释器，直接走降级逻辑。
2. 执行中监控：Swift每秒采样一次Python堆内存（用sys.getsizeof和tracemalloc配合），内存涨速超过阈值就强制插入GC。
3. 线程栈控制：Python线程默认栈在iOS上容易超限，显式用threading.stack_size()控制。

实操中特别推荐使用tracemalloc来定位泄露点，它比memory_profiler轻量，且能给出代码行级别的内存分配报告。在iOS嵌入式环境里这是最可靠的内存追踪手段。

5.3 文件系统空间不足引发的诡异崩溃

这个坑非常隐蔽。静态兼容阶段我把Python标准库放在只读Bundle里，一切正常。但引入远程脚本下载后，脚本要写Documents目录，临时文件要写tmp目录，.pyc缓存写满Library/Caches，一旦空间不足，表现不是正常的写入失败，而是Python解释器根本启动不了——因为Py_Initialize()内部会尝试创建临时目录，失败就直接崩溃，连错误信息都没有。

解决方案是做了三层保障：

• 启动前用FileManager检查沙盒可用容量，低于阈值直接跳过Python初始化
• 启动后设置TMPDIR环境变量到特定子目录，且确保该目录真实存在
• 定期清理.pyc缓存和超时临时文件，防止膨胀

清理策略用一段Python脚本挂在后台定期跑：

import shutil, os, tempfile temp_dir = tempfile.gettempdir() for root, dirs, files in os.walk(temp_dir): for f in files: file_path = os.path.join(root, f) # 删除超过24小时的临时文件 if os.path.getmtime(file_path) < time.time() - 86400: os.remove(file_path)

5.4 远程脚本死锁问题

远程脚本并发执行时，如果多个脚本访问同一个共享资源（比如沙盒中的同一个配置文件），容易出现死锁。Python自带的multiprocessing在iOS沙盒里不能可靠使用，因为沙盒不允许App创建多个进程。所以我最终放弃multiprocessing，改写为asyncio模型，在单进程内做并发管理。

这里要提醒：不要过度相信Python的上层抽象，一旦涉及嵌入式环境，底层限制都会浮上来。沙盒环境对fork的限制，直接让很多依赖多进程的第三方库失效，比如某些爬虫框架。

5.5 常见问题排查速查表

6. 性能调优与进一步扩展的个人心得

6.1 预热机制：把首次执行的时间成本转嫁到启动时

Python脚本首次执行慢的主因是标准库模块首次加载要编译字节码。我做了个预热机制：App启动后空闲时，在后台线程加载一次常用模块（os、json、re、itertools、collections），预编译字节码。这样用户真正触发脚本执行时，这些模块已经在内存里了，首次调用速度能提升30%以上。

如果你脚本涉及特别重的库（比如numpy），预热收益更明显。但注意不要过度——预热太多模块反而会拖慢启动速度和占用内存，预热清单要根据实际业务脚本的依赖动态调整。

6.2 降级策略：从“执行失败”到“优雅降级”

自适应体系最重要的是面对资源不足时，不是直接失败，而是降级执行。我设计了三级降级链路：

• 第一级：性能调优。降低脚本并发、加大GC频率、关闭缓存。
• 第二级：功能裁剪。脚本内部检测资源不足后，自动跳过非核心步骤（比如跳过数据可视化，只做数据计算）。
• 第三级：延迟执行。实在资源不够，就把任务放入队列，等App处于前台且有足够资源再执行。

这个降级链路用策略文件即可灵活切换，不用改代码。实际操作中，我观察到大部分脚本在“功能裁剪”这一级就能解决内存问题，很少进入第三级。

6.3 日志与监控：迁移线上环境的基本功

iOS沙盒里跑Python的日志不好找，尤其脚本运行崩溃时，没有Linux环境下的/var/log可以翻。我搭了一套结构化日志体系：

• Python侧执行日志统一走print，但重定向到沙盒内一个日志文件
• Swift侧通过读取该文件，配合OSLog统一输出
• 在调试模式下，可以实时查看Python侧输出

如果集成的是PythonKit，还可以通过适配PyObject直接拿到Python的stdout，但我的经验是重定向到文件更可靠，特别是脚本崩溃时，文件里的日志比PythonKit的内存缓存能保留更多现场。

6.4 未来扩展：把自适应体系迁移到Android沙盒

这套思路虽然是为iOS设计的，但干完这个项目我发现，Android端的沙盒限制虽然比iOS宽松，但碎片化更严重——机型差异、系统版本差异、厂商定制差异，比iOS还要复杂得多。自适应运行体系的“感知-决策-调整”闭环，在Android上同样适用，甚至更适用。把同一套策略引擎迁移过去，只需要替换底层系统检测API和沙盒路径映射逻辑即可。

如果你正在做移动端脚本引擎相关的开发，我强烈推荐把“自适应”作为核心架构原则，而不是把时间花在“写死一个兼容方案凑合跑”上。环境差异是永远的，写死的方案终将会被下一个机型和系统版本打破。

最后分享一个实操中的小技巧：在验证自适应体系时，不要只看正常路径。用Xcode的Metric工具模拟内存警告、磁盘不足、弱网等场景，强制触发降级逻辑，看看你的策略是否正确触发。不少“稳定”的实现一模拟极端情况就直接崩了，提前验证能省去线上事故的尴尬。