kuanat

@Donduck #41

uclamp 一样支持增加频率 hints ，uclamp 出现的时候还是 dvfs 的时代，现在也是支持 epp 的。严格来说 uclamp 并不直接参与控制，而是通过加权参数影响 governor 对于 cpu 的调度。

我认为 windows 在电源管理和异构调度上的逻辑不是很清晰，至少它没有明确区分 scheduler 和 governor ，所以你会觉得 Windows 有的 Linux/Mac 都没有。实际情况是，Windows 非要自创逻辑和概念，这才是问题所在。

@Donduck #37

为什么 Linux 要有 Windows 的 QoS 控制，这个逻辑不合理，毕竟是两个不同的系统。我猜你想说的是 Linux 没有类似 Windows QoS 的机制？在我看来，Windows 和 Linux 还真就差不多。



我在 https://v2ex.com/t/1129403 这个帖子里解释得比较清楚了，（自动，非指定 affinity ）异构调度是个加权调度，依赖四个方面的参数：

1. soc 向系统汇报自身拓扑、容量以及频率温度等等运行时信息
2. 任务本身的特性定义，这个定义可以是历史数据统计而来，也可以手动指定
3. 用户意图
4. 调度器加权算法

调度行为的数学本质是将 1/2/3 作为参数，通过 4 的算法转化为特定的加权数值。

目前 1 是 soc 厂家提供的，仅取决于硬件平台。

加权算法方面，对于 Linux 来说有代码可以参考，对于 Windows 来说是个黑盒。尽管 Linux 的实现依旧 naive ，但我不认为 Windows 能比 Linux 好到哪里去。这是个约束优化的问题，可能不存在求解全局最优的多项式算法。

对于 2 来说，据我所知 Windows 可以通过任务管理器为某个进程设定“效率模式”来影响对于 P/E 核心的偏好。我对 Windows 了解不深，说错见谅。Linux 对应的实现叫 uclamp ，使用标准 cgroup 机制来手动定义任务特性。

对于 3 来说，Windows 应该是基于电源计划，现在（基于 hwp 的 governor ）应该叫 power mode overlay 了。Linux 对应的入口是 tuned （过去是 power profile ）。两者思路上基本一致。

Windows QoS 或者 Linux 的相关机制，本身只是额外的加权信息，至于它叫什么名字，如何与系统其他部分集成对接，是取决于系统原有框架的。

自动异构调度的未来，以当下的眼光来看就是两条路，要么手动标定所有的任务，要么拉长时间获得足够好的历史参考数据来自动标定任务。调度算法反倒不是很重要（我个人甚至认为 naive 的算法就很好了），毕竟只是个加权，底层逻辑还是公平。

换句话说，只要不用强制 affinity 的手动方式，目前所有依赖动态信息自动做异构调度的效果都差不多，不可能存在质的差异。顶多是有多少人工就有多少智能。

购买方面，Ultra 200H 系列相比 100H 进步很大，所以建议买新不买旧。另外不带 Ultra 的都是马甲别上当。

使用方面，关于核心调度可以参考这个 https://v2ex.com/t/1129403 可用，但不一定好用。Windows 和 Linux 情况差不多。

另外 LPE 核心 intel 是有想法的 https://github.com/intel/intel-lpmd 类似手机上 idle 的时候将负载转移到 LPE 关闭 P/E 来省电。

这个好像是 Google 在全键盘手势之后增加的一个修改，大概 A12 前后有的，也就是说它是 navigation bar 的一部分。

你可以进设置中搜索键盘或者导航条，有可能会有隐藏那个条的选项，我用过的几个 rom 对应设定的名字不一样。

TLDR：正常用几乎不会有负面影响，暂时也不用指望有太智能的调度。建议使用 6.12 之后的内核，如果是最新的 cpu 平台建议 6.14 。



我简单凭印象解释一下关于 linux 调度的逻辑，这个是比较复杂的，可能有说的不对的地方，需要详细了解建议根据关键词去查询。

如果把任务调度理解成数学问题，逻辑一定是从完全公平（ CFS ）开始，之后一般化到根据需要加权获得有偏向的调度，比如 EAS/CAS 等等。具体实现方面，除了加权逻辑之外，还需要运行时参数，比如程序运行了多久，消耗多少能量，想好多少算力，这又是一个约束优化问题。

