修改手机CPU模式

CPU模式:
ondemand
【按需模式】
官方及xray内核默认为此项调节模式，顾名思义，按需调节cpu频率，不操作手机的时候控制在最低频率，滑屏或进入应用后会迅速提升至最高频率，当空闲时迅速降低频率，性能较稳定，但因频率变化幅度过大，省电方面只有一般的水平。
powersave
【省电模式】
按设定最低频率运行，日常没有使用价值，除非配合setcpu情景模式，关屏睡眠时使用此调节模式
performance
【高性能模式】
和省电模式相反，始终按设定最高频率运行，此模式亦无任何日常使用价值，果断pass
userspace
【用户隔离】
严格来说它并不是一个模式，是允许非内核进程控制cpu频率的设置，现在已经不需要它了，setcpu官方的建议是，“不要使用此选项”。
conservative
【保守模式】
和ondemand模式的调频设定类似，不过有操作时提升cpu频率的速度较慢，空闲时迅速降频，所以名字叫保守模式，性能较低，省电程度略好于ondemand，总体不推荐
interactive
【交互模式】
相对于保守模式，这个模式算是高性能版的ondemand，开始操作手机后，频率升至最高，可以带来更好的响应速度，空闲时缓慢降至设定最低频率。电量自然也是要多费一点。
interactivex
交互模式的修改优化版，开屏后进入更好的频率管理方式，比交互模式略省电。
hotplug
ray没有此模式，多核机型上可用，在不需要的时候关闭多余核心，其他部分调节方式与ondemand相同。
smartass
【智能调节模式】
相当于是一个预置的profile，交互模式的另一个修改版，更加省电。根据资源使用智能提供一个适中的频率，空闲时自动降频，锁屏时自动固定频率。特色是锁屏后非常省电。缺点是部分机型锁屏一段时间后容易睡死。
smartassv2
【智能调节模式v2】
aire内核默认，smartass的升级版，最近很流行的模式。能利用cpu设定的所有频率值。算是对cpu利用充分的条件下最省电的一个模式。同系列的优缺点依旧存在。
smoothass
介绍是比smartass“更有活力的渐进式频率调节”，没用过不太清楚。
brazilianwax
与smoothass相同的模式。
savagedzen
基于smartass的另一模式，在耗电和性能间取得更佳的均衡点。
minmax
保守模式的优化配置版，耗电略高于smartassv2，性能较好。
scary
基于保守模式，同时具有smartass的特点。看介绍是很奇怪的一个模式，有人说不错，不过自己没有试过。
lagfree
【无延迟模式】
基本基于保守模式的频率调节机制，频率上升缓慢，不同之处在于唤醒屏幕后会直接跳跃到一个合适的频率，减少亮起以后的延迟现象。但日常使用性能不高。
intellidemand
【智能按需调节模式】
这个模式有点意思，可根据GPU使用情况来针对性调节cpu频率，GPU负载高时，比如运行游戏和测试的时候，cpu频率会迅速升至最高，这时的调节模式类似于ondemand；当GPU空闲时则会自动限制cpu最高频率，更加省电。要游戏性能好，又要省电的可以用下试试。

I/O调度模式：
（i/o即input/output的缩写，关于数据的读写操作，不同进程请求数据的优先顺序等等。io调度模式比较复杂，我没有具体测试，这里仅对ray上出现的几个模式做说明，部分参考xda、androidforums、wik1pedia、linuxarchive资料）
noop
这个调度模式会把所有的数据请求直接合并到一个简单的队列里。不适合有机械结构的存储器，因为没有优化顺序，会增加额外的寻道时间。属于最简单的一个调度模式，无视io操作优先级和复杂性，执行完一个再执行一个，如果读写操作繁多的话，就会造成效率降低。
anticipatory
其实这个有点类似于pc硬盘的NCQ功能，执行有预测性的调度，看起来似乎可以提高效率，不过因为它的预测机制会在进程将要结束一个读写操作时时开始准备下一个的预处理，所以会打乱系统正常的连续io调度，降低随机存取效率。用的人很少，不推荐。
deadline
顾名思义，用过期时间来排序io操作顺序，保证先出现的io请求有最短的延迟时间，相对于写操作，给读操作更优先的级别。是比较好的一个调度模式。
cfq
完全公平队列，是anticipatory模式的替代品，没有过多的做预测性调度，而是根据给定的进程io优先级，直接来分配操作的顺序。这个模式在linux上表现良好，但也许并不是最适合android的io调度模式，太强调均衡，而降低了连续读写数据的性能。
vr
具有和deadline相似的操作排序机制，有着最高的峰值读写速度，但是性能比较不稳定，也就是说可能跑出最高的分数，但是也会出现最低值。
sio
虽然基于deadline，但是它和noop一样，不会对io操作进行排序，所以有着noop那样快速的存取速度，但并没有过多优化io操作。如果不喜欢noop完全不参与调度，也可以选择这个。
总体而言，推荐指数依次为sio=deadline(两种趋向，一种少干预，一种多干预)>vr(性能可以达到最高峰值)>cfq=noop>anticipatory

