mia khalifa ed2k,郭广昌几任老婆,傲世九重天顶点
【android内存优化】android开发如何避免oom？android内存优化是性能优化很重要的一部分，而如何避免oom又是内存优化的核心。
android的dalvik扮演了内存垃圾自动回收的角色。
android和java中都会出现由于不良代码引起的内存泄露，为了使android应用程序能够快速高效的运行，android每个应用程序都会有专门dalvik虚拟机实例来运行，也就是每个程序都在属于自己的进程中运行。
这样，某个应用程序内存泄露仅仅只会使自己进程被kill掉不会影响其他进程（如果是system_process等系统进程出现问题，就会造成系统重启），另一方面，系统为每一个应用程序分配了不同的内存上限，如果超过这个上限被视为内存泄露，从而被kill掉。
dalvik heap size因不同设备的ram不同而有所差异，应用占用内存接近这个阀值，在尝试分配内存就会引起outofmemoryerror的错误。
出现oom有几种情况：
加载对象过大相应资源过多，来不及加载。解决这些问题，有：
内存引用上做一些处理，常用的有软引用。内存中加载图片直接在内存中做处理（如边界压缩）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之间共享内存。
我要评论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的自动装箱，而且避免了装箱后的解箱。
避免在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开源控件可以帮助我们发现内存泄露的问题。
介绍：https://github.com/square/leakcanary中文文档 http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/)注意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 heap
android设备由于软硬件的差异，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。 建议使用intentservice，它会在处理完交代给它的任务之后尽快结束自己。更多信息，请running in a background service。优化布局层次，减少内存消耗
越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的view无法实现足够扁平的时候考虑使用自定义view来达到目的。谨慎使用“抽象”
很多时候，开发者会使用抽象类作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的额外内存开销：他们需要同等量的代码用于可执行，那些代码会被mapping到内存中，因此如果你的抽象没有显著的提升效率，应该尽量避免他们。使用nano protobufs序列化数据
protocol buffers是由google为序列化结构数据而设计的，一种语言无关，平台无关，具有良好的扩展性。类似xml，却比xml更加轻量，快速，简单。如果你需要为你的数据实现序列化与协议化，建议使用nano protobufs。关于更多细节，请参考protobuf readme的”nano version”章节。谨慎使用依赖注入框架
使用类似guice或者roboguice等框架注入代码，在某种程度上可以简化你的代码。下面是使用roboguice前后的对比图：
13.谨慎使用多进程
使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术。
一个典型的例子是创建一个可以长时间后台播放的music player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些ui资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作ui，另外一个给后台的service。
使用proguard来剔除不需要的代码
proguard能够通过移除不需要的代码，重命名类，域与方法等等对代码进行压缩，优化与混淆。使用proguard可以使得你的代码更加紧凑，这样能够减少mapping代码所需要的内存空间。谨慎使用第三方libraries
很多开源的library代码都不是为移动网络环境而编写的，如果运用在移动设备上，并不一定适合。即使是针对android而设计的library，也需要特别谨慎，特别是在你不知道引入的library具体做了什么事情的时候。例如，其中一个library使用的是nano protobufs, 而另外一个使用的是micro protobufs。这样一来，在你的应用里面就有2种protobuf的实现方式。这样类似的冲突还可能发生在输出日志，加载图片，缓存等等模块里面。另外不要为了1个或者2个功能而导入整个library，如果没有一个合适的库与你的需求相吻合，你应该考虑自己去实现，而不是导入一个大而全的解决方案。考虑不同的实现方式来优化内存占用
写在最后：
设计风格很大程度上会影响到程序的内存与性能，相对来说，如果大量使用类似material design的风格，不仅安装包可以变小，还可以减少内存的占用，渲染性能与加载性能都会有一定的提升。内存优化并不就是说程序占用的内存越少就越好，如果因为想要保持更低的内存占用，而频繁触发执行gc操作，在某种程度上反而会导致应用性能整体有所下降，这里需要综合考虑做一定的权衡。android的内存优化涉及的知识面还有很多：内存管理的细节，垃圾回收的工作原理，如何查找内存泄漏等等都可以展开讲很多。oom是内存优化当中比较突出的一点，尽量减少oom的概率对内存优化有着很大的意义。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Android Manifest中meta-data扩展元素数据的配置与获取方式
Android实现获取meta-data和build.gradle的值
Android获取清单文件中的meta-data,解决碰到数值为null的问题
解决webview 第二次调用loadUrl页面不刷新的问题
解决Android WebView拦截url,视频播放加载失败的问题
Android webview加载https链接错误或无响应的解决
网友评论