跳转到主要内容
Flashduty Native RUM 分析看板提供开箱即用的可视化仪表板,自动采集并分析用户会话、应用性能、崩溃异常、网络请求等多维度数据,帮助您全面洞察移动应用真实运行状况,快速定位性能瓶颈与异常问题,持续优化用户体验。
分析看板包含 4 个核心分析维度:概览性能分析异常分析资源分析

概览 — 关键指标一目了然

Native RUM 分析看板概览界面,展示 UV、会话数、崩溃率等核心健康指标
概览模块聚焦于移动应用多维度的核心指标:
  • 流量指标 - 监控 UV(独立访客数)、会话数,帮助您把握整体用户活跃趋势
  • 核心健康指标 - 突出显示三个移动应用核心指标:崩溃次数、无崩溃率、应用卡顿率,快速识别应用稳定性问题
  • 用户访问趋势 - 通过时序图追踪 UV 和 Session 的变化趋势,洞察用户活跃规律
  • 用户分布 - 结合地理位置分析用户来源,了解区域用户活跃情况
  • 会话分析 - 统计会话平均时长分布趋势,评估用户粘性与使用深度
  • 版本分布 - 监控不同系统版本(Android/iOS)和应用版本的用户占比,为兼容性优化与版本迭代提供数据支撑

性能分析 — 全面掌控应用体验

性能分析看板展示启动时间、帧率、CPU 和内存使用等关键性能指标
性能分析模块专注于应用启动、页面渲染、交互流畅度等核心体验指标的全链路监控。

核心性能指标

顶部展示四个关键性能指标的 P75 分位值:
  • 应用启动时间(P75):监控应用启动耗时的 P75 分位数,评估启动性能表现。启动时间直接影响用户的第一印象和使用意愿。
  • 帧率(P75):展示应用运行时帧率的 P75 分位数,衡量画面流畅度。目标为 60fps,数值越高表示交互越流畅。
  • CPU 消耗(P75):追踪 CPU 占用率的 P75 分位数,识别计算密集型操作。过高的 CPU 消耗会导致设备发热和耗电增加。
  • 内存使用(P75):监控应用内存占用的 P75 分位数,及时发现内存泄漏或异常增长。

APP 启动时间分析

  • 启动时间趋势图:展示应用启动时间随时间的变化趋势,帮助您评估启动优化效果,及时发现性能退化。
  • 样本分布柱状图:按时间区间统计启动耗时的分布情况(如 0.9425s-0.9642s、1.1162s-1.1379s 等),了解用户真实启动体验的分布特征,识别性能长尾问题。

视图性能明细

按视图名称(页面/Activity/ViewController)统计各项性能指标:
  • 访问次数:展示各视图的访问量,识别核心高频页面。
  • 启动时间:监控各视图的加载耗时,定位加载缓慢的页面。
  • 帧率:追踪各视图运行时的帧率表现,识别渲染性能问题。
  • CPU 消耗:统计各视图的 CPU 占用情况,优化计算密集型页面。
  • 内存使用:监控各视图的内存占用,发现内存泄漏风险。

流畅度分析

按视图名称统计应用流畅度相关指标:
  • 慢帧数:统计渲染耗时超过阈值的帧数(通常为 16.67ms,即低于 60fps),识别卡顿问题。慢帧会导致用户感知到明显的界面不流畅。
  • 冻结帧数:记录界面完全冻结的帧数(通常超过 700ms),这些是严重影响用户体验的性能问题。
  • 长任务数:追踪主线程长时间运行的任务数量(通常阈值为 100ms 或更长),定位性能瓶颈。长任务会阻塞用户交互和界面更新。
  • 卡顿频率:统计应用卡顿的发生频率(次/秒),评估整体流畅度表现。

内存分析

按视图名称统计内存使用详情:
  • 平均内存:展示各视图的平均内存占用,了解常规内存消耗水平。
  • 峰值内存:记录各视图运行期间的内存使用峰值,识别内存压力高峰,预防因内存不足导致的系统终止(OOM)。
  • P75 内存:显示内存占用的 P75 分位数,反映大部分用户的内存使用情况,比平均值更能代表真实体验。

异常分析 — 快速定位与诊断错误

异常分析看板展示崩溃次数、无崩溃率、ANR 率和应用卡顿率
异常分析模块为您提供全方位的错误监控与诊断能力。

