监控 on Last Stand

APM-B端平台设计

Thu, 07 May 2026 15:42:48 +0800

B 端 APM 平台的目标不是“展示所有数据”，而是让研发团队在最短路径内完成：发现问题、判断影响、定位原因、分配负责人、验证修复、防止再次劣化。

一、信息架构

flowchart TB
Home["质量概览"] --> Stability["稳定性"]
Home --> Performance["性能体验"]
Home --> Network["网络"]
Home --> Session["用户会话"]
Home --> Release["版本发布"]
Home --> Alert["告警中心"]
Home --> Config["SDK 配置"]
Stability --> Crash["Crash"]
Stability --> Watchdog["Watchdog"]
Stability --> FOOM["FOOM"]
Performance --> Launch["启动"]
Performance --> View["页面"]
Performance --> Freeze["卡顿/掉帧"]
Performance --> Resource["资源"]
Release --> Gray["灰度对比"]
Release --> Gate["发布门禁"]
Alert --> Rule["规则"]
Alert --> Notify["通知"]
Alert --> Silence["静默"]

一级导航不要按技术实现命名，比如 Kafka、ClickHouse、符号化任务；应该按用户任务命名，比如稳定性、性能体验、网络、发布、告警。

二、首页质量概览

首页回答三个问题：

当前版本稳不稳？
过去一段时间有没有变差？
最应该处理的 Top 问题是什么？

核心卡片：

APM-C端SDK架构

Thu, 07 May 2026 15:42:48 +0800

iOS APM SDK 是整个系统的数据入口。它运行在真实用户设备上，和业务 App 共进程、共资源、共生命周期，所以设计目标不是“能力越多越好”，而是 低开销、可控制、可降级、可追责、可合规。

一、SDK 职责边界

SDK 应该做：

采集 Crash、Watchdog、FOOM、卡顿、启动、网络、页面、MetricKit、业务 Trace 等现场。
生成并维护 session_id、view_id、action_id、resource_id、trace_id 等关联 ID。
做轻量预处理：去重、聚合、脱敏、采样、压缩、加密。
按数据价值分级落盘和上报。
接收远程配置，动态控制模块开关、采样率、阈值和熔断。

SDK 不应该做：

复杂 OLAP 查询。
大规模归因计算。
服务端符号化。
跨用户聚合。
长时间 CPU 采样或高频全量堆栈采样。
未经允许采集请求 body、用户输入、定位、通讯录等敏感数据。

二、分层架构

