解决 Pythonista 在 iOS 后台运行时被系统强制终止的问题

在 iOS 操作系统中，Pythonista 切入后台后脚本迅速停摆或直接崩溃，其核心原因是 iOS 的前后台生命周期管理机制将切出前台的应用迅速置入“挂起（Suspended）”状态，并在系统资源吃紧或后台无授权活动时由 Watchdog 与 Jetsam 机制直接终止进程。要解决这一问题，核心路径在于根据任务类型选择合规且受系统豁免的通道：对于需要连续运行的本地服务或长耗时任务，通过 objc_util 激活后台音频通道（AVAudioSession）进行微弱静音循环播放，阻止系统冻结进程；对于需要几分钟完成的收尾任务，调用原生临时后台执行请求；对于定期执行的批处理任务，则改用 iOS 快捷指令（Shortcuts）自动化调度唤醒，同时严控脚本内存占用以规避 Jetsam 强杀。

一、iOS 后台生命周期与进程终止诱因剖析

当用户在 iPhone 或 iPad 上切换应用或按下锁屏键时，iOS 并不会将 Pythonista 像桌面操作系统那样保留在全速计算状态。iOS 设计了极其严格的应用程序生命周期状态机，所有未申请特定后台权限或未被系统豁免的应用都会在短时间内被剥夺 CPU 资源。

通常情况下，Pythonista 在进入后台时会经历如下几个关键阶段：

• 前台活跃（Active）：应用处于屏幕可见层，独占主要计算核心与渲染流水线，Python 脚本正常执行。
• 后台过渡（Background Running）：应用刚刚退到后台，系统默认分配短暂的过渡运行时间（现代 iOS 版本中通常仅有 5 到 30 秒）。此时主线程仍然可以处理少量未竟请求。
• 挂起（Suspended）：过渡期结束后，如果应用没有合法的活跃后台音频、持续定位或后台传输任务，iOS 会立即暂停分配 CPU 调度片。此时进程虽然仍保留在 RAM 中，但所有 Python 线程（包括 time.sleep 或网络套接字监听）均被完全冻结。
• 强制终止（Terminated）：当设备内存告急或应用发生违规行为时，iOS 的系统守护进程直接发送 SIGKILL 信号终止 Pythonista。此时脚本执行上下文全毁，重新打开时应用必须经历冷启动。

从上述机制可以看出，解决问题的思路必须分成两步：第一步是**阻止进程进入挂起状态**，让 CPU 持续为 Python 解释器分配时间片；第二步是**控制运行期间的内存占用与资源消耗**，防止被系统的 Jetsam 机制以高内存占用为由优先驱逐。

二、方案一：利用 AVAudioSession 静音音频维持后台长效驻留

在 iOS 体系中，音频播放（Audio Playback）属于少数几类拥有最高优先级系统后台豁免权的功能之一。Pythonista 自身在 Info.plist 中已经声明了 audio 后台模式（UIBackgroundModes）。这意味着只要 Pythonista 正在通过系统的音频通道播放声音，iOS 就会将 Pythonista 判定为“正在向用户提供媒体输出”，从而完全豁免其进入挂起状态。

为了达到不打扰用户、不发出声音且维持后台运行的目的，我们可以借助 Pythonista 自带的 Objective-C 桥接库 objc_util 或 sound 模块，激活 AVAudioSessionCategoryPlayback 类别，并使用一个微小音量的无限循环静音音频来作为“保活针”。

1. 完整可执行的保活代码实现

以下代码提供了一个名为 BackgroundKeepAlive 的上下文管理器。在进入上下文时，它会自动在底层配置音频会话并循环播放极小音量的内置短音频文件；在退出上下文或手动终止时，它会自动释放会话，将系统音频控制器完整交还。

# -*- coding: utf-8 -*-
"""
Pythonista 后台音频保活管理器
运行环境：Pythonista 3 on iOS 15 / 16 / 17+
"""
import time
import threading
from objc_util import ObjCClass, nsurl

