## 前言

"架构"是技术人员最熟悉的词汇之一，但深究起来，大多数人并不能准确回答。本文开始系统梳理**系统与子系统**、**模块与组件**、**框架与架构**三组概念，并给出软件架构的精确定义。

---

## 一、系统与子系统

### 什么是系统？

维基百科定义：系统泛指由一群**有关联**的个体组成，根据**某种规则**运作，能完成个别元件不能单独完成的**工作**的群体。

三个关键词：

| 关键词 | 含义 | 示例 |
|--------|------|------|
| **关联** | 个体间有联系，堆在一起≠系统 | 发动机+PC 不是系统，但发动机+底盘+轮胎+车架 = 汽车 |
| **规则** | 个体按规则分工协作，不是各自为政 | 发动机产生动力→变速器→传动轴→车轮，驱动汽车前进 |
| **能力** | 系统能力 ≠ 个体能力之和，产生了**新能力** | 汽车能载重前进，但发动机、变速器各自都不具备这个能力 |

### 什么是子系统？

> 子系统也是由一群有关联的个体所组成的系统，多半会是更大系统中的一部分。

系统和子系统的定义本质相同，区别在于**观察角度**——同一个系统，放在更大的背景下就成为子系统。

以微信为例：

```
微信（系统）
├── 聊天子系统
├── 登录子系统
│   └── 防刷子系统、验证码子系统……
├── 支付子系统
└── 朋友圈子系统
    ├── 动态子系统
    ├── 评论子系统
    │   ├── 防刷子系统
    │   ├── 审核子系统
    │   ├── 发布子系统
    │   └── 存储子系统  ← 不再是业务子系统，而是技术组件（MySQL/Redis）
```

### 核心认知

- **系统**和**子系统**不是绝对的，是相对分层
- 最顶层是系统，内部各层是子系统，直到不能再拆为止
- 业务子系统和技术系统（如 MySQL）是不同维度的划分

---

## 二、模块与组件

这两个概念最容易混淆。维基百科的定义读完之后依然一头雾水：

> 软件模块（Module）是一套一致而互相有紧密关连的软件组织……
> 软件组件（Component）是自包含的、可编程的、可重用的、与语言无关的软件单元……

关键在于**看问题的角度不同**：

| 角度 | 划分得到的单元 | 目的 |
|------|--------------|------|
| **逻辑角度**（业务边界） | **模块**（Module） | 职责分离 |
| **物理角度**（技术实现） | **组件**（Component） | 单元复用 |

> "组件"的英文 Component 可理解为"零件"——物理概念，独立且可替换。

### 实例：学生信息管理系统

从**逻辑角度**拆分（按业务职责）：

```
学生信息管理系统
├── 登录注册模块
├── 个人信息模块
└── 个人成绩模块
```

从**物理角度**拆分（按可部署单元）：

```
学生信息管理系统
├── Nginx（反向代理 / 静态资源）
├── Web 服务器（处理业务逻辑）
└── MySQL（数据存储）
```

两者都对，只是**视角不同**：

```
逻辑拆分（模块）→ 告诉开发者"系统做什么"
物理拆分（组件）→ 告诉运维"系统怎么部署"
```

### 记忆口诀

> 模块向虚（逻辑），组件向实（物理）。

---

## 三、框架与架构

框架（Framework）和架构（Architecture）关联性强，容易混淆。先看定义：

**框架**：
> 软件框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件**规范**，也指提供规范所要求之基础功能的软件**产品**。

两个关键点：
1. 框架是**组件规范**（如 MVC、MVP、MVVM、J2EE）
2. 框架是**基础功能产品**（如 Spring MVC 提供了 `@Controller` 注解、Spring Security、Spring JPA 等）

**架构**：
> 软件架构指软件系统的"基础结构"，创造这些基础结构的准则，以及对这些结构的描述。

核心区别：

| | 框架（Framework） | 架构（Architecture） |
|--|------------------|---------------------|
| 关键词 | **规范** | **结构** |
| 回答的问题 | "这套代码该**怎么写**？" | "系统**由什么组成**，如何组织？" |
| 示例 | Spring MVC、Django、Rails | 业务架构、物理架构、开发架构 |

### 同一系统的多种"架构"

以学生信息管理系统为例，从不同角度拆分，得到不同的"架构"：

**业务逻辑角度**（如何分工）：

```
学生信息管理系统
├── 登录注册模块
├── 个人信息模块
└── 个人成绩模块
```

**物理部署角度**（在哪运行）：

```
学生信息管理系统
├── Nginx（负载均衡）
├── 应用服务器集群
└── MySQL 主从
```

**开发规范角度**（用什么框架）：

```
采用 Spring MVC 框架 → 标准 MVC 架构
```

三种都是正确的架构，只是**视角不同**——这正是 IBM RUP 提出 **4+1 视图**的原因。

---

## 四、重新定义架构

参考维基百科定义，作者给出更精准的描述：

> **软件架构指软件系统的顶层结构。**

看似简单的一句话，却串起了所有概念：

```
"系统是一群关联个体组成"
   → 个体可以是：子系统、模块、组件
   → 架构要回答：系统包含哪些个体

"个体按规则运作"
   → 架构要回答：个体如何协作

"顶层结构" vs "基础结构"
   → 避免将系统架构和子系统架构混淆
   → 顶层 = 最上层，避免层次混乱
```

### 概念串联图

```
系统
├── 子系统
│   ├── 模块（逻辑拆分）
│   └── 组件（物理拆分）
└── 框架（开发规范）
        ↓
     架构 = 顶层结构
```

| 概念 | 回答的问题 |
|------|-----------|
| 系统/子系统 | 整体与局部的关系 |
| 模块 | "这块做什么业务？" |
| 组件 | "这个零件用什么技术实现？" |
| 框架 | "代码该怎么写？" |
| **架构** | **"系统的顶层结构是什么？"** |

---

## 五、示例程序：模块与组件的代码级展示

以下程序模拟学生信息管理系统的模块与组件划分，直观展示逻辑拆分与物理拆分。

