Shiply(shiply.tds.qq.com)是面向端的全场景发布运营平台，作为腾讯端服务联盟(tds-union.qq.com)的重要成员，提供配置与开关发布、资源发布、热修复、应用内升级、市场发布、应用内测等服务，帮助业务快速、安全地进行客户端功能迭代和上线。

想让产品团队像真实用户一样深度体验自家产品？Shiply应用内测能力，助您分钟级启动高效Dogfooding，粉碎内测分发壁垒！

Eating your own Dogfood（“吃你自家的狗粮”，亦略称为Dogfooding）是一句英语俚语，常用于描述公司（尤指软件公司）使用自己生产的产品这一情况。

这句俚语可能最早是于1988年开始使用的。当时微软公司的高级主管保罗·马瑞兹曾写过一封题为“Eating our own Dogfood”（吃我们自家的狗粮）的邮件提出“提高内部使用自家产品比重”的挑战。而从此以后这一俚语就传播开来了。

践行 Dogfooding 不仅仅是简单地“测试”产品，而是一种将用户视角深度融入团队文化和开发流程的实践。Dogfooding 超越了单纯的测试范畴。它要求产品负责人、产品经理、设计师、开发者，乃至市场、法务、行政、财务等代表‘小白用户’的同事，都成为产品试用的主力军。

它要求我们像真实用户一样去体验，在真实场景中发现那些开发、测试环境里难以复现的 Bug、别扭的交互和模糊的价值主张。

Dogfooding 在业界有非常多的成功案例，从计算机软件、移动互联网应用到今天人工智能应用，Dogfooding 的理念长盛不衰。

• 微软：作为创造了 “吃我们自己的狗粮” 这句话的公司，几乎每款微软产品都经历了Dogfooding，并且这个过程已经融入了他们的产品发布文化中。例如，微软 Outlook 的新版本就是通过Dogfooding来检验的。

• 亚马逊：其著名的“API授权”规定，所有团队的服务接口必须设计成可以先提供给内部其他团队使用。这意味着亚马逊官网的很多功能，其实是通过调用内部API实现的，自身就是最大的用户。

• Slack/Figma：全体员工的工作沟通和设计协作完全依赖于自己的产品，是 Dogfooding 的典范。

• Lyft：这款叫车应用长期以来一直以友好服务、深切关怀用户而闻名。Lyft 要求员工（包括高管）每月至少以 Lyft 司机的身份开车 4 小时。这让他们能更好地理解载客体验，发现司机的需求和痛点，并检测性能问题。

• Facebook：2012 年，Facebook Android 应用缓慢且漏洞百出，还缺少许多网页版功能。但，他们的 iOS 应用因其性能和整体体验而备受赞誉。Facebook 鼓励其员工（大多是 iPhone 用户）使用 Android 手机体验应用。此外，他们还在内部屏蔽了自己的网站 ，迫使员工使用 Facebook 的移动版本，真正体会到用户的痛点。最终，Facebook 的 Android 应用在性能和整体质量方面经历了翻天覆地的变化。

一、为什么需要 Dogfooding​

在开始行动之前，让团队全体成员理解其重要性至关重要。Dogfooding 的核心价值在于：

1.  ​​发现真实问题：​​ 内部员工是产品的第一批用户，他们能在真实工作场景中发现那些在测试环境中难以复现的 Bug、糟糕的用户体验和反直觉的设计。

2.  ​​增强同理心：​​ 当开发者自己也成为用户时，他们会更深刻地理解用户的挫败感和需求，从而在设计和开发时自然地将用户体验放在首位。

3.  ​​提升产品质量与稳定性：​​ 在功能上线前就进行大规模内部试用，能有效拦截问题，提高最终发布产品的质量。

4.  ​​验证产品价值：​​ 如果自己的员工都不愿意使用自家产品，又如何能说服外部用户使用呢？Dogfooding 是产品价值最直接的试金石。

5.  ​​培养主人翁意识：​​ 当员工每天使用自己打造的产品时，会自然而然地产生自豪感和责任感，主动思考如何让产品变得更好。

二、  谁应该参与 Dogfooding​

• 开发者： 关注性能、稳定性、技术细节。他们会遇到一些非常隐蔽的Bug。

• 设计师： 关注交互流程、视觉一致性、易用性。他们会敏锐地发现不符合直觉的设计。

• 产品经理：关注功能是否解决了目标问题，工作流是否顺畅，价值主张是否清晰。

• 非技术岗位（如市场、财务）：他们是“小白用户”的最佳代表。他们的困惑往往最能代表真实新用户的困惑。

Dogfooding 的场景​

• 内部试用：在小范围组织内快速试用新功能，验证稳定性、收集反馈

• 跨部门评审：产品、运营、市场与法务均可便捷安装体验，协同更高效

• 外包协同：权限与有效期可控，既保障交付效率又确保企业安全

三、如何落地 Dogfooding​

然而，将 Dogfooding 从理念变为日常实践，尤其在涉及客户端应用（App）时，常常面临技术和管理上的“拦路虎”：

• ​​分发效率低、流程繁琐：​​ 通过IM传包？iOS、Harmony安装不上！开启 iOA 访问内网、安装蓝盾、在流水线列表中找构建制品安装？繁琐的过程和权限申请，足以劝退非技术人员！

• ​​版本管理混乱：​​ “你装的是哪个版本？” 旧方案缺乏版本控制，测试者易装错包，反馈信息无法对齐，问题排查效率低下。

• UDID 收集与签名噩梦：​​ iOS、Harmony 真机测试需提前收集设备 UDID、手动生成 Profile 文件、反复打包。流程复杂耗时，极易出错，是扩大测试范围的巨大障碍。

• ​​权限与安全控制不足：​​ 测试包被随意外泄、新功能提前曝光风险高。缺乏有效的访问控制和下载追踪。

• ​​缺乏数据洞察：​​ “谁下载了？” “谁真的测试了？” “哪个版本反馈最多？” 没有数据支撑，难以衡量 Dogfooding 效果和推动改进。

• ​​非技术成员参与门槛高：​​ 产品、运营、市场、法务等非技术同事是宝贵的“小白用户”视角来源，但复杂的安装流程常将他们拒之门外。

这些痛点，直接阻碍了 Dogfooding 的广泛、深入和持续开展，让“吃狗粮”变得困难重重。​

四、Shiply 应用内测：助力 Dogfooding 分钟级落地！​

​​别担心！Shiply 应用内测平台将一个原本手动、零散、易出错、低效的内测分发流程，转变为一个标准化、集中化、自动化、高效协同的流程。让 Dogfooding 在数分钟内轻松启动并高效运行！

4.1 为什么选择 Shiply​

Shiply 专为面向开发、测试、IT、产品与业务团队的「一站式内测分发」平台

• 全平台覆盖：同时支持 iOS、HarmonyOS、Android 三大平台，一套方案解决所有端的内测需求

• 极简接入，分钟级落地：

  • 无需接入 SDK！无需对接流水线插件（可选）！

  • 只需在 Shiply 平台上传安装包/直接流水线选包，系统自动生成下载页。

  • 测试者扫码即可安装，告别繁琐步骤。

• ​​企业级安全保障，严防泄露：

  • 权限控制：支持密码安装、按组织架构授权访问（白名单+邮箱域）。

  • 下载有效期：链接可设置长期有效或自定义时间段，灵活控制安全边界。

  • 一次性短时链接：点击“立即安装”生成一次性时效token链接（默认5分钟内限1次下载），过期/超次自动失效。

• 内测记录：自动记录员工参与内测情况（现状），能够进行排名、设置激励等手动持续活跃 Dogfooding 文化（规划）

• 版本管理，告别混乱：​​

  • ​​统一版本库：​​ 清晰管理所有历史版本。

  • ​​自动更新提醒：​​ 新版本上传后，自动通知测试者。

4.2 如何使用 Shiply 应用内测​

一步开启内测分发​

无需接入 SDK、无需对接流水线插件，仅需上传安装包一个步骤即可开启内测分发！

邀请内测​

通过应用内测列表 -> 邀请测试 -> 新增测试用户，可以邀请用户下载内测包。

邀请内测用户后（无需用户同意），平台向用户推送内测版本链接。

管理员发布新的内测版本时，内测用户会收到版本更新通知，快速安装新的内测版本

聪明的下载页​

• 多端合一下载页：任意一个平台的下载页均可自动识别，展示对应最新安装包

• 安装权限验证：支持密码安装、按组织授权安装，严格控制公司内访问权限。

• 下载有效期：长期有效或自定义时间段，灵活控制曝光与安全边界。

数据可视与可控​

• 统计分析：按时间范围查看下载量增势，支持省份维度统计

• 内测记录：区分「仅浏览/已下载」状态，串联用户行为与版本效果

• 证书有效期：在版本详情中提醒证书状态，规避到期风险

五、  常见问题简答​

Q：是否需要接入 SDK？

A：不需要。上传安装包即可使用内测分发与下载页能力。支持哪些包类型？

Q：是否支持流水线传包？

A：支持流水线上传，需先完成流水线授权。

Q：是否支持反馈收集？

A：Shiply 专注于安装包的分发，公司内已有多款反馈收集平台可供接入

六、  总结​

践行 Dogfooding 的本质，是建立一种深度的“产品同理心”文化。它要求团队从领导者到每一位成员，都真诚地将自己置于用户的位置，通过亲身体验驱动产品向更稳定、更易用、更有价值的方向迭代。这不仅仅是一个测试环节，更是一种产品哲学和团队凝聚力的体现。

然而，文化的落地离不开高效工具的支撑。传统内测流程的痛点，正是阻碍 Dogfooding 广泛、深入开展的现实壁垒。​​Shiply 应用内测平台​​，正是为了粉碎这些壁垒而生。它通过​​极简的分发、严格的安全控制、灵活的版本管理和清晰的数据洞察​​，将 Dogfooding 的启动成本降至最低，执行效率提到最高。

选择 Shiply，意味着：

• ​​降低参与门槛：​​ 让包括非技术同事在内的所有相关方都能轻松成为“狗粮品尝官”，获得更丰富的用户视角。

• ​​提升反馈效率：​​ 确保反馈基于正确版本，加速问题定位与修复闭环。

• ​​保障安全可控：​​ 在开放协作的同时，牢牢守住企业资产和敏感信息的边界。

• ​​量化实践效果：​​ 通过数据清晰了解 Dogfooding 的覆盖面和参与度，持续优化流程。