class BackgroundKeepAlive:
    def __init__(self):
        self.AVAudioSession = ObjCClass('AVAudioSession')
        self.AVAudioPlayer = ObjCClass('AVAudioPlayer')
        self.player = None
        self._is_active = False

    def start(self):
        if self._is_active:
            return
        
        # 1. 获取共享音频会话单例
        session = self.AVAudioSession.sharedInstance()
        
        # 2. 设置 AVAudioSessionCategoryPlayback (后台播放)
        # 并附带 AVAudioSessionCategoryOptionMixWithOthers (0x1) 避免打断其他媒体声音
        category = 'AVAudioSessionCategoryPlayback'
        options = 0x1  # MixWithOthers
        session.setCategory_withOptions_error_(category, options, None)
        session.setActive_error_(True, None)

        # 3. 加载 Pythonista 内置的系统提示音作为静音载体
        # 也可以使用极短的本地静音 wav 文件
        sound_path = '/System/Library/Audio/UISounds/nano/Alert_ActivityGoal_Haptic.caf'
        file_url = nsurl(sound_path)
        
        self.player = self.AVAudioPlayer.alloc().initWithContentsOfURL_error_(file_url, None)
        if self.player:
            # -1 代表无限循环播放
            self.player.setNumberOfLoops_(-1)
            # 音量设置为 0.001，既满足音频硬件激活，又完全不产生人耳可察觉声音
            self.player.setVolume_(0.001)
            self.player.prepareToPlay()
            self.player.play()
            self._is_active = True
            print("[KeepAlive] 后台音频保活已激活，Python 解释器在切出后将持续运行")
        else:
            print("[KeepAlive] 播放器初始化失败，请检查音频源路径")

    def stop(self):
        if not self._is_active:
            return
        if self.player:
            self.player.stop()
            self.player = None
        session = self.AVAudioSession.sharedInstance()
        # 停用音频会话并通知其他音频应用恢复原有状态
        session.setActive_withOptions_error_(False, 1, None)
        self._is_active = False
        print("[KeepAlive] 后台保活已解除，恢复系统默认挂起行为")

    def __enter__(self):
        self.start()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        self.stop()

# 示例：后台执行需要持续运行的任务
if __name__ == '__main__':
    def worker_task():
        counter = 0
        while True:
            counter += 1
            print(f"[Worker] 正在后台稳定运行，心跳计数：{counter}")
            time.sleep(5)

    with BackgroundKeepAlive():
        # 将工作逻辑托管在守护线程中或直接在此运行
        t = threading.Thread(target=worker_task, daemon=True)
        t.start()
        
        print("切出应用至手机主屏幕，脚本仍将在后台持续输出...")
        try:
            while True:
                time.sleep(1)
        except KeyboardInterrupt:
            print("收到中断信号，准备退出...")

三、方案二：利用 location 位置更新实现后台防冻结

除了音频播放，持续位置追踪（Location Tracking）是 iOS 另一项允许在后台运行的机制。Pythonista 提供了官方封装的 location 模块，允许开发者直接调用 CoreLocation 服务。

当通过 location.start_updates() 启动位置监控后，一旦设备产生移动或触发基站切换，系统就会分配后台时间来处理位置回调。为了让位置服务能够在应用位于后台时稳定运行，必须在 iOS 系统设置中对 Pythonista 给予明确授权：

1. 打开 iOS “设置” > “Pythonista 3” > “位置”。
2. 将允许访问位置信息修改为“始终”（Always）。若仅设置为“使用 App 期间”，切入后台后系统依然会停止派发位置事件并挂起应用。

在代码实现中，可以通过设定较低的精度要求（如 accuracy=1000 米或 distance_filter=500），在既达到防止进程被挂起目的的同时，显著降低 GPS 射频模块的耗电量：

# -*- coding: utf-8 -*-
import location
import time

def keep_alive_via_location(duration_seconds=3600):
    print("[Location] 启动后台定位保活通道...")
    # 设置精度为 1000 米，避免激活高耗电的高精 GPS 芯片
    location.start_updates()
    
    start_time = time.time()
    try:
        while time.time() - start_time < duration_seconds:
            loc = location.get_location()
            current_stamp = time.strftime("%H:%M:%S")
            print(f"[{current_stamp}] 后台存活正常，当前位置采样可用")
            time.sleep(10)
    finally:
        location.stop_updates()
        print("[Location] 定位保活已关闭")

if __name__ == '__main__':
    keep_alive_via_location(600)

四、方案三：原生临时后台任务扩展（短任务收尾）

如果你的 Python 任务并不需要 24 小时不间断运行，而只是在用户切出应用后需要额外的 30 秒到 3 分钟来完成未写完的日志、上传刚刚处理完毕的数据包或保存文件，盲目开启音频或位置常驻并不是最佳选择。iOS 原生提供了 beginBackgroundTaskWithName:expirationHandler: 接口。

通过 Pythonista 的 objc_util 桥接 UIApplication，可以申请一个临时的任务宽限期。在宽限期即将耗尽时，系统会触发回调函数，让程序有机会保存当前状态并安全退出，从而彻底规避 Watchdog 的直接强杀。

# -*- coding: utf-8 -*-
from objc_util import ObjCClass, ObjCBlock, c_void_p
import time

UIApplication = ObjCClass('UIApplication')

class TemporaryBackgroundTask:
    def __init__(self, name="PythonistaShortTask"):
        self.app = UIApplication.sharedApplication()
        self.task_name = name
        self.task_id = 0

    def __enter__(self):
        # 定义过期处理 Block，在系统强制收回时间前执行
        def expiration_handler():
            print("[SysAlert] 后台宽限期耗尽，立即清理资源并挂起！")
            self.app.endBackgroundTask_(self.task_id)
            self.task_id = 0

        block = ObjCBlock(expiration_handler, restype=None, argtypes=[])
        self.task_id = self.app.beginBackgroundTaskWithName_expirationHandler_(self.task_name, block)
        print(f"[Task] 已向系统成功申请后台扩展，TaskId: {self.task_id}")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        if self.task_id != 0:
            self.app.endBackgroundTask_(self.task_id)
            print(f"[Task] 任务执行完毕，主动归还后台配额 TaskId: {self.task_id}")
            self.task_id = 0