核心稳定性指标

  • 崩溃次数:监控应用崩溃的发生总数和趋势,及时发现异常峰值。崩溃会导致应用强制退出,严重影响用户体验。
  • 无崩溃率:跟踪无崩溃会话占比,评估应用整体稳定性表现。行业标准建议无崩溃率应保持在 99.5% 以上。
  • ANR 率:统计 Android 应用无响应(Application Not Responding)的发生比例。ANR 表示应用主线程被阻塞超过 5 秒,用户会看到”应用无响应”对话框。
  • 应用卡顿率:监控发生卡顿的会话占总会话的比例,用于评估应用流畅度问题的影响范围。卡顿通常指主线程长时间阻塞导致的界面冻结、响应延迟或帧率下降,影响用户交互体验。

错误数据统计

  • 错误数:展示错误总数和时序趋势,了解应用健康状况的整体变化。
  • 错误类型分布趋势图:通过堆叠面积图展示崩溃错误(crash_count)与非崩溃错误(non_crash_count)随时间的分布变化,快速识别异常时段和错误类型变化趋势。
    • 崩溃错误(crash_count):导致应用强制退出的严重错误
    • 非崩溃错误(non_crash_count):被捕获的异常,应用可继续运行但功能可能受影响

页面 Crash 排行(Top10)

列出崩溃次数最多的页面或视图控制器,每条记录包含:
  • 错误类型:崩溃的异常类型(如 java.lang.RuntimeException、SIGTRAP 等)
  • 错误信息:错误的详细描述,帮助快速定位问题
  • 错误数:该错误在该页面发生的总次数
  • 会话数:受该错误影响的会话(用户访问)数量
此排行帮助您优先处理影响最大的页面崩溃问题。

热门 Issue(Top10)

展示影响用户最多的问题排行,每个 Issue 是经过聚合的错误集合,包含:
  • 错误类型:Issue 的主要错误类型(如 java.lang.RuntimeException、TypeError、ReferenceError 等)
  • 错误信息:Issue 的典型错误描述,点击可查看详细堆栈和会话信息
  • 错误数:该 Issue 包含的错误总次数
  • 会话数:受该 Issue 影响的会话数量
注意:一个 Issue 可能聚合了多次相同根因的错误。关于 Issue 聚合策略,可查看异常聚合

错误类型分布

  • 错误类型占比(饼图):展示不同错误类型的占比(如 ReferenceError、java.lang.RuntimeException 等),快速识别主要错误来源。
  • 错误类型分布趋势(堆叠面积图):监控各错误类型随时间的变化趋势,及时发现新增错误类型或某类错误的异常增长。

版本 Crash 分布

  • 版本 Crash 分布(饼图):统计不同应用版本的崩溃分布情况,识别高风险版本。
  • 版本 Crash 分布趋势(堆叠面积图):监控各版本崩溃随时间的变化,评估新版本质量,必要时进行热修复或回滚。

系统版本异常分布

  • 系统版本异常分布(饼图):统计不同操作系统版本(如 Android 11、Android 12、iOS 15 等)的异常分布情况,识别系统兼容性问题。
  • 系统版本异常趋势(堆叠面积图):监控各系统版本异常随时间的变化,为系统兼容性优化提供数据支撑。
如需深入分析具体错误,可参阅错误跟踪了解如何调查关键错误、查看错误堆栈、追踪新错误的出现,以及如何在问题修复后验证效果。

资源分析 — 精细化网络性能优化

资源分析看板展示请求数、成功率、响应时间和资源耗时排行
资源分析模块帮助您深入了解应用的网络请求性能,识别优化机会:
  • 请求数:监控网络请求总量的变化趋势,了解应用网络活跃度。
  • 请求成功率:跟踪请求成功的比例,及时发现网络异常。
  • 中位数请求时间:展示请求耗时的中位数变化(如 p50、p75、p95),评估整体网络性能水平。
  • 慢请求:统计响应时间超过阈值的慢请求趋势,定位性能瓶颈。
  • 异常请求:监控失败或错误请求的发生情况,快速识别接口问题。
  • 资源请求状态分布
    • 请求状态码占比:通过饼图展示不同 HTTP 状态码的分布(如 200、404、500),识别异常请求类型。
    • 请求状态码趋势:监控各状态码随时间的变化,及时发现异常峰值。
  • 请求方式分布
    • 请求方法占比:展示不同 HTTP 方法(GET、POST 等)的使用分布。
    • 请求方法趋势:分析各请求方法的时序变化。
  • 静态资源
    • 静态资源调用排行:列出调用频率最高的静态资源(如图片、字体、配置文件等),了解资源使用热度。
    • 静态资源响应排行:识别响应最慢的静态资源,优化资源加载性能。
  • 网络调用排行
    • Host 排行:按请求来源(Host)统计请求数,识别主要依赖的服务端点。
    • 资源耗时排行:列出耗时最长的网络请求,包含耗时详情(DNS 解析、TCP 连接、SSL 握手、首字节时间、响应时间等),精准定位性能瓶颈。

常见问题

