Skip to main content

· 13 min read

前言: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动态化、热修复、应用内升级、市场发布、应用内测等服务,帮助业务快速、安全地进行客户端功能迭代和上线。

图片

· 19 min read

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

一、  背景

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

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

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

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

时间案例
2023年7月某内容平台配置下发导致 App 在启动阶段闪退,官方通告必须卸载重装才能解决。
2024年6月某工具类产品在配置运营活动过程中出现bug,导致部分用户出现客户端崩溃。需发布新版本修复问题,升级新版本后才可恢复使用。

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

二、发布存在哪些风险

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

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

风险类型风险点
人的风险● 使用不规范:错配、漏配、滥用(不需要配置时使用了配置)
● 发布不规范:随意发布、无验证发布、无灰度发布
● 使用了配置、资源但没有兜底处理措施
● 优先级不合理导致配置、资源互相覆盖
● 依赖审核人员对风险的认知水平
系统风险● 配置变更时缺乏参数合法性校验
● 错误的配置、资源无法快速回退
● 缺乏配置、资源异常检测机制
舆论与合规风险● 运营内容包含民族歧视、地域偏见、宗教矛盾、民俗差异、文化冲突等内容

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

  • 改进措施

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

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

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

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

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

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

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

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

3.  标准化阶段:形成业务集团(BG)、公司级的标准。

  1.  自动化阶段:将经验规范化、将标准工具化、将流程系统化,将执行自动化。

每个团队都需要较长时间从蛮荒阶段往自动化阶段进化。从依靠执行者的风险意识,到依靠系统化的发布风控保障。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 在产品和技术上持续探索全面的监控止损体系,建立线上发布的安全防线,为业务的每次安全发布保驾护航。

产品优势
Bugly 专业版提供专业的质量监控服务,帮助开发者及时发现并解决问题,打造高质量App。支持多维度的质量、性能监控。Bugly 对文中 Crash、ANR、Foom、Error 等多指标监控提供了技术支持。
Shiply 专业版提供专业的客户端发布能力,帮助开发者安全、高效进行动态发布,支持应用灰度升级、远程配置、动态资源包、热修复等。

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动态化、热修复、应用内升级、市场发布、应用内测等服务,帮助业务快速、安全地进行客户端功能迭代和上线。

图片

· 18 min read

导语:本文是腾讯端服务 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. 工具成熟度:编译工具链和框架已经相对成熟

参考资料

· 25 min read

导语: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端可以实现与原生无差别的首屏和流畅度体验。

框架H5Hippy/RNFlutterKuikly
开发语言JavaScriptJavaScriptDartKotlin
开发体验Web 体系Web 体系Dart 体系Android 体系
用户体验非原生接近原生接近原生原生
渲染方案WebView原生自绘(Skia)原生
内存占用
动态化能力支持支持支持支持
热更新支持支持支持支持支持

在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级。

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

Native HookJava HookMultiDexDex替换
原理通过修改ArtMethod的入口来实现函数执行逻辑的替换通过编译时在函数前插桩来实现运行时的函数执行逻辑替换利用ClassLoader的类查找机制实现类的替换,但是要解决预加载和内联问题也是用了ClassLoader的类查找机制,但是替换的范围更大,以规避优化问题,几乎整个App都可以替换
性能1. 无补丁时无影响2. 有补丁时影响小1. 每个函数都预插桩对性能和代码优化有影响2. 有无补丁影响差别不大1. 无补丁时无影响2. 有补丁时影响小1. 无补丁时有轻微影响2. 有补丁时影响较大,冷启动耗时明显增加
兼容性厂商、系统兼容性问题较多,维护难度大兼容性问题少厂商、系统兼容性问题较多,维护难度大兼容性问题少
修改限制函数级修改有限的类级修改有限的类级修改几乎无修改限制
生效速度实时生效实时生效重启生效重启生效
应用场景函数级的Bugfix函数级的Bugfix类级的BugfixBugfix、 功能特性、 版本升级

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

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 腾讯端服务获取更多产品资讯与解决方案。

· 15 min read

苹果的 ​​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"

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

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


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较多,可以考虑使用自动修复脚本:

App Store隐私清单分析器:


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."

​解决方式​
替换 UIWebViewWKWebView,重新编译。


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