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内部存储，联系人内部存储等。这部分服务虽然属于次要服务，但很一些系统功能依然息息相关，我们时常需要用到它们，所以也太希望他们被终止 ；