状态码为 0 通常由以下原因导致:
  • 请求被取消 - 用户在请求完成前离开页面或取消操作,导致请求中断
  • 网络中断或超时 - 请求在发送过程中遇到网络中断、超时等异常情况,可能导致状态码无法正常返回
  • 证书验证失败 - HTTPS 请求的 SSL 证书验证失败,连接建立前就被中断
  • SDK 兼容性 - 在极少数情况下,特定系统版本或设备可能存在兼容性问题,导致数据采集不完整
  • 错误数 - 指原始错误事件的总数,包括每一次错误发生的记录
  • Issue 数量 - 指经过聚合后的问题数量。Flashduty 会根据错误堆栈、错误类型、发生位置等信息,将相似的错误聚合为同一个 Issue
示例:
错误总数:100 次
Issue 数量:5 个
这表示 100 次错误被聚合成了 5 个不同的 Issue,每个 Issue 可能由不同的根因导致。
聚合的优势:
  • 便于定位问题根因:相同根因的错误归为一个 Issue,避免重复处理
  • 优先级排序:通过影响范围(错误数、会话数)识别最需要修复的问题
  • 追踪修复效果:修复一个 Issue 后,可观察该 Issue 下所有错误是否消失
详细了解 异常聚合策略
1

定位高频崩溃

通过”页面 Crash 排行”和”热门 Issue”快速定位影响最大的崩溃问题。
2

分析堆栈信息

点击具体 Issue 查看详细的错误堆栈和用户环境信息,精准定位问题代码。
3

关注系统兼容性

通过”系统版本 Crash 分布”识别特定系统版本的兼容性问题。
4

监控版本质量

通过”版本 Crash 分布”评估新版本质量,必要时进行热修复或回滚。
5

增强异常捕获

合理使用 try-catch、全局异常处理器,避免未捕获异常导致崩溃。
分位数(Percentile)是统计学中衡量数据分布的重要指标:
分位数含义
P50(中位数)50% 的用户体验优于此值,50% 的用户体验劣于此值
P7575% 的用户体验优于此值,25% 的用户体验劣于此值
P9090% 的用户体验优于此值,10% 的用户体验劣于此值
P9595% 的用户体验优于此值,5% 的用户体验劣于此值
为什么使用 P75 而不是平均值?
  • 平均值容易被极端值影响,可能不能代表大多数用户的真实体验
  • P75 更能反映大部分用户的体验情况,是业界常用的性能评估标准
  • Google 推荐使用 P75 作为核心性能指标
示例:
应用启动时间 P75 = 1.7s
→ 表示 75% 的用户启动时间在 1.7s 以内,25% 的用户超过 1.7s

内存使用 P75 = 233MB
→ 表示 75% 的场景下内存占用在 233MB 以内
这些都是衡量应用流畅度的重要指标:
指标类型阈值用户体验影响优先级
慢帧(Slow Frame)渲染耗时 > 16.67ms(60fps 标准)轻微卡顿偶尔出现可接受,频繁出现需要优化
冻结帧(Frozen Frame)渲染耗时 > 700ms界面完全冻结,用户无法交互严重影响体验,必须修复
长任务(Long Task)主线程执行 > 100ms阻塞用户交互和界面更新需要优化
长任务常见原因:
  • 复杂计算
  • 大数据处理
  • 同步 I/O 操作
优化建议:
  • 将耗时操作移至后台线程
  • 分批处理大量数据
  • 优化算法复杂度
  • 避免在主线程进行同步网络请求或磁盘 I/O
1

定位慢页面

通过”页面加载耗时排行”识别加载最慢的页面,优先优化。
2

优化数据加载

  • 采用分页加载或虚拟列表技术,避免一次性加载大量数据
  • 使用数据预加载和缓存策略,减少等待时间
  • 优化网络请求,合并接口调用
3

简化页面布局

  • 减少视图层级嵌套,降低布局计算复杂度
  • 避免过度使用透明视图和圆角效果
  • 延迟加载非首屏内容
4

优化图片资源

  • 使用合适的图片格式和尺寸
  • 采用渐进式加载或占位图
  • 对图片进行压缩和缓存
5

异步渲染

将复杂视图的渲染操作放到后台线程执行。
ANR(Application Not Responding) 是 Android 系统的应用无响应机制:
  • 当应用主线程被阻塞超过 5 秒时,系统会弹出”应用无响应”对话框
  • 用户可以选择”等待”或”关闭应用”
  • ANR 严重影响用户体验,可能导致用户卸载应用
ANR 常见原因:
  • 主线程执行耗时操作:同步网络请求、大文件读写、复杂计算、数据库操作
  • 主线程等待锁:多线程死锁、等待其他线程释放锁
  • 系统资源不足:CPU 被其他应用占用、内存不足导致频繁 GC
