问题背景
近期测试同学反馈了两台机器不开机问题，一直定住在动态开机动画界面，重启设备后问题依然必现。问题有点不可思议，正常情况下，大部分此类问题在重启设备后应该会破坏现象的。对于必现问题，那就很庆幸，可以随便折腾分析，有此果必有起因。
分析思路
-
抓取开机Log
首先根据main log信息，看到系统频繁在GC操作，以及其他进程不断被LowMemroyKiller，以下列出部分关键信息：
lowmemorykiller.png
当卡住在动画界面后，系统不再输出log，看上去就是定屏现象了，根据如上信息，怀疑是系统可用内存不足，导致了这一系列问题，但正常开机流程是不可能出现这种现象的哇。为了验证怀疑，还是用数据证明，有时候不能按照常理来解释。重启设备，不断执行dumpsys meminfo命令，实时输出内存信息。
一看吓一跳，system_server进程在开机过程中竟然达到400M左右，正常是在100M左右的。
-
DDMS+MAT分析内存溢出
System_server进程内存溢出了，使用DDMS抓取system_server进程的内存使用情况，导出hprof格式文件。然后使用MAT来分析抓取的堆存储文件hprof。
MAT，全称为Memory Analysis Tool，是对内存进行详细分析的工具，它是Eclipse的插件，如果用Android Studio进行开发则需要单独下载它，下载地址为：http://eclipse.org/mat/。
-
DDMS生成hprof文件
生成hpof文件主要分为以下几个步骤：- 运行DDMS程序。
- 选择system_server进程，点击Update Heap按钮，开始进行追踪。
- 发生内存溢出后，点击Dump HPROP File按钮结束追踪，生成并保存hprof文件，如下图所示。
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
- MAT分析hprof文件
用MAT打开标准的hpof文件，选择Leak Suspects Report选项。这时MAT就会生成报告，如下图所示。
结果显示，加载一个Bitmap对象时，内存竟然分配了150M，实在太可怕了
- 结合代码分析跟因
Bitmap分配了150M内存，哪能分配这么大呢？
在细看main log信息，发现了一些猫腻，系统的density匪夷所思为30000，设备是720X1280，应该为320dpi才对。这个数值相差太大了。
原来该设备rom版本开放了修改density接口给云端，云端配置了density 30000推送修改了display_density_forced这个setting字段。
至于为什么density修改了30000后，一张Bitmap占用的内存会达到150M呢，这就需要跟踪Graphic系统的skia代码，这里是最终计算一张图片加载的时候系统分配内存大小。
后续会写一篇关于这个Bitmap如何到底分配多大内存的文章。
将density设置到正常值后，重启开机即可恢复正常状态，所以不要滥用设置density数值，会影响资源加载时内存分配情况。