```python
#!/usr/bin/env python3
"""
student_sys.py - 演示学生信息管理系统的模块与组件划分

逻辑视角（模块）：按业务职责划分，每个模块对应一类业务功能
物理视角（组件）：按技术实现划分，每个组件对应一个可替换的技术单元
"""

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import Protocol


# ─────────────────────────────────────────────
# 组件层（物理视角，可独立替换的"零件"）
# ─────────────────────────────────────────────

class StorageComponent(Protocol):
    """存储组件接口——物理视角的"零件"，可替换"""
    def save(self, key: str, value: bytes) -> None: ...
    def load(self, key: str) -> bytes | None: ...
    def delete(self, key: str) -> None: ...


class DatabaseStorage:
    """MySQL 存储组件"""
    def save(self, key: str, value: bytes) -> None:
        print(f"[MySQL] INSERT key={key}, size={len(value)} bytes")

    def load(self, key: str) -> bytes | None:
        print(f"[MySQL] SELECT key={key}")
        return b"student_data_mock"

    def delete(self, key: str) -> None:
        print(f"[MySQL] DELETE key={key}")


class CacheStorage:
    """Redis 缓存组件"""
    def save(self, key: str, value: bytes) -> None:
        print(f"[Redis] SET key={key}, size={len(value)} bytes")

    def load(self, key: str) -> bytes | None:
        print(f"[Redis] GET key={key}")
        return b"cached_data_mock"

    def delete(self, key: str) -> None:
        print(f"[Redis] DEL key={key}")


class SearchComponent(Protocol):
    """搜索组件接口"""
    def index(self, doc_id: str, content: str) -> None: ...
    def search(self, query: str) -> list[str]: ...


class ElasticSearchComponent:
    """ElasticSearch 搜索组件"""
    def index(self, doc_id: str, content: str) -> None:
        print(f"[ElasticSearch] INDEX id={doc_id}")

    def search(self, query: str) -> list[str]:
        print(f"[ElasticSearch] SEARCH query={query}")
        return ["doc1", "doc2"]


# ─────────────────────────────────────────────
# 模块层（逻辑视角，按业务职责划分）
# ─────────────────────────────────────────────

@dataclass
class Student:
    sid: str
    name: str
    grade: float


class LoginModule:
    """登录注册模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent):
        self.storage = storage

    def login(self, sid: str, pwd: str) -> bool:
        key = f"session:{sid}"
        self.storage.save(key, f"session_data:{sid}".encode())
        print(f"[LoginModule] sid={sid} login OK")
        return True


class ProfileModule:
    """个人信息模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent):
        self.storage = storage

    def get_profile(self, sid: str) -> Student | None:
        print(f"[ProfileModule] fetching profile for sid={sid}")
        return Student(sid=sid, name="Alice", grade=85.5)


class GradeModule:
    """个人成绩模块（逻辑视角）"""
    def __init__(self, storage: StorageComponent, search: SearchComponent):
        self.storage = storage
        self.search = search

    def query_grade(self, sid: str) -> float:
        print(f"[GradeModule] querying grade for sid={sid}")
        self.search.index(f"grade:{sid}", f"student:{sid}:grade:85.5")
        return 85.5

    def search_grades(self, keyword: str) -> list[str]:
        return self.search.search(keyword)


# ─────────────────────────────────────────────
# 系统组装（演示逻辑 vs 物理）
# ─────────────────────────────────────────────

def build_system() -> dict[str, object]:
    """
    组装学生信息管理系统。

    从物理视角：组件可以是 MySQL、Redis、ElasticSearch
    从逻辑视角：模块对应登录、个人信息、成绩三个业务域
    """
    # 物理组件实例（可替换）
    mysql = DatabaseStorage()
    redis = CacheStorage()
    es = ElasticSearchComponent()

    # 按逻辑职责组装模块（每个模块内部依赖具体组件）
    login_mod = LoginModule(storage=mysql)
    profile_mod = ProfileModule(storage=redis)  # 个人信息用缓存，读快
    grade_mod = GradeModule(storage=mysql, search=es)  # 成绩用 DB + 搜索

    print("=" * 50)
    print("系统组装完成")
    print("逻辑视角（模块）:", [login_mod, profile_mod, grade_mod])
    print("物理视角（组件）:", [mysql, redis, es])
    print("=" * 50)

    return {
        "login": login_mod,
        "profile": profile_mod,
        "grade": grade_mod,
    }


if __name__ == "__main__":
    system = build_system()

    print("\n--- 业务操作演示 ---")
    system["login"].login("S001", "pass123")
    p = system["profile"].get_profile("S001")
    print(f"  → 姓名: {p.name}, 成绩: {p.grade}")
    g = system["grade"].query_grade("S001")
    print(f"  → 成绩查询: {g}")
    results = system["grade"].search_grades("math")
    print(f"  → 搜索结果: {results}")
```

运行效果：

```bash
$ python3 student_sys.py
==================================================
系统组装完成
逻辑视角（模块）: [<LoginModule>, <ProfileModule>, <GradeModule>]
物理视角（组件）: [<DatabaseStorage>, <CacheStorage>, <ElasticSearchComponent>]
==================================================

--- 业务操作演示 ---
[MySQL] INSERT key=session:S001, size=18 bytes
[LoginModule] sid=S001 login OK
[ProfileModule] fetching profile for sid=S001
[Redis] GET key=session:S001
  → 姓名: Alice, 成绩: 85.5
[GradeModule] querying grade for sid=S001
[ElasticSearch] INDEX id=grade:S001
  → 成绩查询: 85.5
[ElasticSearch] SEARCH query=math
  → 搜索结果: ['doc1', 'doc2']
```

### 代码解读

- **模块（Logic）**：按业务职责划分，`LoginModule` / `ProfileModule` / `GradeModule` 各自封装一类业务行为
- **组件（Physical）**：按技术实现划分，`DatabaseStorage`（MySQL）、`CacheStorage`（Redis）、`ElasticSearchComponent` 是可替换的"零件"
- **同一业务模块可依赖不同组件**：`ProfileModule` 用 Redis（读快），`GradeModule` 用 MySQL + ES（存+搜）
- 这正是"模块向虚，组件向实"的具体体现

---

## 总结

- **系统与子系统**由观察角度决定，系统是最大层，子系统是内部各层，本质相同
- **模块**从逻辑角度拆分，关注"做什么业务"；**组件**从物理角度拆分，关注"用什么技术"
- **框架**是开发规范（回答"怎么写"），**架构**是顶层结构（回答"由什么组成、如何组织"）
- 同一系统可以从**业务逻辑、物理部署、开发规范**多个角度分别描述架构，都正确
- 架构的精确定义：**软件架构指软件系统的顶层结构**，关键在于"顶层"二字——避免层次混淆
- 实践中，模块和组件的划分直接影响代码可维护性和系统可扩展性，是架构设计的基本功




架构1：什么是架构

perfetto支持内存泄露定位和调试Heapprofd，本文基于Heapprofd在原生linux上演示，用来追钟malloc的分配和释放

