Seeder与Linux内核随机数产生器
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左右，也就是说没有出现过因可用熵不足导致线程阻塞的情况，实际使用中在这期间没有出现过卡顿
以上仅为手动测试，下面来个数据测试，安兔兔跑分。当然也是优化和未优化的对比，左图为未优化，右图为优化后数据
看这个跑分图首先应该树立一个观点，那就是偏差小于3%完全可以认为是误差而不必考虑
根据Seeder的第二条优化（IO优化），重点应该是看IO数据，我们可以看到，从190分提升到195分可以认为是测试误差，从另一点来看，SD卡（其实是手机内部存储）的读写速度均有明显下降趋势，这条优化貌似站不住脚。从总分上来看，7383下降到7342也可以认为是测试误差，也就是说Seeder在当前测试环境下没有起作用
总结一下：
通过以上可以看出，从工作原理上讲，Seeder打破了原有的随机数生成规律，使得系统在无任何操作时也能产生随机数（这么来说就是为随机数了），如果随机数产生不足的话，这确实可以在一定程度上改善线程阻塞情况的发生。但是测试中并没有出现随机数产生不足的情况，这样来说Seeder对于优化Android2.3系统可能帮助很小
从实际使用中来看，即使在作者认为最有效果的Android2.3环境下，无论从理论上分析还是具体使用中，Seeder并不能发挥本身设计的作用
Linux之所以使用真随机数意义在于安全性，如果Seeder改变了这一点，却仅仅带来安全性下降而不能带来性能的提升，那我想，应该还是不用Seeder更好一些
博主你好，我在博客里加了一个“独立博客大全”的版块，有时间过来看看，如果没有添加你的，通知我一声，无条件收录！
嘿嘿，那麻烦你啦
真厉害，“独立博客大全”的版块做的很棒
好深奥的内容，既专业又详细，支持一下
来看看 呵呵
@音乐人生网赚 欢迎欢迎～～
谢谢分享内容
@夏宇轩网赚博客 嘿嘿，欢迎光临指导～～～
我的头像很帅，怎么留言完毕就变了一个小猫咪了。
@月小升 好像是头像缓存问题吧，囧～～～
我手机在1W2分左右 其余没测试
@梦月酱 目测A9四核orA15双核
@FROYO 四核
好高端啊 表示看不懂
@空空裤兜 呃，这个没什么用，纯属瞎搞
来看看博主
周末快乐
周末快乐～～～
对了，提升响应速度意味着多线程效能的提高以及单线程效能的低下，所以如果要提高跑分可以延迟响应时间，把CPU占用规划到单线程上面，这样有利于跑分。
基本上这个优化可以忽略不计算。如果优化效果连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增长吧。（就是后期无论缓存设置多大，效果还是提升不大，而且大缓存只适合于大内存的手机）
针对相应速度，我更加提议直接修改响应颗粒。
!/system/bin/sh极限提高响应速度：（由于这样CPU会一直高强度运行，耗电量你懂的……）
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
@花七七 你们俩真专业，佩服佩服。
@常青 话说还是他比较专业= =混xda的人都是科学怪人、哇咔咔~~~
@花七七 不要谦虚，貌似你也常混xda吧。。。
@花七七 曾经我用这个办法提高过跑分，用init.d修改这几个值，曾经是有效的。后来做现在这个ROM，虽然也是这么弄得，init.d也执行了，可那几个值还是默认的。后来我又改init.rc，还是拿它没招，你说这是神马时候被改回去的呢，我已经找的快麻木了
@FROYO 不清楚= =....下个systune玩玩吧= =