这周末在家加了两天班，没有加班工资，也没有调休，甚至都没有人知道我加班了。
事情是这样的，在我们老板的强烈要求下，我开发并上线了一个“牛逼”的技术方案，理论上可以消灭线上所有的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的改动周期通常都比较长。而我们发版节奏又很慢，导致很多问题推动起来非常困难。
总之我觉得自己现在是组里除了老板以外最累的人，别人是两三个人负责一个方向，我是一个人负责两个方向，头秃。
所以工作总是这么累嘛？什么时候才能退休，有时间做自己喜欢的事情啊，好久没弹吉他唱歌了。
网友评论