# 什么是heapprofd
heapprofd本意是在android平台上提供低开销的原生堆分析机制，支持 C++ 和 Java 调用栈归因，供 Android 系统上的所有进程使用。这包括Java和原生服务。该机制能够将堆转储导出为跟踪，以便将堆信息与系统中的其他活动关联起来。此功能是在Android 10版本中添加的。其框架图如下

![image.png](/static/img/54eca3d5f001293f25adb3fd5752e478.image.webp)

可以看到，我们通过hprofd.so对程序的malloc进行hook，然后获取其fp，通过libunwind将其栈展开。最终导出成perfetto可以查看的trace文件。

# 使用场景
heapprofd有三种使用场景，分别为
* 对已有进程进行分析
* 在程序启动时加载分析
* 对整个系统进行内存分析

本文以程序启动时加载的方式来介绍分享

# glibc malloc的heapprofd编译
根据架构图，我们需要为glibc生成一个heapperofd的so文件，`src/profiling/memory/malloc_interceptor_glibc_preload.cc` 提供了glibc的实现，我们只需要编译即可
```
# apt-get install -y gn
# python3 tools/install-build-deps --no-dev-tools
# gn gen out/linux_clang_release
# /usr/bin/ninja -C out/linux_clang_release heapprofd_glibc_preload
```
编译完成之后我们得到编译产物为`out/linux_clang_release/libheapprofd_glibc_preload.so`

接下来就可以直接使用perfetto的二进制采集heap信息了，这里使用perfetto提供的python程序`tools/heap_profile`
```
# tools/heap_profile  -h
usage: heap_profile [-h] [-i INTERVAL] [-d DURATION] [--no-start] [-p PIDS] [-n NAMES] [-c CONTINUOUS_DUMP] [--heaps HEAPS] [--all-heaps] [--no-android-tree-symbolization] [--disable-selinux] [--no-versions] [--no-running]
                    [--no-startup] [--shmem-size SHMEM_SIZE] [--block-client] [--block-client-timeout BLOCK_CLIENT_TIMEOUT] [--no-block-client] [--idle-allocations] [--dump-at-max] [--disable-fork-teardown] [--simpleperf]
                    [--traceconv-binary TRACECONV_BINARY] [--no-annotations] [--print-config] [-o DIRECTORY]
                    {android,host} ...

Collect a heap profile

  The PERFETTO_PROGUARD_MAP=packagename=map_filename.txt[:packagename=map_filename.txt...] environment variable can be used to pass proguard deobfuscation maps for different packages.

positional arguments:
  {android,host}
    android             Profile a process on a connected Android device via adb (default).
    host                Profile a local Linux process via LD_PRELOAD.

options:
  -h, --help            show this help message and exit
  -i INTERVAL, --interval INTERVAL
                        Sampling interval. Default 4096 (4KiB)
  -d DURATION, --duration DURATION
                        Duration of profile (ms). 0 to run until interrupted. Default: until interrupted by user.
  --no-start            Do not start heapprofd.
  -p PIDS, --pid PIDS   Comma-separated list of PIDs to profile.
  -n NAMES, --name NAMES
                        Comma-separated list of process names to profile.
  -c CONTINUOUS_DUMP, --continuous-dump CONTINUOUS_DUMP
                        Dump interval in ms. 0 to disable continuous dump.
  --heaps HEAPS         Comma-separated list of heaps to collect, e.g: libc.malloc,com.android.art. Requires Android 12.
  --all-heaps           Collect allocations from all heaps registered by target.
  --no-android-tree-symbolization
                        Do not symbolize using currently lunched target in the Android tree.
  --disable-selinux     Disable SELinux enforcement for duration of profile.
  --no-versions         Do not get version information about APKs.
  --no-running          Do not target already running processes. Requires Android 11.
  --no-startup          Do not target processes that start during the profile. Requires Android 11.
  --shmem-size SHMEM_SIZE
                        Size of buffer between client and heapprofd. Default 8MiB. Needs to be a power of two multiple of 4096, at least 8192.
  --block-client        When buffer is full, block the client to wait for buffer space. Use with caution as this can significantly slow down the client. This is the default
  --block-client-timeout BLOCK_CLIENT_TIMEOUT
                        If --block-client is given, do not block any allocation for longer than this timeout (us).
  --no-block-client     When buffer is full, stop the profile early.
  --idle-allocations    Keep track of how many bytes were unused since the last dump, per callstack
  --dump-at-max         Dump the maximum memory usage rather than at the time of the dump.
  --disable-fork-teardown
                        Do not tear down client in forks. This can be useful for programs that use vfork. Android 11+ only.
  --simpleperf          Get simpleperf profile of heapprofd. This is only for heapprofd development.
  --traceconv-binary TRACECONV_BINARY
                        Path to local trace to text. For debugging.
  --no-annotations      Do not suffix the pprof function names with Android ART mode annotations such as [jit].
  --print-config        Print config instead of running. For debugging.
  -o DIRECTORY, --output DIRECTORY
                        Output directory.
```
接下来我们就可以采集系统上的malloc信息分布了

我们只需要将preload的so设置为我们刚刚编译的so即可。然后直接调用tracebox抓取数据，导出到

```
# python3 tools/heap_profile host -i 4096 -n python3 --preload-library out/linux_clang_release/libheapprofd_glibc_preload.so  --tracebox-binary /root/claude/perfetto_binary/tracebox -- python3 -c "import sys; print('test')"
[829.759] approfd_producer.cc:250 Connected to the service, mode [child].
[829.760] approfd_producer.cc:373 Setting up datasource: non-statsd initiator.
[829.760] approfd_producer.cc:457 Set up data source.
[829.760] approfd_producer.cc:521 Starting data source 1
[829.760] approfd_producer.cc:564 Started DataSource
[829.760] approfd_producer.cc:890 1819873: Received FDs.
test
[829.781] ctory_standalone.cc:161 Child disconnected.
Waiting for profiler shutdown...
[829.782] approfd_producer.cc:580 Stopping data source 1
[829.801]        unwinding.cc:186 Unwinding error 2
[829.831] pprofd_producer.cc:1230 1819873 disconnected from heapprofd (ds shutting down: 1).
[829.839] approfd_producer.cc:346 Shutting down child heapprofd (status 0).
Wrote profiles to /tmp/6c5112 (symlink /tmp/heap_profile-latest)
The raw-trace file can be viewed using https://ui.perfetto.dev.
The heap_dump.* files can be viewed using pprof/ (Googlers only) or https://www.speedscope.app/.
The two above are equivalent. The raw-trace contains the union of all the heap dumps.
```
我们看到trace导出在 /tmp/heap_profile-latest 我们看看文件有哪些
```
heap_dump.1.1819873.libc.malloc.pb.gz  raw-trace
```
这里`heap_dump.1.1819873.libc.malloc.pb.gz`是内存火焰图，而`raw-trace`是perfetto能够识别的trace，我们先加载火焰图看看