​​立即访问 Shiply (shiply.tds.qq.com)，上传你的安装包，开启高效、安全的 Dogfooding 之旅！让“吃自己的狗粮”不再是一件麻烦事，一旦成功，你的产品团队将拥有无与伦比的洞察力和改进动力。

Unity 应用更新面临的几个问题​

使用 Unity 引擎的团队——无论是游戏开发者还是构建 3D 交互应用的团队——普遍会遇到以下困境：

场景一：紧急 Bug 修复

线上突发崩溃或渲染异常，运营催得很急，研发排查出来只是一个小问题，但修完之后还得走一遍打包、提审、审核、上架的流程，结果真正上线的时候往往已经过去一两周。这种节奏对游戏而言是留存损失，对电商3D展示或工业可视化应用而言则是直接影响交易转化或生产决策。

场景二：包体膨胀

随着3D资产精度提升、材质贴图增加，包体也越来越大，500MB 这种体量并不少见，但应用商店的数据又很现实：包体一旦超过 100MB，下载转化率就会明显下滑，超过 200MB 之后很多用户干脆就不下载了，这对游戏买量、电商App获客、或企业内部分发都是实质性损耗。

场景三：版本碎片化与多场景管理

用户分散在不同版本，运维兼容成本高。更复杂的是，很多团队需要在同一个App中承载多个3D场景（如电商平台的"虚拟试鞋+3D展厅+AR摆放"），传统方式只能全部打包进首包，或引导用户跳转外部下载，体验割裂。

场景四：动态内容运营

节日营销活动、季度新品3D展示、工业数字孪生的实时数据看板——这些内容需要频繁更新，但受限于发版周期，往往内容上线时已错过最佳时机。

这些问题的根源在于：传统模式下，Unity内容和安装包强耦合，一旦内容变了就只能重新发版。Shiply Android Unity 插件化解决方案，正是为了解耦"应用框架"与"实时内容"而生。

Shiply插件化是什么？​

核心理念： 将 Unity 内容拆分为"可动态下发的插件模块"，宿主App仅保留基础框架（30-50MB），真正的3D内容按需下载、热更新时直接替换插件，彻底摆脱应用商店发版依赖。

核心能力一览：

对业务的实际价值：

1. 首包极致瘦身，降低获客门槛

宿主仅保留基础框架，3D内容按需下载。应用商店展示轻量级App，用户下载意愿显著提升——这对游戏买量、电商App拉新、企业应用内部分发均适用。

2. 实时内容交付，抓住运营窗口

线上问题修复或营销内容更新，插件下发后10分钟内全网生效。不再需要等待审核窗口，节日营销、热点运营可即时上线。

3. 科学灰度与风险控制

同一版本下按地域、用户群、设备性能下发不同内容包，数据不理想时秒级回滚。对高客单价的3D电商展示或工业可视化应用尤为重要。

4. 单一应用承载多元3D场景

主场景常驻，活动展厅、新品预览、培训模块、数据可视化面板按需加载，用完即清。实现"一个App，无限3D内容"。

如何让 Unity 应用"插件化"​

整体架构图：

主要技术点：

1.字节码转换（Transform）

Android 要求 Activity 和 Service 必须在 Manifest 里注册，但插件是动态下发的，没法提前写死，所以在编译期会把插件里的 Activity 自动替换成 ShadowActivity，由宿主壳 Activity 代理执行，这样 Unity 工程本身几乎不用改。

2.组件代理（Proxy）

UnityPlayerActivity 需要正确接收触控、按键、横竖屏切换、配置变化等事件，因此宿主提供代理 Activity，把系统事件透传给插件中的 Activity，保证 Unity 的交互逻辑不被破坏。

3.ClassLoader 隔离

宿主和插件依赖的 SDK 版本往往不一致，尤其是广告、支付、统计等库，直接共用会造成冲突，所以每个插件都有独立 ClassLoader，做到互不影响，多游戏共存也更安全。

4.Unity 适配层

Unity 在启动时会校验 libunity.so 的完整性和路径，插件化后路径变化会导致启动失败，因此在 Native 层做了适配，让 Unity 认为自己仍然运行在正常环境中，支持 Unity 2019–2022+，支持 IL2CPP，不需要改 Unity 源码。

与 Lua 动态化方案的对比​

xLua、ToLua 这些 Lua 热更新框架也能实现热更新，为什么要选择 Shiply 插件化？

Lua 的思路是脚本层动态化，Shiply 的思路是整个 Unity 运行时动态化，这两条路线解决的不是同一个问题，所以并不是互相替代关系。

典型场景对比：

场景一：修复 C# 核心 Bug

• Lua 方案： Bug 在 C# 层，Lua 无法修改，必须发版。等待 7-15 天审核。
• Shiply 方案： 直接修改 C# 代码，打包新插件，10 分钟热更全网生效。

场景二：新增3D内容模块

• Lua 方案： 如果关卡逻辑涉及 C# 代码，需要拆分为"C# 框架 + Lua 脚本"，开发复杂度翻倍。
• Shiply 方案： 正常开发，整个关卡打包为插件下发。

场景三：接入新 SDK（如新的广告 SDK）

• Lua 方案： SDK 是 Native/Java 代码，需要编写 Lua 绑定层，工作量大。
• Shiply 方案： 正常接入 SDK，随插件一起下发。

场景四：首包瘦身

• Lua 方案： 无法实现。Lua 虚拟机和 C# 核心代码仍在首包中。
• Shiply 方案： 首包仅含宿主框架（30-50MB），游戏、3D内容全部动态下载。

Shiply 插件化典型应用场景​

场景一：游戏领域

活动副本动态上线： 节日活动插件按需下发，结束后自动清理，首包保持100MB内，下载转化率显著提升。

多游戏聚合平台： 发行商将多款Unity游戏整合至单一宿主App，点击即玩，账号、支付、数据统一管理。

场景二：3D电商与零售

虚拟试衣/试鞋动态上新： 鞋类电商可在不更新App的情况下，每周上线新款3D鞋模；服装电商可在换季时动态更新虚拟试衣素材包，用户无需重新下载App即可体验新品。

3D家居展厅： 家具App可按"客厅/卧室/书房"分场景下发，或根据用户浏览偏好动态加载特定风格展厅，降低首包同时提升个性化体验。

场景三：工业可视化与数字孪生

设备数字孪生动态加载： 工厂管理App可根据工程师权限或当前任务，动态加载特定设备的3D孪生模型与实时数据面板，无需一次性打包全厂设备数据。

培训仿真模块按需分发： 企业培训App可按岗位（操作员/维修工/管理员）下发不同的3D仿真训练模块，降低初始安装包体，支持培训内容的快速迭代。

场景四：教育与文化

虚拟实验室： 教育类App可按学科（物理/化学/生物）或按实验单元动态加载3D实验场景，支持教学内容的持续更新。

博物馆/展览数字化： 文化App可在特展期间动态上线3D展厅，展期结束后自动清理，实现"常设展+特展"的灵活运营模式。

场景五：工具与金融

运营小游戏： 金融或工具类App在节日活动期间，无需跳转应用商店即可上线Unity互动游戏，活动结束快速下线，不影响主应用体积。

技术亮点回顾​

结语​

Shiply 插件化解决的是 "Unity实时内容如何被动态交付" 的根本问题，而非仅限于脚本层的热更新。无论是游戏内容的快速迭代，还是3D电商、工业可视化、教育培训等场景的灵活运营，该方案均能提供：

• 更小的获客包体（提升下载转化）
• 更快的交付速度（抓住运营窗口）
• 更灵活的场景管理（单一应用多元内容）
• 更低的风险控制成本（灰度发布与秒级回滚）

如果您正在寻找 Unity 应用的热更新解决方案，或希望将多个3D场景整合至单一App实现统一运营，欢迎了解试用 腾讯 Shiply 插件化方案，或微信扫码联系技术顾问获取针对性架构建议。更多产品资讯与解决方案，请访问 TDS腾讯端服务。

Shiply（https://shiply.tds.qq.com/）是面向端的一站式发布平台，作为腾讯端服务联盟（https://tds.qq.com）的重要成员，提供配置与开关发布、资源发布、RN热更新、Flutter动态化、Android插件化框架、热修复、应用内升级、市场发布、应用内测等服务，帮助业务快速、安全地进行客户端功能迭代和上线。

前言：RN 动态化的潜力与现实挑战​

作为常用跨平台开发框架，React Native（RN）凭借 “一次开发、多端运行” 的特性，大幅提升了应用迭代效率，成为众多团队加速业务创新的首选。RN动态化更新是RN框架的核心优势，理论上可以快速发布RN编译后产物，实现代码与资源的快速迭代，让业务能更灵活地响应市场需求。

但在实际落地中，RN 动态化却面临多重挑战：

• 发布效率受限于更新包体积与灰度能力，紧急修复仍可能因传输慢、覆盖难导致响应滞后；

• 完整包更新消耗用户流量与企业带宽，既影响用户体验，也推高运营成本；

• 风险管控薄弱，更新异常时回滚困难，易引发用户投诉；

• 全球化场景下，数据跨境传输需符合 GDPR、CCPA 等法规，公有云服务可能存在合规隐患；

• 依赖第三方工具时，服务停服（如 CodePush 终止运营）可能直接中断业务迭代。

针对这些核心问题，常规的移动研发平台（如：Firebase、mPaaS、EMAS），仅提供通用的基础发布能力，较难满足业务复杂场景的需求。腾讯 Shiply 作为专业的移动研发平台，除提供通用的配置、资源发布管理外，还针对各种框架的动态产物发布，提供专有的发布管理服务和一站式的解决方案，帮助业务快速迭代、实时更新。

腾讯 Shiply ReactNative 热更新方案就是其中之一，它提供了一套兼顾效率、风险、成本、与合规的动态化管理体系。

本文将从 “降低更新成本、强化风险管控、满足合规要求、保障服务可持续性” 四个维度，解析腾讯 Shiply 如何助力团队更高效地实现 RN 应用迭代。

一、降低更新成本：优化流量与用户体验​

当前痛点​

传统 RN 动态更新常依赖完整包推送，即使仅修改少量代码或资源，用户仍需下载数 MB 的完整更新包。这不仅消耗用户流量（尤其移动网络环境下），降低用户更新意愿，也会因频繁传输大文件增加企业 CDN 带宽成本，制约迭代频率。

Shiply 优化方案

• 智能差量更新：Shiply 采用智能差量算法，每次只需推送代码或资源的变化部分，更新包体积显著减小。

• 无感静默更新：Shiply 支持后台静默下载差量更新包，用户在无感知状态下完成更新，无需主动操作确认，避免了因流量顾虑导致的更新受阻。

