支付链路整体承载着云音乐业务的主要交易流，随着营收业务的快速增长，链路整体复杂度不断提升，也带来稳定性、支付效率的压力。2023年我们针对支付链路每个环节进行了专门的尝试，并针对一些核心指标的增长取得了优化效果。本文主要介绍云音乐会员团队在支付链路优化方面做的一些解决方案和思路。

商业背景

支付链路，从用户进入支付触点开始，到订单支付完成、合约结束，承载了整个云音乐业务的主要交易流，覆盖会员、数字专辑、商城等各类业务场景，以及支付宝、微信、抖音等各类支付渠道和支付方式。随着营收业务的快速增长，链路整体复杂度不断提升，也带来稳定性、支付效率等压力。

2023年我们针对支付链各个环节特意尝试了不同的优化方案，取得了一些核心指标增长的优化成果，本文主要介绍云音乐会员团队在支付链优化方面做的一些解决方案和思路。

优化概述

完整的支付链条包括引导用户购买的支付触点、不同形态和意图的收银员、承载营销和产品信息的订单服务、第三方支付渠道以及支付后的履约和留存。支付链条是一个巨大的流量漏斗，每个环节都存在一定的用户流失，比如收银员到账率影响用户流入、复杂的订购链条中的流量流失、各种原因导致的支付失败等。

我们建立了全链路支付漏斗监测体系，对重要环节的流失问题进行了详细分析，期间还选取了一些关键指标和扩展因素，如支付成功率、错误率、支付应用安装情况、手机厂商信息、周期性支付数据等，共同构成了支付市场。

最后我们选取支付链中的一些环节，采用不同的策略和工具集来解决客户流失问题，如下图所示：

收银员性能优化

结账页面是用户购买的核心场景，页面曝光度与订单成交量呈显著正相关，因此需要优化页面加载体验，减少页面加载时间，增加页面曝光度，进而增加最终转化的订单量。

页面性能分析

目前云音乐的核心收银台全部是 RN 页面。完整的 RN 应用加载流程如下图所示，可分为三个阶段：白屏阶段、页面首帧（FCP）阶段、页面内容可见（LCP）阶段。性能优化的目的是尽可能减少 LCP 的加载时间，让用户尽快看到完整的页面。因此可以根据 RN 应用的加载特点，分阶段进行优化，降低整体的加载时间。下图展示的是一些常见的优化方式。

优化业绩经营指标

该数据来自于收银员A，经过各种手段优化之后。

常规优化是指主进程加载-

默认的 RN 页面运行在按需加载的进程中，进程的 fork、初始化、加载会带来数百毫秒的额外开销，在低端机器上更加明显。由于收银页面的崩溃率和内存控制都比较好，跨进程的优势并不明显，所以将收银容器切换至主进程更适合业务场景。

RN离线包

RN离线包是指将文件预先存储在客户端本地，这样就无需在运行时下载文件。目前常见的有两种方法：

离线包优化效果虽然很好，但是也会造成一定的资源浪费，增加APP体积，目前仅针对P0业务应用会开启该配置。

RN 解析

RN 解包就是将应用拆分成两个部分：基础包和业务包。这样做有两个好处：

+

RN 升级到 0.70 之后使用了引擎，引擎的一大优势就是预编译和字节码执行能力，以下是使用新架构+引擎+预编译之后的对比数据：

Android 小米8 SE 首帧提升 71.5%，LCP 提升 40.1%； 红米 Note 9 pro 首帧提升 77.3%，LCP 提升 41.9%； iPhone 6 首帧耗时提升 63%，iPhone 12 提升 42%； LCP iPhone 6 提升 48.5%，iPhone 12 提升 18.3%。 相关链接可看前文 《网易云音乐 RN 新架构升级实践》

动态导入

随着 RN 应用越来越复杂，RN 的体积也会越来越大。为了避免加载巨大的代码文件，可以将代码拆分成多个小文件。将首屏的代码打包成一个文件立即加载执行，而首屏之外的代码可以在与页面交互后再进行懒加载，从而提升页面加载性能。

接口预加载

提前声明需要预加载的接口和参数，在RN容器初始化时提前并行进行接口请求，从而减少接口加载阶段时间。

优化收益 = Math.min( 容器初始化耗时 , 接口加载耗时 )

深度优化定制

由于中低端 设备性能较差，即便 RN 应用实现了上述通用的优化措施，但在中低端设备上依然无法完全实现秒开 App 的体验。因此为了不断提升核心页面的性能，我们还针对业务场景定制了一些非通用的优化措施；

RN 预渲染

RN预渲染是指在客户端启动/空闲时提前对RN页面进行预渲染，当用户真正打开RN页面时，无需加载直接可见，实现真正意义上的秒开。但这种优化方式略显激进，会增加APP的内存压力。因此需要制定相应的优化策略，在合适的时间、合适的人、合适的应用开启RN预渲染，最大化​​预渲染的利用率；

合适的时间

合适的人

适用应用

RN 静默加载

在某些场景下，用户在满足某些触发条件和策略（比如播放付费片段、会员过期等）后，会弹出浮层/弹窗收银台引导用户支付。这类收银台被称为被动收银台，具有用户非主动点击、无感知出现时机、加载过程可取消、用户取消率高等特点。对于被动收银台来说，可以将页面静默地在后台加载，加载完成后再展示给用户，从而减少用户感知的加载时间，进而减少用户在页面加载过程中的取消率，最终提高页面访问量。

用户感知的加载时间：用户等待页面加载的时间

主动收银：用户感知加载时间=页面LCP时间-用户点击开始时间

被动收银员：用户感知加载时间=页面LCP时间-白屏/加载感知时间

视图静默加载