# 使用场景：耗时 1~2 分钟的数据同步
if __name__ == '__main__':
    with TemporaryBackgroundTask():
        print("切到其他 App，以下耗时循环依然能不受干扰地运行数分钟...")
        for i in range(12):
            print(f"正在进行核心数据写入步骤 {i+1}/12...")
            time.sleep(5)

五、方案四：使用 iOS 快捷指令（Shortcuts）自动化调度

很多开发者试图让 Pythonista 7×24 小时在后台待命，仅仅是为了实现“每天早晨 8 点抓取一次天气”或“每隔 1 小时检查一次网盘新文件”。在这类场景下，使用常驻保活不仅耗电量大，而且极易在系统经历高负荷时被 Jetsam 清理。更优雅、稳定的方案是采用事件驱动与外部调度架构。

Pythonista 完整支持 iOS URL Scheme。通过 pythonista3:// 协议，iOS 自带的“快捷指令”应用可以在特定时间、连接特定 Wi-Fi、收到特定通知或充电状态改变时，自动将 Pythonista 拉起到前台或静默执行指定脚本。

配置步骤如下：

• 打开 iOS “快捷指令” App，切换至“自动化”标签页，点击右上角加号新建个人自动化。
• 选择触发条件，例如“特定时间（每天 08:00）”或“当接入电源时”，取消勾选“运行前询问”并开启“运行时通知（可选）”。
• 在执行动作中，添加“打开 URL”动作，填入上述带有 action=run 的 Pythonista URL Scheme。
• 在 Python 脚本的末尾加入 import webbrowser; webbrowser.open('shortcuts://') 或配合返回上一级应用，从而在执行完毕后自动返回原界面或锁屏。

六、三大保活策略的综合对比与特性指标

为了让不同应用场景下的技术选型更加清晰，下表从多个维度对上述三种主要方案进行横向对照：

七、防御 Jetsam 强杀的关键内存优化准则

很多开发者在成功加入了音频保活后，发现脚本在运行 20 分钟到数小时后依然会突然消失。排查崩溃原因时，往往误以为是保活代码失效。实际上，这是触发了 iOS 的 Jetsam（系统内存物理清退机制）。

在 iOS 中，每个应用程序都有一个由系统根据机型运存（RAM）动态计算的“最大后台驻留内存高水位线（High Water Mark）”。即便处于音频播放状态，只要 Python 进程占用的内存达到警戒线（例如老款设备 150MB~200MB，新款设备 300MB~500MB），或者前台开启了相机或大型 3D 渲染应用，Jetsam 守护进程就会毫不犹豫地直接向 Pythonista 发送 SIGKILL。

为了保证保活脚本不被 Jetsam 清理，在编写 Python 长期运行脚本时必须严格遵守以下内存控制准则：

• 杜绝全局列表无限追加：记录日志或处理数据流时，严禁使用 all_logs.append(data) 在内存中持续累加。应当改为分块写入本地文件，或使用设定最大容量的 collections.deque(maxlen=500)。
• 强制执行垃圾回收：在循环执行密集计算、图片缩放（PIL.Image / ui.Image）或大量网络请求（requests）后，显式调用 gc.collect()，并使用 del 解除大对象的引用。
• 流式读写替代一次性加载：处理大文件传输或网络下载时，始终采用流式传输模式（stream=True），配合固定大小缓冲区逐步落盘，严禁通过 response.content 将几百兆二进制数据一次性读入 Python 字符串堆。
• 释放 Objective-C 包装对象：使用 objc_util 创建的原生对象如果不加以管理，可能引起 ARC 引用计数未能及时归零。在长时间循环中，应当适度将高频逻辑拆分进独立的局部作用域函数中执行，使局部变量能随函数调用栈及时退出。

# 内存防御实践范例：防范长驻脚本内存膨胀
import gc
import requests
from collections import deque

class MemorySafeWorker:
    def __init__(self):
        # 使用有界队列替代无界列表，避免内存持续上涨
        self.recent_metrics = deque(maxlen=200)

    def fetch_stream_data(self, url, save_path):
        # 1. 采用 stream 模式分块写入，内存峰值恒定在几 KB 以内
        with requests.get(url, stream=True, timeout=15) as r:
            r.raise_for_status()
            with open(save_path, 'wb') as f:
                for chunk in r.iter_content(chunk_size=8192):
                    if chunk:
                        f.write(chunk)
        
        # 2. 周期性主动释放垃圾对象
        gc.collect()

八、场景选型与落地决策流程

面对不同的实际任务需求，如何以最高效、低功耗且稳定的方式组织代码？可以依据以下决策路径来判断最匹配的解决方案：