android内存存储

A. 瀹夊崜8.0闇瑕佸氩ぇ镄勮繍琛屽唴瀛桦拰瀛桦偍绌洪棿锛

瀹夊崜8锛0涓嶅瓨鍦ㄩ渶瑕佺壒瀹氱殑杩愯屽唴瀛鍜屽瓨鍌ㄧ┖闂淬傚彧瑕佹槸瀹夊崜绯荤粺镄勬櫤鑳芥坠链洪兘鍙浠ュ畨瑁呫

android8锛0鏄璋锋瓕锛圙oogle锛夋帹鍑虹殑鏅鸿兘镓嬫満镎崭綔绯荤粺锛2017骞3链21镞Google涓哄紑鍙戣呮帹鍑轰简鏂扮殑AndroidO棣栦釜寮鍙戣呴勮堢増锛2017GoogleI锛廜寮鍙戣呭ぇ浼氢笂鍙戝竷浜嗙浜屼釜AndroidO寮鍙戣呴勮堛

2017骞8链22镞ワ纴璋锋瓕姝ｅ纺鍙戝竷浜咥ndroid8锛0镄勬ｅ纺鐗堬纴鍏舵ｅ纺钖岖О涓猴细AndroidOreo锛埚ゥ鍒╁ゥ锛夈2017骞12链5镞ヨ胺姝屾ｅ纺鍙戝竷浜咥ndroid8锛1镄勬ｅ纺鐗堛

镓╁𪾢璧勬枡锛

Android8锛0镄勯厤阃傛満鍨嬶细

璋锋瓕瀹ｅ竷锛屽畨鍗8鍒濇湡浠呭悜钬滃畨鍗揿紑婧愯″垝钬濓纸Android Open Source Project锛夌殑鐢ㄦ埛寮鏀撅纴瀵硅胺姝岀殑Pixel鍜孨exus镓嬫満鐢ㄦ埛鍦ㄤ笉涔呯殑灏嗘潵涔熷皢寮鏀炬洿鏂般傚叾浠栧搧鐗岀殑鏅鸿兘镓嬫満鍜骞虫澘鐢佃剳鍒栾佸彇鍐充簬灏忕背銆佷笁鏄熴佸崕涓哄拰OnePlus绛夌‖浠跺埗阃犲晢銆

姝ｅ纺鐗圆ndroid8锛0灏嗗緢蹇鎺ㄩ佺粰Pixel鍜孨exus璁惧囷纴绗涓镓规敮鎸丄ndroid8锛0镄勪骇鍝佸垎鍒涓篜ixel銆丳ixelXL銆丳ixelC銆丯exus6P銆丯exus5X浠ュ强NexusPlayer銆

鍙傝冭祫鏂欙细锏惧害锏剧-瀹夊崜8.0

B. android 鍐呭瓨鏁版嵁瀛桦偍鏂瑰纺鍜寃indows镄勫尯鍒

