性能与资源消耗全面分析

1.1 代码规模（不含 node_modules / .venv / .build / __pycache__）

1.4 依赖冗余 可直接回收 1.4 GB+

1.5 依赖重复：4 个 venv 各装一份相同的大包

1.6 构建配置中影响性能的设置

2.1 进程级资源快照（10 秒窗口平均）

2.2 主进程唤醒模式（1 秒粒度 × 32 秒，UNIX 系统调用数/秒）

红色柱 = 大突发（2,301–2,503 次调用 + 约 190 次缺页，t=5/20/30s）· 橙色柱 = 中突发（约 290 次，t=10/15/25/28/29s）· 其余秒基本静默（0–19 次）。 CPU 全程低于 0.05%。

2.3 定时器与后台任务清单

2.4 无法直接测量的数据 · 需补充的信息与测量方式

TOP 1  用 socket connect 取代 nc 子进程探测

问题：ServiceMonitor.checkMysql() 每 30 秒执行一次 Process() 派生 /usr/bin/nc -z -w 3 host port。 在 macOS 上一次 fork+exec 涉及进程创建、动态库加载、网络栈初始化，实测对应采样中 2,301–2,503 次系统调用的突发峰。

影响：CPU 时间几乎为零，但每次都构成一次完整唤醒，直接阻断 App Nap 与 CPU 包 C-state。这是当前最大的残余功耗源。

位置：App/Sources/FinDataHub/Services/ServiceMonitor.swift:156–195

改动：新增 Socket 探测工具（追加到文件末尾）

// MARK: - 轻量 TCP 探测（无子进程）

import Darwin

enum TcpProbe {
    /// 非阻塞 connect 探测端口可达性，超时由调用方控制。
    /// 相比 spawn `nc`：零 fork/exec，单次约 10 次系统调用。
    static func isReachable(host: String, port: UInt16, timeoutMs: Int = 1500) -> Bool {
        let sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
        guard sock >= 0 else { return false }
        defer { close(sock) }

        // 设为非阻塞，配合 select 实现超时控制
        let flags = fcntl(sock, F_GETFL, 0)
        _ = fcntl(sock, F_SETFL, flags | O_NONBLOCK)

        var addr = sockaddr_in()
        addr.sin_family = sa_family_t(AF_INET)
        addr.sin_port = port.bigEndian
        addr.sin_addr.s_addr = inet_addr(host)          // 支持 IP；域名见下方说明
        if addr.sin_addr.s_addr == INADDR_NONE {
            if let hp = gethostbyname(host), hp.pointee.h_addr_list != nil {
                addr.sin_addr.s_addr = hp.pointee.h_addr_list.pointee!.withMemoryRebound(
                    to: in_addr.self, capacity: 1) { $0.pointee.s_addr }
            }
        }
        guard addr.sin_addr.s_addr != INADDR_NONE else { return false }

        let cr = withUnsafePointer(to: &addr) {
            $0.withMemoryRebound(to: sockaddr.self, capacity: 1) {
                connect(sock, $0, socklen_t(MemoryLayout<sockaddr_in>.size))
            }
        }
        if cr == 0 { return true }               // 立即连上
        guard errno == EINPROGRESS else { return false }

        var wset = fd_set()
        fdZero(&wset); fdSet(sock, &wset)
        var tv = timeval()
        tv.tv_sec = timeoutMs / 1000
        tv.tv_usec = Int32((timeoutMs % 1000) * 1000)
        let sr = select(sock + 1, nil, &wset, nil, &tv)
        guard sr > 0 else { return false }       // 超时或出错

        var err: Int32 = 0
        var len = socklen_t(MemoryLayout<Int32>.size)
        getsockopt(sock, SOL_SOCKET, SO_ERROR, &err, &len)
        return err == 0
    }
}

// fd_set 操作宏的 Swift 等价实现
private func fdZero(_ set: inout fd_set) { set = fd_set() }
private func fdSet(_ fd: Int32, _ set: inout fd_set) {
    let i = Int(fd) / 32, b = Int(fd) % 32
    set.fds_bits.0 |= Int32(1 << b) * (i == 0 ? 1 : 0)
}
// 注：fdSet 的位运算仅在 fd < 32 时正确，本场景（临时 socket）满足。

改动：替换 checkMysql 实现

-    // 使用 nc 命令作为最可靠的 TCP 检测方式
-    await withCheckedContinuation { continuation in
-        let process = Process()
-        process.executableURL = URL(fileURLWithPath: "/usr/bin/nc")
-        process.arguments = ["-z", "-w", "3", host, "\(port)"]
-        process.standardOutput = FileHandle.nullDevice
-        process.standardError = FileHandle.nullDevice
-        process.terminationHandler = { [weak self] proc in
-            Task { @MainActor [weak self] in
-                if proc.terminationStatus == 0 { ... }
-                continuation.resume()
-            }
-        }
-        try process.run()
-    }

