注：本文系个人经验分享，并不提供任何推荐或指导。
都是搭载高通骁龙 8 Gen1，有的厂商可以配合高刷新率屏幕和非线性动画实现顺滑的操控体验，有的国际大厂则依然还在卡顿的边缘徘徊——显然，同样的 SoC 交给不同的 Android 厂商调校，最终呈现给消费者的体验也是截然不同的。
正是因为同样的原因，早年不少 Android 玩家都会自己动手，通过修改内核性能配置的方式满足自己对性能和体验的极致追求，更换系统内核对 Android 玩家而言自然也成了家常便饭，超频跑分、降压省电，各类玩法数不胜数。
不过随着通用内核镜像的引入以及 Magisk 的崛起，第三方内核早已不再是我们摆脱厂商单一性能调度的唯一方法。
如果你想为自己的 Android 设备芯片量身定制一套更加符合自己使用习惯和实际需求的「游戏规则」，愿意为续航牺牲些许富余性能、让 CPU 变得更有能效比，今天我们要介绍的 Magisk 模块 Uperf 就是当下最受欢迎的选择之一。
▍又要马儿跑，又要少吃草
Uperf 是一个开源的 Magisk 模块，主要作用是控制手机的 CPU 性能，它由酷安人气开发者 yc9559（下简称 yc）维护，在好几位「老大哥」的基础之上演进而来，包括 cpufreq-interactive-opt、perfd-opt、qti-mem-opt 等等。
这些局限于「体感」「玄学」的早期社区性能调控模块，因为不像 Android 厂商那样拥有完整且准确的芯片测试数据，不少玩家对其实际作用也是半信半疑。随着 Android 的现代化，性能调度/RAM管理不再由某几个内核参数决定，各家推出不同的性能配置文件也让 CPU 性能调优变得更加复杂——好在 yc 坚持了下来，截至今日，单 Uperf 这个项目就已经持续维护了两年半，并且还在最近催生出了拥有自定义调控动态屏幕刷新率的新项目 dfps（后续再聊了）。
坚持自己的爱好并勇于开源贡献，我个人对于 yc 是怀有敬意的。
当今的 Uperf，在思路上和当今主流手机厂商的对性能的调校目的已经非常相似了：又要马儿跑得快，又要马儿尽可能少吃草。不同的是出于商业因素手机厂商鲜少公开自己的秘方；Uperf 作为开源项目，则在文档开放、自定义友好程度和方案设计上带来了如下优势：
模块代码开源：且配有非常详细的原理说明文档和配置解读文档；
使用灵活：预置 4 种不同的性能档位可供选择，且支持分应用配置、重点场景优化（待机、应用启动等）；
适用面广：基本覆盖了主流的 SoC 型号，支持 Magisk 模块安装和 Root 权限手动配置；
原理上相对科学：尽可能选择能效比较高的「甜点频率」、对触摸操作优化等。
▍为处理器找到「甜点频率」
在全球变暖的趋势下，用户也希望手里的设备能凉快一些，让设备性能可调可控的需求自然也逐渐凸显。所以在 Uperf 受到玩机社区青睐的同时，手机厂商也在跟进类似的需求。比如 One UI 最近也在新机中就设立了只对芯片生效的「低功耗」档性能模式，通过降低 CPU 最高频率并采用更保守的性能释放策略，来实现省电降温的目的。
谢谢戴老师提供截图
降低频率虽然可以省电，带来的性能损失又该如何弥补？这里就要聊到「投入产出比」这个概念了。
在大多数人的理解中，CPU 频率和性能收益的关系都是成正比的，但现实的情况却是在频率提升到一定高度后，获得的性能收益会出现明显衰减。
从极客湾的数据来看，主流芯片都存在类似的规律
在这种性能收益出现明显衰减的临界点，如果我们略微降低处理器的最高频，就会获得类似「牺牲 10% 性能，获取 20% 的能耗收益」的效果。在旗舰芯片上，这点降频对于日常「刷刷刷」类用户来说影响甚微。
所以如果我们有足够的数据，能够找到那个性能收益最大化的「甜点频率」，自然就能在维持相对性能的同时大幅减少能耗。这就是 Uperf 所谓「甜点频率」的理论来源。
手机厂商们当然也知道这件事：以我手上同样采用骁龙 730G 芯片的两款手机来说，Galaxy M51 开启性能限制后，大核心的最高频也刚好限制在 1555Mhz；Pixel 4a 在 Google 原厂调度下，大核心会尽可能踩中 1555Mhz 这个点。而我们使用 Uperf 也会获得类似的频率点分布：
那 Uperf 是怎么做到的呢？这里简单讲解一下 Uperf 的部分原理，对于原理不关心的读者朋友可以跳过。
首先，上个章节提到了「足够的芯片数据」来寻找甜点频率，因此对于适配了的 SoC 型号，Uperf 会内置一张频率表，记录了当前芯片在各个频率上的性能和功耗。这张表并不代表绝对事实，比起在芯片实验室测得的数据也会有误差，但其精度足够提供一定的指导。
获取到所需的数据后，剩下的就是三步走：
禁用手机上的其他性能调度机制；
获取到手机目前的性能需求；
根据需求和目前的性能配置提升/降低频率。
一台手机上的性能调度是典型的「一山不容二虎」，因此 Uperf 会禁用手机厂商设置在系统中的性能调度服务或是温度控制服务。
截图来自项目代码
整个流程中，最难以完美实现的是第二步。Uperf 在这里采用的是「持续监测」的办法，同时尽可能优化这个环节的性能开销：
大部分使用场景中，尽可能以甜点频率为基准采用保守参数。
对于触摸事件，和系统框架一样监听某个目录下的变动，可以获知触摸屏的报点、路径、速度等信息，进一步判断是点击还是划动，给出对应的频率提升。
对于屏幕息屏，采用监听系统唤醒锁的形式（系统在切换到息屏状态时，系统唤醒锁中的显示类会发生变化）。
对于切换应用、开启应用、解锁屏幕，则是采用监测系统进程 ActivityManager 的形式，提前放在大核心运行。
对于 Android 底层负责所有帧渲染和提交的进程 Surfaceflinger，则交给配套模块 Sfanalysis，在发生可能的卡顿之时就通知提升频率。
对于其余的重负载场景等实在没有便捷监测方法的情况，就使用脚本轮询，来决定是继续升高频率还是降低频率。
最后则是第三步，其实 Uperf 的前身 WIPE、perfd-opt 已经玩得炉火纯青了：把要设定的值不断写入系统参数，比如把某个任务固定到大核心执行、调整核心的最高频率或最低频率等。
简单了解一下工作原理后，也不难理解为何在 EAS 成为主流、CPU 普遍采用 schedutil 调度器的今天，Uperf 却要坚持使用 powersave 调度器（维持在最低频），以及一般开机后就不会变的 CPU 最大频率、最小频率却在时时刻刻发生变化。这些都是 Uperf 正在工作的标志。
需要注意的是，相对于厂商的方案，Uperf 并非一定是更优选择，更谈不上完美无缺，它只是一个 Android 玩家才有的新增可选项。该消耗的电量还是会消耗，改进频点的选择也只是尽可能让电消耗得更「性价比」一些。在我看来，厂商的调度方案或许不是体验最好的，但可能是比较稳定、省心的选择；而想要更大范围的自由度，或是厂商提供的体验不够优秀，才考虑 Uperf，我称它为「玩家的选择」，just for fun。
▍定制属于你的 Uperf 方案
其实写到这里，文章就该结束了，剩下来要做的事情就是去 Uperf Github 项目的 发布页 下载对应的模块文件、刷入、重启，然后享受冷静下来的手机。但我还是生怕我贫瘠的文笔掩盖了 Uperf，因此增加了本章节的赘述，主要分享我使用 Uperf 中的体验和观察。
既然是一套「量身定制」的调度算法，至少厘清两点：
设备要多流畅
续航持续多久
以我个人为例，几年前的我觉得「流畅无所谓、续航第一位」；如今我天天两点一线通勤，反而觉得「流畅优先，亮屏续航五小时就行」。
Tip：CPU 只是忠实完成派给它的每一份任务，真要追求显著省电，还是要靠减少应用后台活动、减少手机使用时间入手。
选流畅还是选续航，其实并没有绝对的黑白分明，觉得够流畅了就把芯片的余力转为续航，就是那么简单。
确保 Uperf 正确运行
安装模块文件并重启后，Uperf 会在内置存储/Android/yc/uperf 文件夹下创建默认配置文件、日志文件等，我们首先关注 uperf_log.txt 日志文件，检查 Uperf 运行状况。同目录下的 uperf.json 配置文件定义了 Uperf 的行为，一般来说不需要修改，使用 yc 预定义的即可，高级玩家可阅读文档后自行试验。perapp_powermode.txt 分应用性能配置文件我们后面会讲到。所有带有 .bak 后缀的文件并不生效，只作备份用。
如何检查 Uperf 是否正确运行是大部分新手玩家都会问到的问题。很简单：打开 uperf_log.txt 日志文件，时间戳后会附有一个大写字母代表日志的等级，如果均显示 I （Information）而非 W （Warning）或 E（Error），则说明 Uperf 主模块运行正常。如果你安装了 sfanalysis 附属模块，还会额外显示一行 SfAnalysis connected 代表联动成功（当前版本下 ssAnalysis 安装后不会有任何提示）。
关注那一长串的 I，那就意味着 Uperf 正常运行
大部分报错都是因为装用的第三方内核修改过调度导致不兼容，或另外安装了类似的性能调度类 Magisk 模块造成冲突。如果我们修改分应用性能配置文件，无需重启手机，Uperf 会实时应用新的设置，这些改动也会反映在 uperf_log.txt 文件中。
考虑增配附属模块
Uperf 有两个附属模块：sfanalysis、ssanalysis，模块名中的 sf 是上文 Surfaceflinger 的缩写，ss 则是 systemserver 的缩写，这两个模块都是为了补上 Uperf 无法覆盖、造成卡顿的场景。对于普通用户和重视流畅度的用户，我的建议和开发者的一致：推荐安装 sfanalysis，可以极大减少掉帧频率（当然也会支出相对应的额外功耗）；如果遇到了桌面动画掉帧，再考虑安装 ssAnalysis。
在 Uperf 预制的性能配置中，性能释放从保守到激进排序为 powersave、balance、fast、performance。Uperf 单独使用时，每一档性能释放的区别较为显著，体感上甚至能猜个八九不离十；但是安装 sfanalysis 各个调度间的区别就不怎么明显，对于续航的提升也会变得有限。个人经验，仅供参考。
分应用性能配置
而在这份 perapp_powermode.txt 配置文件中，则可让我们分别设置全局的性能配置以及个别应用中的配置。以下是 Uperf 预置的配置：
com.miHoYo.Yuanshen fast# 原神的包名，指定原神使用 fast 配置
-balance# 息屏下使用 balance 配置
*balance# 全局默认使用 balance 配置
上文提到的 powersave、balance、fast、performance 四个预置档位中，powersave 和 balance 都有比较严格的性能限制，偏省电向；fast 的性能限制宽松，适合在手机游戏时使用；performance 基本没有性能限制，也因此对散热有较高要求，适合平板等散热压力较小的设备。
如果觉得当前的设备运行某个应用频繁遇到卡顿，或是遇到可能是因为性能不足造成的问题，则可考虑将其提升到更激进的一档。perapp_powermode.txt 规则格式非常简单，即应用包名（package name）带上空格后指定性能配置，在 perapp_powermode.txt 一行一个添加：
com.tencent.mm powersave # 此处插入评价：使用 powersave 配置
com.robertodoering.harpy.pro fast # 刷推起码的流畅：指定 Harpy pro 使用 fast 配置
co.wordupapp.app fast # 应用性能太差：指定 WordUp 使用 fast 配置
com.tencent.tmgp.supercell.brawlstars fast # 荒野乱斗不接受卡顿，使用 fast 配置
应用包名的获取我这里便不多赘述了，常见的应用管理类工具基本都可查看，我自己使用的是黑阈和 App Manager。
▍附录：我遇到过的问题
在把玩期间，发现几台搭载了 LineageOS 的 Pixel 无法激活 sfanalysis 模块，不知道是谁的锅，但手动执行一下模块目录的脚本又能正常运行了，于是我添加了开机执行一段脚本再手动激活模块脚本一次：
sh /data/adb/modules/sfanalysis/post-fs-data.sh
sh /data/adb/modules/sfanalysis/service.sh
▍结语
我关注 Uperf 其实也有年头了，最近几个月才开始将它奉若至宝，作为主力使用。它的问题在我看来主要是这几点：
先天资源很少，比如测得的频率数据，某个频率下的能耗、性能等，这些数据应该是不如手机厂商从芯片厂拿到的精准。每颗芯片也有体质上的不同，而 Uperf 是预置的「标准数据」；
Uperf 是系统外部的、通用性很强的模块，比起手机厂商要做的 hook 难度会高很多，不得已的轮询方式相比可能显得不那么高效（亮屏静置下的耗电可能会稍稍高一些）；
场景针对性很强，但部分遗漏的场景下就会遭遇性能不佳，比如我经常遇到打开微信小程序偏慢的情况（没有触摸事件）以及其他零零碎碎偶发的小卡顿。
折腾到最后，我发现 Google 官方的调度其实相当出色，算是理想的状态，Tensor 芯片之外的 Pixel 用户其实可以不必安装 Uperf。同时我也发现了旗舰芯片对于我这种轻度用户来说，有相当大的性能余裕可以转化为续航能力，在 Wi-Fi 下获得超过 10 小时的亮屏续航。我没有办法提供可以直接「抄作业」的现成方案，而是希望通过分享我的一些实用心得后，大家可以基于自己的设备情况和自身性能需求设定。
所以，祝大家玩得愉快！
https://sspai.com/post/75695?utm_source=wechat&utm_medium=social
作者：️ &
责编：️