安卓调谐器3CToolbox教程

linux内核内核参数

sysctl.conf file

fs.nr_open=1053696;

fs.inotify.max_queued_events=32000; fs.inotify.max_user_instances=256; fs.inotify.max_user_watches=10240; fs.lease-break-time=10; fs.file-max=165164;

kernel.threads-max=525810;

kernel.random.write_wakeup_threshold=256; kernel.random.read_wakeup_threshold=128; kernel.panic=5;

kernel.sched_compat_yield=1; kernel.panic=0;

kernel.panic_on_oops=1; kernel.msgmni=2048; kernel.msgmax=64000; kernel.shmmni=4096; kernel.shmall=2097152; kernel.shmmax=268435456;

kernel.sem=&39;500 512000 64 2048&39;; kernel.sched_features=24189;

kernel.hung_task_timeout_secs=30; kernel.sched_latency_ns=18000000;

kernel.sched_min_granularity_ns=1500000; kernel.sched_wakeup_granularity_ns=3000000; kernel.sched_shares_ratelimit=256000; kernel.sched_child_runs_first=0; fs.lease-break-time=10; fs.file-max=65536;

net.core.wmem_max=524288; net.core.rmem_max=524288; net.core.rmem_default=262144; net.core.wmem_default=262144; net.core.optmem_max=20480; net.unix.max_dgram_qlen=50

net.ipv4.tcp_keepalive_time=900; net.ipv4.tcp_keepalive_probes=5; net.ipv4.tcp_keepalive_intvl=156; net.ipv4.tcp_timestamps=0;

net.ipv4.tcp_sack=1; net.ipv4.tcp_fack=1;

net.ipv4.tcp_window_scaling=1; net.ipv4.tcp_tw_recycle=1; net.ipv4.tcp_tw_reuse=1;

net.ipv4.tcp_congestion_control=cubic; net.ipv4.tcp_syncookies=1; net.ipv4.conf.all.rp_filter=1; net.ipv4.conf.default.rp_filter=1; net.ipv4.tcp_synack_retries=2; net.ipv4.tcp_syn_retries=2;

net.ipv4.tcp_max_syn_backlog=1024; net.ipv4.tcp_max_tw_buckets=16384; net.ipv4.icmp_echo_ignore_all=1;

net.ipv4.icmp_ignore_bogus_error_responses=1; net.ipv4.tcp_no_metrics_save=1; net.ipv4.tcp_fin_timeout=15; net.ipv4.tcp_keepalive_intvl=30; net.ipv4.tcp_keepalive_probes=5; net.ipv4.tcp_keepalive_time=1800; net.ipv4.ip_forward=0;

net.ipv4.conf.default.accept_source_route=0 ; net.ipv4.conf.all.accept_source_route=0; net.ipv4.conf.all.accept_redirects=0; net.ipv4.conf.default.accept_redirects=0; net.ipv4.conf.all.secure_redirects=0; net.ipv4.conf.default.secure_redirects=0; net.ipv4.udp_rmem_min=6144; net.ipv4.udp_wmem_min=6144; net.ipv4.tcp_rfc1337=1;

net.ipv4.ip_no_pmtu_disc=0; net.ipv4.tcp_ecn=0; net.ipv4.route.flush=1;

net.ipv4.tcp_rmem=&39;6144 87380 524288&39;; net.ipv4.tcp_wmem=&39;6144 87380 524288&39;; net.ipv6.conf.default.use_tempaddr=2; net.ipv6.conf.all.use_tempaddr=2;

net.ipv6.conf.all.temp_prefered_lft=3600; net.ipv6.conf.default.temp_prefered_lft=3600; （net.ipv 是对wifi 和3g网络调整参数） vm.dirty_ratio=90;

vm.dirty_background_ratio=80; vm.oom_kill_allocating_task=1; vm.overcommit_memory=1;

vm.page-cluster=3; vm.drop_caches=3;

vm.min_free_kbytes=4096; vm.panic_on_oom=0;

vm.dirty_expire_centisecs=1000; vm.dirty_writeback_centisecs=2000; vm.oom_kill_allocating_task=0; vm.vfs_cache_pressure=10; vm.min_free_order_shift=4; vm.laptop_mode=0; vm.block_dump=0;

所有的一切都可以手动输入参数build.prop文件

在Android系统中有一个类似Windows系统注册表的文件build.prop。这个文件内定义了系统初始（或永久）的一些参数属性、功能的开放等。通过调整/增加参数可以达到较调系统性能偏重点和附加功能开启的作用。大部分民间第三方ROM所说的优化大部分都是优化build.prop文件

在Android 2.2、2.3、4.0、4.1、4.2、4.3、4.4中虽然每一版都有自己独有的参数，但绝大部分都是通用的，且可以起到关键性作用的。

熵的原理与调试

熵是衡量物质“混乱”程度的一种物理量 熵值越大 物质越混乱

根据物理学基本原理，一个系统的熵越大，该系统就越不稳定。在Android中，目前也只有随机数常处于这种不稳定的系统中了。 关于熵 网上介绍引用百度百科 总述

随机数在许多领域都有重要应用,如Monte Carlo模拟、密码学和网络安全。随机数的质量直接关系到网络安全系统的可靠性和安全性，关系到 Monte Carlo模拟结果的可信度。自从计算机诞生起，寻求用计算机产生高质量的随机数序列的研究就一直是个长期受到关注的课题。Linux内核从 1.3.30版本开始实现了一个高强度的随机数发生器，本文根据Linux 2.6.10内核的源代码，详细分析该随机数产生器的设计与实现。

基本原理

Linux内核采用熵来描述数据的随机性。熵（entropy）是描述系统混乱无序程度的物理量，一个系统的熵越大则说明该系统的有序性越差，即不确定性越大。在信息学中，熵被用来表征一个符号或系统的不确定性，熵越大，表明系统所含有用信息量越少，不确定度越大。

计算机本身是可预测的系统，因此，用计算机算法不可能产生真正的随机数。但是机器的环境中充满了各种各样的噪声，如硬件设备发生中断的时间，用户点击鼠标的时间间隔等是完全随机的，事先无法预测。Linux内核实现的随机数产生器正是利用系统中的这些随机噪声来产生高质量随机数序列。

内核维护了一个熵池用来收集来自设备驱动程序和其它来源的环境噪音。理论上，熵池中的

数据是完全随机的，可以实现产生真随机数序列。为跟踪熵池中数据的随机性，内核在将数据加入池的时候将估算数据的随机性，这个过程称作熵估算。熵估算值描述池中包含的随机数位数，其值越大表示池中数据的随机性越好。（按照这个来说应该是值大一些好）

安卓OOM Dalvik虚拟机的堆内存分配

安卓OOM是Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。

这里3C tooidox直接通过图形化界面调节 不过这些值不能乱调下面说下：

dalvik.vm.heapstartsize堆分配的初始大小，调整这个值会影响到应用的流畅性和整体ram消耗。这个值越小，系统ram消耗越慢，但是由于初始值较小，一些较大的应用需要扩张这个堆，从而引发gc和堆调整的策略，会应用反应更慢。相反，这个值越大系统ram消耗越快，但是程序更流畅。

