「桌面端」|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 二进制文件,没办法直接做问题归因,那就无从优雅的聚合高优问题。

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


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

相关推荐
编程猪猪侠1 天前
解决yarn install 报错 error \node_modules\electron: Command failed.
前端·javascript·electron
zooooooooy1 天前
Electron打包ARM环境deb包
后端·electron
程序员老刘3 天前
差生文具多
flutter·客户端
red润3 天前
浏览器离屏渲染 vs. Electron离屏渲染——核心区别与应用场景
前端·electron·canvas
OpenIM3 天前
Electron Demo 的快速编译与启动
前端·javascript·electron
柚子a4 天前
Electron主进程渲染进程间通信的方式
electron
柚子a4 天前
electron使用remote报错
electron
DevUI团队4 天前
Electron 入门学习指南:快速搭建跨平台桌面应用
前端·javascript·electron
RedHood5 天前
鸿蒙投屏实现
electron·harmonyos
黑金IT5 天前
如何在 Electron 应用中安全地进行主进程与渲染器进程通信
服务器·安全·electron