静默加载期间，视图不显示，用户可以正常与原界面视图交互。当收银台视图完全加载完毕后，RN通知直接显示完整视图：用户所见即所得，从而减少加载损耗，增加页面曝光量。

接口预请求

与接口预加载不同，预加载依赖于用户网络，如果用户网络加载时间超过容器加载时间，那么整体加载速度还是会受到网络加载的影响。

接口预请求在触发前一个业务场景/策略时请求网络，接口请求完成后加载相应页面。例如听会员歌时需要在浮动收银台弹出前请求相关 SKU 数据，返回完整后再直接将数据带入 RN 容器中。

数字收银员 H5->RN 迁移

由于历史原因，数字收银平台有原生容器和H5容器，但两种方案都存在一定的缺点：

RN 迁移统一是兼顾业务和性能的解决方案，一方面开发迁移成本低，另一方面可以复用前面提到的各种 RN 优化工具集，性能和触达率接近 。同时 H5 迁移到 RN 成本低，只需要替换 View 层（CSS -> JSX）和平台 API 适配层即可完成迁移，整体逻辑通用一致。

IAP系统及优化方法-数据预取

在常规的IAP支付流程中，整个流程是从请求苹果服务器获取当前交易商品的对象开始的。由于苹果服务器架设在海外，只有香港等地有中转点，导致在负责国内用户的网络环境下请求苹果服务器时错误率较高。当获取商品信息失败时，用户的支付流程也会失败。这部分错误在云音乐App中占比很大，所以我们针对这个流程进行了预取优化。

优化结果

缓存命中率：0%->96.52%

-4 错误量：减少为0

消耗品支付成功率：+1.35pt

订阅产品支付成功率：+0.46pt

IAP 产品预取流程

当APP启动并访问首页时，云音乐服务器会发送热门商品列表，热门商品用于请求苹果服务器获取对应的商品对象并缓存在内存层面，按照合适的时间和频率对缓存进行更新和维护。

IAP 产品预取后的付款流程

用户在客户端发起对产品X的支付；客户端检查是否有产品X的IAP产品对象缓存；若有，则直接使用该缓存对象进行后续支付流程；若没有，则按照原支付流程，先请求IAP产品对象；

-

此解决方案对 IAP 支付成功率有不显著的正向提升。消费品预取流程的整体支付成功率比订阅品提高更多。IAP 支付整体的预取错误（= -4）几乎已完全解决。

2 是苹果在 iOS 15 和 11 中引入的一套更新改进的框架，用于处理应用内购买和订阅相关功能。2 提供了一些新功能和改进，使开发者能够更方便地实现应用内购买和订阅流程。 需要使用的新功能如下：

访问应包括所有现有的功能并与流程保持一致；需要注意的关键点如下：

为了避免一次性全面发布对收益造成较大且不可预知的影响，需要逐步上量，通过AB实验随时掌控上量节奏和降级回流。

苹果只发布了最新版本，所以有些逻辑需要重新开发。比如产品预取逻辑和产品对象是完全不同的两个类，所以预取逻辑需要重新开发。

对于未完成收据的处理与2有较大区别，云音乐内部验票流程中有缓存收据、轮询重试等优化措施，2中类似的逻辑处理方式需要结合配套API重新开发。另外2中存在与2同时监控同一张收据的情况，因此需要隔离两组未完成收据的监控逻辑。

混音问题，云音乐主站核心是使用OC开发的，所以为了不影响整体项目，方便使用，所有必要的流程都使用OC开发，暴露的接口都使用OC封装；业务层使用时，只需要使用上层OC接口即可，无需使用接口

具体的预期改善

端侧能力同步更新

支付调用依赖第三方渠道，目前云音乐App集成支付宝、微信支付、银联支付、抖音支付、网易支付等多个第三方支付渠道。

云音乐App第三方支付SDK更新频率较低，但部分新版第三方支付SDK引入新功能，稳定性提升。此类SDK同步更新升级可提升支付成功率。例如新版支付宝SDK引入淘宝登录功能，可减少未安装支付宝App的用户，让H5页面支付更加便捷。

优化结果

支付成功率（升级渠道单笔支付）：+3.29%

更新并验证

SDK升级比较简单，只需要按照第三方官网的说明升级版本号、更改兼容方式即可。但是SDK升级也有一定的难度：

基于以上问题，我们采用如下支付SDK升级发布流程，分导流/灰度/渠道等阶段验证不同问题。

第三方支付SDK升级验证流程

支付保留措施 IAP 支付保留短信 - iOS

iOS系统IAP支付成功率较低，有购买意愿的用户误付容易导致订单丢失，对云音乐整体收益影响较大。因此在IAP支付失败后，我们通过短信提醒用户支付失败，引导用户再次支付。

优化结果

主动购买UV：+0.28%

具体计划

云音乐不采用用户支付失败后主动调用前端短信接口的方案，因为可能有些前端页面在支付接口返回之前就关闭了，覆盖范围有限。

如果要覆盖所有未支付成功的IAP订单，需要在IAP支付不成功时，延迟一定时间后发送延时消息，服务器内部会判断订单状态，根据业务自定义的延时时间检查订单是否已支付，若还未支付，则通知业务方，触发后续的留存动作。

相对于没有留单措施来说，丢失订单的挽回还是非常有效的，这个方案的投入产出比非常好。

总结

在过去的一年中，我们建立了交易链路领域相关漏斗，并基于分析对链路的不同环节进行了优化，如核心收银机的性能优化、第三方渠道支付的稳定性保障与提升、支付留存等。事实证明，作为创收业务的核心模块，支付链路的优化不仅能提升支付效率和用户体验，还能有效赋能业务，带动关键业务指标的提升。

未来我们将继续聚焦交易链路领域优化技术漏斗和策略，探索端侧智能与收益策略的结合；