1. 简介
随着移动互联网的深入发展,用户体验已成为决定应用程序成败的核心因素之一。高质量、高稳定性和高性能不再仅仅是技术团队的“加分项”,而是企业保持用户留存、提升品牌声誉、实现商业增长的基本保障。在千万级应用的竞争环境下,任何轻微的崩溃、卡顿或启动延迟都可能导致用户流失率成倍上升。
《2025 移动应用行业质量性能报告》由 Bugly 团队通过分析 Bugly 平台上移动应用的质量及性能数据(包含 1000+ 个产品,亿级真实设备的数据)整理并提供。
本报告旨在为业务质量性能提供参考,帮助业务团队了解业内整体的质量及性能数据,确定自身产品在质量性能指标的优劣,方便业务团队制定优化目标等。
该报告将从行业、用户量等维度对崩溃率、卡顿、内存、启动及网络等几项关键指标进行统计分析及呈现。同时包含主流设备中的性能数据表现,及部分指标数据及业务常见问题进行进一步的分类分析。
2. 应用质量性能数据对产品影响
App 崩溃、卡顿等质量性能数据对用户和应用商店评分具有决定性影响。来自业内各个机构的调查研究显示(相关数据可参考 5.4 声明部分):
- 经历过崩溃的用户,7天内再次打开 App 的概率会下降 70%;
- 启动时间每增加 1 秒,用户流失率平均增加 15%;
- 遇到性能问题的用户,在应用市场给出 1 星差评的概率是其他用户的 5 倍;
在质量方面,崩溃率与其对应的 30 天卸载率之间有着一定的关联,来自相关数据的分析,对于崩溃率高于 0.5% 的业务而言,新用户 30 天卸载的概率高达 83%。
App 的启动时间直接影响新用户 7 日留存率,二者之间存在明显的负相关关系。
优化 App 质量性能指标,不仅是纯技术投入和优化目标,同时对业务增长也有着明显的贡献。 来自业内相关团队的实践结果,其在启动速度(-1.5s)、页面卡顿率(ANR -30%)、崩溃率(< 0.1%)等方面的优化,给其业务留存率分别带来了 5.5%、3.2% 和 8.1% 的提升。
3. 用户移动设备现状
随着移动设备硬件和软件的不断迭代更新,业务 App 的运行环境也在不断的发生变化。Bugly 通过大盘数据的计算,从操作系统版本和硬件配置信息两个角度宏观了解目前用户的设备状况。
3.1 系统版本数据
- Android 系统版本 Top 10 及其占比
-
Android 平台目前的主流系统版本为 2024 年 10 月发布的 Android 15,占比高达 32.71%;
-
2025 年 6 月发布的 Android 16 版本,目前也有 1.86% 的占比;
-
Android 11 及以前的旧版本,依然有一定的占比(合计超过 17.03%),版本碎片化情况依然存在,对于业务适配不同系统依然有一定的挑战;
- iOS 系统版本 Top 10 及其占比
-
iOS 平台目前主流系统为 2024 年 9 月发布的 iOS 18,占比超过 54.36%;
-
2025 年 9 月随新设备推出的 iOS 26 目前也有 15.49% 的占比;
-
iOS 平台得益于其封闭的生态,系统版本更新较为集中,在 Top 10 的系统版本总计占比高达 76.65%,且都为近两年发布的系统;
3.2 设备配置数据
性能数据与设备配置中的处理器和内存高度关联,为此 Bugly 使用 处理器 + 内存 的组合维度,统计不同处理器和内存配置的设备数据,以便了解目前的设备配置情况。
- Android 设备配置 Top 20 及其占比
-
Android 设备中,占比最多的配置为 骁龙8 Gen 3 + 12G 内存组合,占比 4.4%;
-
Top 20 的设备其内存配置都为 8G 及以上,且普遍使用中高端处理器,Top 20 总占比高达 41.01%;
-
Android 设备的内存配置显著改善,8G 及以上内存的设备,占比超过 80%;
-
相较于多年前,目前 Android 平台的设备配置普遍都比较高;
- iOS 设备配置 Top 20 及其占比
-
iOS 设备中,占比最高的配置为 A16 + 6G 内存组合 (2022年9月搭载在 iPhone 14 Pro 上市,并在 iPhone 15 中继续使用),占比 19.71%;
-
得益于 iOS 平台的封闭生态,硬件配置相对统一,Top 20 设备配置总占比高达 99%;
-
iOS 平台的内存主要还分布在 4G 和 6G 设备,其总占比 59.58%,此外 3G 内存一下的设备,还有 10.73%;
-
8G 内存设备主要是 A18 Pro 和 A19 及 M 系列芯片搭载,目前占比 33.21%,明显低于 Android 平台;
4. 质量及性能报告
4.1 App 崩溃
App 崩溃指用户在 App 使用过程中,遇到因为程序错误而突然闪退,导致用户操作中断的情况。崩溃对用户体验影响极大,从而影响业务的口碑和用户留存。
Bugly 通过捕获 App 崩溃事件及对应的现场数据,为开发者提供对应的崩溃堆栈及相关日志,方便开发者定位崩溃原因,修复程序错误,从而降低崩溃率。
4.1.1 各平台崩溃率数据
-
无论是 Android 还是 iOS 平台,崩溃率数据 P50 在 0.1% 左右,意味着有一半的业务其崩溃率数据高于 0.1%;
-
其中,Android 平台的崩溃率 P90 为 0.74%,意味着有 10% 的业务,其崩溃率高于 0.74%,甚至部分业务高于 1%,对于用户存留有着显著的影响;
4.1.2 各行业崩溃率数据
-
崩溃率数据在不同行业之间存在明显差异,其中休闲娱乐、商务办公较其他行业普遍较高,尤其是 P90 数据;此种差异说明崩溃率指标与应用形态和用户使用时长之间存在着明显的关联;
-
阅读学习类应用的崩溃率在两个平台都处在较低水平;
4.1.3 不同 DAU 规模应用崩溃数据
-
不同业务规模下,崩溃率数据也呈现不同表现,随着业务规模的增加,两个平台的崩溃率数据都呈现下降趋势;
-
50W 以下 DAU 业务规模的产品,其崩溃率数据在两个平台都明显高于其他业务;
-
可见较大的业务团队,在产品质量的优化和保障方面有着更大的投入和优势;
4.1.4 主要崩溃类型
- 各平台崩溃类型和原因占比数据
-
内存问题依然是崩溃的主要问题,其中 Android 平台占比 54%,iOS 平台占比 58%;
-
iOS 平台的主要内存问题为访问违例(EXC_BAD_ACCESS)和悬空指针访问,占比分别为 28% 和 23%;
-
Android 由于主要开发语言的差异,主要问题集中访问违例(SIGSEGV)和空指针访问,占比分别为 30% 和 21%;
-
逻辑错误中主要原因为未处理的编程语言异常;
- 各编程语言与崩溃类型及原因占比
-
内存错误中,重灾区依然是 C/C++, Objective-C/C++ 等语言,占比 43%,相较而言 Java 等语言在这方面存在显著的优势;
-
在 C/C++ 语言开发领域,使用智能指针等先进的内存管理机制,在一定程度上可以减缓内存错误等问题;可以推荐使用 ASan 等工具(Bugly 提供线上 ASan 检查工具)来精确定位此类问题;
-
Objective-C/C++ 语言领域可以考虑使用 Swift 替代,其现代化的语言开发范式,在应对顽固的内存问题中有一定的优势;
-
Java 主要集中在空指针访问中,建议广泛使用 @Nullable 和 @NonNull 注解,配合 IDE 的静态分析工具;
-
在逻辑异常中,合理使用语言的异常处理机制,确保异常被捕获后能记录日志并优雅降级,而不是直接 Crash;
-
使用 Kuikly 进行跨平台的开发,可以利用 Kotlin 语言的安全特性(编译时安全、空安全、协程等),减少内存、空指针等问题。
4.2 卡顿/ANR
卡顿即用户在使用过程中遇到 App 响应不及时,页面跳转动画等不流畅的情况。小的卡顿影响用户在使用 App 时的体,严重的卡顿(App 长时间无响应)甚至可能触发系统策略,直接被系统 KILL(SIGKILL),在用户角度表现为闪退(与崩溃类似)。
Bugly 通过挂起率来衡量业务交互 UI 的流畅程度,挂起率被定义为单位时间内用户遇到 App 不响应的时间占比。
ANR 率用于衡量严重卡顿被系统 KILL 的情况,ANR 发生的设备数与总联网设备数的占比统计为 ANR 率。
无论是卡顿还是 ANR ,Bugly 平台均提供了堆栈信息,方便业务定位导致卡顿/ANR 的具体原因,从而进一步实现优化。
4.2.1 各平台 ANR 率及卡顿率数据
- 各平台 ANR 率数据
-
ANR 率数据的 P50 值在 Android 平台接近 0.1%,其对用户的使用体验影响严重程度不亚于崩溃;
-
Android 平台的 P90 值为 0.71%,10% 以上业务的 ANR 率表现处于糟糕水平,对于用户留存和主观评价有者显著影响;
- 各平台挂起率数据
-
挂起率的 P50 值在两个平台表现比较接近,且 20s/h 的水平处于较优秀的水平;
-
挂起率 P90 值两个平台差异较大,Android 平台的值远高于 iOS 平台,对于这 10% 用户(业务)而言,还需要进一步优化相关问题;
4.2.2 各行业 ANR 率及卡顿率数据
- 各行业 ANR 率数据
-
休闲娱乐、影音视听在 Android 和 iOS 平台的 ANR 表现均高于其他行业,尤其是在 P90 中,差异尤为明显;
-
办公商务、游戏、通信聊天等行业的 ANR 率 P75 及 P90 在 Android 和 iOS 表现差异显著,应是 Android 平台存在个别业务其指标表现较差导致;
-
阅读学习在两个平台上 P90 都尤为突出,应是个别业务指标表现较差导致;
- 各行业挂起率数据
-
聊天通讯中挂起率数据 P90 在两个平台均表现较高,与挂起率有这相似的结果;
-
在 iOS 平台,除聊天通讯外,游戏、生活娱乐行业中的挂起率 P90 的值较其他行业也比较高;
4.2.3 不同 DAU 规模应用卡顿及 ANR 率数据
- 不同业务规模 ANR 数据
-
ANR 率数据随业务规模的增加,在两个平台均表现为整体下架趋势,在 iOS 平台表现更为明显,Android 平台则主要表现在 P90 值;
-
Android 平台的 P50、P75 随业务规模的增加变化表现不明显,可以推测,引起 ANR 率整体变化的主要原因应是集中在部分设备或产品中;
- 不同业务规模挂起率数据
-
挂起率数据在不同业务规模上与 ANR 率呈相反趋势,100W DAU 以上业务规模的产品整体高于 100W DAU 以下产品;
-
尤其在 100W~500W 区间,P90 明显高于其他规模产品,应是存在部分产品的挂起率数据较差引起;
-
随着业务规模的增加,App 场景逻辑更为复杂可能是导致挂起率增高的原因之一;
4.2.4 不同类型设备下的卡顿及 ANR 率数据
- 设备配置 Top 20 ANR 率数据
-
ANR 率与设备配置存在明显的关联,整体而言,处理器性能越好的设备,其 ANR 率表现越低;
-
在 Android 平台中,中端处理器(骁龙 7、骁龙6、天玑7等)其 ANR 数据都高于高端系列处理器(骁龙8、天玑9等);
-
iOS 平台除 A10、A11、A12 几款早期处理设备中 ANR 率较高,其他较为新的处理器设备的 ANR 率都较好;
- 设备配置 Top 20 挂起率数据
-
挂起率数据与 ANR 率类似,也与设备配置存在明显关联,且设备性能越好,其指标表现越好;
-
挂起率 P90 数据与设备之间的关联度更为明显,高端或新款处理器设备上,挂起率的 P90 表现明显优于中端或旧款处理器设备;
4.2.5 主要卡顿类型
- 各平台卡顿类型和原因占比数据
-
各平台卡顿的主要原因集中在 UI 布局、IO 访问、锁等待及跨进程访问几点,占据了卡顿中的近 80% 的问题;
-
其中,复杂的 UI 构建布局计算、UI 资源加载解析是造成 UI 布局耗时的主要原因。在 UI 布局构造逻辑中,合理化的布局计算、异步的资源加载解析等逻辑可以有效的改善 UI 卡顿;
-
在主线程进行 IO 操作是造成卡顿的另一主要原因。一般是通过间接方式引入的 IO 操作,通过使用 Bugly 提供的卡顿问题,可以快速发现并找到此类问题并进行异步化处理;
-
跨进程通信和锁等待是较为容易被忽略的一个原因,绝大部分情况下,可能并不会造成卡顿。但由于锁等待的时间是不确定的,因此还是会在线上环境中有大量此类问题的上报。在主线程逻辑中尽量减少此类行为对降低 App 卡顿率有很大的帮助。
4.3 内存/OOM
内存资源一直是移动设备的重要资源,尤其是在移动设备中,内存资源有限,如何合理使用和优化内存资源变得尤为重要。过高的内存使用,会引发系统触发 OOM (表现为 App 闪退)或 App 在进入后台后被频繁回收,给用户体验带来负面影响。
Bugly 收集并统计了 App 运行过程中,单次进程执行期间的物理内存的最大值,定义为峰值内存。同时对于内存使用过渡触发 OOM 的情况进行了统计,将发生 OOM 的设备数与联网设备总数的比例定义为 OOM 率。
4.3.1 各平台 OOM 率及内存数据
- 各平台 OOM 率数据
- 得益于 Android 平台内存配置普遍较高,其 OOM 率表现也明显优于 iOS 平台;较大的内存配置在 OOM 指标上有着明显优势;
- 各平台内存峰值数据
-
内存峰值数据对用户而言,没有明显的感知;但其数据趋势与 OOM 率存在着明显的关联关系;
-
对于内存配置整体更高的 Android 平台,其内存峰值指标相较于 iOS 平台也会更高;
4.3.2 各行业 OOM 率及内存数据
- 各行业 OOM 率数据
-
休闲娱乐、影音视听、游戏等行业的 OOM 率显著高于其他业务类型,这与其业务类型存在一定关联;
-
聊天通讯行业在 Android 平台 OOM 率与 iOS 平台存在显著差异,应是部分业务数据比较突出影响;
- 各行业内存峰值数据
与 OOM 率类似,峰值内存在休闲娱乐和游戏行业其指标值更高,与此类行业的产品业务逻辑存在着明显的关联性。
4.3.3 不同 DAU 规模应用 OOM 率及内存数据
- 不同业务规模 ANR 率数据
-
Android 平台 500W 以下设备的 OOM 率略偏高,尤其是在 P90 上,但其 P50 差异不明显,应是部分业务数据较为突出影响;
-
iOS 平台也有类似表现,主要差异发生在 P90 上,多为部分业务数据较为突出影响;
- 不同业务规模内存峰值数据
- 业务规模与内存峰值之间没有特别明显的关联;
4.3.4 不同类型设备下的 OOM 率及内存数据
- 设备配置 Top 20 OOM 率数据
-
Android 平台 Top 设备内存均为 8G 以上,其 OOM 率相对较低,与 OOM 率 P90 相差甚远,可见 OOM 多发生在低内存设备中;
-
Android 平台上,更高的内存设备内存并未普遍获得更低的 OOM 率,可能与系统的策略存在一定关联;
-
iOS 平台中,高内存设备的 OOM 率明显优于低内存的设备;
- 设备配置 Top 20 内存峰值数据
-
与 OOM 率类似,Android 平台中更高的物理内存设备并未获得更高的峰值内存,可见依然是系统策略影响所致;
-
在 iOS 平台中,物理内存越大,其峰值内存值也普遍较高,与 OOM 率表现类似;
4.4 启动耗时
启动耗时,指用户从点击 App 图标开始(或应用初始化开始),到完成第一帧绘制(可以响应用户交互)的时间。优秀的启动时间,可以减少用户等待时间,改善用户体验。
4.4.1 各平台启动耗时数据
- 各平台启动耗时数据
-
启动数据在两个平台表现差异不大,且 P50 耗时在 1s 左右,表现较优;
-
P90 耗时高达 2.5s 以上,因此是有 10% 的情况下,业务启动 App 的等等时间是大于 2.5s 的;
4.4.2 各行业启动耗时数据
- 各行业启动耗时数据
-
不同行业之间,启动耗存在一定差异,但普遍差异不明显;
-
Android 平台的影音视听,iOS 平台的聊天通讯的 P90 表现较其他业务明显较差,应是个别业务启动耗时数据影响;
4.4.3 不同 DAU 规模应用启动耗时数据
- 不同业务规模启动耗时数据
启动耗时与业务规模之间关联性较小,不同业务规模之间启动耗时的差异不大;
4.4.4 不同设备类型下的启动耗时数据
- 设备配置 Top 20 启动耗时数据
-
启动耗时与设备配置之间存在明显关联,更高端的处理器(或更新设备),其启动耗时相对较低;
-
在 Android 平台中,中端处理器(骁龙 7、骁龙6、天玑7等)其启动耗时数据都高于高端系列处理器(骁龙8、天玑9等);
-
iOS 平台除 A10、A11、A12 几款早期处理设备中启动耗时明显较高,其他较为新的处理器设备的启动耗时明显更低;
-
A19,A19 Pro 的设备,启动耗时 P50 更是接近 500ms,其 P75 也接近 1s,表现尤为突出;
4.5 网络请求
- 各省份之间网络请求平均延迟数据:
数据说明:
-
行对应 client(请求发起方) 区域,列对应 host(请求接收方) 区域;
-
延迟数据为 TCP 建立连接的平均耗时,单位 ms,不区分运营商;
-
client,host 均按照发起请求/接收请求的数量由多到少排序;
-
表格中仅包含请求量较为集中的主要地区,更多网络数据下钻维度可在Bugly平台获取;
-
网络请求延迟与地理位置有明显的关联,在省内部署服务,减少跨地域的请求能够带来更为显著的提升;
-
对于湖南、湖北等地区位于中部地区的服务,从其他地区发起的请求耗时都较为低,对于只有单一节点部署的服务可以优先考虑;
● 主要运营商网络情况
数据说明:
-
行为对应省份,列为该省份内请求 host IP 地址所属的网络运营商;
-
延迟数据为 TCP 建立连接的平均耗时,单位 ms;
-
表格中仅包含广东省内的请求数据,更多网络数据下钻维度可在Bugly平台获取;
-
在广东内,三大主流网络运营商网络请求延迟表现较为接近,其中电信延迟较其他家表现更优;
-
广电与教育网用户较少,但其网络请求的延迟要明显优于其他运营商;
5. 声明
- 该报告中的数据均采集自 Bugly 平台 2025 年 1 月 1 日 ~ 2025 年 10月 30 日前的数据;
- 参与计算的数据中,已剔除部分因 DAU 较低等原因导致的极端值等脏数据;
- 报告中的各项指标、产品行业类型等,均采用 Bugly 平台的指标计算方式和产品分类方式,可能与其他平台存在一定的差异;
- 应用质量性能数据对产品影响数据来源:
- The Critical Connection Between App Load Times and User Retention Rates in Marketplace Platforms: Analyzing the Latest Update
- How Mobile App Stability Impacts User Retention | Appunite
- 网站性能如何影响转化率 | Cloudflare
- 网络请求的数据来自 Bugly 业务的网络监控数据,可能受相关业务逻辑,用户群体等因素影响,仅供参考意义。
Bugly(bugly.tds.qq.com)是专业的监控定位分析平台,作为腾讯端服务联盟(tds.qq.com)的重要成员,提供研发全流程、全平台、智能化的监控定位分析解决方案,助力全球开发者高效地构建高质量应用。