如何无损压缩 bugly 符号表 40％ 体积

背景

58 同城主 APP 的单架构的 bugly 符号表已经达到了53MB（解压后550MB+）。

每次打包都需要存储和每次下载符号表都需要传输 53MB 的数据。

去年一直在解析各种日志，有符号表的，没有符号表的，能记得住打包地址的，记不住打包地址的。

总之，我需要经常在打包平台查找和下载符号表，并人工解析各类日志，这是一个繁琐且痛苦的工作。因此今年考虑打造一个平台，结合打包服务支持，实现各类日志上传一键解析，无需人工查找匹配符号表。

因此，符号表是越小越好，体积过大自动化工具有一定的影响。因此针对符号表进行二次压缩。

趁着假期刚结束还不算太忙，动手处理下。

可读和不可读

bugly 的符号表分为 2 种，一种是可读符号表，另一种是不可读符号表。

其中不可读符号表在 2019 年 1 月 22 日以后默认生成的都是不可读符号表。

如果想要生成可读符号表可以指定参数为-symbol。

具体buglySymboliOS.jar是如何将 DWARF 格式转为符号字符串的没有做深究，猜测是通过解析 DWARF 格式文件提取数据的。

可读符号表和不可读符号表经过观察得知，两者在所占空间体积上没有显著差异。

本方案针对可读符号表进行压缩。

如何使用

使用前需要确保安装 Python3

准备好物料，bugly 的可读符号表

注意：这里的符号表的 zip 包是指通过 buglySymboliOS.jar 处理后的 zip 文件，不是dSYM 文件 zip 压缩后的文件

执行命令后可得到压缩后的文件，与原始文件对比，体积从 52.7MB 减小到 31.3MB。

经过解压后可得到与压缩前一致的文件。

总结

其实整体文件还可以进一步压缩，但是复杂度会提高一些。比如压缩后的符号表还是有很多重复字符，是不是可以考虑像Mach-O那样集中存储字符串，使用的地方指记录地址呢？

如果觉得不错，素质三连、或者点个「赞」、「在看」都是对笔者莫大的支持，谢谢各位大佬啦~