• 提升迭代频率与效果：得益于低成本的更新方式，某业务成功将周迭代次数提升至 3-4 次，更好的用户体验也带动了 DAU 的正向增长。

核心价值​

Shiply 通过差量技术有效控制了更新成本（用户流量和企业带宽），并使高频次、小颗粒度的迭代成为可能，提升应用迭代效率和用户体验。

二、增强风险管控：保障发布过程安全可靠​

常见问题​

传统更新机制下，往往是全量更新，如果更新包出现问题，回滚操作通常需要重新打包提交审核或人工干预通知，流程长且用户影响面可能扩大。

Shiply 安全保障措施​

• 精细化条件圈选及灰度策略：可按用户标签（如地域、设备、系统版本等）灵活圈定灰度范围，支持从少量用户（如5%）逐步扩大到50%乃至全量用户的灰度发布流程，控制影响面。

• 自动化熔断机制：借助Bugly平台实时监控更新后用户设备的关键指标（如异常率、性能指标）。一旦异常率超过预设阈值（如故障率>3%），系统自动暂停该版本更新推送，并向责任人发送告警。

• 快速回滚能力：出现问题时，可一键回滚至稳定版本，保证绝大多数用户的服务连续性。例如，曾有业务在90天内成功执行了3次回滚操作，均未引发负面舆情。

核心价值​

Shiply 提供了精细化的灰度策略、自动化的风险监控与熔断能力、以及快速的回滚机制，显著降低了更新过程的风险，保障业务稳定性。

三、满足合规要求：安全部署全球业务​

合规挑战​

GDPR、CCPA 等法规对用户数据处理（尤其是跨境传输）提出了严格要求。使用公有云热更新服务时，若数据流向不明确，可能触及合规风险，潜在影响包括罚款和业务受限。

Shiply 解决之道

• 通过严格安全审计：解决方案设计遵循安全最佳实践，核心服务通过腾讯内部专业法务团队审计，满足主流数据保护法规（GDPR/CCPA）要求。

• 支持海外独立部署：核心组件和数据可部署在海外，确保用户数据在海外流转，避免数据跨境传输风险。

• 实践验证：某消费电子头部客户成功使用 Shiply 海外部署方案，在海外多个区域长期稳定运行，12个月内未发生合规事故。

核心价值​

Shiply 提供符合国际安全合规标准的解决方案，特别是通过海外独立部署选项，帮助企业在满足全球各地数据主权法规要求的前提下安全开展热更新。

四、确保服务持续性：腾讯自研，稳定保障​

背景考量​

依赖第三方技术栈存在不可控风险（例如25年3月份，热更新服务 CodePush 停运事件曾导致用户项目受到影响）。服务稳定性和长期支持是企业技术选型的重要维度。

Shiply 的优势​

• 强大的技术投入：由腾讯专业团队持续研发维护，拥有多年技术积累。

• 腾讯内部大规模验证：Shiply 核心技术已被广泛应用于腾讯内部多个亿级用户 App（如手机QQ、QQ浏览器、腾讯新闻、腾讯视频等）的动态更新需求，经历过复杂场景和高并发流量的检验。

• 长期支持承诺：作为腾讯自研、自用的核心技术方案，Shiply 承诺提供长期稳定的支持和技术迭代保障。

核心价值​

选择 Shiply 意味着选择了腾讯成熟稳定、持续迭代、有长期支持保障的 RN 热更新技术方案，降低了不可控风险。

五、横向对比：为什么 Shiply 是 CodePush 停服后的较好替代方案？​

当微软 AppCenter 终止服务导致 CodePush 停运，开发者面临两难：自建高成本运维 or 寻找可靠替代。

以下从企业核心关注维度对比 Shiply 与主流方案：

Shiply RN 热更新不仅支持 CodePush 的“分钟级热更新”能力，更通过合规闭环设计与腾讯生态联动（Bugly监控）实现超越，并且使用简单，业务方接入成本低。

六、探索新范式：更细粒度的功能交付与管理​

当前局限​

传统的应用版本更新通常包含多个功能或修复，耦合度高，试错成本大，不便于快速调整单个特性。

结合Shiply 的探索方向​

• 功能级灰度与 A/B 测试：Shiply 支持将新功能拆分为独立模块进行发布和测试。如效果不佳，可快速回滚该功能，不影响主应用；效果良好则可及时全量，无需等待版本审核周期。

• 按需精准更新：结合极小的差量包和用户画像，理论上可针对特定用户群体定向推送特定功能更新或实验。

• 数据驱动的决策闭环：Shiply支持跟Bugly打通，监控 Crash 率等关键数据，支持设置策略（如异常率阈值自动触发熔断或回滚），形成更智能的发布决策闭环。

核心价值​

Shiply 不局限于传统的修复更新，提供了支撑更灵活、更精细化的功能管理和实验发布能力，有助于提升应用迭代效率和效果。

结语

高效的应用迭代能力是企业竞争力的关键，而满足合规要求则是业务拓展的基石。腾讯 Shiply RN 热更新解决方案，通过创新的差量技术、智能风险管控体系、合规的数据部署选项以及腾讯体系的技术与资源保障，有效融合了效率与安全合规的需求，为企业应对快速变化的市场挑战提供有力支持。

如果您的业务使用了React Native框架，正在面临应用发布效率瓶颈、热更新合规要求、更新成本考量或对服务持续性有顾虑，欢迎了解试用腾讯Shiply RN 热更新服务，或者直接联系 Shiply 客户经理 进行咨询，也可以前往 TDS 腾讯端服务获取更多产品资讯与解决方案。

Shiply（https://shiply.tds.qq.com/）是面向端的一站式发布平台，作为腾讯端服务联盟（https://tds.qq.com）的重要成员，提供配置与开关发布、资源发布、RN热更新、Flutter动态化、热修复、应用内升级、市场发布、应用内测等服务，帮助业务快速、安全地进行客户端功能迭代和上线。

导语：Shiply是腾讯端服务（Tencent Device-oriented Service）下的一站式客户端发布平台（支持配置开关、动态资源、热修复、应用升级、应用市场等发布能力）。平台通过多年积累的发布经验，并结合业务发展的需求，逐步将发布规范化从专项、表象、问题驱动的方式转变为工具化、系统化的落地与实践。Shiply 和 Bugly 在产品和技术上持续探索全面的监控止损体系，建立线上发布的安全防线，为业务的每次安全发布保驾护航。

一、  背景​

随着 DevOps 等持续交付范式的不断发展，热发布（包括远程配置下发、离线资源下发等能力）已成为   持续交付的关键工具。在电商、短视频、本地生活、信息流等多种业务场景中，热发布发挥着至关重要的运营作用。

传统的应用程序发布（冷发布）通常涉及多个团队的协作，是一种高压力、高风险的活动，因为一次发布会包含大量的变更。为了减少这种大规模变更带来的风险，越来越多团队转向 DevOps 进行更敏捷的持续交付。DevOps 也意味着开发人员和运维人员的界限模糊，开发人员对生产环境的控制需求增加，在客户端上，这主要通过远程配置、离线资源（热发布）等发布管理系统来实现。

例如：开发人员可通过特性开关进行灰度（分阶段发布），并根据 A/B 测试等指标观察结果，以决定是否全面推广新特性。若不达标，可关闭特性并在后续迭代中进行优化或下线。

然而，热发布在软件系统中的广泛应用也容易导致发布失误，从而引发运营事故，这样的例子屡见不鲜，例如：

从以上案例可以看出热发布失误不仅会影响软件的稳定性，更有可能造成产品口碑下滑导致用户无形流失。

二、发布存在哪些风险​

冷发布（程序包的发布）有隐私合规、稳定性、性能等风险，发布过程中对应的检测、审核、监控机制也都相对完善，在各个环节都有专人跟进，影响可控，真正造成事故的概率是很小的。

而热发布常因为缺少对风险识别的经验，缺乏对应的流程、规范，时而导致事故产生，常见风险如下：

我们可以从一个复盘的改进措施中学习安全发布知识：

• 改进措施

  1、增加XX服务白名单生成结果的校验及告警拦截能力；

  2、增加XX服务白名单更新的灰度验证逻辑，提前发现异常；

  3、增加XX服务白名单的快速恢复能力；

  4、加强产品侧的联动恢复能力。

其中，关键改进措施就是增加：内容校验、告警拦截、灰度验证、快速回滚、止损恢复等能力。这些其实是一个规范的发布流程必备的，除此之外，还应具备：版本管理、查看变更日志等基础能力。

每次线上发布都伴随着风险，发布过程高度依赖于人的经验和风险识别水平。大多数团队在经历问题后，通过复盘和经验总结，再用规范和强制性的流程约束发布行为，以避免再次发生事故。大部分软件工程实施过程中都会经过这四个阶段：

1.  蛮荒阶段：依赖具体执行人员的经验和认知。

2.  规范化阶段：形成中心、部门级的规范，具备强制性的审批流程。

3.  标准化阶段：形成业务集团（BG）、公司级的标准。

4.  自动化阶段：将经验规范化、将标准工具化、将流程系统化，将执行自动化。

每个团队都需要较长时间从蛮荒阶段往自动化阶段进化。从依靠执行者的风险意识，到依靠系统化的发布风控保障。Shiply 就是满足这一目标的解决方案。

Shiply 作为一站式发布平台，在发布流程的各个节点加入防御和止损机制。实现三级风险控制：

• 事前预防：通过建立标准化、自动化的安全发布流程，预防发布中的各项人因风险。

• 事中监控/自动止损：通过建立灰度策略-AB对比-指标监控，准确告警和自动止损。

• 事后回滚/热修复：通过回滚能力低损降级，或通过热修复能力，无需发版修复现网问题。

从根本上将发布安全由“人为保障”转向“平台保障”，将人的经验转为自动执行的规范标准。

三、  Shiply 安全发布​

3.1 事前——安全发布全流程​

功能	描述	功能截图
内容校验	平台为每个配置都创建了校验脚本，可以通过便携校验脚本对配置内容进行自定义校验。每次新增/修改发布任务时都会对配置值进行校验
修改对比	编辑下发内容后，可以通过差异对比对修改内容进行 Review
变更记录版本化	通过发布管理可以获得两种基本能力，它们分别是可追溯性和可重现性，从而提升软件整个生命周期管理的安全性，并提高团队协作效率。其中的可追溯性是指任何人在获得授权的前提下，能够找到该软件的任何变更历史，即对任何一次软件变更，都可以准确地回答5W1H，即谁（who）、什么时间（when）、做了什么（what）、为什么（why）、如何做的（how）。这是软件组织信息安全管理中的一个重要保障手段。
灰度验证	平台支持丰富的灰度策略，满足业务各种场景下的灰度需求 ● 按自定义时长 + 自定义批次的灰度 ● 按自定义时长 + 自定义累计用户数的灰度 ● 灰度结束后是否定时发布 ● 灰度结束后是否暂停发布
发布审核	审核人员可以清晰看到owner对发布任务的修改内容，以便评估修改对线上的影响。

