Apodidae

使用方法等内容见 我们的网站

概述

Apodidae 是一个基于 chenzyyzd CuprumTurbo Scheduler 的调度项目，专为 MediaTek 设备优化

我们在 2023.2.5_11:00 至次日经历了超过12个小时的站点故障,原因是 nalanyinyun.ml 已被注销
所有站点均迁移到 nalanyinyun.top,我们无法重定向,还请您刷新一下脑子中的缓存

避嫌声明

我们不与其他调度竞争，人际关系那点破事我们也懒得搅和

所以不管别人说什么，我们希望你不要在意，只是选择你想要的就好，你觉得什么好用就用什么

Apodidae 诞生的目的

纵观目前耳熟能详的调度项目，Uperf，CuprumTurbo Scheduler，Scene 等等

你会发现这些调度都适配了当时市面上大部分 SoC，适配巨多种 SoC 的难度系数巨大，同时这些开发者们还要维护调度本身，所以他们很难在开发调度的同时针对每一款 SoC 进行单独优化

当然，我们不是在否认开发者们的劳动成果，只是维护数量巨大的 SoC 带来的种种困难阻止了每一款 SoC 的单独优化

Apodidae 清楚适配 SoC 的困难，所以 Apodidae 选择了只维护得到关注较少的 MediaTek 设备

(维护调度在 Apodidae 的目的中只是很小一部分，不过更多的我还不能告诉你)

所以 Apodidae 在尝试取代其他调度？

当然不是，Apodidae 的两个主要维护者连 C 都不会，只是在维护一些配置文件和 Magisk 模块罢了

顺带一提，Magisk 模块模板也是上游提供的

所以你可以了解到 Apodidae 的技术水平到底有多低 (笑)

所以你也可以轻易的加入 Apodidae 的维护，只要你会 GitHub 的基本操作

Apodidae 在维护配置文件，为什么不回馈给上游

我们不能回馈给上游，回馈了上游作者也未必会接受

首先，Apodidae 的配置文件只在部分设备上进行测试，每个数值都卡在流畅的边缘，这样的配置文件并不普适，如果回馈给上游，他的用户肯定会有相当一部分抱怨卡顿

其次，上游作者亲手开发了项目，他们必然比我们清楚每个参数的作用和意义，所以我们的配置文件必然会存在对某些参数的曲解，这样的东西没法回馈给上游