目前所有的调度都是 CFS 完全公平调度的扩展实现。调度过程是：先估算每个任务短期 cpu 占用（这个机制叫 PELT ），然后决定下一个调度任务（这个算法叫 EEVDF ）。推荐 6.12 内核就是因为 6.12 完成了重大改动的合并。

与异构相关调度加权有 Energy Aware Scheduling 和 Capacity Aware Scheduling 。前者 EAS 是 arm 大小核诞生之后就有了，逐渐完善至今，多用于低功耗设备。后者相当于是前者的数学拓展，优化的目标不再是单一能耗比，是未来异构调度的核心。

在 CAS 逻辑中，CPU 硬件向系统汇报核心的拓扑、相对容量/性能以及负载、温度和频率这些运行时状态，然后 CAS 算法根据目标：比如性能、能耗、公平性等等决定如何执行核心迁移。

可以简单认为，Intel/Amd 目前的补丁都能正确告诉内核硬件拓扑，Linux 也能正确理解基础的高性能、平衡和长续航情况下的核心使用优先级，但 CAS 算法以及基础参数都非常 naive 。

一点点使用建议：

异构核心上的（自动最优）任务调度是个很难的事情，这里有两条路可以走，一个是苹果的手动黑白名单，比如将商店进程放到能效核心上，另一个就是全自动，也就是 CAS 的做法。

所以如果你是自己写程序，那完全可以绕开自动逻辑，手动绑定核心。

如果你是要改变 CAS 的优化方向，不是很推荐也没有直接控制的手段，通常是建议保持 SCHED_NORMAL 。

另外 scheduler 和 governor 是不同的，这里只讨论调度器。

AndroidX 只是个支持库，楼主描述的问题核心是 gradle 这种构建系统复杂，与使用什么样的支持库没有关系。我不是专业的 Android 开发，只是经常做一些逆向或者开发个人用的工具，经验不一定靠谱，以下我说的仅供参考。

简单说，一劳永逸解决心智负担的方法就是学明白构建原理以及构建工具的使用方法。

我认为这个问题本质上就和 git 图形化插件一样，你对 git 越熟悉，用图形化插件就越不容易出错。假如对 git 理解不到位，用图形化插件就容易爆炸，最终很可能还是要回到命令行去排错。

构建本身就是个非常复杂的过程，可能很多专业开发写了很多年 Android 都没有尝试过手动构建，因为 IDE 隐藏了构建工具（ gradle ）的细节，构建工具又隐藏了构建过程的细节。当底层构建过程出错的时候，经过两层抽象之后暴露给开发者的信息就非常有限，容易让人摸不着头脑。

我们就用手动模拟 gradle 工作流程的方式，从最简单的开始一步一步说。首先要 Java 编译，所以要配置 jdk ，同时要配置依赖，这里依赖的来源可以是线上仓库，可以是本地引入等等。假如引入的依赖有 C 之类的原生库，就要引入 ndk 做交叉编译。这里就不深究了，假设直接用 CMake 构建工具完成了。

以上只是编译出各个组件，离完整的应用包还有距离。这里字节码要打包成 dex ，资源文件要用特定工具压缩，最终还要把各个模块再打包成 apk ，还要处理签名等等。

如果只看核心的构建过程并不是很复杂，构建 variants 、测试和缓存等等一系列功能不影响理解这个过程。因为 gradle 的配置本身是个 DSL ，如果你不理解 DSL 背后所代表的实际工作过程，想要通过修改 DSL 代码来排错 debug 就不现实。

在理解 gradle 的原理和 IDE 的使用方法的基础上，手动排错 debug 就不是特别难的事情。当然这个事情不绝对，有些项目时间跨度很长，而某些支持依赖没有语义化版本，对应的 gradle 配置可能无法向后兼容，甚至出现版本一换循环依赖解析失败的问题，这时候就要手工重构替换掉特定依赖了。

@burtnonald2 #21

感谢总结，相对来说原帖不如后面回帖里讨论的东西有价值。