Moonshine 项目 iOS 端 ONNX Runtime 最小化构建:静态库体积与安装成本的实测优化指南
Moonshine 项目 iOS 端 ONNX Runtime 最小化构建静态库体积与安装成本的实测优化指南【免费下载链接】moonshineVery low latency speech to text, intent recognition, and text to speech, for building voice agents and interfaces项目地址: https://gitcode.com/GitHub_Trending/moonshine3/moonshineMoonshine 的 iOS 端不再下载 ONNX Runtime 官方预编译 pod archive而是由scripts/build-ort-ios.sh从源码构建一个被裁剪到只含本项目算子的最小化静态库。本文以仓库中core/third-party/onnxruntime/lib/ios/README.md为核心结合构建脚本、测量脚本与相关文档完整讲解 iOS 静态库的构建方式、arm64 设备切片与模拟器 fat 切片的体积实测数据、以及静态库大小 ≠ 应用安装成本的正确衡量方法帮助你在自己工程中复现同样的构建与测量流程。为什么 iOS 的 ORT 库必须从源码构建仓库在core/third-party/onnxruntime/lib/ios/下只保留了arm64/与simulator/两个目录各自存放一个libonnxruntime.a。按照 lib/ios/README.md 的说明这两个静态库不是下载来的预编译产物而是由scripts/build-ort-ios.sh从源码构建并 vendor 进仓库的These are built from source byscripts/build-ort-ios.sh, not downloaded.它们替换掉了官方预编译 pod archivepod-archive-onnxruntime-mobile-c-1.23.2.zip。原 README 特别强调了一个约束不要把 pod archive 再放回该目录该目录之上的一切代码Moonshine 的转录、TTS、嵌入等所有模型加载逻辑都基于最小化构建的前提工作。那么最小化构建到底意味着什么scripts/build-ort-ios.sh的头部注释给出了精确的界定构建被限制在 core/third-party/onnxruntime/moonshine-required-operators.config 列出的算子集合内——这是scripts/generate-ort-op-config.py生成的全项目统一算子白名单与 Android、WebAssembly 等其他平台使用的是同一份配置文件头注释明确写着 Generated by scripts/generate-ort-op-config.py; do not edit by hand。这份配置文件共 269 行逐条列出了 Moonshine 能加载的所有模型Kokoro、Piper、ZipVoice、拼写模型、OOV G2P 等所需的算子。最小化构建的两个直接后果原 README 明确指出iOS 最小化构建带来两个与 Android 平台一致的后果分别由两份官方文档支撑1. 只加载 ORT 格式模型.ort见 docs/ort-only-models.md最小化构建根本没有编译进 ONNX 解析器所以.onnx文件在任何平台上都无法被读取。这统一了各平台行为——原来桌面端支持.onnx、移动端不支持导致开发机上能跑、手机或浏览器上却报 ORT 解析错误的割裂体验。现在所有平台统一拒绝.onnx转换命令为python scripts/convert-models-to-ort.py path/to/model.onnx.ort是自包含的所以原来依赖外部数据 sidecarmodel.onnx.data等的模型必须转换后再使用选项名如piper_onnx、oov_onnx_override保持不变只是接受的格式收窄了。2. 没有 CoreML execution provider见 docs/execution-providers.md这不是选择而是上游限制。ONNX Runtime 1.23 的 CoreML provider 会在GetCapability中无条件调用Graph::GetModel()而该方法在最小化构建中被#if !defined(ORT_MINIMAL_BUILD)编译掉位于 ORT 的include/onnxruntime/core/graph/graph.h--minimal_build extended仍然会定义ORT_MINIMAL_BUILD因此构建会报no member named GetModel in onnxruntime::Graph直接失败。ort_providers选项仍保留但cpu是任何已发布构建唯一可用的取值。构建脚本build-ort-ios.sh实战详解构建入口是 scripts/build-ort-ios.sh完整命令形如scripts/build-ort-ios.sh [force] [with-coreml] [device|simulator]各参数含义参数作用force即使库已存在也强制重建并重新 vendor强制重建会先清空对应 build 目录避免 ORTbuild.py只增不减 CMake 选项导致的陈旧缓存with-coreml尝试加入 CoreML见上预期编译失败用于验证后续 ORT 版本是否修复了GetModel问题no-coreml显式关闭 CoreML默认即关闭device只构建 arm64 设备切片simulator只构建 fatx86_64 arm64模拟器切片不传 slice默认同时构建 device 和 simulator环境变量变量默认值说明ORT_IOS_CONFIGRelease构建配置选择 Release 是因为 MinSizeRel 仅节省约 3% 库体积却损失了未量化的速度与 Android 的对比结论一致见脚本注释MOONSHINE_ORT_ROOT无ORT 源码 checkout 与 build 树所在目录IOS_DEPLOY_TARGET15.1最低部署版本必须与scripts/build-swift.sh中IOS_VERSION保持一致否则会出现库声称支持的版本高于实际链接版本、在旧系统设备上运行失败的问题关键构建流程来自脚本实现ort_require_op_config校验算子配置文件存在构建全程通过--include_ops_by_config传入moonshine-required-operators.config对每个 sysroot/arch 组合调用 ORT 的./build.sh核心参数包括--ios、--cmake_generator XcodeORT 明确拒绝 iOS 构建使用其他 generator、--build_apple_framework让 ORT 把各组件静态库合并成单一归档即我们需要的libonnxruntime.a来源、--apple_deploy_target与--skip_tests架构差异处理--osx_arch一次只能接受 arm64、arm64e、x86_64 中的单个架构所以模拟器 fat 库要分别构建 arm64 与 x86_64 两个切片后用lipo -create合并KleidiAI 处理ORT 1.23 在宿主机为 arm64 时会对 x86_64 目标也开启 KleidiAIaarch64-only导致 Apple Silicon 机器上的 x86_64 模拟器构建出现未定义的ArmKleidiAI符号因此脚本对非 arm64 架构自动追加--no_kleidiai构建完成后cp到对应目录并打印lipo -info校验切片信息。vendored 后CMake 侧通过 core/third-party/onnxruntime/find-ort-library-path.cmake 按 sysroot 选择库CMAKE_OSX_SYSROOT STREQUAL iphonesimulator时取lib/ios/simulator/libonnxruntime.a其余 iOS 场景取lib/ios/arm64/libonnxruntime.a——这正对应原 README 说的 ../find-ort-library-path.cmakeexpects。体积数字为什么.a大小不能代表应用安装成本原 README 给出了一张关键对比表arm64 设备切片单位 MB。注意 iOS 静态库是应用安装成本的糟糕代理指标链接器app linker会丢弃没有任何符号引用的 object file所以.a在磁盘上往往远大于它真正贡献给安装包的字节数。指标Pod archiveMinimal节省libonnxruntime.a36.618.118.5libmoonshine.a合并60.341.818.5Linked app binary45.030.614.4该二进制__TEXT31.122.88.3Linked app binary 这一行才是真正要紧的它就是scripts/measure-mobile-size.sh ios报告的数字脚本会链接一个引用 Moonshine C API 入口点的小型 app并以-dead_strip模拟真实应用的链接取舍然后测量结果。另有两个必须说明的测量口径表中两个 Moonshine 列是在说话人分离diarization模型仍编译进库内时测得的因此比今天的库高 8.2 MB——按 docs/diarization-models.md 的说明这两个模型pyannote community-1 的 segmentation 与 speaker-embedding已改为从 CDN 下载任何平台都因此省下 8.2 MBiOS 的 linked app binary 由 30.6 MB 降到22.4 MB每行的节省数值不受影响因为它是同一批都携带这些模型的两个构建之间的差值。也就是说当前仓库的 iOS 最小化构建的实际安装成本约为 22.4 MBarm64 设备切片而原 README 表格反映的是旧口径下的对比。用measure-mobile-size.sh复现实测scripts/measure-mobile-size.sh支持android/ios/all三个参数iOS 分支的核心做法对应原 README 中 links a small app against the xcframework with-dead_stripand measures the result 的描述静态库位置默认取language-bindings/swift/Moonshine.xcframework/ios-arm64/libmoonshine.a需先运行scripts/build-swift.sh也可用MOONSHINE_IOS_LIB指向其他libmoonshine.a——这正是做前后对比的方式用旧版 ONNX Runtime 在别处构建设备切片再测量该归档生成一个引用moonshine_load_transcriber_from_files、moonshine_create_tts_synthesizer_from_files、moonshine_create_embedding_model三个 C API 入口的main.c保证链接器保留转录、TTS、嵌入三条路径及其全部依赖见脚本内main.c模板用xcrun clang -target arm64-apple-ios15.1 -dead_strip ... -framework Foundation -framework CoreFoundation -framework Accelerate链接出可执行文件报告 linked binary 大小并用xcrun size -m切出__TEXT可执行代码 只读数据随 ORT 链接量增减而变化的正是这一部分与__DATA段大小。因此无论你如何调整 ORT 的构建方式都应该在改动前后各跑一次scripts/build-swift.sh scripts/measure-mobile-size.sh ios用真实链接结果说话而不是用libonnxruntime.a的磁盘大小做推断。脚本头部注释也明确说明了两平台的相反偏差Android 的.so整体打包、文件大小接近真实但 AAR 同时携带全部 ABI 而设备只下载一个iOS 的静态.a则因链接器裁剪而远大于其实际贡献。所以统一用真实链接一个二进制来度量 iOS用按 ABI 拆分来度量 Android。模拟器切片为什么是 fat 的原 README 最后一行解释了模拟器库的体积来源模拟器切片是 fat 库x86_64 arm64双架构所以仅仅因为这一点就比设备切片大。scripts/build-ort-ios.sh对 simulator 的处理是分别构建iphonesimulator/arm64与iphonesimulator/x86_64两个切片再lipo -create合并从而同时覆盖 Intel Mac 与 Apple Silicon Maclipo -info确认合并结果与原 pod archive 一致x86_64arm64这也正是find-ort-library-path.cmake所期望的形态。延伸这一结论的适用范围与注意事项改动模型必须重新生成算子配置最小化构建中配置里缺少的算子会在 session 创建时报错。每当模型发生变化就需要重新运行scripts/generate-ort-op-config.py更新 moonshine-required-operators.config否则新模型无法加载。CoreML 期望值管理对 iOS 上最终用户而言模型只跑 CPU execution provider。虽然ort_providers选项仍接受CoreML但任何已发布构建都不包含它请求时会得到明确报错指向docs/execution-providers.md而不是静默降级。8.2 MB 口径修正若引用本文或原 README 中的旧表格数字45.0 / 30.6 / 22.8 MB务必同时说明 diarization 模型已外移当前 arm64 设备切片的 linked app binary 为 22.4 MB。如果你需要在自己的应用中复现这套做法完整的查看路径是构建入口 scripts/build-ort-ios.sh、测量入口 scripts/measure-mobile-size.sh、库选择逻辑 core/third-party/onnxruntime/find-ort-library-path.cmake、算子白名单 core/third-party/onnxruntime/moonshine-required-operators.config以及两份行为约定文档 docs/ort-only-models.md 与 docs/execution-providers.md。【免费下载链接】moonshineVery low latency speech to text, intent recognition, and text to speech, for building voice agents and interfaces项目地址: https://gitcode.com/GitHub_Trending/moonshine3/moonshine创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

