Android是如何管理App内存的--Android内存优化第二弹

cover

引言

前文我们普及了下关于GC的一些事, 对GC的一些个概念, 流程有个大概的了解. 在Application的启动流程一文中, 我们有提到, Android中每个App默认情况下是运行在一个独立进程中的, 而这个独立进程正是从Zygote孵化出来的VM进程. 也就是说, 每个App是运行在独立的VM空间的. 那么Android是怎么管理这些App的内存的呢, 这些独立运行的VM中的内存管理又是怎样的呢?

今天我们就来聊下Android中的内存管理.

1, Dalvik & ART

Android在4.4之前一直使用的Dalvik虚拟机作为App的运行VM的, 4.4中引入了ART作为开发者备选, 5.0起正式将ART作为默认VM了.

我们首先来简单了解下二者:

1.1 Dalvik

如果只是想简单了解, 个人觉得百度百科上这个Dalvik的介绍基本就满足要求了.

如果大家想深入, 可以看下老罗的Android之旅Dalvik的相关博文, 从代码层面上分析了Dalvik的启动, 运行机制等. 值得一看.

需要说明的是, Dalvik采用的是JIT技术, 在应用程序启动时, JIT通过进行连续的性能分析来优化程序代码的执行, 在程序运行的过程中, Dalvik在不断的进行将字节码编译成机器码的工作.

1.2 ART

ART 取自 Android RunTime. Android用其取代Dalvik, 主要目的就是为了提升运行性能. 所以, ART相比Dalvik有几个关键的提升:

引入AOT(ahead-of-time)预编译技术

在安装apk的过程中, ART会使用dex2oat程序所有的字节码预编译成了机器码. 应用程序运行过程中无需进行实时的编译工作, 只需要进行直接调用. 故而提高了应用程序的运行效率.

GC效率

  • 由原来的两次GC暂停减少为一次.
  • 以较少的GC时间回收最近分配的, 短命的对象.
  • 提升GC工程学, 使并发GC更及时.
  • 压缩GC, 以减少后台内存使用和内存碎片.

开发和调试

  • 支持内存/方法执行的采样分析.
  • 支持更多的调试技.
  • 在Crash report中提供更多信息.

2, Android的内存管理方式

ART和Dalvik都是使用pagingmemory-mapping(mmapping)来管理内存的. 这就意味着, 任何被分配的内存都会持续存在, 唯一的释放这块内存的方式就是释放对象引用(让对象GC Root不可达), 故而让GC程序来回收内存.

2.1 App的内存分配和回收

对于每个App进程来说, Heap内存被限制在一个虚拟的内存区间内. 且定义了逻辑上的使用的Heap Size, 这个Heap Size在系统限制的最大值之内是随着应用的使用情况而变化的.

Heap内存的逻辑大小和实际物理内存的大小是不相同的. 后面我们在使用Memory Monitor等内存分析工具分析内存时, 会看到一个叫做Proportional Set Size (PSS)的值, 这个值才是系统认为的你的App所占用的物理内存大小.

这个PSS值也就是实际物理内存大小, 统计包括了你的应用进程所占用的内存大小, 和共享内存中占用的内存大小(比例分配方式计算).

Android VM不会压缩Heap内存的逻辑大小, 故而无法通过碎片整理的方式来释放Heap空间, 而只能通过回收Heap尾部的空内存块来压缩逻辑内存大小.

这时, 我们的GC就出场了, GC之后, VM会遍历Heap找到不被使用的pages, 通过madvise函数将其返回给内核, 从而释放这块被逻辑Heap使用的物理内存.

2.2 App内存限制

Android是一个多任务系统, 为了保证多任务的运行, Android给每个App可使用的Heap大小设定了一个限定值.

这个值是系统设置的prop值, 系统编译时内置的, 保存在system/build.prop中. 一般国内的手机厂商都会做修改, 根据手机配置不同而不同, 可以通过如下命令查看:

$ adb shell
shell@hwH60:/ $ cat /system/build.prop

以手头的Huawei 荣耀6为例, heap size相关的prop如下:

dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

其中:

dalvik.vm.heapstartsize

-- App启动后, 系统分配给它的Heap初始大小. 随着App使用可增加.

dalvik.vm.heapgrowthlimit

-- 默认情况下, App可使用的Heap的最大值, 超过这个值就会产生OOM.

