程序媛的周末,无偿加两天班

这周末在家加了两天班,没有加班工资,也没有调休,甚至都没有人知道我加班了。

事情是这样的,在我们老板的强烈要求下,我开发并上线了一个“牛逼”的技术方案,理论上可以消灭线上所有的Input Dispatching Timeout ANR。

这个方案从技术角度看非常可行,而且我在线下模拟了几个ANR场景,都可以被解决。比如在dispatchTouchEvent方法里加耗时,在Message Queue里面加耗时,都可以被完美解决。

但是奇怪的是到了线上,这个方案似乎不起作用了。方案上线后的ANR率并没有下降,线上用户还是在疯狂报Input Dispatching Timeout ANR。

上周五上线这个功能,于是这个周末,我就在家疯狂看线上用户日志,希望能找到一些蛛丝马迹。

经过两天的线上排查,确实找到了一些问题,比如:

  • 方案初始化太靠后了,有时候用户启动没多久就ANR了,还来不及加载我的框架
  • 对于跳转页面的场景,我来不及拿到新的fd,所以这种场景没办法解决

但是这几点只能说明有一些场景不能被我的方案捕获,无法说明为什么线上一点用都没有。

而且我已经从线上看到了一些用户的日志,我的方案的确帮他们解决了一些ANR的问题,不至于一点用处都没有吧?这个问题,我周末想了两天也没想明白。

最近工作压力实在是大,可能是因为做的事情太难了。

首先我一个人负责两个方向,老板又不给人力和资源,实在是分身乏术。其次,这两个方向都很麻烦,没有一个省心的事情。

一个方向的代码堆积跟屎山一样,线上一堆bug。偏偏这个项目又非常重要,是所有业务的基础,每天都会有各个业务团队的人找我查问题,查线上用户日志。

另一个方向,ANR和卡顿,可以说是性能优化领域里最难做的事情吧。

在我接手之前,几乎没有任何积累,需要从监控开始做起。

而且ANR不像Crash,ANR问题推动业务非常困难。改Crash对业务来说改动比较小,实在不行还能加个try-catch。但是改ANR,一般都是大的改动,及时是直接扔到子线程,也需要改动业务逻辑,会影响到线上运行的功能。

所以,ANR的改动周期通常都比较长。而我们发版节奏又很慢,导致很多问题推动起来非常困难。

总之我觉得自己现在是组里除了老板以外最累的人,别人是两三个人负责一个方向,我是一个人负责两个方向,头秃。

所以工作总是这么累嘛?什么时候才能退休,有时间做自己喜欢的事情啊,好久没弹吉他唱歌了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容