问题背景

 近期测试同学反馈了两台机器不开机问题，一直定住在动态开机动画界面，重启设备后问题依然必现。问题有点不可思议，正常情况下，大部分此类问题在重启设备后应该会破坏现象的。对于必现问题，那就很庆幸，可以随便折腾分析，有此果必有起因。

分析思路

• 抓取开机Log
  首先根据main log信息，看到系统频繁在GC操作，以及其他进程不断被LowMemroyKiller，以下列出部分关键信息：
  lowmemorykiller.png

gc.png

 当卡住在动画界面后，系统不再输出log，看上去就是定屏现象了，根据如上信息，怀疑是系统可用内存不足，导致了这一系列问题，但正常开机流程是不可能出现这种现象的哇。为了验证怀疑，还是用数据证明，有时候不能按照常理来解释。重启设备，不断执行dumpsys meminfo命令，实时输出内存信息。
 一看吓一跳，system_server进程在开机过程中竟然达到400M左右，正常是在100M左右的。

meminfo.png

• DDMS+MAT分析内存溢出
   System_server进程内存溢出了，使用DDMS抓取system_server进程的内存使用情况，导出hprof格式文件。然后使用MAT来分析抓取的堆存储文件hprof。
   MAT，全称为Memory Analysis Tool，是对内存进行详细分析的工具，它是Eclipse的插件，如果用Android Studio进行开发则需要单独下载它，下载地址为：http://eclipse.org/mat/。

1. DDMS生成hprof文件
    生成hpof文件主要分为以下几个步骤：
   • 运行DDMS程序。
   • 选择system_server进程，点击Update Heap按钮，开始进行追踪。
   • 发生内存溢出后，点击Dump HPROP File按钮结束追踪，生成并保存hprof文件，如下图所示。

ddms.png

DDMS生成的hprof文件并不是标准的，还需要将它转换为标准的hprof文件，这样才会被MAT识别从而进行分析，可以使用Android SDK自带的hprof-conv进行转换，路径在sdk/platform-tools中，进入到该路径执行以下语句即可：

./hprof-conv '/home/wangjiaxi/will_one/wjx_log/l2_h/scan/64/11/hang/hprof/p2_pro_hprof/system_process.hprof' /home/wangjiaxi/will_one/wjx_log/l2_h/scan/64/11/hang/hprof/p2_pro_hprof/hprof/p2pro.hprof

2. MAT分析hprof文件

 用MAT打开标准的hpof文件，选择Leak Suspects Report选项。这时MAT就会生成报告，如下图所示。

mat.png mat_bitmap.png

结果显示，加载一个Bitmap对象时，内存竟然分配了150M，实在太可怕了

• 结合代码分析跟因

 Bitmap分配了150M内存，哪能分配这么大呢？
在细看main log信息，发现了一些猫腻，系统的density匪夷所思为30000，设备是720X1280，应该为320dpi才对。这个数值相差太大了。

activity_config.png

原来该设备rom版本开放了修改density接口给云端，云端配置了density 30000推送修改了display_density_forced这个setting字段。

window_density.png

 至于为什么density修改了30000后，一张Bitmap占用的内存会达到150M呢，这就需要跟踪Graphic系统的skia代码，这里是最终计算一张图片加载的时候系统分配内存大小。

后续会写一篇关于这个Bitmap如何到底分配多大内存的文章。

将density设置到正常值后，重启开机即可恢复正常状态，所以不要滥用设置density数值，会影响资源加载时内存分配情况。