Android避免OOM（内存优化） - 简书
Android避免OOM（内存优化）
Android内存优化是性能优化很重要的一部分，而如何避免OOM又是内存优化的核心。
Android内存管理机制
android官网有一篇文章
Android系统的Dalvik虚拟机扮演了内存垃圾自动回收的角色。
OOM介绍（out of memory 内存溢出）
Android和java中都会出现由于不良代码引起的内存泄露，为了使Android应用程序能够快速高效的运行，Android每个应用程序都会有专门Dalvik虚拟机实例来运行，也就是每个程序都在属于自己的进程中运行。这样，某个应用程序内存泄露仅仅只会使自己进程被kill掉不会影响其他进程（如果是system_process等系统进程出现问题，就会造成系统重启），另一方面，系统为每一个应用程序分配了不同的内存上限，如果超过这个上限被视为内存泄露，从而被kill掉。Dalvik Heap size因不同设备的RAM不同而有所差异，应用占用内存接近这个阀值，在尝试分配内存就会引起outofmemoryError的错误。
出现OOM有几种情况：
加载对象过大
相应资源过多，来不及加载。
解决这些问题，有：
内存引用上做一些处理，常用的有软引用。
内存中加载图片直接在内存中做处理（如边界压缩）这个Glide\Fresco 图片框架可能封装好了3.动态回收内存4.优化Delivk虚拟机的堆内存分配5.自定义堆内存大小共享内存
Android应用程序的进程都是从Zygote的进程fork出来的。Zygote进程在系统启动并载入通用的framework代码和资源后启动。一个新的应用程序启动，系统就会从Zygote中fork出来一个新的进程，在新的进程中加载并允许应用程序的代码。这使得大多数RAM pages被分配给framework的代码，并且RAM资源能够在应用的所有进程之间共享。
大多数static 数据被mmapped到一个进程中，这样使得同样的数据在进程之间能够共享，而且在需要的时候能paged out.常见static 数据包括Dalvik code ,app resourecs,so 文件等。
大多数情况下，Android通过显示的方式分配共享内存区域（例如ashmem或gralloc）来实现动态RAM区域能够在不同进程之间进行共享的机制。比如，Window Surface在APP和Screen Composition之间使用共享的内存，Cursor Buffers在Content Provider与Clients之间共享内存。
分配与回收内存
每个进程的Dalvik heap都反应了使用内存的占用范围,（Dalvik Heap Size）,他可以根据需要进行增长，但是系统有一个上限。
HeapSize跟实际的物理内存大小是不对等的，PSS（proportional Set Size）记录了应用程序自身占用以及和其他进程共享的内容。
Android不会对heap空闲区域进行做碎片整理。系统仅仅在新的内存分配之前判断Heap的尾端剩余空间是否足够，不够就会触发gc操作，从而腾出更多空闲的内存空间。gc操作(garbage collection)也就是所谓的垃圾回收，Android在适当时候触发gc操作，将一些不再使用的对象回收，在Android高级系统针对Heap空间有一个Generational Heap Memory的模型，最近分配的对象在放在young generation区域，当停留一段时间，这个对象会被移动到old generation中，最后在移动到permanent generation区域中。系统会根据内存中不同的内存数据类型进行gc操作，young generation区域的对象更容易被销毁，而且gc操作的速度比old generation的速度要快，时间更短。每个generation的内存区域都有固定的大小，随着新的对象陆续被分配到此区域，当这些对象的大小快达到阀门值时，就会触发gc操作。通常情况下，gc操作发生时，所有线程都是暂停的。如何查看本机heap size:ActivityManager manager=(Activity)getSystemService(Context.ACTIVITY_SERVICE);
int heapsize=manager.getMemoryClass();
应用切换操作
Android系统不会再用户切换应用的时候进行交换内存的操作，而是把不包含Foreground组件的应用进程放到LRUCache中，比如用户启动一个应用，系统会为它创建一个进程，但是当用户离开这个应用，此进程不会背立即销毁而是会放到一个Cache中，当用户切换回来够快速的恢复。
发生OOM的条件
通过不同的内存分配方式对不同的对象(bitmap,etc)进行操作因Android版本差异发生变化。4.0以上，废除了external的计数器，类似bitmap的分配改到dalvik的Java heap(堆)中申请，只要allocated+新分配的内存&=getMemoryClass()就会发生OOM。(在AS memory monitor查看内存中Dalvik Heap的实时变化)
如何避免OOM
减少OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。
使用更加轻量的数据结构考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，因为HashMap需要一个额外的实例对象来记录Mapping的操作。而SparesArray高效的避免了key和value的自动装箱，而且避免了装箱后的解箱。
关于更多ArrayMap/SparseArray的讨论，请参考的前三个段落
避免在Android中使用Enum
减少Bitmap对象的内存占用Bitmap是一个消耗内存的大胖子，减少创建出来的Bitmap的内存占用很重要。一般有两种措施
inSampleSize:缩放比例，在把图片载入内存之前，我们需要计算一个合适的缩放比例，避免不必要的大图载入。
decode format:解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
使用更小的图片在设计图片资源的时候，我们要考虑图片是否存在可以压缩的空间，是否能使用更小的图片，使用小图在xml加载资源时就不会在初始化视图因为内存不足而发生InflationException,其根本原因就是发生了OOM。
内存对象的重复利用
Android最常用的缓存算法LRU(Least Recently Use)
复用系统自带的资源，比如字符串、图片、动画、样式、颜色、简单布局，在应用中直接引用，减少自身负重、apk大小、减少内存的开销、复用性更好。但需要考虑版本差异。
Listview和GirdView出现大量重复子组件的视图里面对ConvertView的复用。
Bitmap对象的复用
在ListView和GridView等显示大量图片的控件里面需要使用LRU机制缓存Bitmap.
利用inBitmap的高级特性提高Android系统在Bitmap分配和释放执行效率，inBitmap属性可以告知Bitmap解码器使用已经存在的内存区域而不是重新申请一块内存区域存放Bitmap,也就是新解码的Bitmap会使用之前那张bitmap在heap占用的内存区域，即使是上千张图片，也只占用屏幕能放下图片的内存inBitmap的限制
SDK19以后：新申请的BItmap大小必须小于或等于前面赋值过的bitmap的大小
新的Bitmap和原来的解码格式要相同，我们可以创建包含多种类型可以重用的bitmap对象池，这样后序的bitmap创建就可以找到合适的模板去重用。
避免在onDraw方法里面执行对象的创建在onDraw这种频繁调用的方法要避免对象的创建操作，因为他会迅速增加内存的使用，引起频繁的gc，甚至内存抖动5.StringBuilder如果代码中有大量字符串拼接操作，使用StringBuilder代替"+"
避免对象的内存泄露
内存对象的泄露会导致不再使用的对象无法及时释放，不仅浪费了宝贵的内存空间，后续要分配内存的时候，空间不足造成OOM。这样，每级的generation会变小，gc更加容易触发，引起内存抖动，带来性能问题。
LeakCanary开源控件可以帮助我们发现内存泄露的问题。介绍：
中文文档 )
注意Activity的泄露Activity泄露是内存泄露最为严重的问题，涉及内存多，影响面广两种情形：
内部类引用导致Activity的泄露典型的是Handler导致的Activity泄露，如果Handler中有延迟的任务或者等待执行的任务队列过长，很可能因为Handler继续执行造成Activity的泄露。引用链是Looper-&MessageQueue-&Message-&handler-&Activity,解决办法是在退出UI之前执行 remove Handler消息队列中的消息与runnable对象。或者使用Static+WeakReference的方式来判断Handler和Activity之间存在引用关系。
Activity Context被传递到其他实例中，可能导致自身被引用而发生泄露
考虑使用Application Context而不是Activity Context除必须使用Activity Context的情况(Dialog的context必须是Activity),我们可以使用Application Context来避免Activity泄露
注意临时Bitmap的及时回收大多数情况下，我们对Bitmap对象增加缓存机制，但是有时候部分bitmap需要及时回收。比如我们临时创建的摸个相对大的bitmap对象，变换得到新的bitmap对象后，尽快回收原始的bitmap,及时释放原来的空间。
注意监听器的注销android程序里面register后要及时释放unregister那些监听器，自己手动add的listener，要记得remove这个listener.5.注意缓存容器的对象泄露有时候我们为了提高对象的复用性，把某些对象放到缓存容器中，如果这些对象没有及时从容器中清楚，也可能导致内存泄露，
注意webview的泄露Android不同版本对webview产生有很大差异，较为严重的问题是webview的泄露，解决办法：为webview新开一个线程，通过AIDL与主进程通信，根据业务的需要在合适的时机进行销毁，从而达到内存的释放。
注意cursor对象是否关闭我们在对数据库进行操作时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响
内存使用策略优化
1.谨慎使用large heapandroid设备由于软硬件的差异，heap阀值不同，特殊情况下可以在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。但是要谨慎使用，因为额外的空间会影响到系统整体的用户体验，并且会使每次gc的运行时间更长。切换任务时性能大打折扣，large heap并不一定能获取到更大的heap.
综合考虑设备内存阈值与其他因素设计合适的缓存大小例如，在设计ListView或者GridView的Bitmap LRU缓存的时候，需要考虑的点有：
应用程序剩下了多少可用的内存空间?
有多少图片会被一次呈现到屏幕上？有多少图片需要事先缓存好以便快速滑动时能够立即显示到屏幕？
设备的屏幕大小与密度是多少? 一个xhdpi的设备会比hdpi需要一个更大的Cache来hold住同样数量的图片。
不同的页面针对Bitmap的设计的尺寸与配置是什么，大概会花费多少内存？
页面图片被访问的频率？是否存在其中的一部分比其他的图片具有更高的访问频繁？如果是，也许你想要保存那些最常访问的到内存中，或者为不同组别的位图(按访问频率分组)设置多个LruCache容器。
onLowMemory() 与onTrimMemory()Android可以在不同的应用当中随意切换。为了让background转到foreground, 每一个background都会占用一定的内存。系统会根据内存的使用情况决定回收部分background的应用内存。background的应用从暂停状态恢复到foreground，比较快，如果从kill状态恢复比较慢。
资源文件需要选择合适的文件夹进行存放我们知道hdpi/xhdpi/xxhdpi等等不同dpi的文件夹下的图片在不同的设备上会经过scale的处理。例如我们只在hdpi的目录下放置了一张100100的图片，那么根据换算关系，xxhdpi的手机去引用那张图片就会被拉伸到200200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到assets或者nodpi的目录下。
Try catch某些大内存分配的操作在某些情况下，我们需要事先评估那些可能发生OOM的代码，对于这些可能发生OOM的代码，加入catch机制，可以考虑在catch里面尝试一次降级的内存分配操作。例如decode bitmap的时候，catch到OOM，可以尝试把采样比例再增加一倍之后，再次尝试decode。
谨慎使用static对象因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏，在Android中应该谨慎使用static对象。
特别留意单例对象中不合理的持有虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。
珍惜Services资源如果你的应用需要在后台使用service，除非它被触发并执行一个任务，否则其他时候Service都应该是停止状态。另外需要注意当这个service完成任务之后因为停止service失败而引起的内存泄漏。 当你启动一个Service，系统会倾向为了保留这个Service而一直保留Service所在的进程。这使得进程的运行代价很高，因为系统没有办法把Service所占用的RAM空间腾出来让给其他组件，另外Service还不能被Paged out。这减少了系统能够存放到LRU缓存当中的进程数量，它会影响应用之间的切换效率，甚至会导致系统内存使用不稳定，从而无法继续保持住所有目前正在运行的service。 建议使用，它会在处理完交代给它的任务之后尽快结束自己。更多信息，请阅读。
优化布局层次，减少内存消耗越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的。
谨慎使用“抽象”编程很多时候，开发者会使用抽象类作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的额外内存开销：他们需要同等量的代码用于可执行，那些代码会被mapping到内存中，因此如果你的抽象没有显著的提升效率，应该尽量避免他们。
使用nano protobufs序列化数据Protocol buffers是由Google为序列化结构数据而设计的，一种语言无关，平台无关，具有良好的扩展性。类似XML，却比XML更加轻量，快速，简单。如果你需要为你的数据实现序列化与协议化，建议使用nano protobufs。关于更多细节，请参考的”Nano version”章节。
谨慎使用依赖注入框架使用类似Guice或者RoboGuice等框架注入代码，在某种程度上可以简化你的代码。下面是使用RoboGuice前后的对比图：
13.谨慎使用多进程使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术。
一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。
使用ProGuard来剔除不需要的代码能够通过移除不需要的代码，重命名类，域与方法等等对代码进行压缩，优化与混淆。使用ProGuard可以使得你的代码更加紧凑，这样能够减少mapping代码所需要的内存空间。
谨慎使用第三方libraries很多开源的library代码都不是为移动网络环境而编写的，如果运用在移动设备上，并不一定适合。即使是针对Android而设计的library，也需要特别谨慎，特别是在你不知道引入的library具体做了什么事情的时候。例如，其中一个library使用的是nano protobufs, 而另外一个使用的是micro protobufs。这样一来，在你的应用里面就有2种protobuf的实现方式。这样类似的冲突还可能发生在输出日志，加载图片，缓存等等模块里面。另外不要为了1个或者2个功能而导入整个library，如果没有一个合适的库与你的需求相吻合，你应该考虑自己去实现，而不是导入一个大而全的解决方案。
考虑不同的实现方式来优化内存占用
写在最后：
设计风格很大程度上会影响到程序的内存与性能，相对来说，如果大量使用类似Material Design的风格，不仅安装包可以变小，还可以减少内存的占用，渲染性能与加载性能都会有一定的提升。
内存优化并不就是说程序占用的内存越少就越好，如果因为想要保持更低的内存占用，而频繁触发执行gc操作，在某种程度上反而会导致应用性能整体有所下降，这里需要综合考虑做一定的权衡。
Android的内存优化涉及的知识面还有很多：内存管理的细节，垃圾回收的工作原理，如何查找内存泄漏等等都可以展开讲很多。OOM是内存优化当中比较突出的一点，尽量减少OOM的概率对内存优化有着很大的意义。
详细看郭霖的总结胡凯大大
我转身，发现你们一直在身后，
这就是我为什么坚持的原因。
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金 Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金 相信有很多...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金相信有很多朋友...
本文转载来源 http://www.csdn.net/article// （一）Android的内存管理机制Google在Android的官网上有这样一篇文章，初步介绍了Android是如何管理应用的进程与内存分配：http://dev...
HereAndroid的内存优化是性能优化中很重要的一部分，而避免OOM又是内存优化中比较核心的一点。这是一篇关于内存优化中如何避免OOM的总结性概要文章，内容大多都是和OOM有关的实践总结概要。理解错误或是偏差的地方，还请多包涵指正，谢谢！（一）Android的内存管理机...
转载： 原文地址:http://www.csdn.net/article// 减小对象的内存占用 避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。 1）使用更加轻量的数据结构例如，我们可以考虑使用...
近日，网上传播一段武汉583路公交司机疑似与一名女性挤坐在驾驶座上搂抱的视频，引起不少网友担心。日，武汉公交公司的相关工作人员经过核实了解，回应称：事实并非如此，当时该女子身体不适要求下车，“挤坐一起”系拍摄角度引起的视觉错位。 记者联系上发布视频的赵先生...
我从懵懂走来，走向青春，走向你 带着欢快和愉悦，带着兴奋与好奇 我向大学走去，一圆幼时的愿望 我向你走去，一定多年的青春 那年花落之时，雪花飘洒 你踏着寒风，乘着雪花 就差骑着一匹白马 漂洋过海成为我的王子 你的温柔，体贴，善解人意，文化修养 打动着我，动摇着我 我从悬崖边...
基本的查询语句allorder_by使用一个或者多个标准条件来查询limit运用限制来查询offset运用偏移来查询first()first_or_404()
【今日话题】： 你报过多少种网络课程？学习情况如何？ 付费课程: 1.小灶群:每天坚持晨读和话题讨论，收获很多； 2.熊猫书院:十个月读书计划，今天第二天打卡学习中； 2.土人老师公考面试网络课程:教授公考面试的一些技巧，观点独特，深入浅出，已学完，让我如愿以偿； 3. ...(dumpstate) lowmemorykiller: Killing 'droid.seccenter' (15796),
&6&[] c3 15885
(dumpstate) to free 18284kB on behalf
of 'dumpstate' (15885) because
&6&[] c3 15885
(dumpstate) cache 45152kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 15885
(dumpstate) Free memory is 3300kB
above reserved
&6&[] c1 15885
(dumpstate) lowmemorykiller: Killing 'ndroid.contacts' (15821),
&6&[] c1 15885
(dumpstate) to free 17148kB on behalf
of 'dumpstate' (15885) because
&6&[] c1 15885
(dumpstate) cache 44704kB is below
limit 46376kB for oom_score_adj 529
&6&[] c1 15885
(dumpstate) Free memory is 3780kB
above reserved
&6&[] c0 387
(AudioOut_2)
[pxa-ssp]: Create playback dump file
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'oenix2.usbproxy' (15887),
&6&[] c3 14741
(dumpstate) to free 16196kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 46168kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 14741
(dumpstate) Free memory is 7184kB
above reserved
&6&[] c3 14741
(dumpstate)
lowmemorykiller: Killing 'doujia.phoenix2' (15900), adj 529,
&6&[] c3 14741
(dumpstate) to free 23192kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 46168kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 14741
(dumpstate) Free memory is 7160kB
above reserved
&6&[] c1 139
lowmemorykiller: Killing 'viders.contacts' (15949), adj 529,
&6&[] c1 139
(zygote) to free 23256kB on behalf of
'zygote' (139) because
&6&[] c1 139
(zygote) cache 46308kB is below limit
46376kB for oom_score_adj 529
&6&[] c1 139
(zygote) Free memory is 8692kB above
&6&[] c2 15988
(dumpstate) lowmemorykiller: Killing 'ReferenceQueueD' (15955),
&6&[] c2 15988
(dumpstate) to free 23272kB on behalf
of 'dumpstate' (15988) because
&6&[] c2 15988
(dumpstate) cache 46308kB is below
limit 46376kB for oom_score_adj 529
&6&[] c2 15988
(dumpstate) Free memory is 9648kB
above reserved
&6&[] c1 139
lowmemorykiller: Killing 'ContactsProvide' (15962), adj 529,
&6&[] c1 139
(zygote) to free 23312kB on behalf of
'zygote' (139) because
&6&[] c1 139
(zygote) cache 46308kB is below limit
46376kB for oom_score_adj 529
&6&[] c1 139
(zygote) Free memory is 9508kB above
&6&[] c0 11934
(kworker/u:3) binder: send failed reply for transaction 6900835
&3&[] c1 1 (init)
sys_prop: permission denied uid:10024&
name:yulong.mms.isDeleteCard
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'android.upgrade' (15866),
&6&[] c3 14741
(dumpstate) to free 16792kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 36616kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 11600kB
above reserved
&6&[] c0 139
lowmemorykiller: Killing 'android.upgrade' (15866), adj 470,
&6&[] c0 139
(zygote) to free 16792kB on behalf of
'zygote' (139) because
&6&[] c0 139
(zygote) cache 36616kB is below limit
36832kB for oom_score_adj 235
&6&[] c0 139
(zygote) Free memory is 11900kB above
&6&[] c0 139
lowmemorykiller: Killing 'd.process.media' (15989), adj 294,
&6&[] c0 139
(zygote) to free 19368kB on behalf of
'zygote' (139) because
&6&[] c0 139
(zygote) cache 36504kB is below limit
36832kB for oom_score_adj 235
&6&[] c0 139
(zygote) Free memory is 12048kB above
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'droid.gallery3d' (15975),
&6&[] c3 14741
(dumpstate) to free 18944kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 35944kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 12172kB
above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'IntentService[G' (16044),
&6&[] c3 14741
(dumpstate) to free 19076kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 35608kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 14348kB
above reserved
&3&[] c0 11934
(kworker/u:3) [BATTERY LOG]get_chg_status: the charging status
is in progress
&3&[] c0 11934
(kworker/u:3) [BATTERY LOG]charger_rst_work:the
charger_rst_work
&6&[] c2 15235
(droid.launcher3) lowmemorykiller: Killing 'droid.seccenter'
(16037), adj 764,
&6&[] c2 15235
(droid.launcher3) to free 18172kB on
behalf of 'droid.launcher3' (15235) because
&6&[] c2 15235
(droid.launcher3) cache 46288kB is
below limit 46376kB for oom_score_adj 529
&6&[] c2 15235
(droid.launcher3) Free memory is
-1460kB above reserved
&6&[] c2 15235
(droid.launcher3) lowmemorykiller: Killing 'Thread-18313'
(16053), adj 764,
&6&[] c2 15235
(droid.launcher3) to free 18364kB on
behalf of 'droid.launcher3' (15235) because
&6&[] c2 15235
(droid.launcher3) cache 46176kB is
below limit 46376kB for oom_score_adj 529
&6&[] c2 15235
(droid.launcher3) Free memory is
-1424kB above reserved
&6&[] c0 16092
(android.upgrade) lowmemorykiller: Killing 'Thread-18313'
(16053), adj 764,
&6&[] c0 16092
(android.upgrade) to free 18364kB on
behalf of 'android.upgrade' (16092) because
&6&[] c0 16092
(android.upgrade) cache 46064kB is
below limit 46376kB for oom_score_adj 529
&6&[] c0 16092
(android.upgrade) Free memory is
-1424kB above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'ndroid.contacts' (16055),
&6&[] c3 14741
(dumpstate) to free 17256kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 43936kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 14741
(dumpstate) Free memory is -280kB
above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'com.svox.pico' (16076),
&6&[] c3 14741
(dumpstate) to free 15700kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 43712kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 14741
(dumpstate) Free memory is 212kB above
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'FinalizerWatchd' (16085),
&6&[] c3 14741
(dumpstate) to free 15832kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 43600kB is below
limit 46376kB for oom_score_adj 529
&6&[] c3 14741
(dumpstate) Free memory is 2688kB
above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'eccenter.remote' (15809),
&6&[] c3 14741
(dumpstate) to free 17836kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 36768kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 10916kB
above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'android.upgrade' (16092),
&6&[] c3 14741
(dumpstate) to free 17252kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 36656kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 10952kB
above reserved
&6&[] c3 14741
(dumpstate) lowmemorykiller: Killing 'GC' (16096), adj 294,
&6&[] c3 14741
(dumpstate) to free 17588kB on behalf
of 'dumpstate' (14741) because
&6&[] c3 14741
(dumpstate) cache 36544kB is below
limit 36832kB for oom_score_adj 235
&6&[] c3 14741
(dumpstate) Free memory is 11592kB
above reserved
&6&[] c0 11934
(kworker/u:3) binder: release
transaction 6903009
in, still active
&6&[] c0 11934
(kworker/u:3) binder: send failed reply for transaction 6903009
&6&[] c0 11934
(kworker/u:3) binder: release
transaction 6902997
in, still active
&6&[] c0 11934
(kworker/u:3) binder: send failed reply for transaction 6902997
&7&[] c2 128
(servicemanager) android(06-04 01:43:34): service
'cloudsecurity' died
&3&[] c2 1 (init)
sys_prop: start service ctl [dumpstate] uid:1000 gid:1000
&6&[] c0 387
(AudioOut_2)
[pxa-ssp]: Create playback dump file
&6&[] c1 14741
(dumpstate) lowmemorykiller: Killing 'inputmethod.oem' (14583),
&6&[] c1 14741
(dumpstate)&span
style='mso-spacerun:yes'& to free 18912kB on
behalf of 'dumpstate'
(14741) because
&6&[] c1 14741
(dumpstate) cache 27248kB is below
limit 27276kB for oom_score_adj 117
&6&[] c1 14741
(dumpstate) Free memory is 25416kB
above reserved
&6&[] c1 14741
(dumpstate) lowmemorykiller: Killing 'WorkThreadHandl' (14632),
&6&[] c1 14741
(dumpstate) to free 19252kB on behalf
of 'dumpstate' (14741) because
&6&[] c1 14741
(dumpstate) cache 27248kB is below
limit 27276kB for oom_score_adj 117
&6&[] c1 14741
(dumpstate) Free memory is 25636kB
above reserved
&6&[] c1 14741
(dumpstate) lowmemorykiller: Killing 'oid.calculator2' (15783),
&6&[] c1 14741
(dumpstate)&span
style='mso-spacerun:yes'& to free 18096kB on
behalf of 'dumpstate'
(14741) because
&6&[] c1 14741
(dumpstate) cache 27248kB is below
limit 27276kB for oom_score_adj 117
&6&[] c1 14741
(dumpstate) Free memory is 25204kB
above reserved
&7&[] c3 15789
(ReferenceQueueD) Process 15783 released (GC Ver
rls_pxa988_JB43_GC10)
&6&[] c2 570
(er.ServerThread) binder: 558:570 transaction failed 29189, size
&4&[] c1 14741
(dumpstate) dumpstate: page allocation failure: order:4,
mode:0x40d0
&7&[] c1 14741
(dumpstate) [&c01140f4&]
(unwind_backtrace 0x0/0x11c) from
[&c01a6ba8&] (warn_alloc_failed
0xf4/0x11c)
&7&[] c1 14741
(dumpstate) [&c01a6ba8&]
(warn_alloc_failed 0xf4/0x11c) from
[&c01a9c84&]
(__alloc_pages_nodemask 0x704/0x824)
&7&[] c1 14741
(dumpstate) [&c01a9c84&]
(__alloc_pages_nodemask 0x704/0x824) from
[&c01a9dfc&] (__get_free_pages
0x10/0x24)
&7&[] c1 14741
(dumpstate) [&c01a9dfc&]
(__get_free_pages 0x10/0x24) from
[&c01d6860&] (kmalloc_order_trace
0x20/0xe0)
&7&[] c1 14741
(dumpstate) [&c01d6860&]
(kmalloc_order_trace 0x20/0xe0) from
[&c02006e4&] (seq_read
0x25c/0x468)
&7&[] c1 14741
(dumpstate) [&c02006e4&] (seq_read
0x25c/0x468) from [&c01e4db0&]
(vfs_read 0xa4/0x12c)
&7&[] c1 14741
(dumpstate) [&c01e4db0&] (vfs_read
0xa4/0x12c) from [&c01e4e6c&]
(sys_read 0x34/0x68)
&7&[] c1 14741
(dumpstate) [&c01e4e6c&] (sys_read
0x34/0x68) from [&c010e500&]
(ret_fast_syscall 0x0/0x30)
&7&[] c1 14741
(dumpstate) Mem-info:
&7&[] c1 14741
(dumpstate) Normal per-cpu:
&7&[] c1 14741
(dumpstate) CPU 0: hi:&span
style='mso-spacerun:yes'& 186,
&7&[] c1 14741
(dumpstate) CPU 1: hi:&span
style='mso-spacerun:yes'& 186,
&7&[] c1 14741
(dumpstate) CPU 2: hi:&span
style='mso-spacerun:yes'& 186,
&7&[] c1 14741
(dumpstate) CPU 3: hi:&span
style='mso-spacerun:yes'& 186,
&7&[] c1 14741
(dumpstate) active_anon:30952 inactive_anon:39101
isolated_anon:0
&7&[] c1 14741
(dumpstate) active_file:491
inactive_file:4297 isolated_file:0
&7&[] c1 14741
(dumpstate) unevictable:1835 dirty:0
writeback:23 unstable:0
&7&[] c1 14741
(dumpstate) free:10204
slab_reclaimable:1797 slab_unreclaimable:4111
&7&[] c1 14741
(dumpstate) mapped:1535 shmem:197
pagetables:2135 bounce:0
&7&[] c1 14741
(dumpstate) free_cma:1907
&7&[] c1 14741
(dumpstate) Normal free:40816kB min:2784kB low:3480kB
high:4176kB
active_anon:123808kB inactive_anon:156404kB
active_file:1964kB
inactive_file:17188kB unevictable:7340kB isolated(anon):0kB
isolated(file):0kB
present:485376kB mlocked:0kB dirty:0kB writeback:92kB
mapped:6140kB shmem:788kB
slab_reclaimable:7188kB slab_unreclaimable:16444kB
kernel_stack:5912kB
pagetables:8540kB unstable:0kB bounce:0kB free_cma:7628kB
writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
&7&[] c1 14741
(dumpstate) lowmem_reserve[]: 0 0 0
&7&[] c1 14741
(dumpstate) Normal: 4910*4kB 2047*8kB 33*16kB 7*32kB 3*64kB
2*128kB 1*256kB
0*512kB 1*1024kB 1*2048kB 0*4096kB = 40544kB
&7&[] c1 14741
(dumpstate) Free pages: 0&span
style='mso-spacerun:yes'& 1&
style='mso-spacerun:yes'& 4&
style='mso-spacerun:yes'& 7&
style='mso-spacerun:yes'& 10
&7&[] c1 14741
(dumpstate) Normal: M[ 0]:&span
style='mso-spacerun:yes'&
1910 0&span
style='mso-spacerun:yes'& 1&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
&7&[] c1 14741
(dumpstate) Normal: M[ 1]:&span
style='mso-spacerun:yes'&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
&7&[] c1 14741
(dumpstate) Normal: M[ 2]:&span
style='mso-spacerun:yes'& 2&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
&7&[] c1 14741
(dumpstate) Normal: M[ 3]:&span
style='mso-spacerun:yes'& 2&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
&7&[] c1 14741
(dumpstate) Normal: M[ 4]:&span
style='mso-spacerun:yes'&
118 25&span
style='mso-spacerun:yes'& 6&
style='mso-spacerun:yes'& 1&
style='mso-spacerun:yes'& 1&
&7&[] c1 14741
(dumpstate) Normal: M[ 5]:&span
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
style='mso-spacerun:yes'& 0&
&7&[] c1 14741
(dumpstate) 8687 total pagecache pages
&7&[] c1 14741
(dumpstate) 1814 pages in swap cache
&7&[] c1 14741
(dumpstate) Swap cache stats: add 19450, delete 17636, find
&7&[] c1 14741
(dumpstate) Free swap = 0kB
&7&[] c1 14741
(dumpstate) Total swap = 32764kB
&7&[] c1 14741
(dumpstate) 131072 pages of RAM
&7&[] c1 14741
(dumpstate) 11741 free pages
&7&[] c1 14741
(dumpstate) 28428 reserved pages
&7&[] c1 14741
(dumpstate) 3752 slab pages
&7&[] c1 14741
(dumpstate) 36194 pages shared
&7&[] c1 14741
(dumpstate) 1814 pages swap cached
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817: dumpstate.
&3&[] c1 14741
(dumpstate) No opened file on process 14817:
dumpstate.
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。