dalvik.vm.heapgrowthlimit极限堆大小，dvm heap是可增长的，但是正常情况下dvm heap的大小是不会超过dalvik.vm.heapgrowthlimit的值。如果受控的应用dvm heap size超过该值，则将引发oom。

dalvik.vm.heapsize使用大堆时，极限堆大小。一旦dalvik heap size超过这个值，直接引发oom。在android开发中，如果要使用大堆，需要在manifest中指定android:largeHeap为true。这样dvm heap最大可达dalvik.vm.heapsize。

dalvik.vm.heaptargetutilization]: [0.75] 可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。

上面的几个参数是与虚拟机的内存分配相关的，虚拟机的内存分配过程是下面这样的：

1 首先判断一下需要申请的size是不是过大，如果申请的size超过了堆的最大限制，则转入步骤6

2 尝试分配，如果成功则返回，失败则转入步骤3

3 判断是否gc正在进行垃圾回收，如果正在进行则等待回收完成之后，尝试分配。如果成 功则返回，失败则转入步骤4

4 自己启动gc进行垃圾回收，这里gcForMalloc的参数是false。所以不会回收软引用，回收完成后尝试分配，如果成功则返回，失败则转入步骤5

5 调用dvmHeapSourceAllocAndGrow尝试分配，这个函数会扩张堆。所以heap startup的时候可以给一个比较小的初始堆，实在不够用再调用它进行扩张

6 进入回收软引用阶段，这里gcForMalloc的参数是ture，所以需要回收软引用。然后调用dvmHeapSourceAllocAndGrow尝试分配，如果失败则抛出OOM。

在android上，主要有6大类进程分别是foregroud, visible, secondary server， hidden, content provider和empty。它们被kill的优先级,依次是emtpy > content provider > hidden > secondary server > visible > foreground。而每一类进程，系统都有一个阀值，而一旦当阀值达到最大阀值，就会按照上面的顺序进程清理进程。

比如策略为6m, 8m, 16m, 20m, 22m, 24m，当系统剩余内存为22m时，就会先清理empty的进程，如果清理完毕之后，如果剩余内存还足24m, 则继续清理content provider的进程，如此类推，直到剩余内存达到24m以上为止。

根据各类进程的作用，以及用户的类型，我们可以配置出各种内存分配模式： 1) 长时间只关注某一个应用，比如游戏，浏览器等——极客模式；

2) 需要在多个应用中来往跳转，比如QQ、浏览器，微信等——多变模式；

3) 只关注来电，短信，邮件等商务——商务模式；

有root的情况下，通过修改系统文件/sys/module/lowmemorykiller/parameters/minfree，即可动态修改这六个值。

下面是关于这六类进程的作用简单介绍：

前台进程（foreground）：目前正在屏幕上显示的进程和一些系统进程。举例来说，Dialer Storage，Google Search等系统进程就是前台进程；

再举例来说，当你运行一个程序，如浏览器，当浏览器界面在前台显示时，浏览器属于前台进程（foreground），但一旦你按home回到主界面，浏览器就变成了

后台程序（background）。我们最不希望终止的进程就是前台进程。

可见进程（visible）：可见进程是一些不再前台，但用户依然可见的进程，举个例来说：widget、输入法等，都属于visible。这部分进程虽然不在前台，但与我们的使用也密切相关，我们也不希望它们被终止（你肯定不希望时钟、天气，新闻等widget被终止，那它们将无法同步，你也不希望输入法被终止，否则你每次输入时都需要重新启动输入法）；

次要服务（secondary server）：目前正在运行的一些服务（主要服务，如拨号等，是不可能被进程管理终止的，故这里只谈次要服务），举例来说：谷歌企业套件，Gmail内部存储，联系人内部存储等。这部分服务虽然属于次要服务，但很一些系统功能依然息息相关，我们时常需要用到它们，所以也太希望他们被终止 ；

ro.media.dec.jpeg.memcap=20000000

ADDITIONAL_BUILD_PROPERTIES （其他性能设置）

no_require_sim=true （手机卡保护设置）

ro.rommanager.developerid=cyanogenmodnightly （固件管理器开发者是CM大神）

ro.url.legal=ht

ro.url.legal=http://www./intl/%s/mobile/android/basic/phone-legal.html

ro.url.legal.android_privacy=http://www./intl/%s/mobile/android/basic/privacy.html

ro. com.google.clientidbase=android-google （谷歌客户身份）

ro. com.android.wifi-watchlist=GoogleGuest （WIFI用户名单）

ro.setupwizard.enterprise_mode=1 （默认情景模式） ro. com.android.dateformat=MM-dd-yyyy （默认时间格式，改为yyyy-MM-dd，显示效果就是XXXX年XX月XX日）

ro. com.android.dataroaming=false （漫游设置）

ro.config.ringtone=Playa.ogg （默认铃声设置，文件在

/system/media/audio/ringtones 把喜欢的铃声放这里，比如123. MP3放入ringtones文件夹中，这里代码改为ro.config.ringtone=123. mp3）

ro.config.notification_sound=regulus.ogg （默认提示音，文件在/system/media/audiotifications 修改方法同上）

ro.config.alarm_alert=Alarm_Beep_03.ogg （默认闹铃，文件在/system/media/audio/alarms 修改方法同上）

ro.modversion=CyanogenMod-7-06192011-NIGHTLY-buzz （版本信息，改这个能让你大名出现系统关于中，改为ro.modversion=xxxxx）

ro.setupwizard.mode=OPTIONAL （安装向导模式）

net. bt. name=Android （系统名称）

dalvik.vm.stack-trace-file=/data/anr/traces.txt

Dalvik虚拟机

Dalvik虚拟机是Android操作系统的核心，是一切应用程序的基础。所有程序在运行时均有Dalvik虚拟机对其进行解析和执行。

dalvik.vm.startheapsize：本参数控制Dalvik虚拟机在启动一个应用程序之后为其分配的初始堆栈大小，可填写的值为2m~48m。 例如：dalvik.vm.startheapsize=8m，就表示应用程序启动后为其分配的初始堆栈大小为8兆字节。

这里分配的内存容量会影响到整个系统对RAM的使用程度，和第一次使用应用程序时的流畅程序。这个值越大，系统消耗RAM则越快，但是应用程序打开后的反应也越快。值越小，系统的RAM剩余则越多，但是程序在启动后会很卡。

建议值是8m，既可以保持140M左右的RAM，程序的反应速度也会大幅度提高。

dalvik.vm.heapsize：本参数控制Dalvik虚拟机给一个应用程序分配的最大堆栈量，可填写的值为12m~48m。 例如：dalvik.vm.heapsize=48m，就表示应用程序在任意时刻内可以使用的最大堆栈大小为48兆字节。这里分配的内存容量会影响到整个系统对RAM的使用程序，和程序在运行一段时间后的反应速度。这个值越大，系统消耗RAM则越快，但是程序会运行的非常稳定，尤其是游戏和视频程序的内容加载速度可以大幅度提升。值越小，系统的RAM剩余则越多，但是程序会很卡，尤其是游戏在切换场景Loading的时候会 花费很多的时间。若应用程序需要使用超过这个值的内存时，将会触发系统的垃圾收集器，系统和程序就会卡顿。 建议值是40~48m。（这里应该结合上面的 Dalvik虚拟机 的堆内存分配来看 ）

