公司的网站推广,wordpress封面外链,垦利网页定制,一个域名一个ip做多个网站写在开头的话#xff1a; 如果有同学对Android性能比较关注的#xff0c;可以阅读这篇文章#xff1a;Android性能优化建议 原文地址#xff1a;http://android.xsoftlab.net/training/articles/memory.html
随机存储器(RAM)在任何运行环境中都是一块非常重要的区域#… 写在开头的话 如果有同学对Android性能比较关注的可以阅读这篇文章Android性能优化建议 原文地址http://android.xsoftlab.net/training/articles/memory.html
随机存储器(RAM)在任何运行环境中都是一块非常重要的区域尤其是在内存受限的移动操作系统上。尽管Android的Dalvik虚拟机会对其进行垃圾回收但是这不意味着APP就可以忽略申请及释放的内存。
为了可以使垃圾回收器能够有效清理APP所占用的内存空间你需要防止内存泄漏发生并需要在适当的时间将Reference对象释放。对大多数APP来说垃圾回收器会在正确的对象使用完毕之后将其所占用的内存回收释放。
这节课将会学习Android如何管理APP进程以及内存空间、以及如何减少内存的占用。
Android如何管理内存
Android并没有提供专门的内存交换空间但是它使用了paging及memory-mapping来管理内存。这意味着任何你所修改的内存——无论是否被对象分配所使用或者是被内存映射所占用——它们会一直遗留在内存中不能被交换出去。所以完全释放APP内存的唯一方式就是释放任何你可能所持有的对象引用这样才可以使垃圾回收器对其进行回收。不过这里有一个例外任何没有被修改的文件映射比如代码在系统需要的时候会被移出RAM。
共享内存
为了可以在RAM中满足一切要求Android试着在进程间共享RAM页面。它通过以下几种方式实现
每个APP进程都是由一个名为Zygote的进程fork出来的。Zygote进程在系统启动加载通用框架代码及资源(比如Activity的主题)时启动。为了启动新的APP进程系统会先fork出Zygote进程然后再在新的进程中加载、运行APP的代码。这使得为Android框架代码以及资源所分配的RAM页面在APP进程间共享成为了可能。大多数的静态数据都是被映射到进程中的。这种方式不仅可以在进程间共享数据还可以在需要的时候将其移除页面。静态数据包含Dalvik代码(放置在预链接的.odex文件中)APP资源以及在.so文件中的本地代码。在很多地方Android通过显式内存分配区域在不同的进程间共享同一块RAM。比如WindowSurface就在APP与屏幕合成器间使用了共享内存CursorBuffer在内容提供者与客户端之间也使用了共享内存。
由于大量使用了共享内存所以检查APP占用的内存空间就显得很有必要了。
内存的分配与回收
以下是Android内存回收与再分配的一些情况 - Dalvik中每个进程的堆都有虚拟内存范围限制。这个范围取决于逻辑堆尺寸的定义它可以随着APP的需要随之增长(不过最大只会增长到系统为每个app所分配的内存大小)。 - 堆栈的逻辑尺寸并不等同于堆栈所使用的物理内存大小。当系统检查APP的堆时会计算一个名为Proportional Set Size(PSS)的值PSS的意思是与其他进程共享的需要清理的页面列表。有关更多PSS的相关信息请阅读指南Investigating Your RAM Usage。 - Dalvik堆栈对堆栈的逻辑空间并不是连续排布的这句话的意思是Android并不会对堆空间进行碎片整理。Android只有在已使用的空间到达堆栈的末端时才会整理堆栈的逻辑空间。不过这不意味着堆所使用的物理空间不能被整理。在垃圾收集之后Dalvik会先扫描堆并找出无用页面然后使用madvise将这些页面返回到kernel。所以成对的分配、回收大段的内存可以使大量的内存能够重复使用。然而回收小段的内存的效率可能会很低因为小段内存的页面可能正在被使用还没有被释放。
侦测应用内存
为了维持一个多任务执行环境Android为每个APP的堆大小都设置了硬性限制。具体的堆大小都不相同这取决于RAM的大小。如果APP已经将所分配的堆容量用完并还要继续申请更多的内存那么APP会收到一个OutOfMemoryError错误。
在一些情况中你可能需要知道当前的设备中还有多少堆内存可用。比如检查多大的数据缓存空间在内存中是安全的。你可以通过getMemoryClass()方法进行这样查询。它会返回一个整型数值这个数值以兆字节为单位代表了APP堆内存的可用值。这项内容将会在下面进行详细讨论。
APP的切换
用户在切换APP时并没有使用交换空间Android将切换到后台的进程放置在一个LRU(最近最少使用)缓存中。这么说吧用户先开启了一个APP那么会专门有个进程为它启动后来用户离开了该APP但这个APP的进程并没有退出那么这时系统会将这个APP的进程缓存下来所以如果用户再次返回了该APP那么刚刚缓存的进程会被再次利用以便完成快速切换。
如果APP含有一个缓存进程并且占用了当前系统并不那么需要的内存那么在用户不再使用它时它就会影响到系统的整体性能。所以随着系统的可用内存减少系统可能会杀死LRU缓存中最近最少使用到的进程。为了使APP尽可能缓存的时间长下面的章节会介绍何时应当释放引用。
有关更多进程在后台如何缓存以及Android是如何决定哪个进程应当被杀死的相关信息请参见Processes and Threads。
APP应当如何管理内存
APP应当在每个开发阶段考虑RAM的限制包括APP的设计阶段。下面将会列出几种有效的解决方案
在开发时应当采用以下方式来增加内存的使用效率。
尽可能少的使用服务
如果APP需要使用服务在后台做一些工作绝不要在服务内做不必要的工作。还要注意在工作完成之后如果服务停止失败则要当心服务的泄露。
当启动服务时系统会为该服务持有一个进程。这会使得系统的开销非常高昂因为服务所使用的内存不能作为它用。这会减少系统保持在LRU缓存中的进程数量并会使得APP的转换效率低下。当内存非常紧张或者系统不能够保证有足够的进程来维持当前的服务数量时它甚至会引起系统的卡死。
对于以上问题最佳的解决方案就是使用IntentService来限制本地服务的数量。
当服务不再需要时留下服务继续运行是APP常见的一种非常糟糕的内存管理错误。所以不要贪图使服务保持长时运行。不及时停止服务不但会增加APP RAM容量不够用的风险而且还会使用户觉得该APP做的非常的烂并顺便将其卸载。
在UI不可见时释放内存
当用户切换到其它APP时这时你的APP UI会变得不可见所以应该释放与UI相关的所有资源。及时释放UI资源可以明显的增长系统缓存进程的能力这会直接影响到用户的体验。
为了可以在用户离开UI后还能收到系统通知应当在Activity内实现onTrimMemory()方法。在该方法内监听TRIM_MEMORY_UI_HIDDEN标志这个标志代表了UI目前进入隐藏态应当释放UI所用到的所有资源。
这里要注意TRIM_MEMORY_UI_HIDDEN标志代表的是APP内所有的UI组件对于用户隐藏。这要与onStop()区分开该方法是在Activity的实例变的不可见时调用它是在APP内部Activity之间的切换时调用的。所以尽管在onStop()中释放了Activity的资源比如网络连接注销广播接收器等等但是一般不要在该方法内释放UI资源。因为这可以使用户在返回该Activity时UI现场可以迅速恢复。
在内存紧张时释放内存
在APP生命周期的任何阶段onTrimMemory()方法会告知当前设备内存很紧张。你应当在收到以下标志时进一步的释放资源
TRIM_MEMORY_RUNNING_MODERATE APP目前处于运行态暂时不会被杀死但是设备目前处于低内存运行态并且系统正在杀死LRU缓存中的进程。TRIM_MEMORY_RUNNING_LOW APP目前处于运行态暂时不会被杀死但是设备目前处于极低内存运行态所以你应当释放无用的资源来增进系统的性能。TRIM_MEMORY_RUNNING_CRITICAL APP还处于运行态但是系统已经准备将LRU缓存中的大部分进程杀死所以APP应当立即释放所有不必要的资源。如果系统没有获得足够数量的RAM空间那么系统会清除LRU中的所有进程并会杀死一些主机正在进行的服务。
还有在APP处于缓存状态时你可能会收到以下标志
TRIM_MEMORY_BACKGROUND APP处于低内存运行态APP的进程处于LRU列表的前端。尽管APP所面临被杀死的风险还比较低但是系统可能已经做好了杀死LRU进程中的准备。APP应当释放那些易于恢复的资源这样的话进程会继续保留在缓存列表中并且会在用户返回到APP时迅速恢复。TRIM_MEMORY_MODERATE APP处于低内存运行态APP的进程处于LRU列表的中部。如果系统的内存进一步的降低那么APP的进程可能就会被杀死。TRIM_MEMORY_COMPLETE APP处于低内存运行态。如果系统没有足够内存的话APP的进程首当其冲会被杀死。APP应当释放在恢复APP时一切不重要的事物。
因为onTrimMemory()方法添加于API 14所以可以使用onLowMemory()来兼容老版本它大致与TRIM_MEMORY_COMPLETE标志是等价的。 Note: 当系统开始杀死LRU中的进程时尽管它是自下而上工作的但是系统还是会考虑这么一种情况哪个进程消耗的内存比较多所以如果将该进程杀死后将会获得更多的内存。所以在APP处于LRU缓存时尽可能的消耗少量的内存这样一直维持在缓存列表中的机会才大才可以在切换回APP时迅速恢复状态。 检查应该使用多少内存
就像我们早期提到的运行Android系统的设备的RAM空间各有不同所以提供给每个APP的堆空间也是不同的。你可以通过getMemoryClass()方法获得APP的可用空间。如果APP试图向系统申请比该方法返回值大的内存空间的话那么它会收到一个OutOfMemoryError错误。
在一些特别特殊的环境中你可以申请更大的堆空间可以通过在清单文件的 application标签中添加largeHeap”true”属性的方式来设置。在设置之后可以通过getLargeMemoryClass()来查询大尺寸的堆栈空间量。
然而申请大堆空间的APP只有正常用途才应该申请比如大照片编辑类APP。决不要是因为经常出现了OutOfMemory错误才这么去做你应该做的是解决那个OutOfMemory的问题。只有在你明确知道正常的堆空间不足以支撑APP的运行时才应该这么做。使用额外的内存空间会严重损害整体的用户体验因为垃圾收集器会在此消耗更长的时间并且在任务切换或者执行其它并发操作时系统性能会明显减慢。
此外大堆空间的尺寸在所有的设备上并不是相等的。当运行在某些RAM限制的设备上大堆空间的尺寸可能与常规的堆空间尺寸相等。所以就算是申请了大堆空间那么还是应该使用getMemoryClass()来检查一下常规堆空间大小并尽量将内存的使用量控制在这个范围以下。
避免浪费位图的内存
当加载一张图片到内存时最好是将该图片适配到当前屏幕分辨率大小之后再做内存缓存如果原图本身分辨率很高的话最好将其缩小到适合屏幕分辨率大小。要注意随着位图分辨率的增加所占的相应内存也一并增加。 Note: 在Android 2.3.x之前位图对象无论分辨率是多大都是以相同的大小出现在堆中的因为位图的实际像素数据被单独的存放在了本地内存中。这使得位图内存分配的调试变得很困难因为大多数的堆栈分析工具并不能探测到本地内存的分配。然而自Android 3.0之后位图的像素数据被分配与APP的Dalvik堆栈中这样增进了垃圾回收的效率以及调试能力。 使用优化过的数据容器
我们建议使用Android框架优化过的数据容器比如SparseArray,SparseBooleanArray,以及LongSparseArray.常规的HashMap其实效率是很低的因为它需要为每个映射创建单独的实体。另外SparseArray的工作效率更高因为它可以避免系统对键或值的自动装箱功能。
要对内存的消耗有一定的意识
要充分了解你所使用的语言以及库的内存开销并要一直保持有这种意识包括在APP的设计阶段。经常表面的事物看起来无伤大雅但实际上它们所消耗的内存是很高的。比如
Java的枚举类型需要占用静态常量的两倍内存。你应该坚决制止在Android中使用枚举。Java中的每个类包含匿名内部类的代码需要占用500个字节。每个类的实例需要占用12-16个字节的RAM空间。将每个实例放入HashMap需要格外花费32个字节的空间。
虽然以上的内容只是会消耗几个字节的空间但是它们会在程序的内部迅速的积累增加成为一个巨无霸级的开销。它会使你在分析内存问题的时候让你处于一个非常尴尬的境地因为这些众多的小对象消耗了大量的内存。
当心抽象代码
经常开发者会使用抽象代码实现一种良好的程序设计结构因为抽象代码可以增进代码的灵活性与可维护性。不过抽象代码会有不菲的开销通常它们需要更多的执行代码需要花费更多的时间以及更多的RAM空间来将这些抽象代码映射到内存。所以如果不是必须的话最好远离它们。
为序列化数据使用纳米级缓冲协议
Protocol buffers是一种由Google设计的序列化结构的数据。它与语言无关、与平台无关的、可扩展。与XML类似但是体积更小速度更快、也更简单。如果你决定要使用该纳米级缓冲协议那么就应当在客户端代码中一直使用它。常规的protobufs会生成非常冗长的代码这会引出相当多的问题增加内存的消耗增长APK的体积减缓执行效率并会迅速接近DEX标志的限制。
避免依赖注解框架
使用Guice、RoboGuice这类注解依赖框架是相当方便的因为这些框架可以简化代码的书写以及提供了相应的测试环境。然而这些框架在扫描代码的注解时会执行大量的初始化工作这会使得大量的代码映射到RAM中尽管你不需要降这些代码载入内存。这些被映射的页面会一直驻留在内存中虽然系统可以将它们清除但是只有在这些页面长时间驻留在内存中才会执行清理。
使用第三方库要当心
第三方代码通常不是专门为移动设备而写。当这些代码运行在移动客户端时往往执行效率很低。在决定使用第三方库之前应该假设正在执行一项很重要的移植工作并将要负担为移动设备的维护、优化工作。在决定使用之前要分析该库的大小以及RAM的占用。
就算是某些库是专门为Android所设计的但是它们还是存在隐患的因为每个库所做的事不同。举个栗子一个库可能使用了纳米级的protobufs而另一个库则使用了毫米级的protobufs。那么现在在APP中使用了两个级别的protobufs。这两种差异可能会发生在日志、解析、图像加载框架、缓存以及其它任何你不期望的事情上。
还要当心掉入共享库的陷阱这种共享库有一个共同的特点就是你只使用了该库所提供的很小的功能你并不希望将其它用不到的大量代码也一并放入你的工程内。在最后如果你不是特别的需要这个第三方库的话那么最好的方式就是自己实现一个。
优化整体性能
有关APP整体性能优化的建议都列在了Best Practices for Performance中。这些建议还包括了CPU的性能优化除此之外还包括了内存的优化比如减少布局对象的数量。
你还应该读一读有关optimizing your UI的文章文章内包含了布局调试工具以及lint tool中所提示的一些布局优化建议。
使用ProGuard筛除无用代码
ProGuard工具可以通过移除无用代码以及以一种无意义的名称重命名类名属性方法的方式来达到一种精简、优化、模糊的效果。接下来还必须使用zipalign工具对重命名后的代码进行调整。如果不做这一步将会大大增加RAM的使用量因为类似于资源这些事物不会再由APK映射到内存。 作者PS: 这段话摘自于zipalign的介绍相当于是说Zipalign的原理与优势: Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application. 分析RAM的使用状况
一旦APP达到一个相对稳定的程度那么接下来就需要分析APP在各个生命周期的RAM使用情况了。有关如何分析APP的RAM使用情况请参见 Investigating Your RAM Usage。
使用多进程
如果它适用于你的APP那么另一项可能帮助你管理APP内存的升级建议就是将组件部署到不同的进程中。使用这项建议必须总是特别的小心并且大部分APP不应该使用这项技术如果处理不当的话它会迅速的增加RAM的消耗。这项技术对于那些运行在后台的工作与前台的工作一样重要的APP极为有用并且可以单独管理这些操作。
使用多进程最适合的场景就是音乐播放器。如果整个APP运行在单一的进程中那么Activity UI所执行的大部分内存分配都会和音乐的播放保持相同的时间甚至是用户切换到了其它APP。那么像这样的APP就应该拥有两个进程一个进程负责UI而另一个的工作就是持续不断的运行后台服务。
你可以在清单文件中需要执行单独进程的组件里添加android:process属性来实现独立进程。比如你可以在需要执行单独进程的服务中添加该属性并声明该进程的名称”background”(你可以命名任何你想命名的名称)
service android:name.PlaybackServiceandroid:process:background /
进程的名称应该以冒号’:’开头以便确保该进程属于你APP的私有进程。
在决定创建一个新进程之前你应该了解一下内存的影响。为了演示每个进程的执行效果首先要考虑到一个不做任何事情的进程需要占用大约1.4MB的内存空间下面显示了空态下的内存信息堆
adb shell dumpsys meminfo com.example.android.apis:empty
** MEMINFO in pid 10172 [com.example.android.apis:empty] **Pss Pss Shared Private Shared Private Heap Heap HeapTotal Clean Dirty Dirty Clean Clean Size Alloc Free------ ------ ------ ------ ------ ------ ------ ------ ------Native Heap 0 0 0 0 0 0 1864 1800 63Dalvik Heap 764 0 5228 316 0 0 5584 5499 85Dalvik Other 619 0 3784 448 0 0Stack 28 0 8 28 0 0Other dev 4 0 12 0 0 4.so mmap 287 0 2840 212 972 0.apk mmap 54 0 0 0 136 0.dex mmap 250 148 0 0 3704 148Other mmap 8 0 8 8 20 0Unknown 403 0 600 380 0 0TOTAL 2417 148 12480 1392 4832 152 7448 7299 148Note: 如何阅读这些信息请参见Investigating Your RAM Usage。这里的关键数据是Private Dirty及Private Clean所指示的内存。它们分别说明了这个进程使用了大概1.4MB左右的非交换页内存而另外150K RAM则是被映射到内存之后将要执行的代码所占用的空间。 了解空进程状态下的内存占用是相当重要的它会随着工作的开始迅速增长。比如下面是一个显示了一些文本的Activity的内存占用情况
** MEMINFO in pid 10226 [com.example.android.helloactivity] **Pss Pss Shared Private Shared Private Heap Heap HeapTotal Clean Dirty Dirty Clean Clean Size Alloc Free------ ------ ------ ------ ------ ------ ------ ------ ------Native Heap 0 0 0 0 0 0 3000 2951 48Dalvik Heap 1074 0 4928 776 0 0 5744 5658 86Dalvik Other 802 0 3612 664 0 0Stack 28 0 8 28 0 0Ashmem 6 0 16 0 0 0Other dev 108 0 24 104 0 4.so mmap 2166 0 2824 1828 3756 0.apk mmap 48 0 0 0 632 0.ttf mmap 3 0 0 0 24 0.dex mmap 292 4 0 0 5672 4Other mmap 10 0 8 8 68 0Unknown 632 0 412 624 0 0TOTAL 5169 4 11832 4032 10152 8 8744 8609 134现在进程使用了刚刚的三倍内存将近4MB只是在UI中展示了一段文本而已。这可以推出一个非常重要的结论如果你将APP的功能放在多个进程中执行只有一个进程用于响应UI而另外的进程则应当避免与UI接触因为这会迅速的增加RAM的消耗。一旦UI被绘制那么几乎就很难将内存的用量降下来。
另外当运行超过一个进程时非常重要的一点是应当使代码尽可能的精简因为任何不必要的开销都是因为相同的实现被复制到了每个进程中。比如如果你正在使用枚举(尽管不应该使用枚举)所有进程的RAM都需要创建并且初始化这些复制到每个进程中的常量其它任何的抽象适配器、常量或者其它占用内存的都会被复制。
使用多进程的另外一个担忧就是它们之间的依赖关系。比如如果APP内含有ContentProvider并且该ContentProvider运行于显示UI的进程那么另一个后台进程的代码需要使用这个ContentProvider时这就需要该UI进程也加载进RAM中。如果你的服务是一个与UI进程相当权重的后台服务那么该服务就不应该依赖UI进程中的ContentProvider或者服务。
