## 前言

理解一个事物的本质，最好的方式是追寻它出现的历史背景和推动因素。本文梳理从机器语言到软件架构的演进脉络，揭示软件架构为何在 20 世纪 90 年代才真正流行。

---

## 一、软件开发演进四阶段

### 阶段1：机器语言（1940 年之前）

最早的软件直接用二进制 `0` 和 `1` 表示机器指令。例：在 8086 上做 `s=768+12288-1280`，机器码如下：

```
101100000000000000000011   ; 赋初值
000001010000000000110000   ; 加法操作
001011010000000000000101   ; 输出结果
```

三难：**太难写、太难读、太难改**。一个 `1` 敲成 `0` 就可能导致火箭坠毁（1963 年 Mariner 1 事故，源于一行 FORTRAN 代码错误）。

### 阶段2：汇编语言（20 世纪 40 年代）

用助记符替代二进制操作码，例如：

| 机器语言 | 汇编语言 |
|---------|---------|
| `1000100111011000` | `mov ax, bx` |

解决了"读"的问题，但依然**面向机器**——程序员必须精确了解 CPU 指令、寄存器、段地址等底层细节。同一个程序，为 Intel CPU 写一次，还需为 Motorola CPU 重新写一次，指令完全不同。

### 阶段3：高级语言（20 世纪 50 年代）

| 语言 | 年份 | 全称 | 用途 |
|------|------|------|------|
| Fortran | 1955 | FORmula TRANslator（公式翻译器） | 科学计算 |
| LISP | 1958 | LISt Processor（枚举处理器） | AI 研究 |
| Cobol | 1959 | Common Business Oriented Language | 商业数据处理 |

高级语言让程序员**不再关注机器底层**，只关注具体业务。同一段代码，经编译器处理后可在多种 CPU 上运行。

```lisp
; LISP 实现 4+6=?
(+ 4 6)  ; → 10
```

### 阶段4：两次软件危机与编程范式演进

**第一次软件危机（1960s~1970s）**：软件规模复杂度激增，质量低、项目延期、超支严重。典型案例：IBM System/360 操作系统，2000+ 程序员、5000 人年、100 万行代码、5 亿美元投入，进度却一再延迟。

**解决方案**：
- "软件工程"概念诞生（NATO 会议 1968/1969）
- Dijkstra 发表《GOTO 有害论》（1968）→ **结构化程序设计**：抛弃 GOTO，自顶向下、逐步细化、模块化
- Pascal 语言诞生（结构化语言的代表）

**第二次软件危机（1980s）**：硬件快速发展导致业务需求和编程领域急剧扩展，核心问题从"逻辑复杂"变为"扩展复杂"。

**解决方案**：**面向对象编程**（C++ → Java → C#），1967 年的 Simula 语言首次提出，但因第二次软件危机才真正流行。

---

## 二、软件架构为何在 1990 年代才出现？

20 世纪 60 年代 Dijkstra 就已涉及软件架构概念，但真正流行却是在 1990 年代。原因在于玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在 1994 年发表的《软件架构介绍》中指出的：

> "When systems are constructed from many components, the organization of the overall system—the software architecture—presents a new set of design problems."

**翻译**：随着软件系统规模增加，计算相关的算法和数据结构不再是主要设计问题；当系统由许多组件构成时，整个系统的**组织方式（软件架构）** 成为新的设计挑战。

换言之：**只有规模足够大的系统，才需要软件架构**。大公司（Rational、Microsoft）由于系统规模大，才率先遇到以下问题：

```
系统规模庞大  →  内部耦合严重，开发效率低
    ↓
系统耦合严重  →  牵一发动全身，修改扩展困难
    ↓
逻辑复杂      →  易出问题，出问题难排查修复
```

### 演进规律：拆分粒度越来越粗

```
模块（结构化编程，1960s）   →  对象（面向对象，1980s）   →  组件（软件架构，1990s）
     粒度粗                       粒度更粗                      粒度最粗
     层次低                       层次更高                     层次最高
```