![image.png](/static/img/44d9500102c2182b9593da86bd9a70dc.image.webp)

可以看到perfetto正常加载了火焰图并展示

注意这里提供了四类数据

![image.png](/static/img/82ed7f62cd170fea35681fb2b67855f4.image.webp)

也就是
1. malloc的次数
2. malloc的大小
3. 未释放的malloc次数
4. 未释放的malloc大小

现在我们看看原生perfetto的trace的效果，加载`raw-trace`

![image.png](/static/img/3b2432f01d0ed9154ebd7be98b34e2e5.image.webp)

可以看到perfetto的track上提供了`Process 1819873`的track轨道信息。我们点击即可显示下面的火焰图。这个设计就是非常方便我们集成内存火焰图和调度图进行统一分析。

# 总结
本文基于ubuntu的glibc演示了perfetto的heap_profile，通过这个工具我们抓取了malloc的分配和释放，并进行了统计。这样能够非常精准的查看内存的分配信息。有助于我们调试内存问题

# 参考
  - https://perfetto.dev/docs/design-docs/heapprofd-design
  - https://perfetto.dev/docs/design-docs/heapprofd-sampling
  - https://perfetto.dev/docs/design-docs/heapprofd-wire-protocol
  - https://perfetto.dev/docs/data-sources/native-heap-profiler
  - https://deepwiki.com/google/perfetto/7.2-memory-profiling-implementation


性能工具-Perfetto(8)-内存调试

性能的重要点是保证核心程序的关键指标不会因为版本改动而出现回归，perfetto作为当前性能分析的终极神器，自然具备metrics监控的功能，本文介绍perfetto的metrics

# 什么是metrics
从 trace 数据中计算出来的性能指标摘要就是metrics

如果我们只是通过perfetto分析问题，那么metrics貌似没有它的作用

但是如果我们要做性能监控，快速评估程序的健康状态，那这是metrics的作用

# 为什么要metrics
原始 trace 包含大量原始事件（如每条 sched_switch、每个函数调用），数据量很大。

Metrics 是对这些原始数据做聚合统计，输出关键指标，这样就能够做到 持续监控、回归测试

# 使用metrics
使用metrics有三种场景，分别为
* perfetto ui
* python
* trace_processor_shell

## perfetto ui
我们直接点击metrics即可

![image.png](/static/img/e52ae6d6a8f0b031e06b3f913568d6eb.image.webp)

点击run，即可看到指标信息

![image.png](/static/img/16d3e5d071a25308b87f63b4f72bb9ed.image.webp)

可惜的是，perfetto 默认没办法让我们预加载自己编写的metrics，根据官网的建议，我们可以自行搭建或者使用其他方式。

因为每家公司的关键metrics是核心机密

```bash
pip install perfetto
```

## python
默认安装perfetto即可加载metric

```python
result = tp.metric(['android_cpu'])
print(result)
```
代码为了节省篇幅，做了TOP10统计，如下
```
    # 按 CPU 时间排序，显示 top 10
    top_processes = []
    for proc in process_info:
        proc_name = proc.get("name", "unknown")
        threads = proc.get("threads", [])

        # 计算进程总 CPU 时间
        total_runtime_ns = 0
        for thread in threads:
            thread_metrics = thread.get("metrics", {})
            total_runtime_ns += thread_metrics.get("runtime_ns", 0)

        # 计算平均频率
        freq_sum = 0
        freq_count = 0
        for thread in threads:
            thread_metrics = thread.get("metrics", {})
            avg_freq = thread_metrics.get("avg_freq_khz", 0)
            if avg_freq > 0:
                freq_sum += avg_freq
                freq_count += 1
        avg_freq = freq_sum / freq_count if freq_count > 0 else 0

        top_processes.append({
            "name": proc_name,
            "runtime_ms": total_runtime_ns / 1e6,
            "avg_freq_mhz": avg_freq / 1000
        })
```
此时运行后输出如下
```
进程名                                      CPU时间(ms)       平均频率(MHz)
------------------------------------------------------------
com.google.android.GoogleCamera          13131.25        2061
/vendor/bin/hw/android.hardware.camera.provider@2.4-service 4421.94         2022
system_server                            4199.63         1969
/system/bin/surfaceflinger               3441.93         1730
/system/bin/traced_probes                3036.97         1583
com.android.systemui                     2621.47         2010
com.google.android.apps.nexuslauncher    1081.21         2105
com.breel.wallpapers                     1062.34         1667
com.google.android.gms.persistent        1022.56         2103
system                                   978.19          1984
com.google.android.apps.messaging        942.45          2061
com.google.android.googlequicksearchbox:search 913.31          1989
kswapd0                                  888.81          2046
com.android.vending                      843.65          2074
com.google.android.apps.photos           633.85          1894
```

## trace_processor_shell
如果不是为了常态化监控，自行调试metrics最方便的办法是trace_processor_shell，我们可以直接使用`--run-metrics`运行metrics，下面开始演示

perfetto默认预置的metrics：
- `android_cpu`：CPU 使用时间和周期统计
- `android_mem`：内存使用统计
- `android_startup`：应用启动时间分析
- `android_batt`：电池使用情况
- `android_jank`：卡顿检测

我们拿`android_cpu`来实验
```
# ./trace_processor_shell --run-metrics android_cpu ~/example.pftrace
```
输出很长，但是能看到每个进程的metrics, 我们需要排序，这里省略了，trace_processor_shell 默认没帮我做统计
```
android_cpu {
  process_info {
    name: "/system/bin/init"
    process {
      name: "/system/bin/init"
      pid: 1
      is_kernel_task: true
    }
    metrics {
      mcycles: 4
      runtime_ns: 2856408
      min_freq_khz: 1900800
      max_freq_khz: 2457600
      avg_freq_khz: 2164000
    }
    threads {
      name: "init"
      metrics {
        mcycles: 4
        runtime_ns: 2856408
        min_freq_khz: 1900800
        max_freq_khz: 2457600
        avg_freq_khz: 2164000
      }
      core {
        id: 1
        metrics {
          mcycles: 1
          runtime_ns: 570365
          min_freq_khz: 1900800
          max_freq_khz: 1900800
          avg_freq_khz: 1902017
        }
      }
```