dalvik.vm.lockprof.threshold：本参数控制Dalvik虚拟机调试记录程序内部锁资源争夺的阈值，默认值是500。多用于程序的数据统计，对性能较调意义不大。

dalvik.vm.stack-trace-file：本参数控制Dalvik虚拟机的堆栈记录调试文件。用于系统调试，一般用户对其调整无意义。

dalvik.vm.execution-mode：本参数控制Dalvik虚拟机的程序执行机制。可填写的值有”int:portable”、”int:fast”和”int:jit”。 其中:

int:portable表示以兼容模式运行(脚本翻译模式)，此模式下程序的兼容性最高，但其执行效率最低(程序优化度依赖于dalvik虚拟机版本)。官方默认此模式。

int:fast表示以快速自优化模式运行(脚本翻译和预优化混合)，此模式下程序的兼容性很高，执行效率也比较高。因为此时dalvik虚拟机允许程序使用自己的预定义优化模式和代码(包括C/C++/汇编代码)。推荐使用。

int:jit表示以Just-In-Time模式运行(JIT模式)，此模式下程序的兼容性最差，但程序一旦加载后其运行效率最高(与C/C++直接编 写的程序效率无异)，因为在此模式下dalvik虚拟机会预先将Java程序翻译成针对机器平台的本地语言(Native)，同时完全允许代码中的所有预 优化和代码，允许所有不安全的非托管代码，同时不严谨的程序如果运行在JIT模式可能会造成内存泄露。但要注意，很多Dalvik虚拟机并不支持此模式 (如官方2.2)。

dalvik.vm.dexopt-flags：本参数控制Dalvik虚拟机的程序代码校验和优化。可填写的值有m、v和o。 m为标准选项，可以是m=y或m=n。若m=y则启用不安全代码的校验和托管代码的优化。兼容性和安全性最高，推荐使用。 v为校验选项，可与o并存。可以是v=a或v=n。若v=a则表示校验所有代码，v=n则关闭代码的校验。 o为优化选项，可与v并存。可以是o=v或o=a。若o=v则表示优化以校验过的代码，o=a则表示优化所有代码。 例如：

dalvik.vm.dexopt-flags=m=y dalvik.vm.dexopt-flags=v=n,o=v 注意，这个参数只会影响到安装APK之后或初次使用APK时生成dex文件时有效。若整个系统(包括应用程序)为odex化，则无意义。

dalvik.vm.verify-bytecode：本参数控制Dalvik虚拟机是否验证应用程序的可执行代码。可以与上一个参数配合使用。可填写的值为true和false。 其具体意义与dalvik.vm.dexopt-flags的v=n一模一样。但可以与dalvik.vm.dexopt-flags配合使用以取得更好的效果。

例如： dalvik.vm.dexopt-flags=v=n,o=v dalvik.vm.verify-bytecode=false 这样可以令后来安装的apk文件可以被优化而不被检验。

dalvik.vm.checkjni：本参数控制Dalvik虚拟机在调用外部jni链接库的时候是否对其做安全性检验。可填写的值为true和false。 此参数会覆盖

ro.kernel.android.checkjni。 若值为true，会增加程序的兼容性和稳定性，但也会增加其加载和执行的时间，推荐为false。

dalvik.vm.deadlock-predict：本参数控制Dalvik虚拟机对程序死锁预测处理。可填写的值有off、warn和err。 off表示关闭死锁预测功能(默认设置)。 warn表示在继续程序运行的同时只记录该死锁预测(如果为真死锁就会出现程序假死现象，然后等N久出现关闭)。 err表示预测到死锁时马上弹出FC。

注意：有些Dalvik虚拟机版本并不支持此参数。

总结： 对于本期此处给出三种常用的配置(以Defy为机型)。

超级急速流畅型：

dalvik.vm.startheapsize=16m

dalvik.vm.heapsize=48m

dalvik.vm.execution-mode=int:jit

dalvik.vm.dexopt-flags=v=n,o=v

dalvik.vm.checkjni=false

常用稳定加流畅型：

dalvik.vm.startheapsize=8m

dalvik.vm.heapsize=40m

dalvik.vm.execution-mode=int:fast

dalvik.vm.dexopt-flags=m=y

dalvik.vm.checkjni=false

超级稳定大内存型：

dalvik.vm.startheapsize=4m

dalvik.vm.heapsize=30m

dalvik.vm.execution-mode=int:portable

dalvik.vm.dexopt-flags=v=a,o=v

dalvik.vm.verify-bytecode=true

dalvik.vm.checkjni=true

系统版本定义

本期将介绍系统版本、定义等相关参数。主要用于定义系统版本特征字串，OTA字串等。由于较少用到，因此只粗略介绍。

本参数定义了系统的版本ID。为系统内部使用，OTA时作为粗略版本比较。更改后可避免OTA提示，但可能会引起预装程序(如Blur)的稳定性。

本参数定义了设置中显示的系统版本号。主要用于设置中显式出现可读版本，一般用于个性化定制和第三方应用程序对系统版本的判断(如魔趣设置)。更改后可自定义版本显示，但某些第三方应用程序会出现错误(如魔趣设置无法实现机器保修查询)。

ro.build.version.incremental:本参数定义了系统的升级字。主要用于系统OTA精确版本比对，同时与ro.build.description和ro.build.fingerprint相匹配。更改后可以免OTA提示(如避免Miui的升级提示和Blur的升级提示)。

ro.product.model:本参数定义了机器的型号字符串。主要用于机器型号显式定义(如系统设置中的手机型号和Blur、Google设置向导中的机型等)。更改后可自定义手机型号名称。

ro.product.locale.language:本参数定义了系统的初始(默认)语言。此处注意是语言，如中文是zh，英文是en。更改后改变系统初次启动时的语言设置。

ro.product.locale.region:本参数定义了系统的初始(默认)区域。此处注意是区域，如中国大陆为CN，台湾为TW，美国为US。更改后改变系统初次启动时的区域设置。 ro.build.description和ro.build.fingerprint均为ROM的编译综合说明。其中包含了平台硬件、Android版本、源代码分支和标签、OTA详细版本等。 其中的OTA部分，例如： umts_jordan_china-user 2.3.6 4.5.3-109_DPP-14 123456 release-keys 将此数字与

ro.build.version.incremental一同更改可避免OTA升级提醒(如Miui和Blur等)。

windowsmgr.max_events_per_sec:本参数定义了Android系统的窗体事件管理器在单位时间内可以处理的最大事件数量。通过更改本参数可以获得非常明显的丝滑流畅体验。可填写的值范围为”大于0的正整数”，官方默认为60。建议150、200、260、300这几个值。

当此值变大时，系统触控平滑度明显提高，但对应的CPU使用率也会升高，最终的结果就是电池续航能力下降。以我个人的经验来说，此值取到240左右时在系统设置中滑动可以得到接近WP7的流畅和平滑度。

ro.min_pointer_dur:本参数定义了两次触摸之间的最短时间间隔，单位是毫秒。默认值为25，推荐值是10。通过调整此参数可以提高系统触控的灵敏度或稳定度。当此值越大时，触控越稳定。此值越小，触控越灵敏。

mot.proximity.delay：本参数定义了手机光纤感应器的抖动消除时间，单位是毫秒。默认值是500，推荐值是250。

