KonaBess 为什么不需要编译内核

传统方案 vs KonaBess

要理解 KonaBess 为什么"革命性"，先看看传统 GPU 调校方案需要做什么：

传统自定义内核流程

内核源码（github.com）
    ↓
修改 GPU dvfs/频率表代码
    ↓
配置交叉编译工具链
    ↓
编译生成 boot.img（几十分钟到几小时）
    ↓
刷入新 boot.img
    ↓
重启验证

这条路的核心瓶颈是内核编译：需要 Android NDK、交叉编译器、正确的 defconfig、匹配的内核版本。普通用户基本走不通。

KonaBess 流程

手机当前 boot.img
    ↓（magiskboot 解包）
Kernel + Ramdisk + dtb
    ↓（dtc 反编译 dtb）
可读的 .dts 文本
    ↓（修改 GPU 频率/电压数值）
编辑后的 .dts
    ↓（dtc 重新编译）
新 dtb
    ↓（magiskboot 重打包）
新 boot.img
    ↓
刷入重启

区别很明显：全程没有编译内核 C 代码。只处理 dtb 文件，它本身就是编译好后的设备描述表。

为什么 dtb 可以改 GPU 参数

在现代 Android 内核中，GPU 的动态电压频率调节（DVFS）策略存储在设备树（Device Tree）里，而不是写死在内核代码。这是 Linux 内核社区长期推进的"平台无关化"设计——硬件参数与驱动代码分离。

dtb 是 Device Tree Blob 的缩写，它是编译后的二进制设备树文件。里面包含：

GPU 每个频率档对应的电压
GPU DVFS 的阶跃策略
Adreno GPU 的电源域配置

这些参数本来就是"数据"，不是"程序"。所以 KonaBess 只需要：

把 dtb 反编译成可读的 .dts 文本
找到 GPU 相关的节点
修改频率/电压数值
编译回 dtb

就像编辑一个 JSON 配置文件一样简单，完全不涉及 C 代码编译。

KonaBess 内置了什么工具

为了让整个流程在 app 内完成，KonaBess 预打包了两个开源二进制：

工具	来源	作用
magiskboot	Magisk 项目（topjohnwu）	解包/打包 boot.img，处理 ramdisk、kernel、dtb 分区
dtc	AOSP 独立版（libxzr 维护的 fork）	反编译 dtb → .dts、编译 .dts → dtb

这两个工具都是命令行程序，KonaBess 在后台调用它们，用户在界面上看到的只是频率表和电压曲线的编辑框。

局限性：不是什么都能改

KonaBess 的优势是轻量，但也意味着它能改的东西有限。它只能修改 dtb 里有的参数：

✅ GPU 频率表（dvfs）
✅ GPU 电压曲线
❌ GPU governor（调度器算法）——这个在内核代码里
❌ CPU 频率/电压 —— KonaBess 只管 GPU
❌ 屏幕刷新率策略 —— 不涉及

如果你需要调 governor 或 CPU 侧参数，还是得走内核编译路线。但对绝大多数只想调 GPU 性能/功耗的用户来说，dtb 里有的东西已经够用了。