flowchart TB
API["Public API
start / identify / track / trace / breadcrumb"]
Core["SDK Core
生命周期 / 插件管理 / 远程配置 / 采样 / 隐私"]
Context["Context Manager
App / Device / User / Session / View / Trace"]
Plugins["Plugin Layer
Crash / Watchdog / FOOM / FPS / Launch / Network / MetricKit / Business"]
Processor["Event Processor
标准化 / 脱敏 / 聚合 / 去重 / 优先级"]
Store["Local Store
mmap / WAL / SQLite / 文件队列"]
Uploader["Uploader
批量 / 压缩 / 加密 / 重试 / 熔断"]
API --> Core
Core --> Context
Core --> Plugins
Plugins --> Processor
Context --> Processor
Processor --> Store
Store --> Uploader
Uploader --> Core

推荐模块：

APM-业界方案

Thu, 07 May 2026 15:42:48 +0800

本文对比目前 iOS APM 领域主流的七大方案，从接入形态、原理、能力深度、适用场景四个维度深入剖析。每个方案都包含核心技术原理与关键源码解读，帮助读者做"自研还是三方、自研该参考哪个"的选型决策。

一、全景对比

quadrantChart
title "iOS APM 方案对比"
x-axis "低侵入" --> "高侵入"
y-axis "浅能力" --> "深能力"
quadrant-1 "专业级"
quadrant-2 "旗舰级"
quadrant-3 "入门级"
quadrant-4 "高性价比"
MetricKit: [0.05, 0.45]
Firebase: [0.15, 0.4]
"Xcode Organizer": [0.02, 0.35]
Sentry: [0.3, 0.65]
Bugly: [0.25, 0.5]
"Matrix (微信)": [0.6, 0.88]
"Slardar (字节)": [0.65, 0.95]
"Hertz (美团)": [0.5, 0.8]
"Alita (阿里 mPaaS)": [0.55, 0.85]

二、MetricKit + Xcode Organizer（Apple 官方）

2.1 定位

Apple 自 iOS 13 推出的官方性能监控框架，完全系统侧实现，SDK 零开销，是所有方案的基线。

APM-产品与架构设计

Thu, 07 May 2026 15:42:48 +0800

APM 系统的产品设计不能从“要采哪些指标”开始，而应该从“谁要用这些数据解决什么问题”开始。iOS APM 的产品形态可以分成 C 端真实用户体验、B 端研发治理平台两面；技术实现则分成 iOS SDK、数据平台、Web 控制台三层。

一、产品边界

APM 的 C 端不是一个给用户看的页面，而是运行在用户设备里的监控能力；APM 的 B 端才是研发、测试、架构、运维、产品、客服使用的控制台。

视角	C 端	B 端
用户	App 真实用户	研发、测试、架构、运维、产品、客服
形态	iOS SDK，无感运行	Web 控制台、告警、工单、报表
核心体验	不打扰、不拖慢、不泄露隐私	快速发现、下钻、归因、分发、验证
主要风险	SDK 自身引发卡顿、崩溃、耗电、流量	指标口径混乱、告警疲劳、无法定位
成功标准	数据真实且采集成本低	问题能被稳定治理，发布劣化能被拦截

因此产品设计要同时回答两类问题：

C端：真实用户到底经历了什么？
B端：团队如何用这些数据把问题修掉？

二、用户角色

APM B 端不是只给研发看，不同角色需要不同入口。

角色	典型问题	核心视图
客户端研发	我负责的模块有没有新 Crash、卡顿、FOOM	我的 Issue、堆栈详情、会话时间线
后端研发	某接口在真实用户侧是否变慢、失败率是否升高	网络资源详情、Trace 关联、接口维度大盘
测试/QA	灰度版本是否比线上版本变差	版本对比、灰度监控、回归报告
架构/技术负责人	App 整体质量趋势如何，哪个团队拖后腿	质量大盘、模块排行、SLO
产品/业务负责人	性能是否影响转化、留存、下单	页面秒开率、关键路径成功率、业务漏斗
客服/运营	单个用户为什么反馈无法使用	用户查询、Session 轨迹、错误上下文

设计 B 端时不要把所有人塞进同一个大盘。首页可以共用，但下钻路径要按角色分流。

APM-指标体系

Thu, 07 May 2026 15:42:48 +0800

APM 的第一步不是写代码，而是定义指标。一个 App 的性能好坏不是一句话能说清的，必须把模糊的"快 / 稳 / 省"拆解为可量化、可对比、可报警的数字。本文把业界常用指标按"稳定性 / 流畅性 / 启动 / 资源 / 业务 / 网络"六大族分类，并补充 RUM 的 Session / View / Action / Resource / Error 口径，给出每个指标的定义、计算方式、典型目标值与常见陷阱。

一、指标设计原则

设计指标前先达成共识：

1.1 北极星分层

graph TB
L0[用户体验北极星
留存率 / NPS]
L1[业务指标
秒开率 / 转化率 / 关键路径完成率]
L2[技术指标
FPS / Crash率 / 启动时间]
L3[原子指标
单帧耗时 / 内存峰值 / 单请求耗时]
L0 --> L1 --> L2 --> L3

好的指标体系应该：技术指标能解释业务指标，业务指标能解释北极星。否则就是"为了采集而采集"。

1.2 分位数思维

永远不要只看平均值。同一个启动指标：

设备	平均	P50	P90	P99
iPhone 15	800ms	750ms	900ms	1200ms
iPhone SE 2	2000ms	1500ms	3500ms	8000ms

平均值把两者拉成 1400ms，但 iPhone SE 的 P99 用户"实际等了 8 秒"。APM 的所有耗时指标都必须同时提供 P50 / P90 / P99。

APM-数据模型与上报

Thu, 07 May 2026 15:42:48 +0800

APM 的上报系统不只是“把 JSON 发到服务端”。它要解决三件事：数据如何建模、事件如何关联、移动端如何可靠且低成本地上传。这一层设计不好，后面的服务端聚合、B 端下钻和告警都会变成补丁工程。

一、设计目标

数据模型与上报层要同时满足：

目标	说明
可关联	页面、操作、网络、错误、性能现场能被 Session 串起来
可聚合	同类问题能按 fingerprint、版本、机型、页面、接口聚合
可重试	弱网、后台、进程退出后数据不轻易丢
可去重	重试不会造成重复统计
可采样	高频数据不会压垮端侧、网络和服务端
可脱敏	敏感数据在端侧就被过滤或掩码
可演进	Schema 版本升级后新旧 SDK 可以共存

二、RUM 对象模型

推荐用 RUM 层级组织端侧事件：

Session
 View
 Action
 Resource
 Error
 LongTask / Freeze
 Custom Event

对象	含义	示例
Session	一次用户前台使用会话	打开 App 到退后台
View	一个页面实例	首页、详情页、支付页
Action	一次用户操作	点击下单、搜索、提交表单
Resource	一次资源请求	HTTP 请求、图片资源、WebView 资源
Error	一次错误	Crash、业务错误、网络错误、JS 错误
LongTask / Freeze	一次长任务或卡顿	主线程阻塞 800ms

RUM 模型的价值是把“点状指标”变成“用户故事”：

APM-数据采集

Sat, 02 May 2026 22:32:27 +0800

本文聚焦 iOS APM SDK 的采集层，把 APM-指标体系 定义好的指标落地到具体代码与底层原理。按照采集对象分八个模块展开：崩溃、卡死、内存/OOM、FPS 卡顿、启动、网络、CPU/磁盘、业务。

原理深度与相关文章联动：本文给出整体采集设计与关键代码；单项（如 Mach 异常、Signal、MemoryGraph 等）的纯原理细节在"崩溃/卡顿/启动/耗电"系列中已有深入剖析，本篇通过链接形式串联，避免重复。

一、采集技术图谱

graph TB
subgraph Hook[Hook 技术]
H1[Method Swizzling
Objective-C Runtime]
H2[fishhook
C 函数符号重绑]
H3[Objc Categroy + +load]
H4[KVO / NSNotificationCenter]
H5[C++ Virtual Table Hook]
end
subgraph System[系统 API]
S1[MetricKit]
S2[os_signpost / OSLog]
S3[Runtime
task_* / thread_*]
S4[libdispatch signpost]
S5[URLSessionTaskMetrics]
end
subgraph Signal[信号/异常]
E1[NSSetUncaughtExceptionHandler]
E2[signal / sigaction]
E3[Mach Exception Port]
E4[libc++ abi 异常]
end
subgraph Sampling[采样]
P1[RunLoop Observer]
P2[Timer/GCD Source]
P3[CADisplayLink]
P4[backtrace 回溯]
end

二、崩溃采集

原理文章：崩溃-原理 · 崩溃-Mach异常 · 崩溃-信号处理 · 崩溃-采集

APM-服务端数据架构

Thu, 07 May 2026 15:42:48 +0800

APM 服务端本质上是一个面向移动端遥测数据的实时数据平台。它不是简单的“接收接口 + MySQL”，而要处理高吞吐写入、弱 Schema 演进、实时聚合、明细查询、符号化、Issue 聚类、告警计算和配置反控。

一、整体架构

flowchart TB
SDK["iOS SDK"] --> Gateway["接入网关"]
Gateway --> RawQueue["Raw Queue
Kafka / Pulsar"]
RawQueue --> Clean["清洗标准化
Schema / 脱敏 / 维度补全"]
Clean --> Stream["实时计算
Flink / Spark Streaming"]
Clean --> RawStore["原始冷存储
OSS / HDFS / S3"]
Stream --> DetailStore["明细存储
ClickHouse / Doris"]
Stream --> MetricStore["指标存储
Prometheus / VictoriaMetrics / M3"]
Stream --> SearchStore["搜索存储
Elasticsearch / OpenSearch"]
Stream --> IssueService["Issue 聚合服务"]
IssueService --> Symbol["符号化服务"]
IssueService --> Alert["告警服务"]
Alert --> Notify["IM / Email / Phone / Webhook"]
DetailStore --> Query["查询 API / BFF"]
MetricStore --> Query
SearchStore --> Query
IssueService --> Query
Config["配置服务"] --> SDK

核心原则：

iOS APM 与 RUM 体系总览

Thu, 07 May 2026 15:42:48 +0800

APM（Application Performance Monitoring / Management）是面向线上真实用户的性能稳定性观测与治理体系。对 iOS App 来说，它不是一个单纯的 Crash SDK，也不是一个“把指标画成图”的后台，而是一套贯穿 C 端真实用户体验、端侧采集 SDK、服务端数据平台、B 端研发治理平台 的完整系统。

RUM（Real User Monitoring）是 APM 在真实用户体验侧的核心模型：把用户的一次使用会话拆成 Session / View / Action / Resource / Error / LongTask 等对象，用统一 ID 串联页面、交互、网络、错误和性能现场。没有 RUM 模型，APM 很容易退化成一堆孤立指标；有了 RUM 模型，平台才能回答“哪个真实用户在什么页面做了什么操作，随后发生了什么性能或稳定性问题”。

一、重构后的系列结构

文章	定位
APM（本文）	系列入口：APM/RUM 定义、B/C 端边界、技术分层、建设路线
APM-产品与架构设计	产品视角：C 端体验、B 端用户、角色视图、治理闭环
APM-指标体系	指标口径：稳定性、流畅性、启动、资源、网络、业务、RUM 指标
APM-C端SDK架构	iOS SDK 架构：插件化、远程配置、采样、隐私、低开销、防自崩
APM-数据采集	采集技术：Crash、Watchdog、FOOM、卡顿、启动、网络、MetricKit、业务 Trace
APM-数据模型与上报	事件模型、RUM ID、协议、落盘、批量、重试、脱敏、采样
APM-服务端数据架构	接入网关、消息队列、实时计算、存储、符号化、Issue 聚合、配置下发
APM-B端平台设计	Web 控制台：大盘、详情页、用户会话、告警、工单、发布防劣化
APM-业界方案	MetricKit、Sentry、Firebase、Bugly、Matrix、Slardar、Hertz 等方案对比

重构后的主线是：