通过调整此参数可以提高在通话结束后屏幕点亮的速度。当此值越大时，通话结束后屏幕点亮所需要的时间越长，但在通话过程中如果手机意外瞬间离开脸部也不会点亮屏幕，可防止通话过程中的误操作(比方说通话时不 小心手机移动了一下，屏幕就会点亮，此时如果脸部触碰到了屏幕就会对通话造成影响)。此值越小，则当手机离开脸部或装入口袋后会立即点亮或关闭屏幕。

mot.proximity.distance：本参数定义了手机屏幕上的两个触摸点之间的最短距离，若距离小于此值则认为是一个触摸点，单位是像素。默认值是60，推荐值

是100。为什么推荐100呢？因为Defy的屏幕分辨率为480×854，也就是说横向有480个像素点，对应上去也就相当于是横向并排允许4个触摸点，平均一个手指一个点，这样在类似于杀西瓜等游戏中可以提升游戏操作。

ro.kernel.android.checkjni：本参数定义了Dalvik虚拟机在执行程序的时候是否要做Jni链接库的检查工作。详细见Dalvik参数属性期。若考虑稳定性可使用true，若需要性能可使用false。注意：此参数会被Dalvik参数覆盖。

ro.media.enc.jpeg.quality：本参数定义了JPEG图像编码器所使用的质量因子，可填写的值为1~100，默认为80。推荐为100。想照出更好的照片吗？想让照片的大小轻松上M吗？那就使用100吧。

debug.sf.hw：本参数定义了系统是否启用GPU来渲染程序的UI，默认为0，推荐为1。

但要注意，如果此值为1，在某些应用程序中可能会出现显示错乱的现象(极少见)。

persist.sys.use_dithering：本参数定义了系统渲染器对图像的缩放是否启用抖动技术。可填写的值为0或1。

当开启抖动后，图像的显示(指背景、解锁等的图像，并非图库、相机那些的)会很柔和，但会增加CPU负载，最终导致ROM卡顿。

persist.sys.purgeable_assets：本参数定义了系统是否可以清除暂时不用的数据以释放更多的RAM。可填写的值为0或1。

当值为1时，系统会定期清理不用的数据以释放更多的RAM，同时作为代价就是下次启动程序或游戏加载数据会变慢。

video.accelerate.hw：本参数定义了系统是否对视频启用硬件加速功能。 这里的视频指代屏幕上显示的东西，不仅仅是”电影视频”。可填写的值为0或1。

需要注意的是：

摩托官方的2.2与2.3系统对此功能支持的不是很好，开启后有时反而会降低系统流畅度，但CM系统绝对建议开启。

debug.performance.tuning：本参数定义了系统是否针对性能做较调。可填写的值为0或1。 需要注意的是：

摩托官方的2.2和2.3系统对此功能支持的不是很好，开启后有时反而会降低系统流畅度。但CM系统绝对建议开启。

ro.HOME_APP_ADJ

ro.FOREGROUND_APP_ADJ

ro.VISIBLE_APP_ADJ

ro.PERCEPTIBLE_APP_ADJ

ro.HEAVY_WEIGHT_APP_ADJ

ro.SECONDARY_SERVER_ADJ

ro.BACKUP_APP_ADJ

ro.HIDDEN_APP_MIN_ADJ

ro.EMPTY_APP_ADJ

以上参数定义了各种应用程序的管理机制，这些并非一两句话可以说清楚的，想深究的同学可以Google一下OOM Killer。可填写的值为整数。

这里只给出值的规律：

0代表降低进程的优先级且驻留内存；

1代表驻留内存；

4代表缓存较多的内存；

15代表尽量缓存内存。

也就是说内存缓存器是按照ADJ从大到小来进行缓存的。

大家可根据自系统中自己对各种应用程序的要求进行更改。

经典用例：

ro.FOREGROUND_APP_ADJ=0 前台程序驻留内存(不缓存)

ro.VISIBLE_APP_ADJ=1 可见的程序驻留内存(不缓存)

ro.PERCEPTIBLE_APP_ADJ=2 缓存的RAM多一些

ro.HOME_APP_ADJ=3 桌面程序，缓存的RAM稍多一些

ro.HEAVY_WEIGHT_APP_ADJ=4 缓存的RAM再多一些

ro.SECONDARY_SERVER_ADJ=5 缓存的RAM再再多一些

ro.BACKUP_APP_ADJ=6 缓存的RAM再再再多一些

ro.HIDDEN_APP_MIN_ADJ=7 隐藏的程序，根据程序的类型进行内存管理，最低为缓存的RAM再再再再多一些，最高就是直接缓存内存。

ro.EMPTY_APP_ADJ=15 已经退出的程序，直接缓存内存

ro.FOREGROUND_APP_MEM

ro.VISIBLE_APP_MEM

ro.PERCEPTIBLE_APP_MEM

ro.HEAVY_WEIGHT_APP_MEM

ro.SECONDARY_SERVER_MEM

ro.BACKUP_APP_MEM

ro.HOME_APP_MEM

ro.HIDDEN_APP_MEM

ro.CONTENT_PROVIDER_MEM

ro.EMPTY_APP_MEM

以上参数定义了各种类型的应用程序在内存缓冲的大小，单位是页，应用上面ADJ参数相对应。 经典用例：

ro.FOREGROUND_APP_MEM=1280 ro.VISIBLE_APP_MEM=2560 ro.PERCEPTIBLE_APP_MEM=3840 ro.HEAVY_WEIGHT_APP_MEM=6400 ro.SECONDARY_SERVER_MEM=7680 ro.BACKUP_APP_MEM=8960 ro.HOME_APP_MEM=5120 ro.HIDDEN_APP_MEM=12800

ro.CONTENT_PROVIDER_MEM=15360 ro.EMPTY_APP_MEM=20480

当然不止这些上面是2.3时代的

更好的录像.照相优化

ro.media.capture.maxres=8m ro.media.capture.fast.fps=4 ro.media.capture.slow.fps=120

ro.media.panorama.defres=3264x1840 ro.media.panorama.frameres=1280x720 ro.camcorder.videoModes=true

wifi速度优化

net.ipv4.tcp_ecn=0 net.ipv4.route.flush=1 net.ipv4.tcp_rfc1337=1 net.ipv4.ip_no_pmtu_disc=0 net.ipv4.tcp_sack=1 net.ipv4.tcp_fack=1

net.ipv4.tcp_window_scaling=1 net.ipv4.tcp_timestamps=1

net.ipv4.tcp_rmem=4096 39000 187000 net.ipv4.tcp_wmem=4096 39000 187000 net.ipv4.tcp_mem=187000 187000 187000 net.ipv4.tcp_no_metrics_save=1 net.ipv4.tcp_moderate_rcvbuf=1

General Performance（普通的基本优化） debug.sf.hw=1

dalvik.vm.heapsize=48m persist.sys.ui.hw=1

Faster Scrolling（滑动的更快，更流畅的意思） ro.max.fling_velocity=12000 ro.min.fling_velocity=8000

Saves power（省电）

ro.ril.disable.power.collapse=1 pm.sleep_mode=1

wifi.supplicant_scan_interval=180 （如果设置后觉得wifi变慢就删掉这行）

Raises quality of images（图像质量优化） ro.media.enc.jpeg.quality=100