# 自建metrics
在实际开发工程中，我们经常要维护一些核心指标，这些指标可以自行开发metrics来实现，现在以android的抖动分析metrics进行实战演示
## 输出结构化
首先我们选用protos将需要的数据格式化出来，生成名为`frame_jitter_metric.proto`的proto文件
```
syntax = "proto2";

package perfetto.protos;

import "protos/perfetto/metrics/metrics.proto";

message FrameJitterMetric {
  optional int64 total_vsync_requests = 1;
  optional double avg_interval_ms = 2;
  optional double min_interval_ms = 3;
  optional double max_interval_ms = 4;
  optional double avg_jitter_ms = 5;
  optional double variance_ms = 6;
  optional int64 potential_dropped_frames = 7;
  optional int64 severe_hitches = 8;
  optional double pct_under_8ms = 9;
  optional double pct_8_to_16ms = 10;
  optional double pct_16_to_24ms = 11;
  optional double pct_over_24ms = 12;
}

extend TraceMetrics {
  optional FrameJitterMetric frame_jitter_metric = 500;
}
```
可以看到这里格式化了一些抖动相关的数据
## 准备sql
既然我们知道需要格式化哪些数据，我们针对这些metrics编写SQL即可，如下
```
CREATE VIEW frame_intervals AS
SELECT
  ts,
  (ts - LAG(ts) OVER (ORDER BY ts)) / 1e6 AS interval_ms
FROM slice
WHERE name = 'requestNextVsync';

CREATE VIEW frame_stats AS
SELECT
  COUNT(*) AS total_vsync_requests,
  AVG(interval_ms) AS avg_interval_ms,
  MIN(interval_ms) AS min_interval_ms,
  MAX(interval_ms) AS max_interval_ms,
  AVG(ABS(interval_ms - 16.67)) AS avg_jitter_ms,
  -- Variance calculation
  AVG((interval_ms - 16.67) * (interval_ms - 16.67)) - AVG(ABS(interval_ms - 16.67)) * AVG(ABS(interval_ms - 16.67)) AS variance_calc,
  -- Dropped frames (interval > 20ms means we missed at least one frame)
  SUM(CASE WHEN interval_ms > 20 THEN 1 ELSE 0 END) AS potential_dropped_frames,
  -- Severe hitches (interval > 32ms = 2+ frames missed)
  SUM(CASE WHEN interval_ms > 32 THEN 1 ELSE 0 END) AS severe_hitches
FROM frame_intervals
WHERE interval_ms IS NOT NULL;

CREATE VIEW frame_distribution AS
SELECT
  100.0 * SUM(CASE WHEN interval_ms < 8 THEN 1 ELSE 0 END) / COUNT(*) AS pct_under_8ms,
  100.0 * SUM(CASE WHEN interval_ms >= 8 AND interval_ms < 16 THEN 1 ELSE 0 END) / COUNT(*) AS pct_8_to_16ms,
  100.0 * SUM(CASE WHEN interval_ms >= 16 AND interval_ms < 24 THEN 1 ELSE 0 END) / COUNT(*) AS pct_16_to_24ms,
  100.0 * SUM(CASE WHEN interval_ms >= 24 THEN 1 ELSE 0 END) / COUNT(*) AS pct_over_24ms
FROM frame_intervals
WHERE interval_ms IS NOT NULL;

-- The view name must match the proto extend field name: {name}_output
CREATE VIEW frame_jitter_metric_output AS
SELECT FrameJitterMetric(
  'total_vsync_requests', total_vsync_requests,
  'avg_interval_ms', avg_interval_ms,
  'min_interval_ms', min_interval_ms,
  'max_interval_ms', max_interval_ms,
  'avg_jitter_ms', avg_jitter_ms,
  'variance_ms', IFNULL(variance_calc, 0.0),
  'potential_dropped_frames', potential_dropped_frames,
  'severe_hitches', severe_hitches,
  'pct_under_8ms', pct_under_8ms,
  'pct_8_to_16ms', pct_8_to_16ms,
  'pct_16_to_24ms', pct_16_to_24ms,
  'pct_over_24ms', pct_over_24ms
)
FROM frame_stats, frame_distribution;
```
可以看到，proto文件和sql文件信息对应起来
## 运行
接下来我们只需要run-metrics即可监控核心指标了，如下
```
# ./trace_processor_shell --run-metrics /tmp/frame_jitter_metric.sql ~/example_android_trace_15s
[054.860] processor_shell.cc:2151 Trace loaded: 57.20 MB in 1.02s (56.0 MB/s)
[perfetto.protos.frame_jitter_metric] {
  total_vsync_requests: 6082
  avg_interval_ms: 2.419482
  min_interval_ms: 0.000677
  max_interval_ms: 20.754741
  avg_jitter_ms: 14.261968
  variance_ms: 12.778111
  potential_dropped_frames: 1
  severe_hitches: 0
  pct_under_8ms: 89.641565
  pct_8_to_16ms: 9.289707
  pct_16_to_24ms: 1.068727
  pct_over_24ms: 0.000000
}
```
可以看到，正常加载了抖动分析的metrics
## 维护
完成metrics的自动化性能看板后，我们只需要推送到daliybuild上进行看护即可。非常方便

# 总结
本文介绍了perfetto的另一个核心功能，metrics。

如果没有metrics，perfetto就是一个利用trace进行分析的调试工具。

如果我们把SQL抽象成metrics的概念，编写核心的sql和格式化的proto文件，这样就能够输出我们想要的关键信息。

利用这些关键信息就可以实现通过核心指标看护系统的性能状态

# 参考

- https://perfetto.dev/docs/analysis/trace-processor
- https://perfetto.dev/docs/analysis/trace-processor-python
- https://perfetto.dev/docs/analysis/metrics

性能工具-Perfetto(7)-指标metrics数据维护

根据之前的文章，我们详细的了解了perfetto的基本使用技巧，这篇文章我们聚焦在perfetto的sql语句，说明其工作原理和如何进行sql查找

# Trace Processor 

Trace Processor 是 Perfetto 生态中最强大的组件之一，它将复杂的二进制 trace 数据转化为可查询的关系型数据库结构，让你可以用 SQL 的方式精确分析性能数据。

Trace Processor 是一个 C++ 库，核心能力包括：