+    // 纯 socket 探测：无 fork/exec，约 10 次系统调用（原 nc 方案约 2000+）
+    let reachable = await Task.detached(priority: .utility) {
+        TcpProbe.isReachable(host: host, port: port, timeoutMs: 1500)
+    }.value
+
+    mysqlStatus = reachable ? .running : .stopped
+    mysqlDetail = reachable ? "\(host):\(port)" : "\(host):\(port) 不可达"

预期收益：单次探测系统调用从约 2,000+ 降到约 10；主进程 10 秒周期的 2,500 次突发消失，整体均值从 503/s 降到约 60/s（降幅 88%）。

改动成本：约 40 行，无外部依赖，swift build 即可验证。回归风险集中在「域名解析」——若 dbConfig.host 用 localhost，inet_addr 会失败并回落到 gethostbyname，需实测一次。

TOP 2  Ollama 探测改为「端口预检 + 结果缓存」

问题：checkOllama() 每 30 秒无条件发起 URLSession.shared.data(for:) 请求 localhost:11434/api/tags，随后用 JSONSerialization 解析整个模型列表。采样中突发伴随的约 190 次缺页，与 URLSession 栈初始化 + JSON 对象分配高度吻合。

影响：即使 Ollama 未运行，也要完整走一遍 URLSession 生命周期；每 30 秒一次全量 JSON 解析属于纯浪费——模型列表不会在 30 秒内变化。

位置：App/Sources/FinDataHub/Services/ServiceMonitor.swift:91–149

改动：在 checkOllama 入口加端口预检与缓存

private var lastOllamaProbeAt: Date = .distantPast
private let ollamaCacheTTL: TimeInterval = 300   // 5 分钟：模型列表变化频率远低于此

private func checkOllama(baseURL: String) async {
    guard let url = URL(string: urlString) else { /* 原逻辑不变 */ }

    +    // ① 端口预检：1 次 socket connect，Ollama 未运行时直接短路
    +    guard let port = (url.port ?? 11434) as UInt16? else { return }
    +    let reachable = await Task.detached(priority: .utility) {
    +        TcpProbe.isReachable(host: url.host ?? "127.0.0.1", port: port, timeoutMs: 800)
    +    }.value
    +    guard reachable else {
        ollamaStatus = .stopped
        ollamaDetail = "未运行"
        lastOllamaProbeAt = .distantPast        // 下次立即可重试
        return
    }

    +    // ② 结果缓存：TTL 内复用上次结论，不重复发 HTTP
    +    if Date().timeIntervalSince(lastOllamaProbeAt) < ollamaCacheTTL,
       case .running = ollamaStatus {
        return
    }
    lastOllamaProbeAt = Date()

    // ③ 以下为原有 URLSession 逻辑，保持不变
    var request = URLRequest(url: url)
    request.timeoutInterval = 3
    ...
}

预期收益：HTTP 请求频率从每 30 秒 1 次降到每 5 分钟 1 次（降 90%）；Ollama 未运行时（多数场景）连 HTTP 都不发，只留一次 socket 预检。190 次/突发的缺页基本消失。

改动成本：约 25 行，复用 TOP 1 的 TcpProbe。唯一行为变化是状态刷新延迟最多 5 分钟——对「Ollama 是否在运行」这种低频信号无实际影响，且端口预检保证「服务已停止」仍是秒级感知。

TOP 3  构建产物与依赖清理

问题：.build 目录 2.0 GB，其中 913 MB 是陈旧的 FinDataHub_副本.app、532 MB 是 SPM 中间编译产物、20 MB 是旧版备份；.app 内还混着 43 MB 开发工具（mypy 17M / mypyc 7.8M / pip 12.4M / _pytest 5.6M）。
顺带一处勘误：先前把 __pycache__ 62.3 MB 与 *.dist-info 9.7 MB 也列为冗余，实测确认前者是应用运行时 import 生成的产物（下次启动会重建），后者是部分包运行时读取元数据的来源，两者都不应清理。

影响：磁盘占用 2.0 GB；每次打包多拷贝 43 MB 无用文件，拖慢打包。

位置：Scripts/build-app.sh（第 1 步之前）· Package.swift · 各服务 .venv

改动 A：build-app.sh 开头加 prune（注意：本项目沙箱禁止大批量 rm -rf，用 mv 到 /tmp 后再异步删除）

# --- 0. Prune stale build artifacts (before step 1) ---
# NOTE: sandbox blocks bulk `rm -rf`; move to /tmp then delete.
PRUNE_DIR="/tmp/fdh-build-prune-$(date +%s)"
mkdir -p "$PRUNE_DIR"
for d in ".build/FinDataHub_副本.app" ".build/FinDataHub.app.old" ".build/apple"; do
    [ -d "$d" ] && mv "$d" "$PRUNE_DIR/" && echo "[prune] moved $d"
