企业服务平台网站建设,壹互联是网站公司吗,wordpress 查看更多,做阿里巴巴英文网站写在最前#xff1a; 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT#xff0c;加上把网上搜集的各种内存零散知识点进行汇总、挑选、简化后整理而成。 所以我将本文定义为一个工具类的文章#xff0c;如果你在Android开发中遇到关于内存问题#xff0c;或者… 写在最前 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT加上把网上搜集的各种内存零散知识点进行汇总、挑选、简化后整理而成。 所以我将本文定义为一个工具类的文章如果你在Android开发中遇到关于内存问题或者马上要参加面试或者就是单纯的学习或复习一下内存相关知识都欢迎阅读。本文最后我会尽量列出所参考的文章。 OOM 内存泄露可以引发很多的问题 1.程序卡顿响应速度慢内存占用高时JVM虚拟机会频繁触发GC 2.莫名消失当你的程序所占内存越大它在后台的时候就越可能被干掉。反之内存占用越小在后台存在的时间就越长 3.直接崩溃OutOfMemoryError ANDROID内存面临的问题 1.有限的堆内存原始只有16M 2.内存大小消耗等根据设备操作系统等级屏幕尺寸的不同而不同 3.程序不能直接控制 4.支持后台多任务处理multitasking 5.运行在虚拟机之上 5R 本文主要通过如下的5R方法来对ANDROID内存进行优化 1.Reckon计算 首先需要知道你的app所消耗内存的情况知己知彼才能百战不殆 2.Reduce减少 消耗更少的资源 3.Reuse重用 当第一次使用完以后尽量给其他的使用 5.Recycle回收 回收资源 4.Review检查 回顾检查你的程序看看设计或代码有什么不合理的地方。 Reckon 关于内存简介和Reckon内存计算的内容请看上一篇文章ANDROID内存优化(大汇总——上) Reduce Reduce的意思就是减少直接减少内存的使用是最有效的优化方式。 下面来看看有哪些方法可以减少内存使用 Bitmap Bitmap是内存消耗大户绝大多数的OOM崩溃都是在操作Bitmap时产生的下面来看看几个处理图片的方法 图片显示 我们需要根据需求去加载图片的大小。 例如在列表中仅用于预览时加载缩略图thumbnails 。 只有当用户点击具体条目想看详细信息的时候这时另启动一个fragmentactivity对话框等等去显示整个图片 图片大小 直接使用ImageView显示bitmap会占用较多资源特别是图片较大的时候可能导致崩溃。 使用BitmapFactory.Options设置inSampleSize, 这样做可以减少对系统资源的要求。 属性值inSampleSize表示缩略图大小为原始图片大小的几分之一即如果这个值为2则取出的缩略图的宽和高都是原始图片的1/2图片大小就为原始大小的1/4。 [java] view plaincopy print? BitmapFactory.Options bitmapFactoryOptions new BitmapFactory.Options(); bitmapFactoryOptions.inJustDecodeBounds true; bitmapFactoryOptions.inSampleSize 2; // 这里一定要将其设置回false因为之前我们将其设置成了true // 设置inJustDecodeBounds为true后decodeFile并不分配空间即BitmapFactory解码出来的Bitmap为Null,但可计算出原始图片的长度和宽度 options.inJustDecodeBounds false; Bitmap bmp BitmapFactory.decodeFile(sourceBitmap, options); 图片像素 Android中图片有四种属性分别是ALPHA_8每个像素占用1byte内存 ARGB_4444每个像素占用2byte内存 ARGB_8888每个像素占用4byte内存 默认RGB_565每个像素占用2byte内存 Android默认的颜色模式为ARGB_8888这个颜色模式色彩最细腻显示质量最高。但同样的占用的内存也最大。 所以在对图片效果不是特别高的情况下使用RGB_565565没有透明度属性如下 BitmapFactory.Optionsopt newBitmapFactory.Options(); opt.inPreferredConfig Bitmap.Config.RGB_565; opt.inPurgeable true; opt.inInputShareable true; //获取资源图片 InputStreamis context.getResources().openRawResource(resId); returnBitmapFactory.decodeStream(is, null, opt); } 图片回收 使用Bitmap过后就需要及时的调用Bitmap.recycle()方法来释放Bitmap占用的内存空间而不要等Android系统来进行释放。 下面是释放Bitmap的示例代码片段。 [java] view plaincopy print? // 先判断是否已经回收 if(bitmap ! null !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap null; } System.gc(); 捕获异常 经过上面这些优化后还会存在报OOM的风险所以下面需要一道最后的关卡——捕获OOM异常 [java] view plaincopy print? Bitmap bitmap null; try { // 实例化Bitmap bitmap BitmapFactory.decodeFile(path); } catch (OutOfMemoryError e) { // 捕获OutOfMemoryError避免直接崩溃 } if (bitmap null) { // 如果实例化失败 返回默认的Bitmap对象 return defaultBitmapMap; } 修改对象引用类型 引用类型 引用分为四种级别这四种级别由高到低依次为强引用软引用弱引用虚引用。 强引用strong reference 如Object objectnew Objectobject就是一个强引用了。当内存空间不足Java虚拟机宁愿抛出OutOfMemoryError错误使程序异常终止也不会靠随意回收具有强引用的对象来解决内存不足问题。 软引用SoftReference 只有内存不够时才回收,常用于缓存当内存达到一个阀值GC就会去回收它 弱引用WeakReference 弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中一旦发现了只具有弱引用的对象不管当前内存空间足够与否都会回收它的内存。 虚引用PhantomReference 虚引用顾名思义就是形同虚设与其他几种引用都不同虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用那么它就和没有任何引用一样在任何时候都可能被垃圾回收。 软引用和弱引用的应用实例 注意对于SoftReference(软引用)或者WeakReference(弱引用)的Bitmap缓存方案现在已经不推荐使用了。自Android2.3版本(API Level 9)开始垃圾回收器更着重于对软/弱引用的回收所以下面的内容可以选择忽略。 在Android应用的开发中为了防止内存溢出在处理一些占用内存大而且声明周期较长的对象时候可以尽量应用软引用和弱引用技术。 下面以使用软引用为例来详细说明弱引用的使用方式与软引用是类似的 假设我们的应用会用到大量的默认图片而且这些图片很多地方会用到。如果每次都去读取图片由于读取文件需要硬件操作速度较慢会导致性能较低。所以我们考虑将图片缓存起来需要的时候直接从内存中读取。但是由于图片占用内存空间比较大缓存很多图片需要很多的内存就可能比较容易发生OutOfMemory异常。这时我们可以考虑使用软引用技术来避免这个问题发生。 首先定义一个HashMap保存软引用对象。 [java] view plaincopy print? private MapString, SoftReferenceBitmap imageCache new HashMapString, SoftReferenceBitmap(); 再来定义一个方法保存Bitmap的软引用到HashMap。 [java] view plaincopy print? public void addBitmapToCache(String path) { // 强引用的Bitmap对象 Bitmap bitmap BitmapFactory.decodeFile(path); // 软引用的Bitmap对象 SoftReferenceBitmap softBitmap new SoftReferenceBitmap(bitmap); // 添加该对象到Map中使其缓存 imageCache.put(path, softBitmap); } 获取的时候可以通过SoftReference的get()方法得到Bitmap对象。 [java] view plaincopy print? public Bitmap getBitmapByPath(String path) { // 从缓存中取软引用的Bitmap对象 SoftReferenceBitmap softBitmap imageCache.get(path); // 判断是否存在软引用 if (softBitmap null) { return null; } // 取出Bitmap对象如果由于内存不足Bitmap被回收将取得空 Bitmap bitmap softBitmap.get(); return bitmap; } 使用软引用以后在OutOfMemory异常发生之前这些缓存的图片资源的内存空间可以被释放掉的从而避免内存达到上限避免Crash发生。 需要注意的是在垃圾回收器对这个Java对象回收前SoftReference类所提供的get方法会返回Java对象的强引用一旦垃圾线程回收该Java对象之后get方法将返回null。所以在获取软引用对象的代码中一定要判断是否为null以免出现NullPointerException异常导致应用崩溃。 到底什么时候使用软引用什么时候使用弱引用呢 个人认为如果只是想避免OutOfMemory异常的发生则可以使用软引用。如果对于应用的性能更在意想尽快回收一些占用内存比较大的对象则可以使用弱引用。 还有就是可以根据对象是否经常使用来判断。如果该对象可能会经常使用的就尽量用软引用。如果该对象不被使用的可能性更大些就可以用弱引用。 另外和弱引用功能类似的是WeakHashMap。WeakHashMap对于一个给定的键其映射的存在并不阻止垃圾回收器对该键的回收回收以后其条目从映射中有效地移除。WeakHashMap使用ReferenceQueue实现的这种机制。 其他小tips 对常量使用static final修饰符 让我们来看看这两段在类前面的声明 static int intVal 42;static String strVal Hello, world!; 编译器会生成一个叫做clinit的初始化类的方法当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal然后把一个指向类中常量表 的引用赋给strVal。当以后要用到这些值的时候会在成员变量表中查找到他们。 下面我们做些改进使用“final”关键字 static final int intVal 42;static final String strVal Hello, world!; 现在类不再需要clinit方法因为在成员变量初始化的时候会将常量直接保存到类文件中。用到intVal的代码被直接替换成42而使用strVal的会指向一个字符串常量而不是使用成员变量。 将一个方法或类声明为final不会带来性能的提升但是会帮助编译器优化代码。举例说如果编译器知道一个getter方法不会被重载那么编译器会对其采用内联调用。 你也可以将本地变量声明为final同样这也不会带来性能的提升。使用“final”只能使本地变量看起来更清晰些但是也有些时候这是必须的比如在使用匿名内部类的时候。 静态方法代替虚拟方法 如果不需要访问某对象的字段将方法设置为静态调用会加速15%到20%。这也是一种好的做法因为你可以从方法声明中看出调用该方法不需要更新此对象的状态。 减少不必要的全局变量 尽量避免static成员变量引用资源耗费过多的实例,比如Context 因为Context的引用超过它本身的生命周期会导致Context泄漏。所以尽量使用Application这种Context类型。 你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。 避免创建不必要的对象 最常见的例子就是当你要频繁操作一个字符串时使用StringBuffer代替String。 对于所有所有基本类型的组合int数组比Integer数组好这也概括了一个基本事实两个平行的int数组比 (int,int)对象数组性能要好很多。 总体来说就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集进而减少对用户体验的影响。 避免内部Getters/Setters 在Android中虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践在公共接口中使用Getters和Setters是有道理的但在一个字段经常被访问的类中宜采用直接访问。 避免使用浮点数 通常的经验是在Android设备中浮点数会比整型慢两倍。 使用实体类比接口好 假设你有一个HashMap对象你可以将它声明为HashMap或者Map Map map1 new HashMap();
HashMap map2 new HashMap(); 哪个更好呢 按照传统的观点Map会更好些因为这样你可以改变他的具体实现类只要这个类继承自Map接口。传统的观点对于传统的程序是正确的但是它并不适合嵌入式系统。调用一个接口的引用会比调用实体类的引用多花费一倍的时间。如果HashMap完全适合你的程序那么使用Map就没有什么价值。如果有些地方你不能确定先避免使用Map剩下的交给IDE提供的重构功能好了。(当然公共API是一个例外一个好的API常常会牺牲一些性能 避免使用枚举 枚举变量非常方便但不幸的是它会牺牲执行的速度和并大幅增加文件体积。 使用枚举变量可以让你的API更出色并能提供编译时的检查。所以在通常的时候你毫无疑问应该为公共API选择枚举变量。但是当性能方面有所限制的时候你就应该避免这种做法了。 for循环 访问成员变量比访问本地变量慢得多如下面一段代码 [java] view plaincopy print? for(int i 0; i this.mCount; i) {} 永远不要在for的第二个条件中调用任何方法如下面一段代码 [java] view plaincopy print? for(int i 0; i this.getCount(); i) {} 对上面两个例子最好改为 [java] view plaincopy print? int count this.mCount; / int count this.getCount(); for(int i 0; i count; i) {} 在java1.5中引入的for-each语法。编译器会将对数组的引用和数组的长度保存到本地变量中这对访问数组元素非常好。 但是编译器还会在每次循环中产生一个额外的对本地变量的存储操作如下面例子中的变量a这样会比普通循环多出4个字节速度要稍微慢一些 [java] view plaincopy print? for (Foo a : mArray) { sum a.mSplat; } 了解并使用类库 选择Library中的代码而非自己重写除了通常的那些原因外考虑到系统空闲时会用汇编代码调用来替代library方法这可能比JIT中生成的等价的最好的Java代码还要好。 当你在处理字串的时候不要吝惜使用String.indexOf()String.lastIndexOf()等特殊实现的方法。这些方法都是使用C/C实现的比起Java循环快10到100倍。 System.arraycopy方法在有JIT的Nexus One上自行编码的循环快9倍。 android.text.format包下的Formatter类提供了IP地址转换、文件大小转换等方法DateFormat类提供了各种时间转换都是非常高效的方法。 TextUtils类对于字符串处理Android为我们提供了一个简单实用的TextUtils类如果处理比较简单的内容不用去思考正则表达式不妨试试这个在android.text.TextUtils的类 高性能MemoryFile类很多人抱怨Android处理底层I/O性能不是很理想如果不想使用NDK则可以通过MemoryFile类实现高性能的文件读写操作。MemoryFile适用于哪些地方呢对于I/O需要频繁操作的主要是和外部存储相关的I/O操作MemoryFile通过将 NAND或SD卡上的文件分段映射到内存中进行修改处理这样就用高速的RAM代替了ROM或SD卡性能自然提高不少对于Android手机而言同时还减少了电量消耗。该类实现的功能不是很多直接从Object上继承通过JNI的方式直接在C底层执行。 Reuse: Reuse重用减少内存消耗的重要手段之一。 核心思路就是将已经存在的内存资源重新使用而避免去创建新的最典型的使用就是缓存Cache和池Pool。 Bitmap缓存 Bitmap缓存分为两种 一种是内存缓存一种是硬盘缓存。 内存缓存LruCache 以牺牲宝贵的应用内存为代价内存缓存提供了快速的Bitmap访问方式。系统提供的LruCache类是非常适合用作缓存Bitmap任务的它将最近被引用到的对象存储在一个强引用的LinkedHashMap中并且在缓存超过了指定大小之后将最近不常使用的对象释放掉。 注意以前有一个非常流行的内存缓存实现是SoftReference(软引用)或者WeakReference(弱引用)的Bitmap缓存方案然而现在已经不推荐使用了。自Android2.3版本(API Level 9)开始垃圾回收器更着重于对软/弱引用的回收这使得上述的方案相当无效。 硬盘缓存DiskLruCache 一个内存缓存对加速访问最近浏览过的Bitmap非常有帮助但是你不能局限于内存中的可用图片。GridView这样有着更大的数据集的组件可以很轻易消耗掉内存缓存。你的应用有可能在执行其他任务(如打电话)的时候被打断并且在后台的任务有可能被杀死或者缓存被释放。一旦用户重新聚焦(resume)到你的应用你得再次处理每一张图片。 在这种情况下硬盘缓存可以用来存储Bitmap并在图片被内存缓存释放后减小图片加载的时间(次数)。当然从硬盘加载图片比内存要慢并且应该在后台线程进行因为硬盘读取的时间是不可预知的。 注意如果访问图片的次数非常频繁那么ContentProvider可能更适合用来存储缓存图片例如Image Gallery这样的应用程序。 更多关于内存缓存和硬盘缓存的内容请看Google官方教程https://developer.android.com/develop/index.html 图片缓存的开源项目 对于图片的缓存现在都倾向于使用开源项目这里我列出几个我搜到的 1. Android-Universal-Image-Loader 图片缓存 2. picasso square开源的图片缓存项目地址https://github.com/square/picasso特点(1)可以自动检测adapter的重用并取消之前的下载(2)图片变换(3)可以加载本地资源(4)可以设置占位资源(5)支持debug模式 3. ImageCache 图片缓存包含内存和Sdcard缓存项目地址https://github.com/Trinea/AndroidCommon特点 (1)支持预取新图片支持等待队列(2)包含二级缓存可自定义文件名保存规则(3)可选择多种缓存算法(FIFO、LIFO、LRU、MRU、LFU、MFU等13种)或自定义缓存算法(4)可方便的保存及初始化恢复数据(5)支持不同类型网络处理(6)可根据系统配置初始化缓存等 4. Android 网络通信框架Volley 项目地址https://android.googlesource.com/platform/frameworks/volley 我们在程序中需要和网络通信的时候大体使用的东西莫过于AsyncTaskLoaderHttpURLConnectionAsyncTaskHTTPClientApache等在2013年的Google I/O发布了Volley。Volley是Android平台上的网络通信库能使网络通信更快更简单更健壮。 特点 (1)JSON图像等的异步下载 (2)网络请求的排序scheduling (3)网络请求的优先级处理 (4)缓存 (5)多级别取消请求 (6)和Activity和生命周期的联动Activity结束时同时取消所有网络请求 Adapter适配器 在Android中Adapter使用十分广泛特别是在list中。所以adapter是数据的 “集散地” 所以对其进行内存优化是很有必要的。 下面算是一个标准的使用模版 主要使用convertView和ViewHolder来进行缓存处理 [java] view plaincopy print? Override public View getView(int position, View convertView, ViewGroup parent) { ViewHolder vHolder null; //如果convertView对象为空则创建新对象不为空则复用 if (convertView null) { convertView inflater.inflate(..., null); // 创建 ViewHodler 对象 vHolder new ViewHolder(); vHolder.img (ImageView) convertView.findViewById(...); vHolder.tv (TextView) convertView.findViewById(...); // 将ViewHodler保存到Tag中(Tag可以接收Object类型对象所以任何东西都可以保存在其中) convertView.setTag(vHolder); } else { //当convertView不为空时通过getTag()得到View vHolder (ViewHolder) convertView.getTag(); } // 给对象赋值修改显示的值 vHolder.img.setImageBitmap(...); vHolder.tv.setText(...); return convertView; } //将显示的View 包装成类 static class ViewHolder { TextView tv; ImageView img; } 池PooL 对象池 对象池使用的基本思路是将用过的对象保存起来等下一次需要这种对象的时候再拿出来重复使用从而在一定程度上减少频繁创建对象所造成的开销。 并非所有对象都适合拿来池化――因为维护对象池也要造成一定开销。对生成时开销不大的对象进行池化反而可能会出现“维护对象池的开销”大于“生成新对象的开销”从而使性能降低的情况。但是对于生成时开销可观的对象池化技术就是提高性能的有效策略了。 线程池 线程池的基本思想还是一种对象池的思想开辟一块内存空间里面存放了众多(未死亡)的线程池中线程执行调度由池管理器来处理。当有线程任务时从池中取一个执行完成后线程对象归池这样可以避免反复创建线程对象所带来的性能开销节省了系统的资源。 比如一个应用要和网络打交道有很多步骤需要访问网络为了不阻塞主线程每个步骤都创建个线程在线程中和网络交互用线程池就变的简单线程池是对线程的一种封装让线程用起来更加简便只需要创一个线程池把这些步骤像任务一样放进线程池在程序销毁时只要调用线程池的销毁函数即可。 java提供了ExecutorService和Executors类我们可以应用它去建立线程池。 通常可以建立如下4种 [java] view plaincopy print? /** 每次只执行一个任务的线程池 */ ExecutorService singleTaskExecutor Executors.newSingleThreadExecutor(); /** 每次执行限定个数个任务的线程池 */ ExecutorService limitedTaskExecutor Executors.newFixedThreadPool(3); /** 所有任务都一次性开始的线程池 */ ExecutorService allTaskExecutor Executors.newCachedThreadPool(); /** 创建一个可在指定时间里执行任务的线程池亦可重复执行 */ ExecutorService scheduledTaskExecutor Executors.newScheduledThreadPool(3); 更多关于线程池的内容我推荐这篇文章http://www.xuanyusong.com/archives/2439 注意 要根据情况适度使用缓存因为内存有限。 能保存路径地址的就不要存放图片数据不经常使用的尽量不要缓存不用时就清空。 写在最后 我准备将文章分为上、中、下三部分。现在已经全部完成 内存简介Recoken计算请看ANDROID内存优化(大汇总——上) Reduce减少Reuse重用 请看ANDROID内存优化(大汇总——中) Recycle回收, Review检查 请看ANDROID内存优化(大汇总——全) 写这篇文章的目的就是想弄一个大汇总将零散的内存知识点总结一下如果有错误、不足或建议都希望告诉我。 参考文章 解析Android开发优化之:软引用与弱引用的应用http://www.jb51.net/article/36627.htmandroid内存泄露优化总结http://blog.csdn.net/imain/article/details/8560986Android 内存优化http://blog.csdn.net/awangyunke/article/details/20380719Android开发优化之——对Bitmap的内存优化http://blog.csdn.net/arui319/article/details/7953690关于android性能内存优化http://www.cnblogs.com/zyw-205520/archive/2013/02/17/2914190.html Android研究院之应用开发线程池的经典使用http://www.xuanyusong.com/archives/2439 转载于:https://www.cnblogs.com/Free-Thinker/p/6397430.html
