APP崩溃上报

最近有崩溃上报的需求。在互联网上搜了一圈，似乎有不少现成服务和配套SDK。比如腾讯bugly、网易云捕、友盟，以及一众小厂。

友盟先否决，名声太差了，一款应用内置友盟SDK就让我心里发毛。那试试网易云捕，好家伙！倒闭了？好吧，上bugly。等等，这官网什么鬼，打开登录页面要以分钟计算。我以为是有什么冷门资源加载慢，下次打开就快了。结果每次打开都这么慢。能用就行，谁叫咱不打算付费呢。在安卓APP上集成的难度很小，而且上传crash的速度是正常的，比打开网页的速度快得多，感动！可是……上报成功率怎么只有一半，再忍忍吧，谁叫咱不打算付费呢。

忍了一天终于忍无可忍，开始寻找替代品。一番搜寻，听说巨硬AppCenter很不错。亲测下来，打开官网和控制台的速度跟腾讯bugly比那是数量级的提升！！！而且无需任何魔法！噼里啪啦敲键盘，把bugly从APP上干掉，换上AppCenter。咦？crash咋报不上去。啊！原来网页不需要魔法，但是上传crash的API它需要啊！这还怎么玩。

无奈下的无奈，尝试谷歌Firebase Crashlytics。网页肯定是需要魔法的，抱着侥幸心理在APP上集成，然后，上报成功了！交互很棒，而且实时性很不错，漏报的概率也不高。不可思议。

桌面程序崩溃上报

由于Crashlytics易用性太高，我一度想将PC上的crash也上报到Crashlytics。几番研究，灭了这个念头，决定手撸一个breakpad服务器。由于我在这之前对breakpad的了解仅仅停留在程序里调用breakpad的接口，崩溃时能产生dump文件，折腾了整整两天才把这个breakpad服务器写好。说说这期间我遇到的问题：

1. 不知道怎么从dump文件中解析出文本形式的崩溃堆栈
2. breakpad的官方文档很多，但是对原本不懂这个的人来说，很糟糕
3. 在Windows上编译breakpad很麻烦
4. 不熟悉HTTP协议、以及不熟悉编写HTTP服务器

解决上面这几个问题，breakpad服务器基本就写出来了：

1. 对于问题1，第一步是用dump_syms从pdb文件中解析出sym文件，以一定路径模式存储。然后运行minidump_stackwalk，指定存储sym的文件夹和dump文件路径即可。
2. 对于问题2，不多说，雷姆。
3. 对于问题3，在这个过程，我们需要编译breakpad的三个模块，a. 生成dump文件所需的代码库；b. dump_syms可执行文件；c. minidump_stackwalk可执行文件。对于a，我是阅读了breakpad的编译脚本，照着用cmake写了一遍，集成到我的程序。对于b，dump_syms需要在windows上运行，但是这个东西在windows上编译就是很麻烦，于是我找了mozilla的一个替代品。对于c，这个只需要在我的Linux服务器执行，跟着文档敲敲敲就行，这是我利用Github Actions编译好的Linux可执行文件。
4. 这个确实，只能碰到一个问题查一个。

这个breakpad服务器是在Github上开源的，传送门github.com/numbaa/bp-server。