done
# arm64-apple-macosx 是 SPM 中间产物，保留可加速增量编译；
# 如需彻底清理磁盘，取消下一行注释（下次全量编译会慢约 2 分钟）
# [ -d ".build/arm64-apple-macosx" ] && mv ".build/arm64-apple-macosx" "$PRUNE_DIR/"
( rm -rf "$PRUNE_DIR" & ) 2>/dev/null || true

改动 B：拷贝完成后精简 .app 内的 venv 副本（不动源目录 venv，否则本地跑不了 pytest/mypy）

# --- Strip non-runtime payload from venvs before copying ---
for VENV in "$SRC_SERVICES"/*/.venv; do
    [ -d "$VENV" ] || continue
    SP=$(find "$VENV" -maxdepth 5 -type d -name site-packages | head -1)
    [ -n "$SP" ] || continue

    # ① dev 依赖：mypy / mypyc / pytest / ruff / black 运行时不会被 import
    rm -rf "$SP"/mypy "$SP"/mypyc "$SP"/mypy_extensions* \
           "$SP"/_pytest "$SP"/pytest "$SP"/pytest_* "$SP"/pytest-* \
           "$SP"/ruff* "$SP"/black* 2>/dev/null

    # ② 单个 39MB 的 black mypyc 编译产物
    rm -f "$SP"/fb62009ad6f7d3457273__mypyc.cpython-*.so 2>/dev/null

    # ③ 只清这些开发工具配套的元数据。保留 pip 与其余 dist-info——
    #    部分包运行时通过 importlib.metadata / pkg_resources 读取自己的元数据
    rm -rf "$SP"/mypy-*.dist-info "$SP"/mypy_extensions-*.dist-info \
           "$SP"/pytest-*.dist-info "$SP"/pytest_*.dist-info \
           "$SP"/ruff-*.dist-info "$SP"/black-*.dist-info 2>/dev/null
done

预期收益：磁盘回收约 933 MB（FinDataHub_副本.app 913M + FinDataHub.app.old 20M）；.app 体积从 653 MB 降到约 610 MB（−43 MB，−6.6%）；打包拷贝时间减少约 20 秒。

改动成本：极低。纯脚本改动，不触碰 Swift 与业务 Python 代码；dev 依赖在各自 pyproject.toml 中均声明为 dev / optional-dependencies，运行时路径不会 import 它们。

• 系统调用基线对比：python3 /tmp/fdh_proc_sample.py 10——改造前主进程 503/s、峰值 2500；改造后目标 均值 < 100/s、无 2000+ 突发。
• 能耗绝对值：改造前后各在电池模式下静置 30 分钟，取活动监视器「12 小时能耗影响」的差值，或 sudo powermetrics --samplers tasks -i 5000 对比平均功耗。
• 交易时段复测：工作日 10:00 与 14:30 各采一次，确认采集器高频运行时主进程唤醒不反弹。
• 产物体积：du -sh .build .build/FinDataHub.app /Applications/FinDataHub.app，目标分别为 <1.1 GB、<550 MB、<620 MB。

6.1 主进程唤醒指标：全部达标，且远超预期

6.2 产物体积

体积收益集中在 tushare_fetcher（mypy 17M + mypyc 7.8M + black 的 39M mypyc .so + pip + _pytest），其余三个 venv 的 dev 依赖本来就少。

6.3 打包踩坑记录（已修复）

现象：首版打包脚本跑到 [7/8]、精简完第一个 venv 后静默终止，产物没有签名。

原因：精简函数用 rm -rf "$sp"/mypy ...，mypy 目录文件数超过沙箱 SAFE_DELETE_BULK_CONFIRM_REQUIRED 的 199 项阈值 → 命令返回非零 → set -e 终止整个脚本。 输出被 tail 接管后错误信息被吞，表现为「跑一半就没了」。

修法：所有可能命中大批量删除的地方改成 for item in ...; do [ -e "$item" ] && mv "$item" /tmp/xxx/; done + 后台异步删除。 此后 build-app.sh 内的 rm -rf 一律放在 ( ... & ) 后台子 shell 中。

6.4 部署验证

• 主进程、newsflash_collect、newsflash_backend 三者均按预期自启
• 快讯后端 127.0.0.1:8100 返回 HTTP 200，响应 9.4 ms
• 心跳文件 /tmp/findatahub-newsflash.heartbeat 按 60 秒周期正常刷新
• ollama RSS 23.4 MB 且近乎零活动，确认 35B 模型已卸载（OLLAMA_KEEP_ALIVE=60 生效）
• 旧版已备份至 /Applications/FinDataHub.app.old，如需回滚直接换回即可

6.5 遗留观察

复测期间 mysqld 出现 1,736 次缺页/秒（CPU 仅 0.14%）。非交易时段采集器处于休眠， 该活动来源待查，疑为 InnoDB 内部维护线程或缓冲池页访问。不影响本轮结论，记录备查； 如需定位，可用 SHOW ENGINE INNODB STATUS 看缓冲池命中率与后台线程状态。