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更好一些