media.stagefright.enable-player=true media.stagefright.enable-meta=true media.stagefright.enable-scan=true media.stagefright.enable-http=true

wifi速度优化

net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960

Makes apps load faster and frees more ram.（使程序加载更快，更多空余的RAM，就是运行内存）

dalvik.vm.dexopt-flags=m=v,o=y

Improve 3g data speeds （提高3g网络的数据传输速度）

ro.ril.hsxpa=2

ro.ril.gprsclass=10 ro.ril.hep=1

ro.ril.enable.dtm=1

ro.ril.hsdpa.category=10 ro.ril.enable.a53=1

ro.ril.enable.3g.prefix=1

ro.ril.htcmaskw1.bitmask=4294967295 ro.ril.htcmaskw1=14449 ro.ril.hsupa.category=5

Increase overall touch responsiveness（提高整体触摸响应） debug.performance.tuning=1 video.accelerate.hw=1

Disable blackscreen issue after a call（通话后禁止屏幕黑屏） ro.lge.proximity.delay=25 mot.proximity.delay=25

Fix some application issues（修复应用程序报错问题） ro.kernel.android.checkjni=0

Force button lights on when screen is on（当屏幕亮时，强制点亮按键灯光） ro.mot.buttonlight.timeout=0

ro.secure=0 默认开启未知源apk..

ro.allow.mock.location=1 开启模拟位置

debug.sf.hw=1 硬件加速设定 0是关闭, 1是开启

persist.service.adb.enable=1 开启调试模式

media.stagefright.enable-player=true media.stagefright.enable-meta=false media.stagefright.enable-scan=false media.stagefright.enable-http=false

这些全改为true会增强系统自带的多媒体效果， ro.ril.def.agps.mode =0

据说改成0可以加速gps定位省流量

dalvik.vm.execution-mode=int:fast关闭JIT dalvik.vm.heapsize=35m 修改虚拟内存

ro.sf.lcd_density= 后面一般为240，可以自己改 dalvik.vm.heapsize=32m，原来的值是24m。

dalvik.vm.execution-mode=int:jit 打开超频模式

view.touch_slop=15 （触摸屏灵敏度，数值越大越灵敏） view.minimum_fling_velocity=25 （滑动速度） view.scroll_friction=0.008 （滑动误差）

ro.product.multi_touch_enabled=true 支持多点触摸 ro.product.max_num_touch=2 触摸点为最多2点！

游戏性能加速：

debug.sf.hw=1，原来的值是0。这个是启用了硬件GUI渲染。 media.stagefright.enable-meta=true media.stagefright.enable-scan=true media.stagefright.enable-http=true 原来这3个设定都是false。

定位加速：

red]ro.ril.def.agps.mode=0（原值2.打开AGPS服务支持，可改为ro.ril.def.agps.mode=0 改后能省电但GPS定位速度会变慢）

To save power while phone is asle To save power while phone is asleep //在手机休眠时更省电

ro.ril.disable.power.collapse=1

To make the phone ring faster when dialing out... //使电话拨出时更快接通

ro.telephony.call_ring.delay=1000

To make UI more responsive //使界面反应更快

windowsmgr.max_events_per_sec=150

To save battery by decreasing the amount of time Wifi looks for an access point

//使WIFI在查找接入点时更省电 wifi.supplicant_scan_interval=150

**Now wifi will scan once every 1.5 minutes when not around a known location instead of once every minute which will save battery.** //现在wifi将每隔1.5分钟查找一次接入点而不是每分钟查一次。当你在一个没有已知接入点的地方。（估计是，如果你开WIFI了，如果没有连接到接入点，查找接入点的时间间隔改成了一分半钟) 1. 强制把Home程序驻入内存. 参数:

ro.HOME_APP_ADJ=1

2.提高 JPG 质量为 100% 参数:

ro.media.enc.jpeg.quality=100 3. VM 虚拟堆大小; 提高 RAM 参数:

dalvik.vm.heapsize=48m 4. 使用 GPU 渲染UI 参数:

debug.sf.hw=1

5. 减少拨号后出现的延时 参数:

ro.telephony.call_ring.delay=0 6.提高滑动响应 参数:

windowsmgr.max_events_per_sec=150 7.电池优化 参数:

wifi.supplicant_scan_interval=180 pm.sleep_mode=1

ro.ril.disable.power.collapse=0 8. 禁止调试通知图标出现在状态栏处 参数:

persist.adb.notify=0 9. 提高全局触摸屏响应 参数:

debug.performance.tuning=1 video.accelerate.hw=1 11. (3G) 信号优化 参数:

ro.ril.hsxpa=2 ro.ril.gprsclass=10 ro.ril.hep=1 ro.ril.enable.dtm=1

ro.ril.hsdpa.category=10 ro.ril.enable.a53=1

ro.ril.enable.3g.prefix=1

ro.ril.htcmaskw1.bitmask=4294967295 ro.ril.htcmaskw1=14449 ro.ril.hsupa.category=5 12. 网络速度优化 参数:

net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960 net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960 13. 禁止拨号后出现黑屏. 参数:

ro.lge.proximity.delay=25 mot.proximity.delay=25

14.修复应用程序出现问题. 参数:

ro.kernel.android.checkjni=0 15.不通过按加/减音键唤醒手机 参数:

ro.config.hwfeature_wakeupkey=0 16.屏幕点亮时强制开启功能键背光 参数:

ro.mot.buttonlight.timeout=0

17.不显示开机动画(system/media/bootanimation.zip动画将不显示,加速开机速度) 参数:

debug.sf.nobootanimation=1 18.其他优化 参数:

ro.config.hw_menu_unlockscreen=false persist.sys.use_dithering=0 persist.sys.purgeable_assets=1 dalvik.vm.dexopt-flags=m=y ro.mot.eri.losalert.delay=1000

系统优化

一键调整很方便其中cwm固件备份使用 cwm也就是常说的 工程模式

cwm是手机内置恢复模式，也称刷机模式，主要是固件升级，备份/还原系统，格式化手机系统用的。

odex要说一下 ODEX是安卓上的应用程序apk中提取出来的可运行文件，即将APK中的classes.dex文件通过dex优化过程将其优化生成一个·dex文件单独存放，原APK中的classes.dex文件会保留。

odex化rom这样做可以加快软件的启动速度，预先提取，减少对RAM的占用，因为没有odex的话，系统要从apk包中提取dex再运行。

所谓Odex，是由android软件中的classes.dex生成的，Odex化即是把那个文件预先提取出来作用是能加快软件加载速度和开机速度。不过Odex也有缺点，那就是有时候加刷东西会出现问题。

简单说，原本系统恢复出厂设置后第一次开机需要先提取classes.dex出来，而Odex化就是现在你提前把它提取出来了。系统启动或者程序运行加快的原因也就在此。并且将dex变为odex还可以节省空间，因为提取后可以把apk内的dex删除。如果不odex，那么系统还是会自动提取dex,这时不仅apk内有dex,/data/dalvik-cache目录下也有dex,虽然apk内的dex经过压缩了，但是两份dex的总体积已经大于一份odex的体积了。

Odex化后系统启动和程序运行速度大大提高，稳定性不变。因此推荐做Odex化。

