Android上的内存分配策略优化

在Android上,其实自身有一套完善的内存管理机制。但由于我们深受Windows和塞班的毒害,每当看到手机剩余内存只有30m时,就觉得非常不爽,总是希望通过一些工具清理一下内存,而当Toast显示已经为你清理500m内存时,就会产生无比的快感。比如管家的小火箭发射,就是利用了这种用户心理。

所以,那些内存清理工具在windows上是很有必要的,但在Android上,实属多此一举。至于进程的优先级以及memorykiller的管理机制,系统是通过oom_adj来进行管理,这个可以通过之前小管的一个邮件了解得更详细。

在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)   只关注来电,短信,邮件等商务——商务模式;

4)   等等。

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

下面是关于这六类进程的作用简单介绍, 从网上找到的:

  1. 前台进程(foreground):目前正在屏幕上显示的进程和一些系统进程。举例来说,Dialer Storage,Google Search等系统进程就是前台进程;再举例来说,当你运行一个程序,如浏览器,当浏览器界面在前台显示时,浏览器属于前台进程(foreground),但一旦你按home回到主界面,浏览器就变成了后台程序(background)。我们最不希望终止的进程就是前台进程。
  1. 可见进程(visible):可见进程是一些不再前台,但用户依然可见的进程,举个例来说:widget、输入法等,都属于visible。这部分进程虽然不在前台,但与我们的使用也密切相关,我们也不希望它们被终止(你肯定不希望时钟、天气,新闻等widget被终止,那它们将无法同步,你也不希望输入法被终止,否则你每次输入时都需要重新启动输入法)
  1. 次要服务(secondary server):目前正在运行的一些服务(主要服务,如拨号等,是不可能被进程管理终止的,故这里只谈次要服务),举例来说:谷歌企业套件,Gmail内部存储,联系人内部存储等。这部分服务虽然属于次要服务,但很一些系统功能依然息息相关,我们时常需要用到它们,所以也太希望他们被终止
  1. 后台进程(hidden):虽然作者用了hidden这个词,但实际即是后台进程(background),就是我们通常意义上理解的启动后被切换到后台的进程,如浏览器,阅读器等。当程序显示在屏幕上时,他所运行的进程即为前台进程(foreground),一旦我们按home返回主界面(注意是按home,不是按back),程序就驻留在后台,成为后台进程(background)。后台进程的管理策略有多种:有较为积极的方式,一旦程序到达后台立即终止,这种方式会提高程序的运行速度,但无法加速程序的再次启动;也有较消极的方式,尽可能多的保留后台程序,虽然可能会影响到单个程序的运行速度,但在再次启动已启动的程序时,速度会有所提升。这里就需要用户根据自己的使用习惯找到一个平衡点
  1. 内容供应节点(content provider):没有程序实体,进提供内容供别的程序去用的,比如日历供应节点,邮件供应节点等。在终止进程时,这类程序应该有较高的优先权
  1. 空进程(empty):没有任何东西在内运行的进程,有些程序,比如BTE,在程序退出后,依然会在进程中驻留一个空进程,这个进程里没有任何数据在运行,作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。这部分进程无疑是应该最先终止的。

当手机剩余内存比较时,手机就变得比较慢的,原因是因为emtpy 的进程的阀值设置得太低了,导致系统在剩余内存很低的情况下,才开始清理进程。当剩余内存比较低,但还没有达到清理内存的条件时,系统整体就会比较卡。

因此,我们的策略,主要是解决两方面的问题:

1.  提升阀值的上限,空出更多的剩余空间,以提升系统整体的运行速度;

2.  各个进程的阀值要拉开,要形成梯度,使得进程管理机制更有效工作;

时间: 2024-07-31 09:23:14

Android上的内存分配策略优化的相关文章

垃圾收集器与内存分配策略(四)之垃圾收集器

垃圾收集器与内存分配策略(四)--垃圾收集器 收集算法是内存回收的方法论,垃圾收集器则是内存回收的具体实现. 垃圾收集器介绍 在垃圾收集器的层面上对并行与并发的解释: 并行(Parallel):指多条垃圾收集线程并行工作,但此时用户现场仍处于等待状态. 并发(Concurrent):指用户线程与垃圾收集线程同时执行(但并不一定是并行的,可能会交替执行),用户程序仍在继续执行,而垃圾收集程序运行于另一个CPU上. 对于不同的厂商,不同的版本的虚拟机都可能有很大的差别.此处讨论的是jdk1.7之后的

jvm笔记2--垃圾收集器与内存分配策略