- **多格式解析**：解析 Perfetto protobuf、Systrace 文本、Chrome JSON、`perf.data` 等多种 trace 格式
- **统一 SQL 接口**：将所有数据暴露为一组一致的 SQL 表
- **低延迟查询**：为构建可视化工具优化的查询性能
- **跨平台**：在 Perfetto UI 中作为 WebAssembly 模块运行，也可作为独立工具或 C++ 库使用

# 使用方式
perfetto提供了三种使用sql的办法。分别如下

## CLI版本：trace_processor_shell
通过下载perfetto的binary可以获取 trace_processor_shell
```bash
# wget https://github.com/google/perfetto/releases/download/v54.0/linux-amd64.zip
```
我们可以直接将sql作为参数输入给 trace_processor_shell
```
# ./trace_processor_shell --help
[290.273] processor_shell.cc:1016
Interactive trace processor shell.
Usage: ./trace_processor_shell [FLAGS] trace_file.pb

PerfettoSQL:
 -q, --query-file FILE                Read and execute an SQL query from a file.
                                      If used with --run-metrics, the query is
                                      executed after the selected metrics and
                                      the metrics output is suppressed.
 -Q, --query-string QUERY             Execute the SQL query QUERY.
                                      If used with --run-metrics, the query is
                                      executed after the selected metrics and
                                      the metrics output is suppressed.
 --add-sql-package PATH[@PACKAGE]     Registers SQL files from a directory as
                                      a package for use with INCLUDE PERFETTO
                                      MODULE statements.

                                      By default, the directory name becomes the
                                      root package name. Use @PACKAGE to
                                      override.

                                      Given a directory structure:
                                        mydir/
                                          utils.sql
                                          helpers/common.sql

                                      --add-sql-package ./mydir
                                        Registers modules as:
                                          mydir.utils
                                          mydir.helpers.common
                                        Usage: INCLUDE PERFETTO MODULE mydir.utils;

                                      --add-sql-package ./mydir@foo
                                        Registers modules as:
                                          foo.utils
                                          foo.helpers.common
                                        Usage: INCLUDE PERFETTO MODULE foo.utils;

                                      --add-sql-package ./mydir@foo.bar.baz
                                        Registers modules as:
                                          foo.bar.baz.utils
                                          foo.bar.baz.helpers.common
                                        Usage: INCLUDE PERFETTO MODULE foo.bar.*;
```
## Python API
同样，我们可以直接使用perfetto的python包，也能够进行sql查询,只需要按照perfetto即可
```
pip3 install perfetto
```
安装完成后，pip list可以查看如下
```
perfetto                  0.14.0
```
此时代码可以直接加载sql进行查询
```python
from perfetto.trace_processor import TraceProcessor

tp = TraceProcessor(trace='trace.perfetto-trace')
qr_it = tp.query('SELECT ts, dur, name FROM slice LIMIT 10')
for row in qr_it:
    print(row.ts, row.dur, row.name)
```

## Perfetto UI 内置

在 Perfetto UI 底部的 "Query (SQL)" 标签中直接输入和执行 SQL 查询。点击即可

![image.png](/static/img/212acfdeff39a1b09b2b7176183216fe.image.webp)

# 核心概念

## 时间单位

Perfetto 中所有时间值以**纳秒（ns）** 为单位：
- `ts`（timestamp）：事件开始时间，纳秒
- `dur`（duration）：事件持续时间，纳秒
- 转换：`dur / 1e6` = 毫秒，`dur / 1e9` = 秒

## 唯一标识符

Perfetto 使用内部唯一标识符，而非系统的 PID/TID：
- **`utid`**（Unique TID）：线程的唯一标识
- **`upid`**（Unique PID）：进程的唯一标识
- 同一个 PID 在 trace 中被回收重用时，utid/upid 仍然唯一

## 表基本信息

* slice：一个时间片
* counter：一个计数器
* thread：线程状态

## 表结构

slice存储所有有时长的事件（函数调用、ATrace 标记等），其结构如下

```sql
SELECT
  id,
  ts,                    -- 开始时间（纳秒）
  dur,                   -- 持续时间（纳秒）
  name,                  -- 事件名称
  category,              -- 事件类别
  track_id,              -- 所属轨道
  depth,                 -- 嵌套深度
  parent_id,             -- 父事件 ID
  arg_set_id             -- 参数集 ID
FROM slice;
```

thread 和 process 表提供了关于线程的id信息
```sql
-- 线程信息
SELECT utid, tid, name AS thread_name, upid FROM thread;

-- 进程信息
SELECT upid, pid, name AS process_name FROM process;
```

thread_state 表提供了线程的状态信息
```sql
SELECT
  ts,
  dur,
  utid,
  state,                 -- 'Running', 'R' (Runnable), 'S' (Sleeping),
                         -- 'D' (Uninterruptible Sleep), 'T' (Stopped)
  cpu,                   -- 运行在哪个 CPU
  blocked_function       -- D 状态时阻塞在哪个内核函数
FROM thread_state;
```

counter 表 默认记录了CPU 频率、内存等随时间变化的数值

```sql
SELECT
  ts,
  value,
  track_id
FROM counter;
```
sched_slice 表提供了调度事件，记录每个 CPU 上的调度切换：
```sql
SELECT
  ts,
  dur,
  cpu,
  utid,
  end_state,             -- 线程被切出时的状态
  priority
FROM sched_slice;
```
ftrace_event 表：原始 ftrace 事件

```sql
SELECT
  ts,
  name,
  cpu,
  utid,
  arg_set_id
FROM ftrace_event;
```

# 常用查询模式
现在以android上的完整示例进行sql演示
## 查找最耗时的事件

```sql
SELECT
  s.name,
  s.dur / 1e6 AS dur_ms,
  t.name AS thread_name,
  p.name AS process_name
FROM slice s
JOIN thread_track tt ON s.track_id = tt.id
JOIN thread t ON tt.utid = t.utid
JOIN process p ON t.upid = p.upid
ORDER BY s.dur DESC
LIMIT 20;
```

![image.png](/static/img/f022c73d791e77ce3c65a12cc8e2c2d4.image.webp)

可以看到用时最多的是，PortraitProc的PortraitProcessor::Process

## 统计特定事件的耗时分布

```sql
SELECT
  name,
  COUNT(*) AS count,
  MIN(dur) / 1e6 AS min_ms,
  MAX(dur) / 1e6 AS max_ms,
  AVG(dur) / 1e6 AS avg_ms,
  SUM(dur) / 1e6 AS total_ms
FROM slice
WHERE name GLOB '*Trace GPU completion fence*'
GROUP BY name
ORDER BY total_ms DESC;
```