3.2 事中——监控止损​

当一项发布进入灰度阶段时，我们希望能够在灰度早期，影响少量用户时，就能发现问题。但实际上，灰度用户较小时，各项指标的波动都很大，容易出现误报。而常规的监控方案，是通过监控大盘 Crash 率指标来实现的，但这难以发现新增的个例问题，当问题引起大盘波动时，影响已经很大，监控就失去了原本的预警作用。

Shiply 安全发布能够从灰度小样本用户中准确发现问题，我们通过以下思路实现：

1.  建立多维监控能力

我们支持多种指标的监控，及问题全生命周期的观测：

• 支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控。

• 能够发现灰度新增问题、存量问题恶化、灰度群体问题恶化。

2.  灰度过程中的 AB 对比

我们通过AB对比的方式科学评估每一次发布质量：

• AB对照：设置对照组和实验组，确保实验的公正性和结果的可比性。

• 流量分配：根据实验需求，合理分配流量，确保数据的代表性。

• 实验指标监控：在灰度中，针对实验组和对照组，实时监控各项指标的变化。

• 告警置信度：根据灰度设备量级和Crash率的波动关系分布符合正态分布的规律，通过算法计算告警的置信度，在少量样本时减少误报，提高告警可信度。

3.  提高告警准确性

我们通过告警置信度和动态告警阈值减少误报：

• 根据灰度人群大小设置告警阈值：在灰度初期，由于样本量小，设置较高的告警阈值以减少误报。随着灰度范围的扩大，逐步降低告警阈值，提高监控的敏感度。

• 根据历史数据设置告警阈值：参考历史数据，结合当前的业务情况，合理设置告警阈值。

• 提高告警的可操作性：当收到告警信息后，接警人应该可以针对这个告警做出相应的操作。

4.  自动止损

我们支持问题自动分析关联性，并自动止损：

•  自动问题归因：平台通过 AB 对比，自动分析问题与发布任务的关联，避免人工分析、归因耗时过长，导致止损时机太晚，造成影响扩大化。

• 自动止损：当问题的指标达到熔断阈值时，平台自动停止发布任务，熔断止损。

3.2.1 Shiply x Bugly 监控联动能力​

Shiply 与 Bugly 在产品和技术上持续探索全面的监控止损体系，建立线上发布的安全防线，为业务的每次安全发布保驾护航。

Shiply 平台通过 Bugly 提供的监控能力来实现 Crash、ANR、FOOM 等问题的监控，配置开关、资源、程序包灰度和市场发布均具备监控止损能力。

• 平台默认监控所有灰度任务，业务可自行设定告警和熔断。

• 平台默认给所有应用开启新增 Issue 告警，覆盖大部分场景。

• 用户可自行开启 Crash 率、突增 Issue 告警和熔断。

• 平台同时支持 ANR、FOOM、Error 等多种指标的监控告警和止损。

• 经过灰度发布流程的任务，会自动进入监控，系统每5分钟抓取数据 Crash 等指标与发布任务进行归因诊断。

• 支持查看 Crash 率等指标在时间上的变化趋势，能够看到每个时间节点的 Crash 率、影响设备数、联网总数。

3.2.2 Shiply 安全发布监控止损效果​

通过与Bugly监控发布系统的打通，由发布导致的新增问题，通常在影响设备数小于100人时，可诊断出 Crash、Error 与发布任务的关联性，并及时通知业务通过修改/回滚配置解决，将风险防范于未然，避免了影响面扩大造成线上事故。

3.3 事后——回滚/热修复​

发现本次发布出现问题时，可直接停止当前任务，平台会依据下发任务匹配漏斗，自动匹配上一次发布，实现自动降级。也可以选择想要回滚的目标版本，进行手动降级。Shiply 还提供热修复解决方案，实现便捷、用户无感的现网问题修复。

四、  结语​

发布的过程就是风险管控的过程。本文以配置、资源等热发布为例，介绍了线上发布存在的风险，以及发布过程中人的风险给发布带来的巨大不可靠性。

Shiply平台通过将经验规范化、将标准工具化、将流程系统化，将执行自动化来保障发布全链路的稳定、高效、安全、合规。Shiply 平台多项下发能力均支持“事前防御-事中监控止损-事后回滚”三级风险管控机制，大幅降低线上事故的风险。

在探索线上监控止损机制上，与 Bugly 平台联动，支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控、告警、止损。同时通过解决“告警海洋”问题，使告警及时、精准。能够在影响设备数较小时发出告警，同时支持自动止损，助力发布无人值守！

我们在发布风险管控上做了很多努力，但深知与风险斗争的道路没有尽头，因此我们持续提高对发布风险的理解、洞察和防御水平，为业务的每次安全发布保驾护航！

Shiply（https://shiply.tds.qq.com/）是面向端的一站式发布平台，作为腾讯端服务联盟（https://tds.qq.com）的重要成员，提供配置与开关发布、资源发布、RN热更新、Flutter动态化、热修复、应用内升级、市场发布、应用内测等服务，帮助业务快速、安全地进行客户端功能迭代和上线。

导语：本文是腾讯端服务 Shiply 平台 C++ SDK 适配鸿蒙平台过程中，对依赖三方库在鸿蒙平台交叉编译的实践总结。Shiply 支持鸿蒙平台的远程配置、远程开关、远程资源、应用内更新提示、应用商店提审、应用尝鲜提审、企业签名包内部分发等诸多强大功能，欢迎联系 Shiply 客户经理 进行咨询

概述​

本文档基于bzip2和OpenSSL库在OpenHarmony平台上的完整交叉编译实践，总结了使用lycium框架进行C/C++三方库交叉编译的经验和方法。通过本次实践，我们成功在macOS环境下为OpenHarmony 3.2 Release系统编译了bzip2和OpenSSL两个核心库，涵盖了armeabi-v7a、arm64-v8a和x86_64三种主流架构。

项目背景与技术生态​

OpenHarmony三方库适配现状​

OpenHarmony作为华为推出的开源分布式操作系统，在C/C++三方库适配方面面临着独特的挑战：

1. 编译方式多样化：开源C/C++库的构建方式包括cmake、configure、make等多种方式
2. 架构支持需求：需要同时支持armeabi-v7a、arm64-v8a、x86_64等主流架构
3. 工具链差异：OpenHarmony使用LLVM工具链，与传统的GCC工具链存在差异
4. 运行时环境：OpenHarmony的运行时环境与Linux、Android等系统存在差异

tpc_c_cplusplus项目定位​

tpc_c_cplusplus是OpenHarmony三方库适配的重要仓库，主要功能包括：

1. 三方库适配脚本管理：存放已适配OpenHarmony的C/C++三方库的编译配置
2. 技术文档沉淀：提供三方库适配指导文档和最佳实践
3. 工具链支持：提供交叉编译框架lycium和相关工具

lycium框架​

lycium是OpenHarmony三方库适配的核心框架，它是一个基于shell脚本的自动化交叉编译工具链。本文档将深入分析lycium框架的架构设计、工作原理和技术特点，帮助开发者更好地理解和使用这个框架。

lycium 解决的问题​

1. 编译方式多样化：开源C/C++库使用不同的构建系统（cmake、configure、make等），lycium 通过HPKBUILD配置文件统一管理这些构建方式。
2. 架构支持复杂：需要同时支持armeabi-v7a、arm64-v8a、x86_64等多种架构
3. 工具链差异：OpenHarmony使用LLVM工具链，与传统的GCC工具链存在差异
4. 依赖管理复杂：三方库之间存在复杂的依赖关系
5. 自动化构建：一键完成源码下载、交叉编译、产物打包
6. 测试验证：提供HPKCHECK脚本支持自动化测试

lycium 目录结构​

lycium/
├── build.sh              # 主构建脚本
├── test.sh               # 测试脚本
├── script/               # 核心脚本目录
│   ├── build_hpk.sh      # 单个库构建脚本
│   └── envset.sh         # 环境变量设置脚本
├── template/             # 模板文件
│   ├── HPKBUILD          # 构建配置模板
│   └── HPKCHECK          # 测试配置模板
├── Buildtools/           # 构建工具
│   ├── toolchain.tar.gz  # 交叉编译工具链
│   └── README.md         # 工具说明
├── CItools/              # 持续集成工具
├── doc/                  # 文档目录
├── usr/                  # 编译产物目录
└── docker/               # Docker支持

lycium 架构层次​

┌─────────────────────────────────────────────────────────┐
│                    用户接口层                              │
│  build.sh (主构建脚本)  test.sh (测试脚本)                │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    业务逻辑层                              │
│  依赖解析 │ 构建调度 │ 环境管理 │ 错误处理                │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    构建执行层                              │
│  build_hpk.sh │ envset.sh │ HPKBUILD │ HPKCHECK         │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    工具链层                               │
│  LLVM工具链 │ 交叉编译工具 │ 构建系统适配                │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    平台层                                 │
│  OpenHarmony SDK │ 操作系统 │ 硬件架构                   │
└─────────────────────────────────────────────────────────┘

技术架构分析​

交叉编译技术栈​

macOS + DevEco Studio SDK
    ↓
OHOS_SDK环境配置
    ↓
LLVM交叉编译工具链
    ↓
lycium框架构建
    ↓
多架构二进制产物

关键技术组件​

1. OpenHarmony SDK：提供LLVM交叉编译工具链
2. lycium Buildtools：补充交叉编译工具包
3. HPKBUILD配置：定义编译参数和依赖关系
4. 自动化脚本：实现编译、测试、打包全流程

编译实践总结​

1. 编译环境准备​

1.1 基本工具检查​

首先检查系统是否安装了必需的基本编译工具：

# 检查基本编译工具
which gcc make pkg-config autoconf autoreconf automake

检查结果：

• ✅ gcc: /usr/bin/gcc
• ✅ make: /usr/bin/make
• ✅ pkg-config: /opt/homebrew/bin/pkg-config
• ✅ autoconf: /opt/homebrew/bin/autoconf
• ✅ autoreconf: /opt/homebrew/bin/autoreconf
• ✅ automake: /opt/homebrew/bin/automake

缺少的工具可以使用 homebrew 进行安装

