背景
58同城主APP的单架构的bugly符号表已经达到了53MB（解压后550MB+）。每次打包都需要存储和每次下载符号表都需要传输53MB的数据。去年一直在解析各种日志，有符号表的，没有符号表的，能记得住打包地址的，记不住打包地址的。总之，我需要经常在打包平台查找和下载符号表，并人工解析各类日志，这是一个繁琐且痛苦的工作。因此今年考虑打造一个平台，结合打包服务支持，实现各类日志上传一键解析，无需人工查找匹配符号表。因此，符号表是越小越好，体积过大自动化工具有一定的影响。因此针对符号表进行二次压缩。趁着假期刚结束还不算太忙，动手处理下。
(https://github.com/pilaf-king/bugly_symbol_thin)
可读和不可读
bugly的符号表分为2种，一种是可读符号表，另一种是不可读符号表。其中不可读符号表在2019年1月22日以后默认生成的都是不可读符号表。如果想要生成可读符号表可以指定参数为-symbol。具体buglySymboliOS.jar是如何将DWARF格式转为符号字符串的没有做深究，猜测是通过解析DWARF格式文件提取数据的。可读符号表和不可读符号表经过观察得知，两者在所占空间体积上没有显著差异。本方案针对可读符号表进行压缩。
如何使用
使用前需要确保安装Python3
准备好物料，bugly的可读符号表
注意，这里的符号表的zip包是指通过 buglySymboliOS.jar 处理后的zip文件，不是dSYM文件zip压缩后的文件
python3 compressed.py -i <bugly符号表的zip包> -o <压缩后的输出路径>
执行命令后可得到压缩后的文件，与原始文件对比，体积从
52.7MB减小到31.3MB。
image.png
日志符号化可以会根据新生成的符号格式来解析匹配。但是也实现了还原到bugly.symbol.zip的功能。接下来我们对文件进行还原测试看下：
python3 decompress.py -i <经过上步压缩的zip路径> -o <输出路径>
image.png
经过解压后可得到与压缩前一致的文件。
image.png
总结
其实整体文件还可以进一步压缩，但是复杂度会提高一些。比如压缩后的符号表还是有很多重复字符，是不是可以考虑像Mach-O那样集中存储字符串，使用的地方指记录地址呢？