![image.png](/static/img/d621dd6117ac8a5f3e4452f3ef9034f8.image.webp)

可以看到fence 864 耗时0.71224ms，最长

## 搜索特定名称的 Slice

```sql
-- 使用 GLOB 进行模糊搜索
SELECT ts, dur / 1e6 AS dur_ms, name
FROM slice
WHERE name GLOB '*GPU*'
LIMIT 20;

-- 使用 LIKE 搜索
SELECT ts, dur / 1e6 AS dur_ms, name
FROM slice
WHERE name LIKE '%GPU%'
ORDER BY dur DESC
LIMIT 10;
```

![image.png](/static/img/3cd380b9cfb91eecd38b38efd784586d.image.webp)

这个sql经常使用，直接找slice，然后导出track如下

![image.png](/static/img/7eebb4a78fe48238b75b90c93512ffc4.image.webp)

## 分析线程状态分布

```sql
SELECT
  state,
  SUM(dur) / 1e6 AS total_ms,
  COUNT(*) AS count
FROM thread_state
GROUP BY state
```

![image.png](/static/img/ee9e6f447f48f1b440ff16023e99df1a.image.webp)


## CPU 利用率分析

```sql
-- 每个 CPU 的利用率
SELECT
  cpu,
  SUM(dur) / 1e6 AS busy_ms,
  (SELECT MAX(ts) + MAX(dur) - MIN(ts) FROM sched_slice) / 1e6 AS total_ms,
  CAST(SUM(dur) AS FLOAT) /
    (SELECT MAX(ts) + MAX(dur) - MIN(ts) FROM sched_slice) * 100 AS util_pct
FROM sched_slice
GROUP BY cpu
ORDER BY cpu;
```

![image.png](/static/img/d514d10d7cac9be54af14459e03861ee.image.webp)

## 提取 ftrace 事件参数

```sql
SELECT
  EXTRACT_ARG(arg_set_id, 'prev_comm') AS prev_comm,
  EXTRACT_ARG(arg_set_id, 'prev_pid') AS prev_pid,
  EXTRACT_ARG(arg_set_id, 'next_comm') AS next_comm,
  EXTRACT_ARG(arg_set_id, 'next_pid') AS next_pid
FROM ftrace_event
WHERE name = 'sched_switch'
LIMIT 20;
```

![image.png](/static/img/2b01c37dbd1ddcfb7e227c20b9bddda2.image.webp)

### 10. 内存计数器趋势

```sql
SELECT
  c.ts / 1e9 AS ts_sec,
  c.value / 1024 AS value_kb,
  ct.name AS counter_name
FROM counter c
JOIN counter_track ct ON c.track_id = ct.id
WHERE ct.name LIKE '%mem%'
ORDER BY c.ts;
```

![image.png](/static/img/b4c8454d5a15173f27899a9312dca8bd.image.webp)

## SQLite 的窗口函数

PerfettoSQL 支持 SQLite 的窗口函数，适合计算滑动平均等：

```sql
SELECT
  ts / 1e9 AS ts_sec,
  value,
  AVG(value) OVER (
    ORDER BY ts
    ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING
  ) AS moving_avg
FROM counter
WHERE track_id = 50;
```
![image.png](/static/img/a9875bf5f51bc65d5d8059cbd8a8b56d.image.webp)


## 总结
Trace Processor 和 PerfettoSQL 是 Perfetto 分析能力的核心。熟练掌握这些sql，能够让你性能分析事半功倍

同样的，如果借助ai给你这些sql，相比于原来手搓sql更加轻松


## 参考资料