1.2 OHOS SDK环境配置​

检查OHOS_SDK环境变量配置：

echo $OHOS_SDK

配置结果：

• ✅ OHOS_SDK: /Applications/DevEco-Studio.app/Contents/sdk/default/openharmony

1.3 交叉编译工具链检查​

检查SDK中的交叉编译工具链：

ls -la $OHOS_SDK/native/llvm/bin/ | head -10

工具链文件：

• ✅ aarch64-unknown-linux-ohos-clang
• ✅ aarch64-unknown-linux-ohos-clang++
• ✅ armv7-unknown-linux-ohos-clang
• ✅ armv7-unknown-linux-ohos-clang++
• ✅ clang, clang-15
• ✅ 其他LLVM工具

1.4 cmake版本检查​

检查cmake版本是否满足要求（需要3.26+）：

which cmake && cmake --version

检查结果：

• ✅ cmake路径: /opt/homebrew/bin/cmake
• ✅ cmake版本: 3.31.6 (满足3.26+要求)

1.5 编译工具包配置​

解压并配置lycium提供的交叉编译工具包：

# 进入Buildtools目录
cd lycium/Buildtools

# 检查工具包文件
ls -la lycium/Buildtools/
# 输出：
# -rw-r--r--   1 mellow  staff  2323 Dec 19  2023 README.md
# -rw-r--r--   1 mellow  staff   146 Dec 19  2023 SHA512SUM
# drwxr-xr-x@  2 mellow  staff    64 Aug 12 10:38 toolchain
# -rw-r--r--   1 mellow  staff   438 Aug 12 10:23 toolchain.tar.gz

# 解压工具包
tar -zxvf toolchain.tar.gz

