#说是安卓的内核,其实应该Linux系统都有相关的设置的吧
#文章内容部分摘录于http://www.chenyue404.tk/?p=56
最近在这里下载到了一个调教安卓内核的应用,看着各种参数真的赶脚不明觉厉。姑且算是结合网上的文章改了几个参数~不同手机可选择的内核参数不同,文章以渣米3w为例~
先来看看关于CPU的设置
其中有一个挺有意思的设置是[CPU Governor],根据网络上的文章,各种选项有如下解释
【ondemand】按需模式:
→按需调节cpu频率,不操作手机的时候控制在最低频率,滑屏或进入应用后会迅速提升至最高频率,当空闲时迅速降低频率,性能较稳定,但因频率变化幅度过大,省电方面只有一般的水平。是一种在电池和性能之间趋向平衡的默认模式,但是对于智能手机来说,ondemand在性能表现方面略有欠缺。
【interactive】交互模式:
→和ondemand相似,规则是“快升慢降”,注重响应速度、性能,当有高需求时迅速跳到高频率,当低需求时逐渐降低频率,相比ondemand费电。这货竟然是渣米的默认设置,看来时不时发发烧也是有理由的。
【conservative】保守模式:
→和ondemand相似,规则是“慢升快降”,注重省电,当有高需求时逐渐提高频率,当低需求迅速跳至低频率。
【userspace】用户模式:
→任何情况下都会控制CPU运行在配置的频率范围内,配置中的用户自己添加的省电设置。在此情景模式下,降低CPU最大运行频率可以延长电池待机时间,但同时也会降低机器的唤醒速度。嘛,反正我是懒得调参数了,这个估计我用不着~
【powersave】省电模式:
→按设定最低频率运行,日常没有使用价值,除非配合setcpu情景模式,关屏睡眠时使用此调节模式,省电但系统响应速度慢。很类似Windows里面的[节能]嘛。
【performance】高性能模式:
→高性能模式,按你设定范围的最高频率运行,即使系统负载非常低cpu的频率也为最高。性能很好,因为CPU本身不需要资源去调整频率,但是电量消耗较快,温度也高一些。渣米发烧友必备233333
看过这些解释之后,我选择了保守模式。可以达到CPU的需求,也能一定程度上节电嘛~
还有一个设置叫[Multicore Power Saving],多核节电处理。
原理是尽量将处理任务交给尽可能少的处理核心处理。说实话我不知道为什么这能节电,既然名称是这样了,就给打开了~
BTW,这个软件有一个[Frequency Table]信息,能查看CPU在各频率工作的时间。通过它可以看到,渣米3w的CPU均衡模式把四核CPU的最高频率降到了960MHz,最高频率的一般呦~
然后是I/O调度的设置模块
里面有一个挺有意思的设置是[Internal Storage Scheduler],用来设置设备的处理I/O请求的算法的~有以下选项:
【noop】
这个调度模式会把所有的数据请求直接合并到一个简单的队列里。不适合有机械结构的存储器,因为没有优化顺序,会增加额外的寻道时间。属于最简单的一个调度模式,无视io操作优先级和复杂性,执行完一个再执行一个,如果读写操作繁多的话,就会造成效率降低。
【deadline】
顾名思义,用过期时间来排序io操作顺序,保证先出现的io请求有最短的延迟时间,相对于写操作,给读操作更优先的级别。是比较好的一个调度模式。
【cfq】
完全公平队列,是anticipatory模式的替代品,没有过多的做预测性调度,而是根据给定的进程io优先级,直接来分配操作的顺序。这个模式在linux上表现良好,但也许并不是最适合android的io调度模式,太强调均衡,而降低了连续读写数据的性能。
此外还有【row】和【test-iosched】,等我找到资料后再补上解释~
根据描述,我就Happy地设置为了deadline~
说句题外话,我发现渣米在双清之后,系统快!了!很!多!比任何优化软件都强。只不过我的数据ToT。
估计双清的时候清楚了好多乱七八糟软件建立的无用文件夹吧。清清更健康~
赞x2147483647
英语渣渣表示翻译无能,大家姑且看下英文解释~
【ROW】
ROW stands for “READ Over WRITE”which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else,thus we want to give READ IO requests as much priority as possible. In mobile devices we won’t have as much parallel threads as on desktops. Usually it’s a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
【test-iosched】
The test scheduler allows testing a block device by dispatching
specific requests according to the test case and declare PASS/FAIL
according to the requests completion error code.