背景
58 同城主 APP 的单架构的 bugly 符号表已经达到了 53MB（解压后 550MB+）。
每次打包都需要存储和每次下载符号表都需要传输 53MB 的数据。
去年一直在解析各种日志，有符号表的，没有符号表的，能记得住打包地址的，记不住打包地址的。
总之，我需要经常在打包平台查找和下载符号表，并人工解析各类日志，这是一个繁琐且痛苦的工作。因此今年考虑打造一个平台，结合打包服务支持，实现各类日志上传一键解析，无需人工查找匹配符号表。
因此，符号表是越小越好，体积过大自动化工具有一定的影响。因此针对符号表进行二次压缩。
趁着假期刚结束还不算太忙，动手处理下。
可读和不可读
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。
日志符号化可以会根据新生成的符号格式来解析匹配。但是也实现了还原到bugly.symbol.zip 的功能。接下来我们对文件进行还原测试看下：
python3 decompress.py -i <经过上步压缩的zip路径> -o <输出路径>
经过解压后可得到与压缩前一致的文件。
总结
其实整体文件还可以进一步压缩，但是复杂度会提高一些。比如压缩后的符号表还是有很多重复字符，是不是可以考虑像Mach-O那样集中存储字符串，使用的地方指记录地址呢？
如果觉得不错，素质三连、或者点个「赞」、「在看」都是对笔者莫大的支持，谢谢各位大佬啦~