相关新闻

基于OpenCV的弱光图像增强算法实现与优化

基于OpenCV的弱光图像增强算法实现与优化

1. 项目背景与核心需求在计算机视觉和图像处理领域,弱光环境下的图像增强一直是个经典难题。无论是安防监控、医疗影像还是移动摄影,我们经常会遇到因光照不足导致的图像质量下降问题。传统解决方案往往面临细节丢失、噪声放大或色彩失真的困扰。这个项目…

2026/11/1 19:03:23 阅读更多 →
Pragmatic Drag and Drop 全解析:跨技术栈的底层拖放工具链

Pragmatic Drag and Drop 全解析:跨技术栈的底层拖放工具链

Pragmatic Drag and Drop 全解析:跨技术栈的底层拖放工具链 【免费下载链接】pragmatic-drag-and-drop Fast drag and drop for any experience on any tech stack 项目地址: https://gitcode.com/GitHub_Trending/pr/pragmatic-drag-and-drop 导读 Pragmat…

2026/11/1 18:50:58 阅读更多 →
如何用 multinode-demo 搭建本地单节点测试网并运行 bench-tps 压测?

如何用 multinode-demo 搭建本地单节点测试网并运行 bench-tps 压测?

如何用 multinode-demo 搭建本地单节点测试网并运行 bench-tps 压测? 【免费下载链接】solana Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces. 项目地址: https://gitcode.com/GitHub_Trending/so/solana 如果你需…