一般来说官方rom都是odex化的rom（含Odex文件），而定制rom大部分都是deodex化的（无odex文件）。两者应该各有优点吧，貌似现在也没有统一的说法。官方rom大部分每个apk对应一个.odex文件，而deodex化的rom里面只有一个apk，把.odex转换成classes.dex放到apk包里面了。所以 odex rom的.apk+.odex=deodex化rom的1个.apk (简单地来说，其实就上一个合并的过程) 优点

1.刷完机首次进入系统的时间会缩短一些。文件的运行速度应该也有所提升。

2.APK文件不能单独安装，并且如果反编译APK文件，一般也只能得到资源文件。可以说是起到一定的保护作用，避免被肆意修改和使用。这样做可以使其厂商保证一定的反盗版，因为没有dex文件的apk是无法正常安装的。

3.会增加一些可安装应用的空间，虽然不是很多。

4.某些机身内存太小的手机优化的时候可以删除dex文件来达到制作大内存包的目的，但是这种大内存包会使手机软件启动速度变慢。适合不追求速度，需要更多内存装软件的用户。 缺点

1.不方便修改ROM以及文件本身。

2.增加ROM包的体积，虽然不是很多。

3.当你升级某个被Odex的应用后，这个应用将会出现故障，最常见的就是FC（在android系统里，运行程序的时候弹出一个对话框，强制关闭）。（odex化会占用更多空间和导致一些app不能运行）

CPU调整器模式

【ondemand】

按需调节cpu频率,不操作手机的时候控制在最低频率,滑屏或进入应用后会迅速提升至最高频率,当空闲时迅速降低频率,性能较稳定,但因频率变化幅度过大,省电方面只有一般的水平。是一种在电池和性能之间趋向平衡的默认模式,但是对于智能手机来说,ondemand在性能表现方面略有欠缺。 【interactive】

和ondemand相似,规则是“快升慢降”,注重响应速度、性能,当有高需求时迅速跳到高频率,当低需求时逐渐降低频率,相比ondemand费电 【conservative】

和ondemand相似,规则是“慢升快降”,注重省电,当有高需求时逐渐提高频率,当低需求迅速跳至低频率。 【OndemandX】

在Ondemand基础上改进而来。关屏时手机进入睡眠状态时,锁定最高频率频率为500Mhz 【Scary】

基于Ondemand修改,CPU提升速度比ondemand慢,同时具有smartass的特点 【interactiveX】

在interactive基础上改进而来。关屏时手机进入睡眠状态时,锁定频率为最低值,同时在手机唤醒时能有更好的提升表现。比interactive更注重保护电池。 【Wheatley】

规则和Ondemand一样,但是响应速度稍慢,比Ondemand省电 【hotplug】

和ondemand模式差不多,当有高需求时直接跳到最高频率,当需求见效时逐级降低频率,但关屏时就单核低频运行,省电。 【lionheart】

基于conservative模式,但性能有所提高,增快了CPU的调整速度 【lulzactive】

在interactive基础,根据负载逐级升高或降低频率,每一级频率有一个限制值,负载高于限制值就提高一级频率,低于限制值就降低一级频率。所以这个调速器在各个频率上的停留时间都很短。这个调速器的特点是在各个频率之间频繁变动,但是运行于最高和最低频的时间最多。 【smartass】

是interactive和conservative的升级,根据资源使用智能提供一个适中的频率,空闲时自动降频,锁屏时自动固定频率。特色是锁屏后非常省电。缺点是部分机型锁屏一段时间后容易睡死。 【smartassV2】

smartass的升级版,平衡效能和耗电,升频快,降频慢,同时间亦会于锁屏时将频率降到最低,集成了休眠策略,不单单是指关了屏幕和开着屏幕的区别。 【smoothass】

在smartass基础上改进得来的,性能更高,调节速度更快,耗电少。

【SavagedZen】

在smartass的基础优化而来,同时注重电池和性能,使CPU达到一个更好的整体平衡。 【BrazilianWax】

基本就和smoothass一样 【Minmax】

基于conservative的优化版,类似smartassV2,速度性能最好,比smartassV2略微耗掉。 【intellidemand】

可根据GPU使用情况来针对性调节cpu频率,当GPU于重度使用时 ,所有动作都依照ondemand 不变。当3GP于闲置时,会自动限制cpu最高频率,将CPU最高频率锁死于1.0Ghz以减少耗电。关屏时亦会视乎 GPU 情况而作出调整。 【Pegasusq】

源自三星猎户座处理器的一个调速器,可以单独调控单个CPU内核,理论上性能不错也很省电。 【badass】

一个新型的CPU调速器,只能用于多核CPU,可分开控制单个CPU内核,来分工完成不同的工作,并且跟着工作量的不同,分别调整单个CPU内核的频率,从而提高性能,节省资源。这个模式现在好像只能用在特定修改的。 【performance】

高性能模式,按你设定范围的最高频率运行,即使系统负载非常低cpu的频率也为最高。性能很好,因为CPU本身不需要资源去调整频率,但是电量消耗较快,温度也高一些。 【powersave】

按设定最低频率运行,日常没有使用价值,除非配合setcpu情景模式,关屏睡眠时使用此调节模式,省电但系统响应速度慢。 【userspace】

任何情况下都会控制CPU运行在配置的频率范围内,配置中的用户自己添加的设置。在此情景模式下,降低CPU最大运行频率可以延长电池待机时间,但同时也会降低机器的唤醒速度,建议最好不使用该选项。 【lagfree】

很少用的调速器,不紧不慢型,无论负载变化快慢与否,CPU都按一定的停顿时间逐级升高或降低频率。 【lazy】

与 ondemand 相似,对于频率上升和下降的响应都很迟缓,可以忽略掉部分迅速变化的频率变化,优点是省电。

（注意的是高通cpu和联发科cpu在此页面的配置有所不同因为高通cpu是来源的而联发科的cpu是闭源的所以不同）

高通开源能调节的非常多包括GPU调度模式，和cpu温度与频率api接口，不过这里要说的是这个api不一定能让cpu在高温下不降频因为有可能cpu有芯片级的温度策略

I/O调整

TCP拥塞

先说下一TCP机制

拥塞的发生与不可避免

拥塞发生的主要原因在于网络能够提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间节点的处理能力。由于互联网的设计机制导致其缺乏“接纳控制”能力，因此在网络资源不足时不能限制用户数量，而只能靠降低服务质量来继续为用户服务，也就是“尽力而为”的服务。

但是，是不是说只要增加网络资源，就能避免拥塞呢？答案却是否定的！拥塞虽然是由于网络资源的稀缺引起的，但单纯增加资源并不能避免拥塞的发生。例如增加缓存空间到一定程度时，只会加重拥塞，而不是减轻拥塞，这是因为当数据包经过长时间排队完成转发时，它们很可能早已超时，从而引起源端超时重发，而这些数据包还会继续传输到下一路由器，从而浪费网络资源，加重网络拥塞。事实上，缓存空间不足导致的丢包更多的是拥塞的“症状”而非原因。另外，增加链路带宽及提高处理能力也不能解决拥塞问题。

例如：我们有四台主机ABCD连接路由器R，所有链路带宽都是1Gbps，如果A和B同时向C以1Gbps的速率发送数据，则路由器R的输入速率为2Gbps，而输出速率只能为1Gbps，从而产生拥塞。避免拥塞的方法只能是控制AB的速率，例如，都是0.5Gbps，但是，这只是一种情况，倘若D也向R发送数据，且速率为1Gbps，那么，我们先前的修正又是不成立的，可见，拥塞其实是一个动态问题，我们没有办法用一个静态方案去解决，从这个意义上来说，拥塞是不可避免的。

