android应用内存,android应用内存最大是多少

如何管理Android手机剩余内存

大家知道要如何管理Android手机剩余内存吗?管理Android手机剩余内存有什么方法?下面一起来看看!

其实大家不用那么在意android手机剩余内存的大小。

很多人都是把使用其他系统的习惯带到了android手机上，不是所有的智能手机系统都一样的。android大多数应用没有退出的设计其实是有道理的，这和系统对进程的调度机制有关系。如果你知道java，就能更清楚这机制了。其实和java的垃圾回收机制类似，系统有一个规则来回收内存。进行内存调度有个阀值，只有低于这个值系统才会按一个列表来关闭用户不需要的东西。当然这个值默认设置得很小，所以你会看到内存老在很少的数值徘徊。但事实上他并不影响速度。相反加快了下次启动应用的速度。这本来也是android的优势之一，如果人为去关闭进程，没有太大必要。特别是自动关进程的软件。

　 　为什么内存少的时候运行大型程序会慢呢?

其实很简单，在内存剩余不多时打开大型程序，会触发系统自身的调进程调度策略，这是十分消耗系统资源的操作，特别是在一个程序频繁向系统申请内存的时候。这种情况下系统并不会关闭所有打开的进程，而是选择性关闭，频繁的调度自然会拖慢系统。

　 　进程管理软件到底还有存在的价值吗?

其实还是有的，在运行大型程序之前，你可以手动关闭一些进程释放内存，可以显著的提高运行速度。但一些小程序，完全可交由系统自己管理。很多朋友还有个疑问，如果不关程序是不是会更耗电?这里也解释一下，android的应用在被切换到后台时，它其实已经被暂停了，并不会消耗cpu资源，只保留了运行状态。所以为什么有的程序切出去重新进入，还会到主界面。但是，一个程序如果想要在后台处理些东西，如音乐播放，它就会开启一个服务，服务可在后台持续运行，所以在后台耗电的也只有带服务的应用了。这个在进程管理软件里能看到，名字是service。所以没有带服务的应用在后台是完全不耗电的，没有必要关闭。这种设计本来就是一个非常好的设计，下次启动程序时，会更快，因为不需要读取界面资源，何必要关掉他们抹杀这个android的优点呢?

为什么android应用看起来那么耗内存?

大家知道，android上的应用是java，当然需要虚拟机，而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机。这样设计的原因是可以避免虚拟机崩溃导致整个系统崩溃，但代价就是需要更多内存。

至于为什么开了大程序或者开了好几个程序之后切换会变慢，具体分析如下:

已经开启了一个大程序，占用70%内存，如果再想运行一个程序，此时还需要50%的内存，则就需要一个从大程序占用的内存中释放或者压缩的过程，所以表现出来的就是慢一会儿。

已经开启了几个程序共占用内存80%，运行新程序时又需要20%的内存，系统内存因为没见过剩余0的时候，也就是应该剩一部分空闲内存，那么就需要从之前开启的这几个程序中选择一个或者几个来关闭，这一过程也需要耗费系统资源，所以会慢一会儿。也就是说你手动去结束程序的时候，就是替系统在释放内存，就算你不去结束，在需要内存的时候系统也会自动结束程序释放内存。

