.so mmap计算工具内存翻倍现象

作者：admin
/
时间：2小时前
/
浏览：14 次
/
分类：厚积薄发

1）.so mmap计算工具内存翻倍现象
2）iOS报告中的Low Memory是如何被促发的

这是第461篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

From 问答社区

Q：结合UWA DAY分享的.so mmap内存分析流程，我发现在我们项目中libil2cpp.so有个奇怪的现象，想要问问大家是否知道是怎么一回事：

这里列出来libil2cpp.so占据了4段内存，其中第一段：770e779000-771c606000，和第二段开始到第四段结束地址（78bfac9000-78cd956000）的内存容量完全一致。而且，命令结果显示它们映射到的文件以及offset也都完全一致。我高度怀疑这两段内存的内容也是一致的，很有可能是两段虚拟内存映射到同一段物理内存。但是这个情况只有libil2cpp符合，libunity并不符合。包括我用后来我们打的包，执行同样命令，分析结果，还是符合这个现象。这是否意味着libil2cpp的内存占用实际上是上面统计值的一半？

补充一点：我用我们自己打的包，查看proc/pid/maps，结合readelf命令，发现后面三个段已经映射了所有libil2cpp中的LOAD段了。

附：包含文中提到的“.so mmap内存分析流程”的课程：
Unity移动游戏性能优化全解析与小游戏转化的实战经验

A：试了几个不同的包，有的确实会出现第一段等于后面几段之和的情况：

也有几段互不相同没有加和关系的情况。这两种包的运行时数据和拆包得到的so硬盘占用大小也都基本对得上：

这是因为，UWA DAY PPT中用来计算内存的Python代码会粗暴地计算所有地址的插值并无脑求和，如下图：

但在出现”第一段等于后面几段之和的情况”的包中，前两段的Offset都是偏移0，此时不能强行求和。可以考虑根据这种规律调整代码或人为重新算一下就对了：

欢迎大家转至社区交流：
https://answer.uwa4d.com/question/696ddb25244ce21ce9ec096f

From UWA AI 问答

Q：iOS平台上[UIApplicationDelegate applicationDid ReceiveMemoryWarning]调用只在1.8GB左右频繁触发，内存更高以后反而触发率降低了，是什么原因？

A：该现象符合iOS内存管理机制的分层压力响应策略，根本原因在于：applicationDidReceiveMemoryWarning并非在内存使用达到绝对阈值时触发，而是由系统基于当前可用内存余量、后台进程竞争状态及设备实际内存压力动态判定的“相对性警告”。

具体解释如下：
1. 触发逻辑本质是“内存压力等级”，而非“绝对用量”
iOS不以固定内存值（如1.8GB）为硬触发点，而是通过vm_pressure_level监控全局内存压力。当系统检测到：

可用内存页急剧减少（尤其活跃/非换页内存不足）；

后台App被大量驱逐释放内存；

文件缓存或压缩内存已达上限；
→ 系统向前台应用发送applicationDidReceiveMemoryWarning，提示其主动降载。

2. 1.8GB 高频触发的典型场景
此区间常对应：

应用已加载大部分资源（纹理、Mesh、Audio），但尚未触发Unity的Resources.UnloadUnusedAssets()或AssetBundle卸载；

原生堆（Native Heap）与托管堆（Mono Heap）持续增长，GLES驱动内存池（如MTL/OpenGL纹理缓存）接近饱和；

系统仍保留一定后台缓冲空间，此时压力信号敏感且频繁。

3. 更高内存（如>2.2GB）后触发率下降的合理原因
⚠️ 并非系统“变宽松”，而是进入更危险阶段：

系统已启动强制干预：终止后台App、压缩inactive pages、回收文件缓存；

若应用继续申请内存，不再发送警告，直接触发SIGKILL（OOM Killer）；

此时applicationDidReceiveMemoryWarning反而减少 —— 因系统已无“协商余地”，转向静默强杀。

验证与优化建议

使用Xcode Instruments → Activity Monitor查看Real Memory + Pressure Level曲线，确认是否伴随vm: pressure上升；

在OnLowMemory回调中立即执行：

Resources.UnloadUnusedAssets() + Texture2D.DestroyImmediate()清理未引用纹理；

切换至低配资源（如ASTC 4x4替代8x8）；

持久化关键游戏状态（防被杀丢档）；

限制峰值内存：通过UWA GOT Online的GPU/Resource/Mono报告，定位内存大户（如超大图集、未卸载AB、Mono GC堆膨胀）。

该行为是 iOS 内存保护机制的正常表现，高频警告恰说明应用处于“可挽救临界区”，需优先优化资源生命周期管理。

可以参考以上AI回答。而且实际上看起来这个警告只在1.8GB左右触发，也即内存更高时反而不触发的原因。