二.流量控制

早期的TCP协议只有基于窗口的流控制（flow control）机制，我们简单介绍一下，并分析其不足。 在TCP中，为了实现可靠性，发送方发出一个数据段之后要等待接受方相应的确认信息，而不是直接发送下一个分组。具体的技术是采用滑动窗口，以便通信双方能够充分利用带宽。滑动窗口允许发送方在收到接收方的确认之前发送多个数据段。窗口大小决定了在收到目的地确认之前，一次可以传送的数据段的最大数目。窗口大小越大，主机一次可以传输的数据段就越多。当主机传输窗口大小数目的数据段后，就必须等收到确认，才可以再传下面的数据段。例如，若视窗的大小为 1，则传完数据段后，都必须经过确认，才可以再传下一个数据段；当窗口大小等于3时，发送方可以一次传输3个数据段，等待对方确认后，再传输下面三个数据段。

窗口的大小在通信双方连接期间是可变的，通信双方可以通过协商动态地修改窗口大小。在TCP的每个确认中，除了指出希望收到的下一个数据段的序列号之外，还包括一个窗口通告，通告中指出了接收方还能再收多少数据段（我们可以把通告看成接收缓冲区大小）。如果通告值增大，窗口大小也相应增大；通告值减小，窗口大小也相应减小。但是我们可以发现，接收端并没有特别合适的方法来判断当前网络是否拥塞，因为它只是被动得接收，不像发送端，当发出一个数据段后，会等待对方得确认信息，如果超时，就可以认为网络已经拥塞了。所以，改变窗口大小的唯一根据，就是接收端缓冲区的大小了。 流量控制作为接受方管理发送方发送数据的方式，用来防止接受方可用的数据缓存空间的溢出。流控制是一种局部控制机制，其参与者仅仅是发送方和接收方，它只考虑了接收端的接收能力，而没有考虑到网络的传输能力；而拥塞控制则注重于整体，其考虑的是整个网络的传输能力，是一种全局控制机制。正因为流控制的这种局限性，从而导致了拥塞崩溃现象的发生。

三.重传

1、一旦收到确认，发送方关闭重发定时器并且将数据片的备份从重发队列中删除。发送方如果在规定的时间内没有收到数据确认，就重传该数据。

2、当TCP超时并重传时，它不一定要重传同样的报文段，相反，TCP允许进行重新分组而发送一个较大的报文段，这将有助于提高性能(当然，这个较大的报文段不能够超过接收方声明的MSS)。在协议中这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。 3、重发定时器

(1) 每一次一个包含数据的包被发送（包括重发），如果该定时器没有运行则启动它，使得它在RTO秒之后超时（按照当前的RTO值）。 (2) 当所有的发出数据都被确认之后，关闭该重发定时器。

(3) 当接收到一个ACK确认一个新的数据，重新启动该重发定时器，使得它在RTO秒之后超时（按照当前的RTO值）

四.TCP拥塞控制机制

TCP的拥塞控制由4个核心算法组成：“慢启动”（Slow Start）、“拥塞避免”（Congestion voidance）、“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）。

这里我会把自己的理解尽可能详细的列出来。为了方便起见，把发送端叫做client，接收端为server，每个segment长度为512字节，阻塞窗口长度为cwnd（简化起见，下面以segment为单位），sequence number为seq_num，acknowledges number为ack_num。通常情况下，TCP每接收到两个segment，发送一个ack。

慢启动

早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端一开始并不知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生，这里有一个“学习”的过程。 假设client要发送5120字节到server 慢启动过程如下：

1.初始状态，cwnd=1,seq_num=1；client发送第一个segment; 2.server接收到512字节（一个segment），回应ack_num=513;

3.client接收ack(513)，cwnd＝1+1=2;现在可以一次发送2个数据段而不必等待ack

4.server接收到2个segment，回应ack_num=513+512*2=1537 5.client接收ack(1537)，cwnd=2+1;一次发送3个数据段 6.server接收到3个segment，回应2个ack，分别为ack_num=1537+1024=2561和ack_num=2561+512=3073

7.client接收ack(2561)和ack(3073),cwnd=3+2=5；一次可以发送5个数据段，但是只用4个就满足要求了

8.server接收到4个segment，回应2个ack，分别为4097,5121 9.已经发送5120字节，任务完成！

总结一下：

当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量。

拥塞避免 可以想象，如果按上述慢启动的逻辑继续下去而不加任何控制的话，必然会发生拥塞，引入一个慢启动阈值ssthresh的概念，当cwnd

3.client接收到ack(102048),cwnd = 65459 + [(512 * 512) /65459] = 65459 + 4 = 65463，也就是说，每接到一个ack，cwnd只增加4个字节。

4.client发送一个segment，并开启ack timer,等待server对这个segment的ack，如果超时，则认为网络已经处于拥塞状态，则重设慢启动阀值ssthresh=当前cwnd/2＝65463/2=32731，并且，立刻把cwnd设为1，很极端的处理！ 5.此时，cwnd

总结一下：

如果当前cwnd达到慢启动阀值，则试探性的发送一个segment，如果server超时未响应，TCP认为网络能力下降，必须降低慢启动阀值，同时，为了避免形势恶化，干脆采取极端措施，把发送窗口降为1，个人感觉应该有更好的方法。

快速重传和快速恢复

前面讲过标准的重传，client会等待RTO时间再重传，但有时候，不必等这么久也可以判断需要重传，例如：client一次发送8个segment，seq_num起始值为100000，但是由于网络原因，100512丢失，其他的正常，则server会响应4个ack(100512)(为什么呢，tcp会把接收到的其他segment缓存起来，ack_num必须是连续的)，这时候，client接收到四个重复的ack，它完全有理由判断100512丢失，进而重传，而不必傻等RTO时间了。这就是快速重传。

那么，什么是快速恢复呢？我们通常认为client接收到3个重复的ack后，就会开始快速重传，但是，如果还有更多的重复ack呢，如何处理？这就是快速恢复要做的，事实上，我们可以把快速恢复看作是快速重传的后续处理，它不是一种单独存在的形态。

以下是具体的流程：

假设此时cwnd=70000,client发送4096字节到server,也就是8个segment，起始seq_num = _100000：

1.client发送seq_num = _100000

2.seq_num =100512的segment丢失 3.client发送seq_num = _101024

4.server接收到两个segment，它意识到100512丢失，先把收到的这两个segment缓存起来

5.server回应一个ack(100512),表示它还期待这个segment 6.client发送seq_num = _101536 7.server接收到一个segment，它判断不是100512，依旧把收到的这个segment缓存起来，并回应ack(100512)。

8.以下同6、7,直到client收到3个ack(100512)，进入快速重发阶段 9.重设慢启动阀值ssthresh=当前cwnd/2＝70000/2=35000 10.client发送seq_num = 100512以下，进入快速恢复阶段

11.重设cwnd = ssthresh + 3 segments =35000 + 3*512 = 36536，之所以要加3，是因为我们已经接收到3个ack(100512)了，根据前面说的，每接收到一个ack，cwnd加1