垃圾收集器与内存分配策略 Java运行时,内存的各个部分中,程序计数器,虚拟机栈,本地方法栈3个区域随线程而生,随线程而灭:栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈的操作.每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的.因此这几个区域不需要过多考虑回收的问题,因为线程结束时,内存自然就跟着回收了. Java堆和方法区不一样,一个接口中的多个实现类需要的内存可能不一样,一个方法中的多个分支需要的内存也可能不一样,只有在程序运行期间才知道会创建哪些对象,这部分内存的分配

垃圾收集器与内存分配策略

①对于java虚拟机来说,垃圾收集器主要关注的内存区域是 堆和方法区. ②垃圾收集器就是要收集那些已经“死了”的对象.如果判断一个对象是否存活? 对象引用计数法 对象引用增加一个,那么相应的计数器加1,否则,减1. 优点:实现简单 缺点:不能处理对象间的循环引用.a引用b,b同时引用a. 可达性分析 如果节点到root节点可达,则证明是存活的:否则,已死.所以对于下图的o5,o6,o7虽然他们是循环引用的,但是到root节点无可达,所以已死可清除. ③垃圾回收器对于不同类型引用的回收规则 强引用

【转载】Ogre的内存分配策略

原文:Ogre的内存分配策略 读这个之前,强烈建议看一下Alexandrescu的modern c++的第一章关于policy技术的解释.应该是这哥们发明的,这里只是使用. 首先列出涉及到的头文件:(这几个头文件彼此之间相关性挺大的,应该一起看) 只在调试期使用: OgreMemoryTracker.h 这个头文件中定义了MemoryTracker这个类,用来测试和调试Ogre的内存分配系统的.能跟踪内存的分配.回收.泄漏和统计信息.Ogre使用者不需要关注. OgreAlignedAlloca

JVM总结(二):JVM的内存分配策略

这节我们总结一下JVM中的内存分配策略.目录如下: 内存分配策略 对象优先在新生代Eden分配 大对象直接进入老年代 长期存活的对象将进入老年代 动态对象年龄判定 空间分配担保 内存分配策略 Java技术体系中所提倡的自动内存管理可以归结于两个部分:给对象分配内存以及回收分配给对象的内存. 我们都知道,Java对象分配,都是在Java堆上进行分配的,虽然存在JIT编译后被拆分为标量类型并简介地在栈上进行分配.如果采用分代算法,那么新生的对象是分配在新生代的Eden区上的.如果启动了本地线程分配缓

Memcache 内存分配策略和性能(使用)状态检查

前言: 一直在使用Memcache,但是对其内部的问题,如它内存是怎么样被使用的,使用一段时间后想看看一些状态怎么样?一直都不清楚,查了又忘记,现在整理出该篇文章,方便自己查阅.本文不涉及安装.操作.有兴趣的同学可以查看之前写的文章和Google. 1:参数 memcached -h memcached 1.4.14 -p <num> TCP端口,默认为11211,可以不设置 -U <num> UDP端口,默认为11211,0为关闭 -s <file> UNIX soc

Java虚拟机垃圾收集器与内存分配策略

Java虚拟机垃圾收集器与内存分配策略 概述 那些内存需要回收,什么时候回收,如何回收是GC需要完成的3件事情. 程序计数器,虚拟机栈与本地方法栈这三个区域都是线程私有的,内存的分配与回收都具有确定性,内存随着方法结束或者线程结束就回收了. java堆与方法区在运行期才知道创建那些对象,这部分内存分配是动态的,本章笔记中分配与回收的内存指的就是:java堆与方法区. 判断对象已经死了 引用计数算法:给对象添加一个引用计数器,每当有一个地方引用它,计数器+1;引用失败,计数器-1.计数器为0则改判

第三章 垃圾收集器与内存分配策略

书中笔记: 也许并不会死: 要宣告回收一个对象死亡,至少要经历两次标记过程: 当可达性分析发现一个对象不可达的时候,将标记第一次并进行筛选,筛选的条件是此对象是否有必要执行finalize()方法,当对象没有覆盖finalize或者已被调用过,则虚拟机认为此对象没必要执行finalize,  如果判断有必要执行,则此对象将会被放入一个F-Queue队列中,之后会被一个优先级比较低的Finalizer线程去调用,但是并不会等待他执行完毕,因为此对象的finalize并不可靠,可能会死循环之类的,如

第三章 垃圾收集器和内存分配策略

第三章 垃圾收集器和内存分配策略 对象已死吗 引用计算方法 可达性分析算法 通过一些列的GC roots 对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径成为引用链,当一个对象到GC roots 没有任何引用链的则证明对象不可用的 虚拟机栈中的引用的对象 方法区中类静态属性引用的对象 方法去区中常量引用的对象 本地方法栈中JNI引用的对象 生存还是死亡 一次筛选,筛选是否有必要执行 finalize()方法 没有覆盖或者finalize()已经被调用过  视为没必要执行 放入一个F-Qu