1.名词解释
    GPU：Graphic  Processing Unit （图形处理器）
    OpenGL：Open  Graphic Library 定义了一个跨编程语言、跨平台的编程接口的规格，不同厂商会有不同的实现方法，它主要用于三维图象（二维的亦可）绘制。
    SurfaceFlinger：Android中负责Surface之间叠加、混合操作的动态库
    Skia：Android中的2D图形库
    libagl：Android中通过软件方法实现的一套OpenGL动态库
    libhgl：为区别libagl，自定义的一种叫法。特指GPU厂商提供的硬件实现的OpenGL
    composition：特指SurfaceFlinger对各个Surface之间的叠加、混合操作
    render：特指使用OpenGL动态库进行3D渲染
    copybit:Android使用2D引擎来加速图形操作（主要是Surface之间的composition操作）的一种技术，对应着一个或几个动态库。
    pmem：Android特有驱动，从linux内核中reserve物理连续内存，可以为2d、3d引擎、vpu等设备分配物理连续内存。
2   3D、2D引擎在Android中的使用方法
2.1  Android如何使用2D、3D引擎
    Android在启动后，会在运行时根据配置文件加载OpenGL（libagl & libhgl）的实现，如果有libhgl实现，默认使用libhgl实现，否则使用libagl实现。
     
    Android OpenGL动态库使用方法：
    1. 判断是否含有egl.cfg文件，如果没有在加载libagl
    2. 如果有egl.cfg文件，则解析egl.cfg文件，根据egl.cfg文件加载对应libhgl和libagl
    3. 分别解析libagl和libhgl，获取libagl和libhgl中标准OpenGL函数的函数地址（函数指针）
    4. 系统在执行过程中，会通过函数指针调用到libagl或者libhgl中去，从而实现图形的绘制。
     
    OpenGL在Android中两个作用：
    1. 用于Surface的composition操作。
             SurfaceFlinger会调用到OpenGL中，通过libagl或者libhgl做Surface的组合、叠加操作。
    2. 用于图形图像的渲染
             Android framework会对OpenGL实现进行java层次的简单封装，在java应用程序中对OpenGL的调用最终会调用到libagl或者libhgl中去。
             很多第三方游戏、3D图库、某些launcher会使用OpenGL实现比较炫丽UI的特效。
     
    Copybit在Android中的作用
    Copybit在Android中主要用于Surface的composition操作。
     
     
    Skia在Android中的作用
    Skia是Android的2D图形库，用于绘制文字、几何图形、图像等。
    Skia的设备后端：Raster、OpenGL、PDF
     

     
    2.2 使用GPU硬件加速需要做的工作
    1. Linux内核方面：
             1.1添加GPU驱动支持，以模块方式编译GPU驱动，Android启动时加载内核模块。
             1.2添加PMEM支持，预留内存供GPU使用
    2. Android方面：
             2.1添加copybit HAL
    我们使用copybit调用2D engine对surface composition进行硬件加速。这样可能会达到更大的性能提升效果（比起使用3D  engine）。
             2.2修改gralloc
    gralloc负责显存等的分配，以及对framebuffer操作。如果使用copybit，必须修改gralloc
             2.3修改libagl
    如果使用copybit，必须修改libagl，对libagl做部分hack，使之能够调用到copybit。
             2.4修改surfaceflinger
             如果使用 copybit可能需要做部分修改

  
3D性能提升
（有很多人问，这样会不会增加耗电什么的，我觉得只会减少耗电，毕竟3D本来就是gpu的强项，之所以系统还会调用cpu，是为了保证兼容性。本帖士只会让系统优先调用gpu）

用Root Explorer打开 /system/lib/egl

长按并选择打开egl.cfg文件
会有一下：
0 0 android
0 1 adreno200
删去第一行，使之成为： 0 1 adreno200
这样更改之后，3D游戏明显流畅，象限3D跑分轻松上700，其中星球的那一项可以达到60fps。
原理说明：
本文件的作用是帮助系统选择“在某些3D应用时，使用cpu还是gpu来解码”，0为是，1为否。
即每行语法如下： 情况A是否调用 情况B是否调用 调用什么

可以看到，原设置是，在情况A下，cpu和gpu都可以被选择，而情况B下则选择cpu。
问题就出在这个情况A，很多软件会默认选择cpu，可能因为它在第一行，所以我们要更改这一设定。
更改有三种方法，都是在xda上被广泛认可的：
1.删除cpu的解码包（同文件夹下的libGLES_android.so），这个是xda上最开始出现的做法，很野蛮，可能会出问题，强烈不推荐。
2.将第一行的两个0改成两个1，使之成为：
0 0 android
0 1 adreno200
这样就迫使软件使用gpu。那为什么不改成1 0呢？因为大神们还没搞清楚情况A和情况B的对应关系。
3.如本人所述，直接删除第一行。这样，软件默认使用gpu，因为没有cpu的描述，在gpu失败的情况下，系统还是会继续使用cpu。