不在后台运行的程序(没服务的)，即使不结束也不会耗电。在后台运行的(有服务的`)程序，如一些播放器或实时监控的软件，自然会耗电。这就说明结束进程并不是没用，我们只需要看哪个带服务耗电哪个程序后台一直在运行，看服务就能看出来，这样的软件如果用不到的时候就结束了吧。

以QQ举例，正常的退出，会在进程管理里留下qq的运行过的状态，但不耗电不占 cpu，如果你只是切换出去(按房子键而不是退出)那么自然会耗电，因为程序还在运行，QQ还在线呢。

这里就有个要注意的地方了，虽然房子键和那个返回键都可以将程序切换出去，但是两者的效果差异是很大的，返回键可以视作程序已经退出了，而按房子键，则是将程序切换到了后台来运行，软件并没有退出哦!

以上这些设计都是为了确保了android的稳定性，正常情况下最多单个程序崩溃，但整个系统不会崩溃，也永远没有内存不足的提示出现。大家可能是被windows毒害得太深了，总想保留更多的内存，但实际上这并不一定会提升速度，相反却丧失了程序启动快的这一系统特色，得不偿失。大家不妨换种观念习惯来使用android系统。

相关问答

Q1: Android如何统计应用占用内存

要获取过去三小时内应用内存占用情况统计信息可以使用如下命令：

会输出应用运行时间百分比，以及PSS(分摊内存大小)，USS(独占内存大小)，RSS（常驻内存大小）（minPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS/minRSS-avgRSS-maxRSS over 样本数）

参考：

Q2: 安卓手机下载软件总是提示内存不足，怎么办？

vivo手机提示内存不足处理方法：

手机运行内存不足：

1、调出后台运行软件，一键加速清理后台；

2、卸载手机中不常用的软件（软件的进程、插件等会占用手机运行内存）；

3、根据手机配置合理运行软件，若手机配置较低，尽量不要运行对配置需求较高的大型游戏；

4、进入手机设置--运存与存储空间--运行内存，开启内存融合，将RAM和ROM融合扩展，没有此选项则代表机型不支持。

手机存储空间不足 ：

1、进入i管家--空间清理/空间管理--扫描并清理垃圾文件；

2、卸载手机中不常用的软件，避免不必要的内存占用；

3、进入文件管理，对手机中的视频、歌曲、压缩包等进行清理；

4、 部分支持SD卡的机型，可选择安装SD卡，将存储在手机中的数据移动到SD卡存储。

手机存储空间足够却提示内存不足 ：

1、重启一下手机，查看是否恢复正常；

2、进入设置--系统管理/更多设置--备份与重置--还原所有设置，该操作会导致登录的第三方软件账号需要重新登录，但不会清除手机存储中的照片，视频等文件，请确认不影响某些第三方软件的使用后再进行还原所有设置操作。 避免操作出现异常导致数据丢失，建议先备份下手机的重要数据；

3、进入i管家--空间清理/空间管理--扫描并清理垃圾缓存；

4、必要时，请先备份好手机中的重要数据，进入设置--系统管理/更多设置--备份与重置--清除所有数据试试。

Q3: 安卓手机运行内存很小的软件为什么占用很大内存？求解决办法

手机运行整个Android系统需要一定的内存，部分系统程序和第三方程序也会开机自启动，所以占用了较多的内存，以致于开机后内存占用率比较高。

若是使用vivo手机，建议您时常一键加速来清理手机运行内存，并进入i管家--（应用管理/软件管理）--权限管理--自启动里面关闭不必要的自启动软件。

Q4: Android系统内存管理

部分内容出至林学森的Android内核设计思想。

Android官网内存管理

部分出至

Android本质是Linux所以先从Linux说起。

Linux的内存管理为系统中所有的task提供可靠的内存分配、释放和保护机制。

核心：

虚拟内存

内存分配与释放

内存保护

将外存储器的部分空间作为内存的扩展，如从硬盘划出4GB大小。

当内存资源不足时，系统按照一定算法自动条形优先级低的数据块，并把他们存储到硬盘中。

后续如果需要用到硬盘中的这些数据块，系统将产生“缺页”指令，然后把他们交换回内存中。

这些都是由操作系统内核自动完成的，对上层应用”完全透明“。

每个进程的逻辑地址和物理地址都不是直接对应的，任何进程都没办法访问到它管辖范围外的内存空间——即刻意产生的内存越界与非法访问，操作系统也会马上阻止并强行关闭程序，从而有力的保障应用程序和操作系统的安全和稳定。

一旦发现系统的可用内存达到临界值，机会按照优先级顺序，匆匆低到高逐步杀掉进程，回收内存。

存储位置：/proc/PID/oom_score

优先级策略：

进程消耗的内存

进程占用的CPU时间

oom_adj（OOM权重）

Android平台运行的前提是可用内存是浪费的内存。它试图在任何时候使用所有可用的内存。例如，系统会在APP关闭后将其保存在内存中，以便用户可以快速切换回它们。出于这个原因，Android设备通常运行时只有很少的空闲内存。在重要系统进程和许多用户应用程序之间正确分配内存内对存管理是至关重要。

Android有两种主要的机制来处理低内存的情况：内核交换守护进程(kernel swap daemon)和低内存杀手(low-memory killer)。

当用户在APP之间切换时，Android会在最近使用的（LRU）缓存中保留不在前台的APP，即用户看不到的APP，或运行类似音乐播放的前台服务。如果用户稍后返回APP，系统将重用该进程，从而使APP切换更快。

如果你的APP有一个缓存进程，并且它保留了当前不需要的内存，那么即使用户不使用它，你的APP也会影响系统的整体性能。由于系统内存不足，它会从最近使用最少的进程开始杀死LRU缓存中的进程。该系统还负责处理占用最多内存的进程，并可以终止这些进程以释放RAM。

当系统开始终止LRU缓存中的进程时，它主要是自底向上工作的。系统还考虑哪些进程消耗更多的内存，从而在终止时为系统提供更多的内存增益。你在LRU列表中消耗的内存越少，你就越有可能留在列表中并能够快速恢复。

为了满足RAM的所有需求，Android尝试共享RAM来跨进程通信。它可以做到以下方式：

Android设备包含三种不同类型的内存：RAM、zRAM和storage。

注意：CPU和GPU都访问同一个RAM。

内存被拆分成页。通常每页有4KB的内存。

页面被认为是空闲的或已使用的。

空闲页是未使用的RAM。

已使用页是系统正在积极使用的RAM，分为以下类别：

干净的页面(Clean pages)包含一个文件（或文件的一部分）的一份精确副本存在存储器上。当一个干净的页面不再包含一个精确的文件副本（例如，来自应用程序操作的结果）时，它就变成了脏页。可以删除干净的页，因为它们始终可以使用存储中的数据重新生成；不能删除脏页(Dirty pages)，否则数据将丢失。

内核跟踪系统中的所有内存页。

当确定一个应用程序正在使用多少内存时，系统必须考虑shared pages。APP访问相同的服务或库将可能共享内存页。例如，Google Play Services 和一个游戏APP可能共享一个位置服务。这使得很难确定有多少内存属于这个服务相对于每个APP。

当操作系统想要知道所有进程使用了多少内存时，PSS非常有用，因为页面不会被多次计数。PSS需要很长时间来计算，因为系统需要确定哪些页面是共享的，以及被有多少进程。RSS不区分共享页面和非共享页面（使计算速度更快），更适合于跟踪内存分配的更改。

内核交换守护进程（kswapd）是Linux内核的一部分，它将使用过的内存转换为空闲内存。当设备上的空闲内存不足时，守护进程将变为活动状态。Linux内核保持低和高的可用内存阈值。当空闲内存低于低阈值时，kswapd开始回收内存。当空闲内存达到高阈值，kswapd将停止回收内存。

kswapd可以通过删除干净的页面来回收干净的页面，因为它们有存储器支持并且没有被修改。如果进程试图寻址已删除的干净页，则系统会将该页从存储器复制到RAM。此操作称为请求分页。

kswapd将缓存的私有脏页(private dirty pages)和匿名脏页(anonymous dirty pages)移动到zRAM进行压缩。这样做可以释放RAM中的可用内存（空闲页）。如果进程试图触摸zRAM中脏页，则该页将被解压缩并移回RAM。如果与压缩页关联的进程被终止，则该页将从zRAM中删除。

如果可用内存量低于某个阈值，系统将开始终止进程。

lmkd实现源码要在system/core/lmkd/lmkd.c。

lmkd会创建名为lmkd的socket，节点位于/dev/socket/lmkd，该socket用于跟上层framework交互。

小结：

LMK_TARGET： AMS.updateConfiguration() 的过程中调用 updateOomLevels() 方法, 分别向/sys/module/lowmemorykiller/parameters目录下的minfree和adj节点写入相应信息；

LMK_PROCPRIO： AMS.applyOomAdjLocked() 的过程中调用 setOomAdj() 向/proc/pid/oom_score_adj写入oom_score_adj后直接返回；

LMK_PROCREMOVE： AMS.handleAppDiedLocked 或者 AMS.cleanUpApplicationRecordLocked() 的过程,调用remove(),目前不做任何事,直接返回；

为了进一步帮助平衡系统内存并避免终止APP进程，可以Activity类中实现ComponentCallbacks2接口。提供的onTrimMemory()回调方法允许APP在前台或后台侦听与内存相关的事件，然后释放对象以响应应用程序生命周期或表明系统需要回收内存的系统事件。

onTrimMemory()回调是在Android 4.0（API级别14）中添加的。

对于早期版本，可以使用onLowMemory()，它大致相当于TRIM_MEMORY_COMPLETE事件。

一个专门的驱动。(Linux Kernel 4.12 已移除交给kswapd处理)。

很多时候，kswapd无法为系统释放足够的内存。在这种情况下，系统使用onTrimMemory()通知APP内存不足，应该减少其分配。如果这还不够，内核将开始终止进程以释放内存，它使用低内存杀手（LMK）来完成这个任务。

为了决定要终止哪个进程，LMK使用一个名为oom_adj_score的“out of memory”分数来确定运行进程的优先级，高分的进程首先被终止。

后台应用程序首先被终止，系统进程最后被终止。

下表列出了从高到低的LMK评分类别。第一排得分最高的项目将首先被杀死：

Android Runtime（ART）和Dalvik虚拟机使用分页（Paging）和内存映射（mmapping）来管理内存。应用程序通过分配新对象或触摸已映射页面来修改内存都将保留在RAM中，并且不能被调出。应用程序释放内存的唯一方式是垃圾收集器。

Q5: Android App内存优化

内存优化就是对内存问题的一个预防和解决，做内存优化能让应用挂得少、活得好和活得久。

挂的少：

“挂”指的是 Crash，内存问题导致 Crash 的具体表现就是内存溢出异常 OOM。

活得好：

活得好指的是使用流畅，Android 中造成界面卡顿的原因有很多种，其中一种就是由内存问题引起的。内存问题之所以会影响到界面流畅度，是因为垃圾回收（GC，Garbage Collection），在 GC 时，所有线程都要停止，包括主线程，当 GC 和绘制界面的操作同时触发时，绘制的执行就会被搁置，导致掉帧，也就是界面卡顿。

活得久：

活得久指的是我们的应用在后台运行时不会被干掉。Android 会按照特定的机制清理进程，清理进程时优先会考虑清理后台进程。清理进程的机制就是LowMemoryKiller。在 Android 中不同的进程有着不同的优先级，当两个进程的优先级相同时，低杀会优先考虑干掉消耗内存更多的进程。也就是如果我们应用占用的内存比其他应用少，并且处于后台时，我们的应用能在后台活下来，这也是内存优化为我们应用带来竞争力的一个直接体现。

内存占用是否越少越好？

当系统 内存充足 的时候，我们可以多用 一些获得更好的性能。当系统 内存不足 的时候，我们希望可以做到 ”用时分配，及时释放“。内存优化并不能一刀切。

我们都知道，应用程序的内存分配和垃圾回收都是由Android虚拟机完成的，在Android 5.0以下，使用的是Dalvik虚拟机，5.0及以上，则使用的是ART虚拟机。

Android虚拟机Dalvik和ART

1、内存区域划分

详细请看以下两篇文章（建议全看）：

java内存四大区_JVM内存区域划分

Android 内存机制

2、内存回收

垃圾收集的标记算法（找到垃圾）：

垃圾收集算法（回收垃圾）：

引用类型：强引用、软引用、弱引用、虚引用

对象的有效性=可达性+引用类型

JAVA垃圾回收机制-史上最容易理解看这一篇就够了

Android：玩转垃圾回收机制与分代回收策略

android中还存在低杀机制，这种情况属于系统整机内存不足，直接把应用进程杀掉的情况。

Android后台杀死系列：LowMemoryKiller原理

1、内存溢出

系统会给每个App分配内存空间也就是heap size值，当app占用的内存加上申请的内存超过这个系统分配的内存限额，最终导致OOM(OutOfMemory)使程序崩溃。

通过命令 getprop |grep dalvik.vm.heapsize 可以获取系统允许的最大

注意：在设置了heapgrowthlimit的状况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，若是要使用大堆，须要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。

关于heapsize heapgrowthlimit

2、内存泄漏

Android系统虚拟机的垃圾回收是通过虚拟机GC机制来实现的。GC会选择一些还存活的对象作为内存遍历的根节点GC Roots，通过对GC Roots的可达性来判断是否需要回收。内存泄漏就是 在当前应用周期内不再使用的对象被GC Roots引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，使实际可使用内存变小。简言之，就是 对象被持有导致无法释放或不能按照对象正常的生命周期进行释放。

Android常见内存泄漏汇总

3、内存抖动

指的是在短时间内大量的新对象被实例化，运行时可能无法承载这样的内存分配，在这种情况下就会导致垃圾回收事件被大量调用，影响到应用程序的UI和整体性能，最终可能导致卡顿和OOM。

常见情况：在一些被频繁调用的方法内不断地创建对象。例如在View 的onDraw方法内new 一些新的对象。

注意内存抖动也会导致 OOM，主要原因有如下两点：

1、Android Studio Profiler

作用

优点

内存抖动问题处理实战

理解内存抖动的概念的话，我们就能明白只要能找到抖动过程中所产生的对象及其调用栈，我们就能解决问题，刚好Android Studio 的Porfiler里面的Memory工具就能帮我们记录下我们操作过程中或静止界面所产生的新对象，并且能清晰看到这些对象的调用栈。

选择Profile 中 的Memory ，选择 Record Java/Kotlin allocations，再点击Record开始记录， Record Java/Kotlin allocations 选项会记录下新增的对象。

操作完成之后，点击如图所示的红脑按钮，停止记录。

停止记录后，我们就可以排序（点击 Allocations可以排序）看看哪些对象或基本类型在短时间被频繁创建多个，点击这些新增的对象就可以看到它的完成的调用链了，进而就找找到导致内存抖动的地方在哪里了。

2、利用DDMS 和 MAT(Memory Analyzer tool)来分析内存泄漏

我们利用工具进行内存泄漏分析主要是用对比法：

a.先打开正常界面，不做任何操作，先抓取一开始的堆文件。

b.一顿胡乱操作，回到原来操作前的界面。主动触发一两次GC,过10秒再抓取第二次堆文件。

c.通过工具对比，获取胡乱操作后新增的对象，然后分析这些新增的对象。

DDMS作用:抓取堆文件，主动触发GC。（其实也是可以用Android Studio 的Profile里面的Memory工具来抓取堆文件的，但是我这边在利用Profile 主动触发gc 的时候会导致程序奔溃，也不知道是不是手机的问题，所以没用Android Studio的Profiler）

MAT作用：对堆文件进行对比，找到多出的对象，找到对象的强引用调用链。

以下是详细的过程：

步骤1.打开DDMS,选择需要调试的应用，打开初始界面，点击下图的图标（Dump Hprof File）先获取一次堆文件。

步骤2.对应用随便操作后，回到一开始的界面，先多触发几次GC ，点击下图的图标(Cause Gc)来主动触发GC,然后再次点击 Dump Hprof File 图标来获取堆文件。

步骤3.通过Android Studio Profile 或者 DDMS dump 的堆文件无法在MAT 打开，需要借助android sdk包下的一个工具hprof-conv.exe来转换。

格式为 hprof-conv 旧文件路径名 要转换的名称；

例如：hprof-conv 2022-04-13_17-54-40_827.hprof change.hprof

步骤4.把两份堆文件导入MAT,然后选择其中第二次获取的堆文件，点击 如图所示的 Histogram查看。

步骤5.点击下图图标，Compare To Another Heap Dump ,选择另一份堆文件。

6.会得出下图所示的 Hitogram 展示，我们主要看Objects 这一列。 如下图所示 “+ 2” 则代表前面两份堆文件对比，这个对象多了两个，我们主要就是要分析这些多了出来，没有被回收的对象。

7.加入我们从增加的对象中，看到了MainActivity ，则需要从一开始打开的Hitogram 展示里面找到这个对象的调用栈。如下图所示，搜索MainActivity

8.看到下图所示解雇，然后鼠标右键点击下图红色圈圈着的MainActivity ,选择 Merger Shortest Paths to Gc Roots ，再选择 exclude all phantom/weak/soft etc.references ,就可以看到这个MainActivity 对象的强引用链，至此我们就可以找到MainActivity对象是被什么引用导致无法回收了。

3、内存泄露检测神器之LeakCanary（线下集成）

自行学习了解，接入简单，使用简单，基本可以解决大部分内存泄漏问题。

github地址 ：

学习地址 ：

针对内存抖动的建议：

针对内存泄漏问题的建议：

针对内存溢出问题的建议（主要就是要减少内存占用）：

建议参考：

深入探索 Android 内存优化（炼狱级别）

对于 优化的大方向，我们应该优先去做见效快的地方，主要有以下三部分：内存泄漏、内存抖动、Bitmap。完善监控机制也是我们的重点，能帮助我们对内存问题快速分析和处理。

参考：

深入探索 Android 内存优化（炼狱级别）