dalvik.vm.heapsize

-- 如果App的manifest文件中配置了largeHeap属性, 如下.则App可使用的Heap的最大值为此项设定值.

<application
    android:largeHeap="true">
    ...
</application>

dalvik.vm.heaptargetutilization

-- 当前理想的堆内存利用率. GC后, Dalvik的Heap内存会进行相应的调整, 调整到当前存活的对象的大小和 / Heap大小 接近这个选项的值, 即这里的0.75. 注意, 这只是一个参考值.

dalvik.vm.heapminfree

-- 单次Heap内存调整的最小值.

dalvik.vm.heapmaxfree

-- 单次Heap内存调整的最大值.

也可以直接使用getprop查看单项prop:

$ adb shell getprop dalvik.vm.heapsize
512m

2.3 切换App时的内存管理机制

Android的进程级别

Android 系统会尽可能长时间地保持应用进程, 但为了新建进程或运行更重要的进程, 最终需要清除旧进程来回收内存. 为了确定保留或终止哪些进程, 系统会根据进程中正在运行的组件以及这些组件的状态, 将每个进程设定了一个重要级别. 必要时, 系统会首先消除重要性最低的进程, 然后是重要性略低的进程, 依此类推, 以回收系统资源.

依据重要程度从大到小依次分为5级:

前台进程

用户当前操作所必需的进程. 如果一个进程满足以下任一条件, 即视为前台进程:

  • 托管用户正在交互的 Activity(已调用 Activity 的 onResume() 方法)
  • 托管某个 Service,后者绑定到用户正在交互的 Activity
  • 托管正在“前台”运行的 Service(服务已调用 startForeground())
  • 托管正执行一个生命周期回调的 * Service(onCreate()、onStart() 或 onDestroy())
  • 托管正执行其 onReceive() 方法的 BroadcastReceiver

只有在内在不足以支持它们同时继续运行这一万不得已的情况下,系统才会终止它们。 此时,设备往往已达到内存分页状态,因此需要终止一些前台进程来确保用户界面正常响应。

可见进程

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。 如果一个进程满足以下任一条件,即视为可见进程:

  • 托管不在前台、但仍对用户可见的 Activity(已调用其 onPause() 方法)。例如,如果前台 Activity 启动了一个对话框,允许在其后显示上一 Activity,则有可能会发生这种情况
  • 托管绑定到可见(或前台)Activity 的 Service
    可见进程被视为是极其重要的进程,除非为了维持所有前台进程同时运行而必须终止,否则系统不会终止这些进程。

服务进程

正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联,但是它们通常在执行一些用户关心的操作(例如,在后台播放音乐或从网络下载数据)。因此,除非内存不足以维持所有前台进程和可见进程同时运行,否则系统会让服务进程保持运行状态。

后台进程

包含目前对用户不可见的 Activity 的进程(已调用 Activity 的 onStop() 方法)。这些进程对用户体验没有直接影响,系统可能随时终止它们,以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行,因此它们会保存在 LRU (最近最少使用)列表中,以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法,并保存了其当前状态,则终止其进程不会对用户体验产生明显影响,因为当用户导航回该 Activity 时,Activity 会恢复其所有可见状态。

空进程

不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存,以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡,系统往往会终止这些进程。

切换App的内存管理

当用户切换App时, 被切换到后台的App所使用的内存并未因此删除, 该App进程被缓存到一个LRU缓存中, 以便用户切换回来时, 能更快的启动App, 让多任务更流畅.

但是, 当系统内存不够用的时候, 就会根据LRU特性, 以及上面说到的进程级别(同时也会考虑该App进程占用的内存大小)来决定杀死哪些进程, 来回收内存, 以便执行当前任务.

所以, 如果我们为了不要让系统kill掉我们的App, 可以从进程级别, 内存消耗量等几个方面进行优化.

结语

本文加上GC那些事儿, 我们讲了两篇的理论知识, 相信大家对Android的内存管理有了个大体的了解, 后面将介绍一些内存分析工具以及使用, 结合实际来说明怎么分析内存问题.

参考


转载请注明出处, 欢迎大家分享到朋友圈, 微博~

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,530评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,403评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,120评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,770评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,758评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,649评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,021评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,675评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,931评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,751评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,410评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,004评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,969评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,042评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,493评论 2 343

推荐阅读更多精彩内容