导语: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端可以实现与原生无差别的首屏和流畅度体验。
框架 | H5 | Hippy/RN | Flutter | Kuikly |
---|---|---|---|---|
开发语言 | JavaScript | JavaScript | Dart | Kotlin |
开发体验 | 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 Hook | Java Hook | MultiDex | Dex替换 | |
---|---|---|---|---|
原理 | 通过修改ArtMethod的入口来实现函数执行逻辑的替换 | 通过编译时在函数前插桩来实现运行时的函数执行逻辑替换 | 利用ClassLoader的类查找机制实现类的替换,但是要解决预加载和内联问题 | 也是用了ClassLoader的类查找机制,但是替换的范围更大,以规避优化问题,几乎整个App都可以替换 |
性能 | 1. 无补丁时无影响2. 有补丁时影响小 | 1. 每个函数都预插桩对性能和代码优化有影响2. 有无补丁影响差别不大 | 1. 无补丁时无影响2. 有补丁时影响小 | 1. 无补丁时有轻微影响2. 有补丁时影响较大,冷启动耗时明显增加 |
兼容性 | 厂商、系统兼容性问题较多,维护难度大 | 兼容性问题少 | 厂商、系统兼容性问题较多,维护难度大 | 兼容性问题少 |
修改限制 | 函数级修改 | 有限的类级修改 | 有限的类级修改 | 几乎无修改限制 |
生效速度 | 实时生效 | 实时生效 | 重启生效 | 重启生效 |
应用场景 | 函数级的Bugfix | 函数级的Bugfix | 类级的Bugfix | Bugfix、功能特性、版本升级 |
综合来看各个方案在性能影响、兼容性、使用限制方面都各有优劣。
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 腾讯端服务获取更多产品资讯与解决方案。