2026/11/1 19:03:31 阅读更多 →

最新新闻

Electron桌面应用开发实战:从环境搭建到打包发布全流程

Electron桌面应用开发实战:从环境搭建到打包发布全流程

做前端这些年,我大部分时间都在跟浏览器标签页打交道,直到第一次把桌面应用跑起来,才发现原来自己一直被限制在地址栏和刷新按钮围起来的框框里。Electron这个词,最开始是在某段时间频繁出现在同事的讨论里,一个用HTML…

2026/11/8 1:19:03 阅读更多 →
滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

简介:亚太天能T109滑盖智能锁产品说明书是一份PDF格式的官方技术文档,主要面向智能锁安装人员、终端用户及售后维护者,帮助快速掌握产品安装、配置与常见故障处理。全包仅1个PDF文件,大小4.37MB,内容结构清晰&#xff…

2026/11/8 14:17:55 阅读更多 →
PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

上个月我在调试一台高速AGV的驱动系统,整车要求空载跑到8m/s,电机转速已经拉到额定点,驱动器的输出电压也顶到了母线电压极限附近。再往上踩速度指令,转速纹丝不动,三相电流反而开始震荡。那会儿我的第一反应就是&…

2026/11/9 1:59:56 阅读更多 →
C++核心知识点:从内存管理到STL的实战指南

