Seeder是一个Android系统加速软件,由XDA首发。在网上查了很多资料,也看了很多反馈,网友们评论褒贬不一,有说系统速度明显改善的,也有说安装之后压根不起作用的。对这种神奇的东西充满了好奇,现在就来研究一下这东西到底神马原理。

根据xda作者的原帖帖,大概是这样的:

主要优化的内容有2项:

a.优化了RNG(随机数生成器),这里针对的Android系统迟滞是由于JVM和组件经常读取的dev/random设备(RNG)阻塞造成的。作者使用不会发生阻塞的/dev/urandom来生成entropy,每秒钟填充一次/dev/random,来解决这个问题。ICS以后,系统JVM和组件基本不再使用dev/random,所以情况相对不严重。但是ICS还是会由于其他程序消耗完entropy,可能需要等待entropy的生成。结论是a优化主要针对4.0之前的系统,4.0之后的系统在理论上效果比2.3小很多。
b.增加了存储设备MMC的IO队列长度(原帖说部分用户在大量IO操作时可明显改善性能),理论上可以优化Governor(调度器)的调度结果,合并重复的IO操作。

又查了一下有关Linux随机数生成器的资料,大体上是这样的:

Linux内核实现了一个随机数产生器,从理论上说这个随机数产生器产生的是真随机数。对于需要真随机数的程序,都不能允许使用伪随机数。为了获得真正意义上的随机数,需要一个外部的噪声源。Linux内核找到了一个完美的噪声源产生者--就是使用计算机的人。
我们在使用计算机时敲击键盘的时间间隔,移动鼠标的距离与间隔,特定中断的时间间隔等等,这些对于计算机来讲都是属于非确定的和不可预测的。内核根据这些非确定性的设备事件维护着一个熵池,池中的数据是完全随机的。当有新的设备事件到来,内核会估计新加入的数据的随机性,当我们从熵池中取出数据时,内核会减少熵的估计值。
如果我们完全不操作计算机会如何呢?也就是作为噪声源的产生者,我们完全不去碰键盘,鼠标等外设,不让熵池获得新的数据,这个时候如果去熵池取数据内核会如何反应? 内核在每次从熵池中取数据后都会减少熵的估计值,如果熵估计值等于0了,内核此时可以拒绝用户对随机数的请求操作

有关/dev/random和/dev/urandom

这两个特殊设备都是字符型设备。我们可以在用户空间通过read系统调用读这两个设备文件以此获取随机数。这两个设备文件的区别在于:如果内核熵池的估计值为0时, /dev/random将被阻塞,而/dev/urandom不会有这个限制

具体试用:

作者说在Android2.3系统效果最明显,那我就用2.3做测试。机型:Moto里程碑3(OMAP4430@1200MHz、PowerVR SGX540@300MHz)

首次打开此软件后,显示可用熵300左右
开启优化,可用熵瞬间达到4096,并维持在4096,在这种状态下折腾了几个消耗可用熵以及IO的程序,比如微信、浏览器和QQ,感觉和没优化差不多
关闭优化,可以看到可用熵开始下降,打开微信-1000左右,折腾一下QQ-1000左右,最终降到400左右。每次用手触摸屏幕(毫无意义的瞎按),可用熵会增加20-50左右,看来前面的理论是正确的。随后折腾一圈浏览器,照相机等软件后,发现可用熵竟然高达1500左右,也就是说没有出现过因可用熵不足导致线程阻塞的情况,实际使用中在这期间没有出现过卡顿

以上仅为手动测试,下面来个数据测试,安兔兔跑分。当然也是优化和未优化的对比,左图为未优化,右图为优化后数据
Seeder

看这个跑分图首先应该树立一个观点,那就是偏差小于3%完全可以认为是误差而不必考虑
根据Seeder的第二条优化(IO优化),重点应该是看IO数据,我们可以看到,从190分提升到195分可以认为是测试误差,从另一点来看,SD卡(其实是手机内部存储)的读写速度均有明显下降趋势,这条优化貌似站不住脚。从总分上来看,7383下降到7342也可以认为是测试误差,也就是说Seeder在当前测试环境下没有起作用

总结一下:

通过以上可以看出,从工作原理上讲,Seeder打破了原有的随机数生成规律,使得系统在无任何操作时也能产生随机数(这么来说就是为随机数了),如果随机数产生不足的话,这确实可以在一定程度上改善线程阻塞情况的发生。但是测试中并没有出现随机数产生不足的情况,这样来说Seeder对于优化Android2.3系统可能帮助很小

