雷系泡泡

```golang var _ cron.Job = (*tmpJob)(nil) type tmpJob struct { name string done chan struct{} } func (t *tmpJob) Run() { fmt.Println("hi", t.name) t.done

最近有点忙，这个 PR 可能要晚一点处理

等有空了我直接在你们的分支上修改, 有太多不符合我个人预期的改动

🉑️ 暂时放 [dev-performance-monitoring](https://github.com/electricbubble/gidevice/tree/dev-performance-monitoring) 了， 最近要处理的事情确实多，我尽可能腾出时间参与修改

偶现这个问题时，是否都恰好在 `app` 元素较多的页面？

不是这原因，只是因为看提供的日志，恰好停留在匹配元素的输出后面， 结合报错信息，猜测可能是响应过大，同时赶上未知的原因导致接收的数据不完整， 所以只是猜测，问这个只是为了判断是否可能存在这种可能。 --- 原因暂无思路定位，但这个 `panic` 可以避免掉， 晚些时候我做一些调整，这种情况数据不完整的情况可能还是会出现

⚠️只是现状无法定位的猜测

已尝试避免 `panic` [v0.5.2](https://github.com/electricbubble/gidevice/releases/tag/v0.5.2)，有空再试一试 > [electricbubble/gidevice-cli v0.8.0](https://github.com/electricbubble/gidevice-cli/releases/tag/v0.8.0)

这个库是由 plist 导入， 该漏洞问题，理论上不影响这个项目的运作，因为 gidevice 本质上是一个客户端库

Is the device locked when an error is reported?