此问题可能与Android或Linux有关。如果您不熟悉Android，那么让我首先简单介绍一下init和bootanimation。 Android初始化与Linux初始化相同。这是用户空间中的第一个过程。 pid为1。初始化过程将执行init.rc中定义的一些系统初始化。初始化之一是启动动画。它由名为bootanimation的进程播放。引导动画是一个本地过程。它使用OpenGL ES播放动画。引导动画通常由包含数十个或数百个静态图像的zip文件描述。以一定的速率播放它们会变成动画。
现在奇怪的问题来了。它与初始化进程的内存占用有关。在干净的Android 8.1.0系统中，init占用的内存超过40M +。我们可以通过adb shell命令'dumpsys meminfo init'找到分配细节。
Pss
Total
------
Native Heap 1076
Dalvik Heap 0
Stack 16
Other dev 363
Other mmap 333
EGL mtrack 10040
GL mtrack 29170
Unknown 32
TOTAL 41030
我们可以看到与图形相关的EGL / GL占用了大部分内存。通常，init是一个后端过程。它与图形无关。那么为什么图形相关的内存占用最多。我能弄清楚的与图形有关的唯一东西是启动动画。如上所述，它是通过init进程启动/派生的。所以我做了一些测试。如果我禁用启动动画，则init的内存占用确实减少了很多，降至约20M。我也做了其他测试。我试图修改引导动画的源代码以加载和渲染单个图像，而不是数百个图像。 init的内存占用也减少了很多。这意味着init的内存占用与引导动画加载的图像数量有关。我做了进一步的测试，发现通过init进行引导动画处理后，init的内存占用将减少很多。似乎内存已从init转移到其子进程引导动画。
接下来是我的最后一个问题：作为子进程，引导动画为什么会影响其父进程的内存占用？引导动画过程退出时，是否不应该释放所有占用的资源？
额外注释：尽管就我而言，当进程退出时，应释放所有资源。并且由Google编写的android源代码应经验丰富且没有错误。我仍然对引导动画中的资源泄漏感到怀疑。 Bootanimation使用Skia库中的SkBitmap加载图像并使用OpenGL ES 1.0纹理进行渲染。我确认如果没有错误确认，SkBitmap和OpenGL纹理将被正确破坏。你们可能对相关的android源代码感兴趣。
在引导动画中播放动画的核心代码： http://androidxref.com/8.1.0_r33/xref/frameworks/base/cmds/bootanimation/BootAnimation.cpp#862 加载图像的代码： http://androidxref.com/8.1.0_r33/xref/frameworks/base/cmds/bootanimation/BootAnimation.cpp#190 在init中启动引导动画的代码： http://androidxref.com/8.1.0_r33/xref/system/core/init/service.cpp#688
感谢您的所有回答，建议和评论。
答案 0 :(得分：0)
经过一系列新的测试和代码阅读，我发现了一些新东西。我将添加一些新评论。这个问题与init无关。该问题与 dumpsys meminfo 的实现有关。 dumpsys meminfo 显示的进程内存由两部分组成。此过程直接分配一部分。例如Dalvik Heap和Native Heap。虽然其他部分不是由该过程直接分配的，但它是由系统直接分配的，由该过程引起。上面显示的EGL / GL mtrack部分属于该部分。跟踪这部分内存是由不同的硬件平台实现的。由显示驱动器计数。我正在使用的是MTK平台。它将跟踪那些执行实际GL操作的进程的GL内存。我相信这些统计数字是准确的。但是系统会消耗总的GL内存，也就是我们在没有附加参数的情况下执行 dumpsys meminfo 时可以看到的总GL mtrack值。它可能不等于所有会计处理的总帐值的总和。然后，它计算总GL内存和GL内存总和之间的差异，以进行初始处理。因为init是所有其他进程的祖先进程。因此，init的GL mtrack的值看起来很大，它不是由init分配的，也不是实际上由init引起的。
现在，我们可以解释上面非常奇怪的问题，并且知道它与进程init无关。但是我的问题仍然没有解决。也就是说，为什么事件 bootanimation 被终止，由它分配的GL内存没有被释放？这是否意味着资源泄漏？还是我可以认为它是mtk显示驱动程序的错误？