从实际使用中来看,即使在作者认为最有效果的Android2.3环境下,无论从理论上分析还是具体使用中,Seeder并不能发挥本身设计的作用

Linux之所以使用真随机数意义在于安全性,如果Seeder改变了这一点,却仅仅带来安全性下降而不能带来性能的提升,那我想,应该还是不用Seeder更好一些

标签: Android

已有 26 条评论

  1. 博主你好,我在博客里加了一个“独立博客大全”的版块,有时间过来看看,如果没有添加你的,通知我一声,无条件收录!

    1. FROYO FROYO

      嘿嘿,那麻烦你啦
      真厉害,“独立博客大全”的版块做的很棒

  2. 好深奥的内容,既专业又详细,支持一下

  3. 来看看 呵呵

  4. 谢谢分享内容

    1. FROYO FROYO

      @夏宇轩网赚博客 嘿嘿,欢迎光临指导~~~

  5. 我的头像很帅,怎么留言完毕就变了一个小猫咪了。

    1. FROYO FROYO

      @月小升 好像是头像缓存问题吧,囧~~~

  6. 我手机在1W2分左右 其余没测试

  7. 好高端啊 表示看不懂

    1. FROYO FROYO

      @空空裤兜 呃,这个没什么用,纯属瞎搞

  8. 来看看博主
    周末快乐

    1. FROYO FROYO

      周末快乐~~~

  9. 对了,提升响应速度意味着多线程效能的提高以及单线程效能的低下,所以如果要提高跑分可以延迟响应时间,把CPU占用规划到单线程上面,这样有利于跑分。

  10. 基本上这个优化可以忽略不计算。如果优化效果连10%都不到的话,证明实验操作可能存在不可消除的误差计算,如CPU的效能计划等。

    A.优化了RNG(随机数生成器),这里针对的Android系统迟滞是由于JVM和组件经常读取的dev/random设备(RNG)阻塞造成的。作者使用不会发生阻塞的/dev/urandom来生成entropy,每秒钟填充一次/dev/random,来解决这个问题。ICS以后,系统JVM和组件基本不再使用dev/random,所以情况相对不严重。但是ICS还是会由于其他程序消耗完entropy,可能需要等待entropy的生成。结论是a优化主要针对4.0之前的系统,4.0之后的系统在理论上效果比2.3小很多。

    ——RNG阻塞是否为真,我们可以从跑分方面的现象去验证:对比修改线程响应颗粒与他所谓的优化工具优化后的跑分。
    sched_wakeup_granularity_ns 、 sched_min_granularity_ns 、 sched_latency_ns

    B.增加了存储设备MMC的IO队列长度(原帖说部分用户在大量IO操作时可明显改善性能),理论上可以优化Governor(调度器)的调度结果,合并重复的IO操作。

    ——应该是修改mmcblock的缓存大小,调度器一般都是采用noop或者cfq/bfq。某些民间rom内核是非官方的可能还有vr。至于能不能合并我就不清楚了,但是缓存越大数据安全性就越低,性能提升应该呈lnx增长吧。(就是后期无论缓存设置多大,效果还是提升不大,而且大缓存只适合于大内存的手机)

    针对相应速度,我更加提议直接修改响应颗粒。
    极限提高响应速度:(由于这样CPU会一直高强度运行,耗电量你懂的……)

    !/system/bin/sh

    echo 10000 /proc/sys/kernel/sched_latency_ns
    echo 10000 /proc/sys/kernel/sched_wakeup_granularity_ns
    echo 10000 /proc/sys/kernel/sched_min_granularity_ns

    1. @花七七 你们俩真专业,佩服佩服。

      1. @常青 话说还是他比较专业= =混xda的人都是科学怪人、哇咔咔~~~

        1. FROYO FROYO

          @花七七 不要谦虚,貌似你也常混xda吧。。。

    2. FROYO FROYO

      @花七七 曾经我用这个办法提高过跑分,用init.d修改这几个值,曾经是有效的。后来做现在这个ROM,虽然也是这么弄得,init.d也执行了,可那几个值还是默认的。后来我又改init.rc,还是拿它没招,你说这是神马时候被改回去的呢,我已经找的快麻木了

      1. @FROYO 不清楚= =....下个systune玩玩吧= =

添加新评论