降低 ANR 率的方法:
  1. 避免主线程阻塞 - 将耗时操作移至后台线程(使用 AsyncTask、Coroutines、RxJava 等)
  2. 优化锁使用 - 减少锁的持有时间,避免嵌套锁,使用无锁数据结构
  3. 优化生命周期方法 - onCreate/onResume 等方法要快速返回
  4. 监控和分析 - 使用 StrictMode 发现主线程违规,通过 RUM 看板定位问题
1

定位卡顿来源

通过”长任务监控”和”卡顿时长分布”识别导致卡顿的具体代码。
2

优化主线程任务

将耗时操作(如网络请求、数据库读写、复杂计算、大文件 I/O)移至后台线程。
3

优化 UI 渲染

  • 减少视图层级,降低布局复杂度
  • 避免在主线程进行复杂的视图计算
  • 使用 RecyclerView(Android)或 UITableView/UICollectionView(iOS)的优化技巧
  • 合理使用硬件加速
4

优化列表性能

  • 实现视图复用机制
  • 优化 item 布局复杂度
  • 避免在 item 绑定时执行耗时操作
5

监控工具配合

结合性能分析看板和系统工具(Android Profiler、Xcode Instruments)定位具体卡顿代码。
建议根据业务特点和用户预期,设置合理的卡顿检测阈值(建议 200-500ms)。
登录态用户识别对于需要用户登录的应用(如电商、社交、金融等),您可以在用户登录后调用 SDK 的用户标识方法:设备指纹识别对于无登录态的应用,推荐基于设备信息生成稳定的设备指纹并上报用户标识:
平台可用标识符
AndroidAndroid ID、IMEI(需权限)、广告 ID
iOSIDFV(Identifier for Vendor)、IDFA(需用户授权)
1

识别慢请求

通过”资源耗时排行”定位响应时间最长的接口。
2

分析耗时分布

查看 DNS 解析、TCP 连接、SSL 握手、首字节时间等各阶段耗时,精准定位瓶颈。
3

针对性优化

优化方向具体措施
DNS 优化使用 DNS 缓存、HTTPDNS
连接优化启用 HTTP/2、连接复用、减少重定向
传输优化启用 GZIP 压缩、优化数据格式、减少请求体积
接口优化优化后端接口性能、使用 CDN 加速静态资源
1

分析启动数据

  • 查看”应用启动时间(P75)“指标,了解大部分用户的启动体验
  • 通过”启动时间趋势图”评估优化效果,避免性能退化
  • 查看”样本分布柱状图”识别长尾问题
2

延迟非关键初始化

将非必要的初始化操作延迟到首屏渲染后执行,缩短启动时间。
3

优化依赖加载

减少启动期间加载的第三方 SDK 和库,采用懒加载策略。
4

简化首屏布局

降低首页视图层级复杂度,减少首次渲染耗时。
5

使用启动优化工具

  • Android: 使用 App Startup Library 管理组件初始化顺序
  • iOS: 利用 Lazy Initialization 延迟初始化非关键组件
Flashduty RUM 通常在数据产生后的 1-3 分钟内完成采集和展示。在网络状况良好的情况下,大部分数据可实现准实时更新。

指标口径参考

概览指标

指标采集字段说明
UVusr_id去重后的用户总数
会话数session_id应用被打开使用的总会话数量
会话平均时长-会话总时长除以会话总数
使用频次-会话总数除以活跃用户数

性能指标阈值

指标采集字段良好中等
应用启动时间view_app_start_time2s 以内4s 以内超过 4s
帧率view_refresh_rate_average55 FPS 以上50 FPS 以上低于 50 FPS
CPU 消耗view_cpu_ticks_per_second低于 40 ticks/s低于 60 ticks/s60 ticks/s 以上
内存使用view_memory_average低于 100 MB低于 200 MB200 MB 以上
峰值内存view_memory_max低于 200 MB低于 400 MB400 MB 以上

流畅度指标

指标定义采集字段
慢帧数渲染耗时超过 16ms 的帧数-
冻结帧数渲染耗时超过 700ms 的帧数-
长任务数执行时间超过 100ms 的任务数量long_task_duration
卡顿频率平均每秒发生冻结的次数-

稳定性指标

指标计算方式说明
崩溃次数直接统计由未处理的异常或信号引起的崩溃总次数
无崩溃率1 减去崩溃会话占比建议保持在 99% 以上
ANR 率ANR 会话数除以总会话数UI 线程阻塞超过 5 秒时触发(Android)
应用卡顿率卡顿会话数除以总会话数主线程无响应超过 250ms 时计入(iOS)

延伸阅读

SDK 接入与配置

数据分析与监控