本质：面对规模不断增长的系统，**拆分粒度越来越粗，拆分层次越来越高**，目的都是将复杂度控制在可管理范围内。

> 如果 IBM System/360 在 1990 年代开发，质量、效率、成本都会好得多——当然，我们就看不到《人月神话》了。

---

## 三、示例程序：编程范式演进对比

以下程序用三种方式实现同一个功能——计算并输出三个数的求和与平均值，演示从机器语言思维到高级语言思维的演进。

```python
#!/usr/bin/env python3
"""
paradigm_demo.py - 演示编程范式从机器思维到高级思维的演进

阶段1（机器思维）：像汇编一样，直接操作寄存器/变量地址
阶段2（结构化思维）：分步骤、自顶向下、模块化
阶段3（面向对象思维）：抽象出数据和操作，消息传递

运行方式: python3 paradigm_demo.py
"""

from dataclasses import dataclass
from typing import Callable


# ─────────────────────────────────────────────
# 阶段1：机器语言式的直接操作
# 不封装，像汇编一样直接处理数据地址
# ─────────────────────────────────────────────

def machine_style_demo():
    """
    模拟机器语言/汇编风格：
    - 直接操作数值，不封装
    - 没有函数抽象，一步一步做
    """
    print("=== 阶段1: 机器语言风格（直接操作） ===")

    # 直接用数值计算，不命名，就像寄存器操作
    a = 10
    b = 20
    c = 35

    # 第一步：计算总和（像汇编一步一步来）
    total = a
    total = total + b
    total = total + c

    # 第二步：计算平均值
    count = 3
    average = total / count

    # 第三步：输出
    print(f"  总和: {total}, 平均值: {average}")
    return total, average


# ─────────────────────────────────────────────
# 阶段2：结构化程序设计风格
# 自顶向下、逐步细化、模块化
# ─────────────────────────────────────────────

def compute_sum(values: list[float]) -> float:
    """模块1：计算总和"""
    total = 0.0
    for v in values:
        total += v
    return total


def compute_average(total: float, count: int) -> float:
    """模块2：计算平均值"""
    return total / count


def output_result(total: float, average: float) -> None:
    """模块3：输出结果"""
    print(f"  总和: {total}, 平均值: {average}")


def structured_style_demo():
    """
    结构化程序设计风格：
    - 函数封装（模块化）
    - 自顶向下分解
    - 每个函数做单一职责的事
    """
    print("=== 阶段2: 结构化程序设计风格（模块化） ===")

    values = [10.0, 20.0, 35.0]

    # 自顶向下调用各模块
    total = compute_sum(values)
    avg = compute_average(total, len(values))
    output_result(total, avg)
    return total, avg


# ─────────────────────────────────────────────
# 阶段3：面向对象风格
# 抽象数据+行为，消息传递
# ─────────────────────────────────────────────

@dataclass
class StatisticsResult:
    """统计结果：聚合了多个相关数据"""
    total: float
    average: float
    count: int
    values: list[float]

    def report(self) -> str:
        return f"总和={self.total}, 均值={self.average:.2f}, 数量={self.count}"


class DataProcessor:
    """
    数据处理器（对象）：
    - 封装了数据和操作
    - 对外暴露行为（方法），隐藏内部细节
    """
    def __init__(self):
        self._values: list[float] = []
        self._total: float = 0.0
        self._computed: bool = False

    def add(self, value: float) -> "DataProcessor":
        """链式调用：add() 返回 self"""
        self._values.append(value)
        self._total += value
        self._computed = False
        return self

    def compute(self) -> StatisticsResult:
        """计算统计结果（延迟计算）"""
        count = len(self._values)
        avg = self._total / count if count > 0 else 0.0
        self._computed = True
        return StatisticsResult(
            total=self._total,
            average=avg,
            count=count,
            values=self._values.copy()
        )


def oop_style_demo():
    """
    面向对象风格：
    - 数据和操作封装在一起
    - 通过消息传递（方法调用）交互
    - 可扩展、可替换（多态的潜在基础）
    """
    print("=== 阶段3: 面向对象风格（封装+消息） ===")

    # 创建处理器对象，链式添加数据
    processor = DataProcessor()
    processor.add(10.0).add(20.0).add(35.0)

    # 发送消息让对象执行计算
    result = processor.compute()
    print(f"  {result.report()}")
    return result.total, result.average


# ─────────────────────────────────────────────
# 主函数：运行并验证三种风格输出一致
# ─────────────────────────────────────────────

def main():
    print("编程范式演进对比演示\n")

    r1_t, r1_a = machine_style_demo()
    r2_t, r2_a = structured_style_demo()
    r3_t, r3_a = oop_style_demo()

    # 验证三种方式结果一致
    print()
    assert r1_t == r2_t == r3_t, "计算结果不一致！"
    assert abs(r1_a - r2_a) < 1e-9 and abs(r2_a - r3_a) < 1e-9, "平均值不一致！"
    print(f"✓ 三种风格的计算结果一致：总和={r1_t}, 均值={r1_a:.4f}")
    print()
    print("演化规律总结：")
    print("  机器语言 → 关注 '怎么做'（寄存器/地址）")
    print("  结构化    → 关注 '分步骤做'（函数/模块分解）")
    print("  面向对象  → 关注 '谁来负责'（对象/消息/封装）")


if __name__ == "__main__":
    main()
```

