「桌面端」|Electron 崩溃自行上报实现

凡是跨端,终是有坑

背景

但凡是个商业化应用,都需要有完善的崩溃分析机制来保证整体的可用性。

一般 App 上都是采用接入第三方平台来简化基建开发工作,但对于桌面端 Electron 来说,这在市面上虽然是不少见,但也是不常见的,导致国内主流的质量监控平台(友盟、Bugly 等)并没有对其进行支持[手动狗头]。

Electron 崩溃分析现状

三方平台

按官方推荐,都是国外平台,国内没人做三方平台。

不一一列举了,大体上都是 14 天免费,基础班收费情况从 39 ~ 65 美元不等,且网络情况堪忧,要考虑用户设备能不能访问到。

另外,大名鼎鼎的Firebase,没有支持 Electron。

自研平台

笔者能找到文章的就两家,也都是自研的上报平台。

阿里

如何治理 Electron 版本淘宝直播应用崩溃

可以看到这是今年3月阿里官方的文章,非常新了,给了笔者很多方向,也可以看到 Electron 崩溃问题确实不少见,特别是在 Windows 平台上。

从文章中可以看到,阿里是自研这条路,通过官方提供的采集能力,上传平台进行解析。

另外,他们的上报分析平台都是内部平台,并没有商用化。

字节

火山引擎作为字节提供的一站式解决方案,其中也包括各端的采集上报分析能力。

而它对 Electron 并没有直接支持,而是提供了一个 C 库来支持非 Native App 能力: www.volcengine.com/docs/6431/1...

这个看起来能用,但貌似不是正式版,C 库会不会带来额外风险,这也不好评断。

另外,火山是商业化的,所以用它的平台分析需要付费。

自研

大概有以下4个步骤:

  1. 采集: 使用 Electorn 提供的crashReport可以拿到崩溃的 Dump 文件。
  2. 上传: 将 Dump 文件以及相关信息上传到服务器。
  3. 解析: 用符号表解析 Dump 文件,还原堆栈,进行聚合归因。
  4. 查看: 在平台上进行展示、查询、监控。

自研成本也是比较高的,毕竟现在并没有合适的平台。

方案

(如果有的选,谁想搞自研)

整体流程

因为我们不像官方推荐的那样,具有现成可接收崩溃信息上传的服务接口,所以我们把整个上传流程拆解成2个部分:

  1. OSS 上传崩溃 Dump 文件。
  2. 把 OSS 地址、设备信息、设备环境等崩溃信息当作上传至 ELK 日志平台。

当然这个触发时机也是在客户端下次启动后。这里有一点问题是,崩溃发生时间的记录,因为是 Electorn 直接写入文件到本地的,所以如何记录崩溃发生时间呢?

笔者这里是使用的记录当前 Dump 的创建时间。但这有一些问题,这个时间是本地时间,如果用户有篡改时间或者不同时区,那就会有不准确的现象。

详细步骤

采集能力

crash-reporter

使用官方提供的能力,但我们没办法直接上传到服务器,因为牵扯到服务端需要提供单独的 API,所以我们只能采用放到本地的形式:

typescript 复制代码
app.setPath('crashDumps', '/path/to/crashes') 
crashReporter.start({
    uploadToServer: **false**,
})

可以看到 Electron 提供的能力也是很简单,生成到本地的结果也很简单,只是一个 Dump 文件。

这里因为没有用它的上传机制,所以只会存储在 pending 文件夹里,不会流转到 completed 等文件夹。

本地存储

因为采用了本地存储,那就需要进行管理:

  1. 分天保存本地崩溃记录
  2. 删除已上传的崩溃记录

那本地存储路径设置为:{当前 App 安装路径}/crashes/{当天日期},这样来简化必要信息存储成本。

这里笔者前期没有在 Windows 上进行验证,所以这里踩了一个大坑,导致线上有个版本的 Windows 崩溃没有上报成功:

Windows 的存储目录和 Mac 是不一样的,而且 Mac 会自动生成 pending / completed 文件夹,但 Windows 并不是这样,需要每个路径检查下是否存在,不存在需要去手动执行createDirectory...

上报位置

这里采用公司现有的 OSS 进行文件上传保存,这里不细讲。

上报内容

由于崩溃后会直接退出,且只会记录 Dump 文件,所以上报内容上分为2个部分:

  1. Dump 文件本身上传至 OSS。
  2. 在文件上传到 OSS 上后,把崩溃额外信息上报到日志平台,用于查询。

OSS 上传成功 / 上传失败的都进行下记录。

上报时机

为了减少对客户端本身的影响,但现在又没有构建 CPU 闲忙时这种监控机制,所以拍脑袋决定在启动后 5 秒检测是否存在未上报崩溃并上报。

实现效果

崩溃条数可视化,可以初步分析用户/设备崩溃率,给当前客户端质量评价提供有力的支撑。整个客户端的崩溃情况不再是一个盲盒了。

后续

我们在这篇文章实现了从 Electron 客户端把崩溃自行上传到服务端的能力。但接收到的是 Dump 二进制文件,没办法直接做问题归因,那就无从优雅的聚合高优问题。

笔者会在下一篇文章中跟大家探讨下我们是如何自行实现问题归因的。


感谢阅读,如果对你有用请点个赞 ❤️

相关推荐
森叶7 小时前
Electron 安装包 asar 解压定位问题实战
前端·javascript·electron
森叶13 小时前
Electron-vue asar 局部打包优化处理方案——绕开每次npm run build 超级慢的打包问题
vue.js·electron·npm
diygwcom14 小时前
electron-updater实现electron全量版本更新
前端·javascript·electron
volodyan14 小时前
electron react离线使用monaco-editor
javascript·react.js·electron
春蕾夏荷_7282977251 天前
electron nsis打包windows应用程序
javascript·windows·electron·nsis
Lovely Ruby3 天前
Vite + Electron 时,Electron 渲染空白,静态资源加载错误等问题解决
前端·javascript·electron
diygwcom4 天前
electron多标签页模式更像客户端
前端·javascript·electron
亦世凡华、5 天前
探索 Electron:助力文档操作应用快速落地
前端·javascript·经验分享·electron·前端框架
volodyan6 天前
electron-vite vue3离线使用monaco-editor
前端·vue.js·electron
cyt涛7 天前
Redis访问工具
数据库·redis·spring cache·注解·客户端·lettuce·redistemplae