# 拷贝编译工具到SDK目录
cp toolchain/* $OHOS_SDK/native/llvm/bin/

解压的工具文件：

• ✅ arm-linux-ohos-clang++
• ✅ aarch64-linux-ohos-clang++
• ✅ x86_64-linux-ohos-clang
• ✅ aarch64-linux-ohos-clang
• ✅ x86_64-linux-ohos-clang++
• ✅ arm-linux-ohos-clang

2. bzip2库配置检查​

2.1 库目录结构​

检查bzip2库的配置文件和目录结构：

ls -la thirdparty/bzip2/

目录结构：

thirdparty/bzip2/
├── docs/                              # 文档目录
├── HPKBUILD                           # 构建脚本
├── HPKCHECK                           # 测试脚本
├── README_zh.md                       # 中文说明
├── README.OpenSource                  # 开源信息
├── SHA512SUM                          # 校验文件
└── 构建目录/                          # 编译生成的目录

2.2 构建脚本分析​

查看HPKBUILD构建脚本的关键配置：

cat thirdparty/bzip2/HPKBUILD

关键配置信息：

• 库名称: bzip2
• 版本: 1_0_6
• 支持架构: armeabi-v7a, arm64-v8a, x86_64
• 构建方式: make
• 编译工具: 使用OHOS SDK中的交叉编译工具链

3. bzip2编译执行过程​

3.1 开始编译​

在lycium目录下执行编译命令：

cd lycium
./build.sh bzip2

3.2 编译输出日志​

Build OS Darwin
OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony
CLANG_VERSION=15.0.4
x toolchain/
x toolchain/arm-linux-ohos-clang++
x toolchain/aarch64-linux-ohos-clang++
x toolchain/x86_64-linux-ohos-clang
x toolchain/aarch64-linux-ohos-clang
x toolchain/x86_64-linux-ohos-clang++
x toolchain/arm-linux-ohos-clang
cp: the -R and -r options may not be specified together
Start building bzip2 1_0_6!
Downloading bzip2-bzip2-1_0_6.zip
bzip2-bzip2-1_0_6.zip: OK
Compileing OpenHarmony armeabi-v7a bzip2 1_0_6 libs...
Compileing OpenHarmony arm64-v8a bzip2 1_0_6 libs...
Compileing OpenHarmony x86_64 bzip2 1_0_6 libs...
Build bzip2 1_0_6 end!
ALL JOBS DONE!!!

编译状态：

• ✅ 源码下载成功
• ✅ 三个架构版本编译完成
• ✅ 编译过程无错误

4. bzip2编译结果验证​

4.1 生成文件结构检查​

检查编译生成的库文件结构：

ls -la usr/bzip2/

生成目录结构：

usr/bzip2/
├── arm64-v8a/          # 64位ARM架构
├── armeabi-v7a/        # 32位ARM架构
└── x86_64/             # x86_64架构

4.2 详细文件检查​

检查arm64-v8a架构的生成文件：

ls -la usr/bzip2/arm64-v8a/

文件结构：

arm64-v8a/
├── bin/                # 可执行文件目录
├── include/            # 头文件目录
├── lib/                # 库文件目录
└── man/                # 手册页目录

4.3 关键文件验证​

生成文件：

• ✅ 静态库: libbz2.a (207,002 bytes)
• ✅ 头文件: bzlib.h (6,245 bytes)

可执行文件（我们只集成静态库可以删掉可执行文件）：

• ✅ bzip2 (218,176 bytes) - 主要压缩工具
• ✅ bunzip2 (218,176 bytes) - 解压工具
• ✅ bzcat (218,176 bytes) - 查看压缩文件内容
• ✅ bzip2recover (32,800 bytes) - 恢复损坏的压缩文件
• ✅ 其他工具脚本: bzdiff, bzgrep, bzmore等

5. OpenSSL库编译记录​

5.1 OpenSSL库配置检查​

检查OpenSSL库的配置文件和目录结构：

ls -la thirdparty/openssl/

目录结构：

thirdparty/openssl/
├── docs/                              # 文档目录
├── HPKBUILD                           # 构建脚本
├── HPKCHECK                           # 测试脚本
├── README_zh.md                       # 中文说明
├── README.OpenSource                  # 开源信息
├── SHA512SUM                          # 校验文件
├── openssl_oh_test.patch              # 测试补丁文件
└── openssl-OpenSSL_1_1_1u/           # 源码目录

5.2 构建脚本分析​

查看HPKBUILD构建脚本的关键配置：

cat thirdparty/openssl/HPKBUILD

关键配置信息：

• 库名称: openssl
• 版本: OpenSSL_1_1_1u
• 支持架构: armeabi-v7a, arm64-v8a, x86_64
• 构建方式: configure (autotools)
• 特殊配置: 使用patch文件修复测试问题

5.3 OpenSSL编译执行过程​

在lycium目录下执行编译命令：

cd lycium
./build.sh openssl

5.4 编译输出日志​

Build OS Darwin
OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony
CLANG_VERSION=15.0.4
x toolchain/
x toolchain/arm-linux-ohos-clang++
x toolchain/aarch64-linux-ohos-clang++
x toolchain/x86_64-linux-ohos-clang
x toolchain/aarch64-linux-ohos-clang
x toolchain/x86_64-linux-ohos-clang++
x toolchain/arm-linux-ohos-clang
cp: the -R and -r options may not be specified together
Start building openssl OpenSSL_1_1_1u!
Downloading openssl-OpenSSL_1_1_1u.zip
openssl-OpenSSL_1_1_1u.zip: OK
openssl_oh_test.patch: OK
Compileing OpenHarmony armeabi-v7a openssl OpenSSL_1_1_1u libs...
patching file 'util/check-malloc-errs'
patching file 'util/find-doc-nits'
patching file 'util/find-unused-errs'
patching file 'util/openssl-format-source'
Compileing OpenHarmony arm64-v8a openssl OpenSSL_1_1_1u libs...
Compileing OpenHarmony x86_64 openssl OpenSSL_1_1_1u libs...
Build openssl OpenSSL_1_1_1u end!
ALL JOBS DONE!!!

编译状态：

• ✅ 源码下载成功
• ✅ 测试补丁应用成功
• ✅ 三个架构版本编译完成
• ✅ 编译过程无错误

5.5 OpenSSL编译结果验证​

生成目录结构：

usr/openssl/
├── arm64-v8a/          # 64位ARM架构
├── armeabi-v7a/        # 32位ARM架构
└── x86_64/             # x86_64架构

文件结构：

arm64-v8a/
├── bin/                # 可执行文件目录
├── include/            # 头文件目录
├── lib/                # 库文件目录
├── share/              # 共享文件目录
└── ssl/                # SSL配置文件目录

6. 编译结果总结​

6.1 成功编译的库​

✅ bzip2库：

• 版本: 1_0_6
• 架构: armeabi-v7a, arm64-v8a, x86_64
• 主要文件: libbz2.a, bzlib.h, bzip2可执行文件

✅ OpenSSL库：

• 版本: OpenSSL_1_1_1u
• 架构: armeabi-v7a, arm64-v8a, x86_64
• 主要文件: libcrypto.a, libssl.a, openssl头文件

技术难点与解决方案​

1. 交叉编译工具链配置​

问题：OpenHarmony使用LLVM工具链，需要正确配置交叉编译环境

解决方案：

# 设置环境变量
export OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony

# 补充编译工具
cp lycium/Buildtools/toolchain/* $OHOS_SDK/native/llvm/bin/

2. 多架构编译支持​

问题：需要同时支持多种CPU架构

解决方案：

# HPKBUILD中配置多架构
archs=("armeabi-v7a" "arm64-v8a" "x86_64")

# 针对不同架构设置编译参数
if [ $ARCH == "armeabi-v7a" ]; then
    cc=${OHOS_SDK}/native/llvm/bin/arm-linux-ohos-clang
    host=linux-generic32
elif [ $ARCH == "arm64-v8a" ]; then
    cc=${OHOS_SDK}/native/llvm/bin/aarch64-linux-ohos-clang
    host=linux-aarch64
fi

3. 测试验证问题​

问题：OpenSSL等库的测试用例在OpenHarmony环境下可能失败

解决方案：

• 应用测试补丁修复已知问题
• 区分误判和真实错误
• 避免使用dlopen等有问题的功能

4. 构建方式适配​

问题：不同库使用不同的构建系统

解决方案：

• make方式：直接使用原生Makefile
• configure方式：使用autotools配置
• cmake方式：使用CMake构建系统

最佳实践总结​

1. 环境准备最佳实践​

# 1. 检查基础工具
which gcc make pkg-config autoconf autoreconf automake

# 2. 验证SDK配置
echo $OHOS_SDK

# 3. 检查cmake版本
cmake --version  # 需要3.26+

# 4. 配置工具链
cd lycium/Buildtools
tar -zxvf toolchain.tar.gz
cp toolchain/* $OHOS_SDK/native/llvm/bin/

2. HPKBUILD配置最佳实践​

# 基本信息配置
pkgname=your_library
pkgver=1.0.0
pkgdesc="Library description"
url="https://example.com"
archs=("armeabi-v7a" "arm64-v8a" "x86_64")
license=("MIT")
depends=()
makedepends=()

# 源码配置
source="https://example.com/your_library-1.0.0.tar.gz"
downloadpackage=true
autounpack=true
buildtools="make"  # 或 "configure" 或 "cmake"

# 构建目录配置
builddir=your_library-1.0.0
packagename=$builddir.tar.gz

3. 编译流程最佳实践​

# 1. 准备阶段
prepare() {
    mkdir -p $builddir/$ARCH-build
    # 设置架构相关环境变量
    if [ $ARCH == "arm64-v8a" ]; then
        setarm64ENV
    fi
}

# 2. 构建阶段
build() {
    cd $builddir/$ARCH-build
    # 执行编译命令
    $MAKE
    cd $OLDPWD
}

# 3. 打包阶段
package() {
    cd $builddir/$ARCH-build
    $MAKE install
    cd $OLDPWD
}

4. 测试验证最佳实践​

# 1. 编写测试脚本
check() {
    cd $builddir/$ARCH-build
    # 运行测试用例
    $MAKE test
    cd $OLDPWD
}

# 2. 在设备上验证
./test.sh your_library

应用集成指南​

1. 库文件集成​

# 拷贝库文件到项目
cp -r lycium/usr/your_library/ your_project/cpp/thirdparty/

2. CMakeLists.txt配置​

# 静态库链接
target_link_libraries(entry PRIVATE 
    ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/your_library/${OHOS_ARCH}/lib/libyour_library.a)

# 头文件路径
target_include_directories(entry PRIVATE 
    ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/your_library/${OHOS_ARCH}/include)

3. 动态库集成​

# 动态库需要拷贝到libs目录
cp your_library.so your_project/entry/libs/${OHOS_ARCH}/

常见问题与解决方案​

1. 编译失败问题​

问题：编译过程中出现错误

解决方案：

• 检查OHOS_SDK环境变量设置
• 验证交叉编译工具链配置
• 确认源码下载是否成功
• 检查磁盘空间是否充足

2. 架构不匹配问题​

问题：库文件架构与目标平台不匹配

解决方案：

• 确认使用正确的架构版本（arm64-v8a或armeabi-v7a）
• 检查HPKBUILD中的archs配置
• 验证编译产物架构

3. 依赖缺失问题​

问题：库依赖其他三方库

解决方案：

• 在HPKBUILD中配置depends字段
• 确保依赖库先编译完成
• 检查依赖库的架构支持

4. 测试失败问题​

问题：测试用例在OpenHarmony环境下失败

解决方案：

• 应用必要的测试补丁
• 区分误判和真实错误
• 避免使用不兼容的功能

总结​

通过本次bzip2和OpenSSL库的编译实践，我们成功验证了：

1. 技术可行性：lycium框架能够有效支持C/C++三方库的交叉编译
2. 多架构支持：成功编译出支持多种架构的库文件
3. 质量保证：通过测试验证确保库的功能完整性
4. 工具成熟度：编译工具链和框架已经相对成熟

参考资料​

• lycium框架README

• OpenHarmony三方库适配指导

• bzip2集成指南

• OpenSSL集成指南

• OpenHarmony三方库地址

• OpenHarmony知识体系

导语：Shiply 是腾讯应用的全场景发布平台，为 App 提供一站式的动态发布解决方案。多种端云一体的服务，有效降低技术门槛，减少研发成本，助力业务快速搭建稳定高质量的移动应用。也是腾讯端服务（Tencent Device-oriented Service）联盟的重要产品成员（tds.qq.com）。

源自腾讯的 Shiply，沉淀了腾讯在移动应用领域多年的成熟发布经验。为旗下众多千万级、亿级用户量的国民应用提供发布管理支持，也支撑内部众多创新产品的敏捷开发和高速迭代，是腾讯内部客户端应用不可或缺的发布管理平台。

过去十年，客户端技术架构的演进核心是提升动态交付能力，对应用发布基础设施建设提出了前所未有的高要求：​​

• 原生技术​​：从单体架构演进至组件化、插件化，核心诉求是实现模块热插拔与问题热修复​​，缩短修复路径，提升迭代灵活性。

• 跨平台技术​​：从 Hybrid 经 RN、Flutter 发展至 KMM (Kotlin Multiplatform Mobile)，演进方向聚焦于开发态的热重载与运行态的热更新​​，以加速开发流程并实现运行时无感更新。

​​如今，"发布"范畴已发生根本性改变：​​ 不再局限于传统安装包的发布（上架）​​，更扩展至涵盖离线包、插件包、热修复补丁、跨平台动态产物等多种形式的动态发布​​，乃至安装包内资源、应用配置的实时化下发​​。

​​Shiply 通过持续挖掘发布形态，扩展发布品类，构建了覆盖客户端全生命周期的统一发布平台。​​ 这一能力体系旨在​​无缝支撑不同技术栈下的全场景发布诉求​​，无论是技术优化、新特性上线还是高频运营活动，均能提供高效、稳定、灵活的发布保障。

一、 Shiply 全场景发布能力概览​

Shiply 提供的软件交付的全场景、全生命周期管理方案，包括安装包发布和动态发布两大发布模式。

传统安装包发布

-应用内测分发：iOS/Harmony 企业签名包、Android DailyBuild 包在企业内部的分发。

• 应用内升级：实现 Android APK 应用内自升级，iOS/Harmony 的更新提示。

• 邀请、开放式测试：例如 iOS（Testflight），Harmony（AppGallery）的邀请测试、开放式测试。

• 应用商店提审：支持 iOS（AppStore）、Android（主流手机厂商应用商店）、Harmony（AppGallery）的自动传包、提审。

动态发布

将安装包解构为代码（可执行二进制文件、库文件）、配置、资源三类文件，实现局部动态更新：

• 跨平台发布（跨平台代码）：面向各类跨平台框架（Kuikly、Hippy、Flutter、React Native等）的构建产物，支持多平台、多产品的同步发布，极大提升发布效率。

• 热修复发布（原生代码）： 无需上架新版安装包，即可发布补丁紧急修复线上问题。。

• 远程资源发布（资源文件）：支持端智能模型、主题、字体、皮肤、图片、动画、SO库等任意文件的按需加载与更新。

• 远程配置发布（配置文件）：支持 DSL 动态化、路由与接口动态化、动态调优参数、特性开关等场景配置的动态更新。

Shiply 的动态发布解决方案旨在实现应用功能、数据、配置、视觉样式的无感更新，摆脱对应用商店审核流程的依赖。

二、 动态发布的核心价值​

2.1 满足业务快速迭代的敏捷性需求​

• 精细化运营驱动高频发布：移动互联网进入存量竞争，用户增长放缓要求企业转向精细化运营。业务需高频更新以优化体验、进行 A/B 测试创新、开展活动运营。传统应用商店审核流程（iOS 需 1-3 天）无法满足需求，动态发布可实现"分钟级"热更新，避免迭代延迟导致用户流失。

• 热点场景驱动功能快速上线：视频、新闻、体育等产品需快速响应节日活动、社会热点、赛事直播。突发活动易引发流量陡增，需动态调整功能应对需求变化。

2.2 解决安装包版本更新滞后的痛点​

• 用户升级周期长：传统安装包版本更新依赖用户主动升级意愿，版本覆盖率提升慢，版本碎片化问题难以根除。动态发布实现用户无感更新，确保所有用户即时使用最新功能。

• 强制更新的代价：强制更新易引发用户抵触，在存量竞争下存在用户流失风险。动态发布通过渐进式更新降低风险。

2.3 应对多平台、多产品的技术挑战​

• 平台多样化：国内手机厂软件能力不断提高，Harmony OS、Hyper OS 等自研系统不断涌现。

• 产品多元化：为挖掘下沉市场，常需推出"极速版"等多版本应用。

伴随平台与产品的增多，功能复用成为降低开发成本、提升迭代效率的关键，催生跨平台开发框架，衍生出跨平台动态发布需求。

2.4 对用户、开发者带来的价值​

动态发布的无感更新可以为用户、开发者、运维、运营的人员解决诸多痛点问题：

• 对用户：烦人的更新弹窗、强制退出、更新失败、新版本Bug影响使用。

• 对开发者/运维：发布窗口紧张、上线风险高、用户流失、问题修复慢、用户体验差、差评增多、业务损失。

三、 动态发布之跨平台发布​

3.1 跨平台发布的痛点​

跨平台开发框架（Kuikly、Hippy、Flutter、React Native等）凭借"一次开发，多端运行"优势，成为提效保质的行业标配。但其发布复杂度远超传统火车发版（Release Train）模式：

• 发布效率瓶颈：

  • 平台差异需分别构建iOS、Android、Harmony、Web等多端产物，多端发布工作量倍增；

  • 跨平台开发以"页面"为发布单元的灵活性导致页面数量越多，发布频次越高。

• 跨应用复用复杂性：模块（如天气模块）常需服务于多个宿主应用（如QQ、TIM），进一步放大发布规模。

• 依赖管理难题：模块版本与宿主App之间的兼容性、升级/降级管理错综复杂。

3.2 跨平台发布解决方案​

为了应对这些错综复杂的发布挑战，Shiply 推出「跨平台发布」解决方案深度优化发布流程。

• 以模块绑定不同平台的资源ID：模块支持绑定不同平台、产品下的资源包 ID，实现统一发布流程管理。

• 跨端发布的模块依赖问题：

将功能模块拆细后，模块间也可能会形成依赖关系。单一模块的更新依赖更底层模块的更新，形成了依赖更新困局。

Shiply 支持多模块聚合形式的发布，客户端拉取任意一个模块，Shiply SDK 都能将关联模块同时更新到本地。解决了依赖模块发布、下载时序不一可能导致的潜在问题。

• 可分别设置发布条件

  • 发布灵活：可以灵活选择发布到其中的一个或多个产品。

  • 规则强大：包含20多种系统内置条件，满足人群、地域、网络、系统版本、机型等设置。支持关联画像、AB实验人群下发；支持千万级超大人群包。具备全局条件、条件模板、自定义条件等多种发布规则填充方式。支持用户自定义属性作为下发条件，发布条件可无限扩展。

• 自动差量：平台能够自动为已发布的历史N个任务生成差量包，最高可节省60-80%流量，省流效果十分显著。

• 统一设定灰度放量策略

丰富的灰度策略：按批次灰度、按比例灰度、平滑灰度、灰度后定时发布等等。按比例灰度能够解决不同产品用户量级

灰度过程自动化：灰度批次自动流转，灰度过程无人值守。

• 统一控制发布流程

  • 发布全生命周期管理：标准化流程（测试、体验、审批、灰度、全量、回滚、停止）提供完备的发布生命周期管理能力。在发布的前、发布中、发布后阶段均有对应机制保障发布安全。

  • 独立流程控制：支持对聚合发布的任意产品暂停、停止、回滚，既能同一控制多端，又能保持最大的灵活度。当特定产品的发布出现问题时，可定点止损。

3.4 发布监控止损机制​

跨平台开发提升了的功能复用水平和开发效率，但同时也带来了更长的逻辑链路，链路从时间维度上划分是：下载链路、加载链路、使用链路。

例如我们在使用Hippy框架（类似RN）的时候，会涉及到bundle的启动下载或预热下载，bundle解压缩，Hippy引擎初始化，bundle加载，JS的加载、执行，页面渲染等步骤，其中的每个步骤都可能存在性能问题和质量风险。因此，我们需要升级我们的衡量指标系统来应对跨平台发布带来的新的挑战。

发布全链路监控和止损：Shiply 基于腾讯前端监控框架 Aegis，开发了 Hippy 和 Kuikly 两款跨平台框架的监控 SDK。通过 SDK 和 Bugly 监控平台打通，能够对两款跨平台产物的发布进行全链路的监控、告警、止损。

• 下载链路：支持配置拉取成功率、程序包下载覆盖率、加载成功率的监控

• 加载链路：支持页面加载耗时，支持秒开率指标，支持各项细分指标下钻分析。

• 执行链路(运行时)：支持错误日志、网络请求错误码与耗时、各种自定义上报

-Native 核心指标：支持 Crash、ANR、FOOM、ERROR、隐私合规、业务自定义指标的监控、告警、止损

3.5 跨平台发布支持情况​

Shiply 目前除了支持 H5 、Hippy、React Native 框架产物的跨平台聚合发布，还支持 Flutter、Kuikly 等框架的动态化 SDK + 发布解决方案：

• Flutter 动态化：支持Flutter在Dart语言层的热修复和动态化。内部纯自研方案，主打高性能和原生开发体验，性能和易用性远高于传统JS、AST方案。

• Kuikly 动态化：能够支持 Android、iOS、Harmony 等多端动态化，在Android端采用类原生Dex加载模式，相比SO模式首屏速度提升20%。在iOS端可以实现与原生无差别的首屏和流畅度体验。

在2025年6月，我们统计了当前市面上应用热门跨平台框架 Flutter、RN 使用情况

• Flutter 整体渗透率约 13%，在旅游类应用渗透率最高（29.5%）。

• React Native 整体渗透率约 9%，在旅游类产品渗透率最高（18.2%）。

跨平台框架在应用中的渗透率仍有很大提升空间，Shiply 专业版（对外提供服务）将陆续开放相关能力，助力行业应用更好的利用跨平台开发技术，通过动态发布技术将功能更快、更安全的推向市场。

3.6 跨平台发布小结​

Shiply 提供的跨平台发布解决方案，系统性解决了跨平台、跨应用场景下的高频发布难题​​。能同时协调跨平台、跨应用的复杂发布任务，其核心在于灵活发布规则引擎，强大的端侧 SDK 能力，能够解决模块间依赖问题，支持自动降级、一键回滚等关键操作，彻底打破跨平台发布壁垒。唯有实现高频动态化发布，才能发挥出跨平台框架的最大价值。

四、动态发布之应用热修复​

4.1 热修复的适用场景​

面对线上突发问题，传统修复流程迟缓且成本高昂。Shiply的热修复技术提供了实时响应能力：

紧急Bug修复

让无法登录问题、启动闪退、支付障碍等核心体验问题不再束手无策。

提高线上容错

严格的版本质量控制意味着繁重的流程规范约束，和投入大量的测试资源。为了找出5%的问题需要付出80%的精力全面回归测试。失去灵活和敏捷也会导致丢失市场先机。通过热修复提升线上容错能力，可适当降低无效的测试投入，将产品更快的推向市场。

轻量版本快速升级

新功能从开发上线、版本覆盖，再到回收数据往往需要较长的周期才能形成闭环。应用热修复提供了一种轻量化更新的能力，在功能修改较小的情况下，可以快速的实现用户无感升级。

4.2 Shiply 热修复 SDK 方案​

Android 热修复方案按修复粒度可分为三类：函数级、类级、Dex级。

我们对这些方案进行对比：

综合来看各个方案在性能影响、兼容性、使用限制方面都各有优劣。

Shiply 热修复 SDK 采用多方案融合的混合引擎（Tinker, Redirect），结合海量业务实践，在补丁稳定性、兼容性、生效速度上深度优化。业务接入无须关注引擎差异，发布时可灵活选择最优打包方案。

修复能力：除 AndroidManifest.xml、RemoteView 等受系统管理的资源外，支持 dex、res、so 的修复，实现功能级更新。

• Tinker 引擎：支持 Dex、So库及资源替换（综合性），提供 回滚能力（安全性），社区活跃（微信开源）。其本质是 Android 类加载机制的应用与优化。

• Redirect 引擎：函数插桩方案。Redirect并未采用基于注解的差异标记，而是通过DexDiff来分析差异，实现修复代码的自动提取，这对于开发者来说使用门槛更低，而且也可以规避编译期的内联优化导致的注解失效等问题。同时我们也加强了自动生成代码的能力（类继承等少量特性从原理层面无法支持），对于增删变量、增删函数、增删类、lambda等都进行了最大限度的支持，将插桩的修改限制控制在极小范围内。

4.3 Shiply 热修复全流程管理方案​

Shiply 应用热修复提供了一站式的补丁发布管理，包括：任务管理、分支管理、流水线插件、灰度管理、审批放量、灰度放量、实时数据统计、发布质量监控联动。

Shiply 通过标准的发布流程和配套工具来保证发布的快捷、安全、稳定，打通发布过程所涉及的多个系统，让发布更简单省心。

4.4 Shiply 热修复落地效果​

Shiply 已为公司内 30+ APP 提供能力支撑，覆盖​​峰值设备数超10亿/天​​，​​补丁加载成功率高达99.9%+​​。过去一年，Shiply通过热修复能力​​显著提升了公司多款产品核心场景的稳定性与用户体验​​：

• ​​核心模块稳定性与性能优化：​​ 快速修复业务 A 文件、相册、本地文档、预加载、冷启动过程中的 Crash 及卡顿。

• ​​关键用户体验修复：​​ 保障业务 B 投屏体验、核心页面（如奥运轮播图）UI一致性及流程卡顿。

• ​​业务关键流程保障：​​ 解决业务 C 广告与闪屏加载、直播间核心功能以及底层页跳转中的异常问题。

• ​​基础功能与兼容性适配：​​ 针对业务 D 内核引擎、皮肤、商城、推送、语音等高频模块进行热修复与兼容适配。

五、结语：让进化隐于无形，使价值显于极致​

在应用竞争进入白热化的今天，产品的竞争力是「进化速度 × 迭代成本 × 用户体验」，动态发布能力已成为应用高速进化的核心引擎之一。Shiply 致力于将技术迭代的复杂度隐于幕后 ，通过提供全场景、一站式的发布能力，助力开发者为用户创造功能无感升级、问题无感修复的极致顺畅体验 ——当技术迭代隐于无形，产品价值方能显于极致。

近半年，Shiply也开始对外提供商业化服务。凭借高可靠、大规模落地验证的技术方案，目前已在消费电子、汽车、医疗、电商、内容、社交等多个行业落地，持续为业务提供高质量的动态发布服务、跨端动态化框架、应用热修复等能力支持。

欢迎访问 腾讯 Shiply 开启免费试用，开启应用发布的新范式！

或直接联系 Shiply 客户经理 进行咨询，您也可以前往 TDS 腾讯端服务获取更多产品资讯与解决方案。

苹果的 ​​ITMS（iTunes Store）错误​​通常与应用程序或内容提交到 App Store 的过程相关，尤其是在使用 ​​Transporter​​、​ ​​App Store Connect API​​、altool 等工具时出现的问题。苹果对这些错误的定义和管理主要集中在确保开发者遵守技术规范和审核指南，同时提供工具和文档帮助开发者解决问题。

• 在提交应用到 App Store Connect 时，苹果的自动化系统会执行预检，检测常见错误（如签名、元数据格式等），并直接返回错误代码和描述。
• 开发者需根据错误提示修改后重新提交。

一、I​TMS 错误类型​

ITMS 错误通常以 ITMS-XXXXX 格式编号（例如 ITMS-9000 等），涵盖以下常见类型：

1. ​​元数据错误​​
   • 与应用名称、描述、截图、关键词等元数据相关的问题。
2. ​​二进制文件问题​​
   • 构建版本（IPA 文件）的签名、架构或格式错误。
3. ​​合规性问题​​
   • 违反 App Store 审核指南（如隐私政策缺失、使用私有 API、数据收集不合规等）。
4. ​​证书与配置文件错误​​
   • 签名证书失效、设备权限配置错误。
5. ​​服务器或网络问题​​
   • 苹果服务器故障或开发者网络不稳定导致的提交失败。

二、如何处理 ITMS 错误​

1. ​​开发者支持渠道​​

• ​​联系苹果技术支持​​：通过 App Store Connect 的「联系我们」提交问题。
• ​​开发者论坛​​：在 Apple Developer Forums 中搜索类似案例或提问。
• ​​Xcode 和 Transporter 日志​​：通过工具生成的详细日志定位问题根源。

2. ​​审核团队的反馈​​​

• 如果应用通过预检但被审核团队拒绝，开发者会收到包含具体条款的邮件（如违反指南 4.3、5.1.1 等），需根据反馈修改并重新提交。

三、ITMS 错误：编译与二进制问题​

ITMS-90668​

​​错误信息​​

ERROR ITMS-90668: "Invalid Bundle Executable. The executable file contains incomplete bitcode."

​​原因​​
二进制文件未正确启用 Bitcode 或编译参数不完整。

​​解决方式​​

1. 方案一：​​关闭 Bitcode​​
   检查二进制文件是否开启 Bitcode：

   otool -arch arm64 -l ./MXFFI | grep __LLVM | wc -l
   
   • 结果为 0 表示 ENABLE_BITCODE = NO
   • 结果不为 0 表示 ENABLE_BITCODE = YES

2. 方案二：​​强行移除 Bitcode 并重签名​​

   # 移除 Bitcode 
   xcrun bitcode_strip Flutter.framework/Flutter -r -o Flutter.framework/Flutter 
   # 重签名 Framework 
   codesign -fs "证书名称" Flutter.framework 
   # 重签名整个 App 
   codesign -fs "证书名称" --entitlements ${appPath}/entitlements.plist ${appPath}
   

ITMS-90087​

​​错误信息​​

ERROR ITMS-90087: "Unsupported Architectures. The executable contains unsupported architectures [x86_64,i386]."

​​原因​​
二进制包含模拟器架构（x86_64/i386）。

​​解决方式​​
添加构建脚本移除无效架构：

APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}" find "$APP_PATH" -name '*.framework' -exec lipo -remove x86_64 {} -output {} \;

ITMS-90209​

​​错误信息​​

ERROR ITMS-90209: "Invalid Segment Alignment. The binary does not have proper segment alignment."

​​原因​​
二进制文件段对齐异常。

​​解决方式​​

1. 升级 Xcode 至最新版本。
2. 使用 lipo 重新编译第三方库。

ITMS-90125​

​​错误信息​​

ERROR ITMS-90125: "The binary is invalid. The encryption info is missing or invalid."

​​原因​​
二进制文件加密信息缺失。

​​解决方式​​
确保未手动修改二进制加密标志，使用Xcode默认构建流程。

TMS-90048​

​​错误信息​​

ITMS-90048: This bundle is invalid - Your archive contains paths that are not allowed: [._Symbols]

​​原因​​
提交给 App Store Connect 的归档文件 (.xcarchive) 里，包含了一个不允许存在的隐藏文件 ._Symbols。

macOS 15.4 的 APFS 文件系统在处理文件时，会为某些操作（如 rsync）自动生成以 ._ 开头的隐藏文件，用于存储 Finder 元数据或资源 fork。在 iOS 构建过程中，生成 Symbols 目录时，系统可能因文件操作触发元数据文件 ._Symbols 的创建

​​解决方式​​
解决方式一：构建后，解压 ipa，删除 ._Symbols 解决方式二：通过Xcode 里通过 Prodict > Archive 提交

ITMS-90426​

​​错误信息​​

ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.

​​原因​​

SwiftSupport 文件夹丢失

​​解决方式​​

1. Build Settings -> Always Embed Swift Standard Libraries 设置成 YES
2. 重新打包，然后解压 ipa 检查是否包含 SwiftSupport 文件夹

四、ITMS 错误：版本与配置问题​

ITMS-90060​

​​错误信息​​

ERROR ITMS-90060: "Invalid CFBundleShortVersionString '1.2.2.1'. Must be a period-separated list of three non-negative integers."

​​原因​​
版本号格式不符合三段式要求。

​​解决方式​​
检查所有依赖库的 CFBundleShortVersionString，修改为三段式（如 1.2.2）。

ITMS-90062​

​​错误信息​​

"This bundle is invalid. The value for key CFBundleShortVersionString [...] must contain a higher version"

​​原因​​
提交版本号低于已审核版本。

​​解决方式​​
确保 CFBundleShortVersionString 和 CFBundleVersion 均高于最近审核通过版本。

ITMS-90725​

​​错误信息​​

ITMS-90725: SDK Version Issue - This app was built with the iOS 15.5 SDK. All iOS apps submitted to the App Store must be built with the iOS 16.1 SDK or later, included in Xcode 14.1 or later."

​​解决方式​​
升级 Xcode 至 14.1 或更高版本，使用 iOS 16.1+ SDK 重新编译。

ITMS-90098​

​​错误信息​​

The bundle identifier contains disallowed characters

​​解决方式​​
检查并修改 Bundle Identifier，确保其不包含不允许的字符

ITMS-90186​

​​错误信息​​

Invalid Pre-Release Train. The train version is closed for new build submissions

*​原因​​

该版本的预发布列车已关闭，无法提交新的构建版本

​​解决方式​​
检查 App Store Connect 中的版本设置，确保提交的版本号正确

五、ITMS 错误：隐私与权限问题​

ITMS-91053、ITMS-91056、ITMS-91061​

​​错误信息​​

ITMS-91053: Missing API declaration - Your app’s code in the “Runner” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryDiskSpace. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91056: Invalid privacy manifest - The PrivacyInfo.xcprivacy file from the following path is invalid: "PrivacyInfo.xcprivacy". Keys and values in your app's privacy manifests must be valid. For more details about privacy manifest files, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files.

ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/X.framework/X”, which includes X, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements.

​​原因​​
2024.2.29 日 Apple 发布了《关于 App Store 提交的隐私更新》，明确要求 新上架或更新的APP 必须包含 「PrivacyInfo.xcprivacy」 隐私清单文件，否则可能被拒审，部分第三方SDK若以二进制形式集成，还需附带签名。

开发者需要给 SDK 创建 PrivacyInfo.xcprivacy 隐私清单文件。

• NSPrivacyAccessedAPICategoryFileTimestamp
• NSPrivacyAccessedAPICategoryUserDefaults
• NSPrivacyAccessedAPICategoryDiskSpace
• NSPrivacyAccessedAPICategoryUserDefaults

​​解决方式​​

手动创建 PrivacyInfo.xcprivacy（根据你的情况修改）

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array/>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

第三方SDK较多，可以考虑使用自动修复脚本：

• https://github.com/crasowas/app_privacy_manifest_fixer

• https://github.com/ymoyao/cocoapods-privacy

App Store隐私清单分析器：

• https://github.com/crasowas/app_store_required_privacy_manifest_analyser

ITMS-91061​

​​错误信息​​

ITMS-91061: "Missing privacy manifest. Third-party SDK must include a privacy manifest."

​​解决方式​​
联系第三方 SDK 提供商获取包含隐私清单的更新版本。

ITMS-90683​

​​错误信息​​

"Missing Info.plist key. Your app's code references [...] but the Info.plist file does not contain [...]"

​​原因​​
访问敏感数据（如位置、相机）未提供隐私描述。

​​解决方式​​
在 Info.plist 中添加对应键值：

• NSLocationWhenInUseUsageDescription
• NSCameraUsageDescription

ITMS-90078​​

​​错误信息​​

"Missing push notification entitlement [...] entitlements do not include the 'aps-environment' entitlement"

​​原因​​
应用包含APNs相关API但未声明推送通知权限

​​解决方式​​

1. 在项目Capabilities中启用推送通知
2. 检查第三方库是否隐式引用APNs API，使用nm或otool排查二进制文件中的符号引用

六、ITMS 错误：签名与描述文件问题​

ITMS-9000​

​​错误信息​​

ERROR ITMS-9000: "The binary you uploaded was invalid."

​​原因​​
描述文件（Provisioning Profiles ）过期或被删除。

​​解决方式​​
重新生成并下载描述文件，使用有效文件重新打包。

ITMS-90165​

​​错误信息​​

ERROR ITMS-90165: "Invalid Provisioning Profile Signature. The provisioning profile [...] is not valid"

原因

描述文件签名失效（苹果更新签名机制导致）

​​解决方式​​

1. 重新编辑描述文件并下载。
2. 删除旧文件后重新打包。

ITMS-90046​

​​错误信息​​

ERROR ITMS-90046: "Invalid Code Signing Entitlements"

​​原因​​
代码签名权利无效，可能是描述文件有问题或 Bundle Identifier 命名不规范等

​​解决方式​​
检查描述文件是否正确配置，确保 Bundle Identifier 命名符合要求

ITMS-90535​

​​错误信息​​

Invalid Code Signing Entitlements

​​原因​​
第三方 info.plist 文件中的 Bundle Identifier 或版本号等信息未正确配置

​​解决方式​​
修改第三方 info.plist 文件，添加正确的 Bundle Identifier、版本号等信息

七、ITMS 错误：界面与图标问题​

ITMS-90809​

​​错误信息​​

ERROR ITMS-90809: "Deprecated API Usage. UIWebView is no longer accepted."

​​解决方式​​
替换 UIWebView 为 WKWebView，重新编译。

ITMS-90022、ITMS-90025​

​​错误信息​​

# ITMS-90022
Missing required icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '57x57' pixels, in.png format for iOS versions < 7.0
# ITMS-90025
Missing recommended icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '120x120' pixels, in.png format for iOS versions >= 7.0

​​解决方式​​
在 images.xcassets 的 AppIcon.appiconset 中添加相应尺寸的图标，并在 Contents.json 中进行配置

ITMS-90705​

​​错误信息​​

Launch storyboard not found. Make sure you specify the launch storyboard filename without a filename extension for the key UILaunchStoryboardName in the Info.plist

原因

启动故事板未找到，Info.plist 中的 UILaunchStoryboardName 值不正确

​​解决方式​​
检查 Info.plist 中的 UILaunchStoryboardName 值，确保其与启动故事板文件名一致，且不包含扩展名

ITMS-90096​

​​原始错误信息​​

Missing recommended icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '57x57' pixels, in.png format for iOS versions < 7.0

原因

应用缺少 LaunchImage 或其设置有问题

​​解决方式​​
添加相应尺寸的启动图片到项目根目录，并修改 info.plist 文件，或检查 LaunchScreen.storyboard 是否存在

八、ITMS 错误：其他常见问题​

ITMS-90474 / ITMS-90475​

​​错误信息​​

ERROR ITMS-90474: “Invalid Bundle. iPad Multitasking support requires these orientations: ‘UIInterfaceOrientationPortrait,UIInterfaceOrientationPortraitUpsideDown,UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight’. Found ‘UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight’ in bundle ‘...’.”

ERROR ITMS-90475: “Invalid Bundle. iPad Multitasking support requires launch story board in bundle ‘...”

原因 iPad 分屏适配，需要添加全屏声明

​​解决方式​​
在 Info.plist 中添加：

<key>UIRequiresFullScreen</key> <true/>

ITMS-90529​

​​错误信息​​

ERROR ITMS-90529: "IInvalid package. Applications built with sdk 9.0 or later must be packaged as proper IPA files"

原因

打包方式不正确，未使用 .ipa 文件格式

​​解决方式​​
将编译后的 .app 放入 Payload 文件夹，压缩为 .ipa 文件。

ITMS-90983​

​​错误信息​​

ERROR ITMS-90983: "Missing purpose string in Info.plist for media classification."

原因

iOS 16 及以上需要在 Info.plist 中添加媒体分类的目的字符串

​​解决方式​​
在 Info.plist 中添加媒体分类描述：

• NSMediaLibraryUsageDescription
• NSAppleMusicUsageDescription