运行效果：

```bash
$ python3 paradigm_demo.py

编程范式演进对比演示

=== 阶段1: 机器语言风格（直接操作） ===
  总和: 65.0, 平均值: 21.666666666666668
=== 阶段2: 结构化程序设计风格（模块化） ===
  总和: 65.0, 平均值: 21.666666666666668
=== 阶段3: 面向对象风格（封装+消息） ===
  总和: 65.0, 均值=21.67, 数量=3

✓ 三种风格的计算结果一致：总和=65.0, 均值=21.6667

演化规律总结：
  机器语言 → 关注 '怎么做'（寄存器/地址）
  结构化    → 关注 '分步骤做'（函数/模块分解）
  面向对象  → 关注 '谁来负责'（对象/消息/封装）
```

### 代码解读

| 阶段 | 思维方式 | 关键特征 |
|------|---------|---------|
| 机器风格 | 直接操作，步步控制 | 无封装，全是变量和临时计算 |
| 结构化风格 | 分模块，单一职责 | 函数分解，自顶向下调用 |
| 面向对象风格 | 封装数据，消息传递 | 类 + 方法，链式调用，延迟计算 |

三次演进的核心变化：**抽象层次不断提高，程序员关注的问题域不断远离机器底层**。

---

## 总结

- **机器语言→汇编→高级语言**：解决"机器能看懂"的问题，核心是**抽象机器细节**
- **结构化编程**（1960s）解决第一次软件危机——逻辑复杂，方法是**自顶向下模块化**
- **面向对象**（1980s）解决第二次软件危机——扩展复杂，方法是**封装+消息传递**
- **软件架构**（1990s）是大规模系统催生的新学科，解决的不是新危机，而是**系统组织**问题
- 演进规律：拆分粒度从**模块→对象→组件**，粒度越来越粗，层次越来越高，本质都是**控制复杂度**
- 没有银弹：结构化、面向对象、软件工程、架构设计各自解决了特定历史背景下的问题，但业务永远在变，技术永远在演进

---

## 参考
- 软件架构基础
- Frederick P. Brooks,《人月神话》, 1975
- Mary Shaw & David Garlan,《An Introduction to Software Architecture》, 1994

架构2：历史背景

## 前言

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

---

## 一、系统与子系统

### 什么是系统？

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

三个关键词：

| 关键词 | 含义 | 示例 |
|--------|------|------|
| **关联** | 个体间有联系，堆在一起≠系统 | 发动机+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)