C++核心知识点:从内存管理到STL的实战指南

C 这门语言我前前后后折腾了十几年,用它写过嵌入式驱动、做过游戏服务端,也搭过基础组件库。每次看到新人一头扎进"C 核心知识点"这个搜索词,我其实挺感慨的——这门语言的难点从来不是语法多,而是知识点之间的耦合太深…

2026/11/8 1:38:41 阅读更多 →
T109滑盖智能锁怎么装?安装调试与故障排查全攻略

T109滑盖智能锁怎么装?安装调试与故障排查全攻略

简介:亚太天能T109滑盖智能锁产品说明书以PDF格式发布,适合智能锁用户、安装人员与售后维修人员阅读。内容围绕T109系列指纹密码刷卡锁展开,先介绍前面板、后面板、锁体、机械钥匙、电池盒盖等部件名称与功能,再给出完整安装步骤&…

2026/11/7 12:08:40 阅读更多 →
LLM知识降熵:从信息垄断到理解权下放

LLM知识降熵:从信息垄断到理解权下放

你有没有过这种经历:翻开源码注释、论文摘要或者一份专业报告,每个字都认识,连在一起却像天书。想找人聊聊,身边要么没人懂,要么懂的懒得跟你解释。后来我试着把同一段内容丢给一个大语言模型,几秒钟之后&a…

2026/11/8 1:23:14 阅读更多 →

日新闻

周新闻

月新闻