wp7吧 关注：853,962贴子：67,383,934
不感兴趣
开通SVIP免广告
问题分析：
为了找到根本原因，我找了个安卓4.0的源码包，从18万个文件里面定位到了构造和使用这个文件的一个java脚本，/frameworks/base/media/java/android/media/MiniThumbFile.java，这里面的代码就是问题的根本所在。
解开问题的关键其实只需要看其中一句代码“long pos = id * BYTES_PER_MINTHUMB”，写过程序的人可能很容易猜出来，这句代码的意思是“缩略图起始位置=图片id*每个缩略图的长度”。这句代码就揭示了上面几个问题的根本原因：
这里的id是安卓后台数据库里的文件编号，是数据库的自增主键，随着使用时间的增加，系统中不断有新文件产生，那么新文件的id会越来越大，无论是否删除旧文件。
BYTES_PER_MINTHUMB是每个id在thumbdata里面占用的固定空间，无论这个id对应的文件是否是图片（是图片则存储缩略图相关信息，剩余的空间用0填充，不是图片则全用0填充）。
pos是缩略图在thumbdata里面的偏移量，而thumbdata文件的大小就等于图片文件的最大id（或者全局最大id，没严格验算过）乘以BYTES_PER_MINTHUMB。按附件程序中每个id占10000Bytes来计算，如果系统最大文件id是100000，那么thumbdata大约有950MB。
因此，随着新增图片id的不断变大，这个文件会越来越大，并且其中非图片id对应的位置是空值（即使是图片id，末尾通常也留有大量空白空间），大量的空值使其体积比手机里所有图片加一起还大，系统也很容易通过现存的图片来重构这个文件。
这么做的目的应该是为了快速定位缩略图信息，但是可能股沟的工程师没想到现在的手机里会有那么多的文件。
为了找到根本原因，我找了个安卓4.0的源码包，从18万个文件里面定位到了构造和使用这个文件的一个java脚本，/frameworks/base/media/java/android/media/MiniThumbFile.java，这里面的代码就是问题的根本所在。
解开问题的关键其实只需要看其中一句代码“long pos = id * BYTES_PER_MINTHUMB”，写过程序的人可能很容易猜出来，这句代码的意思是“缩略图起始位置=图片id*每个缩略图的长度”。这句代码就揭示了上面几个问题的根本原因：
这里的id是安卓后台数据库里的文件编号，是数据库的自增主键，随着使用时间的增加，系统中不断有新文件产生，那么新文件的id会越来越大，无论是否删除旧文件。
BYTES_PER_MINTHUMB是每个id在thumbdata里面占用的固定空间，无论这个id对应的文件是否是图片（是图片则存储缩略图相关信息，剩余的空间用0填充，不是图片则全用0填充）。
pos是缩略图在thumbdata里面的偏移量，而thumbdata文件的大小就等于图片文件的最大id（或者全局最大id，没严格验算过）乘以BYTES_PER_MINTHUMB。按附件程序中每个id占10000Bytes来计算，如果系统最大文件id是100000，那么thumbdata大约有950MB。
因此，随着新增图片id的不断变大，这个文件会越来越大，并且其中非图片id对应的位置是空值（即使是图片id，末尾通常也留有大量空白空间），大量的空值使其体积比手机里所有图片加一起还大，系统也很容易通过现存的图片来重构这个文件。
这么做的目的应该是为了快速定位缩略图信息，但是可能股沟的工程师没想到现在的手机里会有那么多的文件。
不感兴趣
开通SVIP免广告