12.client接收到第四个、第五个ack(100512)，cwnd=36536+2*512=37560 13.server接收到100512,响应ack_num = _104096 14.此时，cwnd>ssthresh，进入拥塞避免阶段。

【思考】

为什么通常clieng每接收到一个ack，会把cwnd增加一个segment呢？ 这是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。

【联想】

想想看，能不能把TCP解决拥塞的方法应用到交通拥塞呢？ 我们有两个原则：

一是拥塞不可避免，单纯增加资源并不能避免拥塞的发生，只能用动态的方法加以解决； 二是数据包守恒原则。政府花费很大资金修路，并不能避免堵车，只能从源头控制，例如首先限制车辆进入主路，根据实际情况，再慢慢增加每一个路口的车流量，但是，当达到一个阀值，增加速度要放缓，并不时探测整个主路的拥堵情况，如果情况危急，立刻封闭半个路口，并将车流量降到最低，也就是重新回复到慢启动状态。

这里给了两个TCP拥塞算法预设cubicle和reno由于TCP拥塞算法专业性太强我也无法全部理解所以就不说了

4.SD卡读取缓存能够增加一些速度

i/o调度程序

工作原理

如果简单地以内核产生请求的次序直接将请求发向块设备的话，性能肯定让人难以接受。磁盘寻址是整个计算机中最慢的操作之一，每一次寻址---定位硬盘磁头到特定块上的某个位置---需要花费不少时间。（手机对应的就是emmc了）所以尽量缩短寻址时间无疑是提高系统性能的关键。 为了优化寻址操作，内核既不会简单的按请求接收次序，也不会立即将其提交给磁盘。相反，它会在提交前，先执行名为合并和排序的预操作，这中预操作可以极大地提高系统的整体性能。在内核中负责提交I/O请求的子系统被称为I/O调度程序。

I/O调度程序将磁盘I/O资源分配给系统中所有挂起的块I/O请求。具体的说，这种资源分配是通过将请求队列中挂起的请求合并和排序来完成的。注意不要将I/O调度程序和进程调度程序混淆。进程调度程序的作用是将处理器资源分配给系统中的运行进程。这两种系统有相似性，但并不相同。进程调度程序和I/O调度程序都是将一个资源虚拟给多个对象，对进程调度程序来说，处理器被虚拟并被系统中的运行进程共享。这种虚拟提供给用户的就是多任务和分时操作系统，像unix系统。相反，I/O调度程序虚拟块设备给多个磁盘请求，以便降低磁盘寻址时间，确保磁盘性能的最优化。

I/O调度程序的工作是管理块设备的请求队列。它决定队列中的请求排序顺序以及在什么时刻派发请求到块设备。这样做有利于减少磁盘寻址时间，从而提高全局吞吐量。注意全局这个定语很重要，坦率的将，一个I/O调度器可能为了提高系统整体性能，而对某些请求不公。

合并：

考虑一下这种情况，文件系统提交请求到请求队列---从文件中读取一个数据区，如果这时队列中已经存在一个请求，它访问的磁盘扇区和当前请求访问的磁盘扇区相邻，那么这两个请求就可以合并为一个对单个和多个相邻磁盘扇区操作的新请求。通过合并请求，I/O调度程序将多次请求的开销压缩成一次请求的开销。更重要的是，请求合并后只需要传递给磁盘一条寻址命令，就可以访问到请求合并前必须多次寻址才能访问完的磁盘区域了，因此合并请求显然能减少系统开销和磁盘寻址次数。 现在，假设在读请求被提交给请求队列的时候，队列中并没有其他请求需要操作相邻的扇区，此时就无法将当前请求与其他请求合并，当然，可以将其插入请求队列的尾部。但是如果有其他请求需要操作磁盘上类似的位置呢？如果存在一个请求，它要操作的磁盘扇区位置与当前请求的比较接近，那么是不是该让这两个请求在请求队列上也相邻呢？事实上，I/O调度程序的确是这样处理上述情况的，整个请求队列将按扇区增长方向有序排列。使所有请求按硬盘上扇区的排序有序排列的目的不仅是为了缩短单独一次请求的寻址时间，更重要的优化在于，通过保持磁盘头以直线方向移动，缩短了所有请求的磁盘寻址时间。该排序算法类似于电梯调度---电梯不能随意的从一层跳到另一层，它应该向一个方向移动，当抵达了同一方向的最后一层后，再掉头向另一个方向移动。出于这种相似性，所以I/O调度程序被称作电梯调度。

一) I/O调度程序的总结

1) 当向设备写入数据块或是从设备读出数据块时,请求都被安置在一个队列中等待完成.

2) 每个块设备都有它自己的队列. 3) I/O调度程序负责维护这些队列的顺序,以更有效地利用介质.I/O调度程序将无序的I/O操作变为有序的I/O操作.

4) 内核必须首先确定队列中一共有多少个请求,然后才开始进行调度.

二) I/O调度的4种算法

CFQ (Completely Fair Queuing 完全公平的排队)(elevator=cfq)：

这是默认算法，对于通用服务器来说通常是最好的选择。它试图均匀地分布对I/O带宽的访问。在多媒体应用, 总能保证audio、video及时从磁盘读取数据。但对于其他各类应用表现也很好。每个进程一个queue，每个queue按照上述规则进行merge 和sort。进程之间round robin调度，每次执行一个进程的4个请求。

Deadline (elevator=deadline)：

这个算法试图把每次请求的延迟降至最低。该算法重排了请求的顺序来提高性能。

NOOP (elevator=noop):

这个算法实现了一个简单FIFO队列。他假定I/O请求由驱动程序或者设备做了优化或者重排了顺序(就像一个智能控制器完成的工作那样)。在有 些SAN环境下，这个选择可能是最好选择。适用于随机存取设备, no seek cost，非机械可随机寻址的磁盘。

Anticipatory (elevator=as): 这个算法推迟I/O请求，希望能对它们进行排序，获得最高的效率。同deadline不同之处在于每次处理完读请求之后, 不是立即返回, 而是等待几个微妙在这段时间内, 任何来自临近区域的请求都被立即执行. 超时以后, 继续原来的处理.基于下面的假设: 几个微妙内, 程序有很大机会提交另一次请求.调度器跟踪每个进程的io读写统计信息, 以获得最佳预期.

I/O 调度算法再各个进程竞争磁盘I/O的时候担当了裁判的角色。他要求请求的次序和时机做最优化的处理，以求得尽可能最好的整体I/O性能。

对IO调度使用的建议：

Deadline I/O scheduler 使用轮询的调度器,简洁小巧,提供了最小的读取延迟和尚佳的吞吐量,特别适合于读取较多的环境(比如数据库,Oracle 10G 之类).

Anticipatory I/O scheduler 假设一个块设备只有一个物理查找磁头(例如一个单独的SATA硬盘),将多个随机的小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.适用于 大多数环境,特别是写入较多的环境(比如文件服

务器)Web,App等应用我们可以采纳as调度.

CFQ I/O scheduler使用QoS策略为所有任务分配等量的带宽,避免进程被饿死并实现了较低的延迟,可以认为是上述两种调度器的折中.适用于有大量进程的多用户系统

本文来源：https://www.bwwdw.com/article/ys8o.html