- [Getting Started with PerfettoSQL](https://perfetto.dev/docs/analysis/perfetto-sql-getting-started)
- [Cookbook: Analysing Android Traces](https://perfetto.dev/docs/getting-started/android-trace-analysis)


性能工具-Perfetto(6)-PerfettoSQL查询

之前详细的介绍了perfetto抓取日志的办法，这些办法都会获得一个pftrace的文件，我们只需要将这个文件在[https://ui.perfetto.dev](https://ui.perfetto.dev) 加载即可显示。本文介绍可视化UI的一些基础使用办法

# 打开 Perfetto UI

![image.png](/static/img/0d0a335cd300d495c294ab1040884ba0.image.webp)

默认界面如上，我们只需要点击 `Open trace file` 将perfetto/tracebox抓到的日志上传上去即可

# 调度全景图
以调度轨迹为例的一张视图如下，我们先看`CPU Scheduling` 这行，这是sched_switch的事件，代表整个系统上的调度情况。这些sched_switch的事件的组成就是 CPU 调度全景图

![image.png](/static/img/b5abf2fcadf45145c8f42a4cf911425e.image.webp)

可以看到这里有16个核心，从粗的角度来看，CPU6，7，8，2，10，14，5几个CPU上运行的任务事件比较密集，我们大概知道当前系统环境的性能状态

# Ftrace Events
`Ftrace Events`代表者ftrace提供的信息,这是原始ftrace ring buffer的信息，因为这份日志抓的是调度轨迹，所以我们只看到了sched_wakeup(蓝色)和sched_switch(黄色)的信息，也就是任务什么时候被唤醒，什么时候切换

![image.png](/static/img/fd27e3f62bfdd1f249b87586ee193aaa.image.webp)

# 调度关键指标
`Scheduler`行提供了调度的关键指标的折线图显示如下

![image.png](/static/img/39f96bbdb1aa0ab1ee4f57a36a791eed.image.webp)

## Runnable Thread Count（可运行线程数） 
当前有多少线程处于R状态，因为Linux不区分runable和running的状态标记，所以这是 所有 CPU 上正在跑的线程 + 等待被调度的就绪队列线程。

  - 值持续很高 → 线程太多，CPU 竞争激烈
  - 突然飙高 → 可能有大量线程被同时唤醒

在我这个例子里面，可以看到当前调度状态非常空闲，因为max是1

## Uninterruptible Sleep Thread Count（不可中断睡眠线程数）
这是影响调度的关键指标，不可中断线程就是D状态的线程，也就是正在等待 I/O、磁盘、网络等不可中断的操作

通常为 磁盘IO/网络IO/锁
  - 值持续 > 0：说明系统有 I/O 瓶颈
  - 值突然升高：可能是某个线程在做大量 I/O
  - 值很高但 CPU idle：可能是磁盘满了或网络卡了

在这个例子里面，可以看到我后台有多个claude在运行，所以max是3，这个3大概率全是磁盘IO状态的线程

## Active CPU Count（活跃 CPU 数）
所谓活跃的cpu计数，其实就是非 idle 的 CPU 核心数，在统计的时候非常简单，就是总CPU减去swapper即可
* Active CPU = 总 CPU 数 - 运行 swapper/N 的 CPU 数

在我这个例子里面，max是14，说明这段时间最大调动了14个cpu工作，但绝大部分情况下是0，说明系统非常空闲

# Clock Snapshots
这是 记录 trace 中不同data source 的时钟基准

![image.png](/static/img/e824eea93bc849fa30b40465e71c74ea.image.webp)

我们之前提过，perfetto是生产者消费者模型，那么生产者可以多个，也就意味着时钟源也是多个,但是我们想要的是系统性分析性能问题，perfetto做了时钟同步规则，就是通过 Clock Snapshots 来实现

  例如：  
  * ftrace 的 sched_switch 事件：ts=1776586699190768428 (REALTIME)  
  * trace_event 的 DrawGame 事件：ts=2398626394976745 (BOOTTIME)

  通过 Clock Snapshots 中的对照关系，Perfetto 可以换算成统一的时间轴进行对比。

在我这个例子里面，是记录了BOOTTIME，perfetto默认支持如下几类事件
* BOOTTIME: clock_gettime(CLOCK_BOOTTIME)，包含睡眠时间
* REALTIME: clock_gettime(CLOCK_REALTIME)，墙上时间 
* TAI: 原子钟时间，不跳变
* MONOTONIC: CLOCK_MONOTONIC，不含系统睡眠
* SCHEDCLOCK: 内核 sched_clock，每个 CPU 不同 
* CGLAST: cgroup last-update 时钟

当然，也支持自定义的时间戳统一, 如果 trace 配置了 allow_all_kernel_clocks: true，Perfetto 会自动把不同数据源的时间转换到同一个时钟基准。

简单来说，我们不需要担心时间不统一的情况，perfetto ui 内部做好了对齐

# 自定义data source
通过sdk内嵌到程序代码的slice也可以一并查看，下面是自定义data source(实际复用了perfetto原生 trace event)的信息，每个长条都是一个slice块

![image.png](/static/img/830f83806bfb3f823d4671e21c6d5b00.image.webp)

# 单一进程视角调度状态
perfetto会抓取单一视角的调度状态，分为runable和running状态，下图是以claude本身的调度情况

![image.png](/static/img/cc08a45e6caac1ec0037c99b5719e570.image.webp)

如果我们放大，可以看到进程的详细状态信息，例如什么时刻出现了 `Uninterruptible Sleep`

![image.png](/static/img/fb165423a4ad11b70cfb3ff6d2e4364e.image.webp)

如果我们点击空白处，就是进程sleep的时间

![image.png](/static/img/47f9df047cf143433e210a18a5d9636b.image.webp)

# 快捷键介绍

## 导航操作

| 快捷键 | 功能 | 说明 |
|--------|------|------|
| `W` | 放大 | 沿时间轴放大 |
| `S` | 缩小 | 沿时间轴缩小 |
| `A` | 左移 | 向左平移时间线 |
| `D` | 右移 | 向右平移时间线 |
| `Shift + 拖拽` | 鼠标平移 | 按住 Shift 拖拽平移 |
| `Ctrl + 滚轮` | 鼠标缩放 | 滚轮放大缩小 |

## 选择操作

| 快捷键 | 功能 | 说明 |
|--------|------|------|
| 点击 | 选择事件 | 点击 slice 查看详情 |
| `.` | 下一个 slice | 跳到同一轨道的下一个事件 |
| `,` | 上一个 slice | 跳到同一轨道的上一个事件 |
| `F` | 聚焦选中事件 | 将选中事件居中显示；再按 F 适配视口 |
| `R` | 转为面积选择 | 将当前选中事件转为面积选择 |
| `Escape` | 清除选择 | 取消所有选择 |

# 分析操作
上面都是简单粗略的查看了系统的性能状态，下面简单介绍一下如何初步分析

## 单事件选择
如果我点击任意的进程内的slice，可以详细的看到这个进程此时的信息，如下

点击任意 slice，底部 "Current Selection" 标签显示：

![image.png](/static/img/c116fe897234c95fa7d5c10fb3f6ff7f.image.webp)

对于ftrace，可以获取ftrace的原始数据信息，这对调试内核的同学来说应该再熟悉不过了

![image.png](/static/img/36b31c26978f1d99848e4cb8baf2bc74.image.webp)

## 区域选择
直接鼠标在上面拉框就可以看到一段区域的统计信息，如果当前模式不在选择模式，可以使用快捷键R转到面积选择

![image.png](/static/img/45b6fb2af428cb43e1b2666c5946d36e.image.webp)

我选中了前7个核的2.68s时间，可以看到下面的统计 snap 在这7个核心上运行了87ms，平均运行时间是378.9us

如果我们要看整个声明周期的，按下ctrl+a可以统计，我们统计claude进程的进程状态如下

![image.png](/static/img/b8302bd0021795b3dddeed4ef6c260cd.image.webp)

可以看到claude运行了353us，sleep了14.68ms，runable状态是34.17us。可以看到系统非常空闲

## SQL 查询
Perfetto的精髓在于能够sql查询，这里先简单的演示如何快速sql。我们直接在顶部输入栏输入
```
: select * from slice 
```
这会查找所有的slice

![image.png](/static/img/da2309df3ec0164c2bb0397cf9f5e7d4.image.webp)

可以看到快速的找到了我自定义程序的slice片段

## 固定Track
根据上面描述的信息，我可以统计所有的running状态
```
: select * from thread_state where state like "%running%"
```
现在可以自定义一个Track proc_sum，如下

![image.png](/static/img/5ae4ff7095f2f11d07856d594c8c67bc.image.webp)

通过这个track可以获取到所有cpu的running状态的统计，如下

![image.png](/static/img/a19bb01214232e6077d883a711531a3e.image.webp)

我们可以选择一个比较密集的状态，查看哪些cpu在运行，如下

![image.png](/static/img/f39399a7bbb2546ef846b83c98b71ab6.image.webp)


# 总结
本文详细介绍了perfetto ui的使用办法，掌握这些技巧就可以初步的看到系统的性能状态，接下来详细介绍SQL进行trace分析

## 参考资料
- [Perfetto UI 官方文档](https://perfetto.dev/docs/visualization/perfetto-ui)
