App 内存优化
共 6774字,需浏览 14分钟
·
2024-04-11 10:59
和你一起终身学 习,这里是程序员Android
经典好文推荐,通过阅读本文,您将收获以下知识点:
一、App内存优化概述一、App内存优化概述
二、监视可用内存和内存使用情况
三、合理的释放内存
四、分析App需要用多少内存
五、使用内存优化框架
六、移除内存密集型资源,以及lib库
随机存取存储器(RAM)
在任何软件开发环境中都是非常有价值的资源,但对于物理内存经常受到限制的移动操作系统来说,它更有价值。尽管Android运行时(ART
)和Dalvik虚拟机
都执行常规垃圾收集,但这并不意味着您可以忽略应用程序分配和释放内存的时间和位置。您仍然需要避免引入内存泄漏,这些通常由静态成员变量中的对象引用引起,并在生命周期回调定义的适当时间释放任何引用对象。
本页面介绍了如何主动减少应用程序中的内存使用量。有关Android操作系统如何管理内存的信息,请参阅Android内存管理概述
二、监视可用内存和内存使用情况在修复解决APP
中的内存使用问题之前,首先需要找到它们。 Android Studio
中的内存分析器Memory Profiler
可以帮助您通过以下方式查找和诊断内存问题:
1 . 查看App如何分配内存。
Memory Profiler
显示了一个实时图,显示您的应用程序使用了多少内存,分配了Java
对象的数量以及何时发生垃圾回收。
2. 记录GC快照
启动垃圾收集事件并在运行应用程序时抓取Java堆的快照。
3.记录您的应用程序的内存分配
然后检查所有分配的对象,查看每个分配的堆栈跟踪,然后跳转到Android Studio
编辑器中的相应代码。
Android可以通过多种方式从您的应用程序中回收内存,或者在必要时将应用程序彻底关闭以释放内存以用于关键任务。为了进一步帮助平衡系统内存,避免系统需要终止应用程序进程,可以在Activity
类中实现ComponentCallbacks2
接口提供的onTrimMemory()
回调方法,从而允许您的应用程序在处于前台或后台时侦听与内存相关的事件,然后释放对象以响应应用程序生命周期,或者指示系统需要回收内存的系统事件。
例如,您可以实现onTrimMemory()
回调以响应不同的内存相关事件,如下所示:
import android.content.ComponentCallbacks2;
// Other import statements ...
public class MainActivity extends AppCompatActivity
implements ComponentCallbacks2 {
// Other activity code ...
/**
* Release memory when the UI becomes hidden or when system resources become low.
* @param level the memory-related event that was raised.
*/
public void onTrimMemory(int level) {
// Determine which lifecycle or system event was raised.
switch (level) {
case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN:
/*
Release any UI objects that currently hold memory.
The user interface has moved to the background.
*/
break;
case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:
case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL:
/*
Release any memory that your app doesn't need to run.
The device is running low on memory while the app is running.
The event raised indicates the severity of the memory-related event.
If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
begin killing background processes.
*/
break;
case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:
/*
Release as much memory as the process can.
The app is on the LRU list and the system is running low on memory.
The event raised indicates where the app sits within the LRU list.
If the event is TRIM_MEMORY_COMPLETE, the process will be one of
the first to be terminated.
*/
break;
default:
/*
Release any non-critical data structures.
The app received an unrecognized memory level value
from the system. Treat this as a generic low-memory message.
*/
break;
}
}
}
onTrimMemory()
回调方法是在Android 4.0
时候添加的,之前版本请用onLowMemory()
方法,跟TRIM_MEMORY_COMPLETE
事件处理一样。
为了允许多个正在运行的进程,Android
为每个应用程序分配的堆大小设置了硬限制。确切的堆大小限制根据设备有多少总体可用RAM
不同而有所不同。如果您的应用程序已达到堆容量并尝试分配更多内存,则系统将引发OutOfMemoryError
。
为了避免OutOfMemoryError
内存不足,可以查询系统以确定当前设备上有多少可用的堆空间。你可以通过调用getMemoryInfo()
来查询这个数字。这将返回一个ActivityManager.MemoryInfo
对象,该对象提供有关设备当前内存状态的信息,包括可用内存,总内存以及内存阈值(即系统开始中断进程的内存级别)。 ActivityManager.MemoryInfo
对象还暴露了一个简单的布尔值,lowMemory
,可以判断你设备是否在低内存下运行。
如下例子,举例使用getMemoryInfo()
public void doSomethingMemoryIntensive() {
// Before doing something that requires a lot of memory,
// check to see whether the device is in a low memory state.
ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();
if (!memoryInfo.lowMemory) {
// Do memory intensive work ...
}
}
// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(memoryInfo);
return memoryInfo;
}
五、使用内存优化框架
一些Android
功能,Java类和代码构造倾向于使用比其他更多的内存。您可以通过在代码中选择更有效的替代方法来最大限度地减少应用程序使用的内存量
1. 谨慎使用Services
在不需要Services的情况下运行Services,是造成最严重的内存管理错误之一。
如果你的应用程序需要一个Services来在后台执行工作,那么除非它需要运行一个后台任务,否则不要让它保持运行。记得在完成任务时停止Services。否则,您可能会无意中造成内存泄漏。
当你启动一个Services时, 系统需要始终保持运行该Services的进程。此行为使得Services进程非常昂贵,因为Services使用的RAM对其他进程仍然不可用。这样可以减少系统在LRU缓存中
保留的缓存进程的数量,从而降低应用程序切换的效率。内存不足时系统甚至可能导致系统崩溃,系统无法维护足够的进程来承载当前运行的所有服务。
您通常应该避免使用持久性Persistent Services
,因为这些服务会常驻系统内存。相反,我们建议您使用诸如JobScheduler
之类的替代实现。有关如何使用JobScheduler
安排后台进程的更多信息,请参阅后台优化。
如果您必须使用服务,那么限制服务使用寿命的最好方法就是使用IntentService
,一旦完成了处理启动它的意图,IntentService
就会自动完成。有关更多信息,请阅读在后台服务中运行。
2.使用更优化的数据容器
编程语言提供的某些类未针对在移动设备上使用进行优化。例如,通用的HashMap
实现可能是相当低效的内存,因为每个映射都需要单独的入口对象。
Android
框架包括几个优化的数据容器,包括SparseArray
,SparseBooleanArray
和LongSparseArray
。例如,SparseArray
类更有效率,因为它们避免了系统需要自动复制密钥的情况,有时还需要创建另外一个或两个对象。
如有必要,您可以随时切换到原始数组以获得精简的数据结构。
3.使用nano protobufs进行序列化数据
协议缓冲区是一种语言中立,平台无关,可扩展的机制,由Google设计
,用于序列化结构化数据 - 类似于XML
,但更小,更快,更简单。如果你决定为你的数据使用protobufs
,你应该总是在你的客户端代码中使用nano protobufs
。经常protobufs
生成非常详细的代码,这可能会导致您的应用程序中的许多种问题,如增加的RAM
使用,APK
大小增加,和较慢的执行。
有关更多信息,请参阅protobuf自述文件中的“Nano版本”部分
。
4.避免内存泄漏
如前所述,垃圾收集事件通常不会影响您的应用程序的性能。但是,很多短时间内发生的垃圾收集事件可能会很快消耗掉你的帧时间。系统花费在垃圾收集上的时间越多,执行其他内容(如渲染或流式传输音频)的时间就越少。
内存流失通常会导致大量的垃圾收集事件发生。在实践中,内存流失描述了在给定的时间内发生的分配的临时对象的数量。
例如,您可以在for
循环中分配多个临时对象。或者您可以在视图的onDraw()
函数内创建新的Paint
或Bitmap
对象。在这两种情况下,应用程序都会以大批量快速创建大量对象。这些可能会迅速消耗年轻一代中的所有可用内存,从而迫使垃圾收集事件发生。
当然,你需要在你的代码中找到内存流失高的地方,然后才能修复它们。为此,您应该在Android Studio
中使用Memory Profiler
。
你的代码中的一些资源和库可以在你不知道的情况下吞噬内存。您的APK
的整体大小(包括第三方库或嵌入式资源)可能会影响您的应用消耗的内存量。您可以通过从代码中删除冗余,不必要或臃肿的组件,资源或库来改善应用程序的内存消耗。
1.减小APK的大小
您可以通过减少应用程序的整体大小来显着减少应用程序的内存使用量。比如:bitmap大小,res资源,动画帧数以及第三方库都可以影响APK
的大小。 Android Studio
和Android SDK
提供了多种工具来帮助您减少资源和外部依赖的大小。
有关如何减少您的整体APK
大小的更多信息,请参阅缩小APK
大小。
2.使用Dagger 2进行依赖注入
依赖注入框架可以简化您编写的代码,并提供适用于测试和其他配置更改的自适应环境。
如果您打算在应用程序中使用依赖项注入框架,请考虑使用Dagger 2
. Dagger 2
不使用反射来扫描您的应用程序的代码。Dagger的静态编译实现,意味着它可以在Android
应用程序中使用,而无需增加运行成本或内存使用。
其他使用反射的依赖注入框架倾向于通过扫描代码来注释来初始化进程。这个过程可能需要更多的CPU
周期和内存,并且在应用程序启动时会引起明显的滞后。
3.谨慎使用外部库
外部库代码通常不是针对移动环境编写的,而且在用于移动客户端时可能效率低下。当您决定使用外部库时,您可能需要为移动设备优化该库。预先计划好这个工作,然后根据代码大小和内存占用情况来分析这个库,然后才决定使用它。
即使一些移动优化的库可能由于不同的实现而导致问题。例如,一个库可能使用nano protobufs
,而另一个库使用微型protobufs
,导致您的应用程序中有两个不同的protobuf
实现。这可能发生在不同的日志记录,分析,图像加载框架,缓存以及许多您不希望的事情上。
尽管ProGuard
可以帮助您使用正确的标志删除API
和资源,但它不能删除库的大型内部依赖关系。您需要在这些库中的功能可能需要较低级别的依赖关系。如果库使用反射,这是常见的,并且意味着您需要花费大量时间手动调整ProGuard
才能使用反射,那么当您从库中使用Activity子类时,这往往会产生大量的依赖关系工作等等。
至此,本篇已结束。转载网络的文章,小编觉得很优秀,欢迎点击阅读原文,支持原创作者,如有侵权,恳请联系小编删除。同时感谢您的阅读,期待您的关注。
点个在看,方便您使用时快速查找!