瀛桦偍绌洪棿涓链変袱涓鍐呭瓨钬濓细RAM鍜孯OM銆傚叾涓锛孯AM灏辨槸杩愯屽唴瀛桡纴灏卞ソ浼糚C涓镄勫唴瀛樻浔锛涜孯OM灏辨槸澶瑙嗙偖杞扮殑瀛桦偍绌 闂达纴鐩稿綋浜嶱C涓镄勭‖鐩樸 钥孯OM鍒嗕负涓変釜鍒嗗尯锛 绯荤粺鍒嗗尯----鐢ㄤ簬瀛樻斁Android绯荤粺 (Android4.x鐗堢郴缁熻呖灏500MB浠ヤ笂)銆佽缮铡熷囦唤(300MB宸﹀彸)銆佸埛链篟ecovery璧勬簮(绾20MB锝50MB)銆佺郴缁熺骇APP(瀹 瑁呭湪姝ょ┖闂寸殑APP闇瑕丷oot𨱒冮檺镓嶅彲鍗歌浇)浠ュ强浜ゆ崲绌洪棿銆佺‖浠跺簳灞傜┖闂寸瓑绛夛纴锷犲湪涓璧风害1.5GB锝2GB銆傝繖閮ㄥ垎绌洪棿灏卞ソ浼糚C涓婂畨瑁呭湪C鐩树腑镄 Windows绯荤粺鍜岀‖浠堕┍锷ㄧ▼搴忥纴浠ュ强鐢ㄤ簬瀛樻斁涓阌鎭㈠嶉暅镀忕殑闅愯棌鍒嗗尯銆 銆銆绋嫔簭鍒嗗尯----鐢ㄤ簬瀛樻斁闅忔満棰勮呯殑绗涓夋柟 APP(鐢ㄦ埛鍙鍗歌浇)锛屼綘镊宸变笅杞界殑镓链堿PP涓荤▼搴忛兘浼氩畨瑁呭埌杩欎釜绌洪棿鍐咃纴镓嬫満铡傚晢阃氩父浼氢负姝ゅ垎鍖洪勭暀1GB锝3GB镄勫瓨鍌ㄧ┖闂淬傚綋璇ョ┖闂磋鍗犳弧钖庯纴浣 鍐嶅畨瑁匒PP镞朵细鍑虹幇镞犵┖闂村畨瑁呯殑鎶ラ敊鎻愮ず銆傛垜浠鍙浠ュ皢鍏剁悊瑙ｄ负PC C鐩橀噷镄勨淧rogram Files钬濇枃浠跺す锛屽彧鏄浣犳墍瀹夎呯殑镓链夌▼搴忛粯璁ゅ彧鑳藉畨瑁呬簬姝や笖镞犳硶淇鏀硅矾寰勚傗灭郴缁熷垎鍖猴纭绋嫔簭鍒嗗尯钬濈殑镐诲拰灏辨槸鐢佃剳C鐩樼殑鍏ㄩ儴绌洪棿銆 銆銆瀛桦偍鍒嗗尯----杩欐墠鏄褰撴坠链鸿繛鎺PC钖庢墍璇嗗埆 鍑烘潵镄勨灭Щ锷ㄧ‖鐩樷濓纴灏忕背3镄12.38GB鍜岃仈𨱍矺900镄7.88GB灏辨槸瀛桦偍鍒嗗尯銆傝繖閮ㄥ垎绌洪棿鍙浠ョ敱鐢ㄦ埛镊鐢辨敮閰嶏纴鍙瀛樻斁澶у瀷娓告垙镄勬暟鎹鍖呫侀煶涔愩 锲剧墖銆佽嗛戯纴鍙镀废鐩树竴镙烽殢镒忔姌鑵俱傛崲锅歅C棰嗗烟锛屽瓨鍌ㄥ垎鍖哄氨濂戒技D鐩樸丒鐩樸丗鐩樼瓑闱炵郴缁熷垎鍖恒 绯荤粺鍒嗗尯鍜岀▼搴忓垎鍖猴纴铏界劧镞犳硶琚鐢ㄦ埛鐩存帴鍒╃敤锛屼絾鍗存圹𨰾呯潃闱炲父閲嶈佺殑瑙掕壊銆

C. android系统大概占多大的内存那

不是的。不知楼主说的是内存卡还是手机内存。首先要说明，卡上说的是8G，实际只能用7G多。因为生产厂家采用1000为单位，而手机读取采用1024未单位，所以有误差。我的android 手机由于有导航，导航占用了1.5G多。实际系统文件只有几百M。

D. Android系统内存管理

部分内容出至林学森的Android内核设计思想。
Android官网内存管理
部分出至 https://www.jianshu.com/p/94d1cd553c44

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/mole/lowmemorykiller/parameters目录下的minfree和adj节点写入相应信息；
LMK_PROCPRIO： AMS.applyOomAdjLocked() 的过程中调用 setOomAdj() 向/proc/<pid>/oom_score_adj写入oom_score_adj后直接返回；
LMK_PROCREMOVE： AMS.handleAppDiedLocked 或者 AMS.() 的过程,调用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中，并且不能被调出。应用程序释放内存的唯一方式是垃圾收集器。