最近手头分来了一个bug，该bug很诡吊，一行代码的改动，花了四天时间，因为该Bug会block出货，项目经理每天催问进度，期间真是感觉整个人都不好了。本篇博文记录解决该问题的坎坷历程，因为代码保密原则，技术细节不便详细给出，重点记录解决问题的过程。

问题描述

MTK平台双摄拍完的景深图片在Gallery内，能进行refocus（重聚焦）操作，Camera近期新增拍摄4：3比例的图片，refocus时该种比例的图片显示会拉伸，为了解决该问题，我对refocus后的图片进行了一个resize操作。之后就报出对该种图片进行refocus操作，非常高的概率出现点击两次才能正确改变图片焦点的bug。16：9的图片则没有该Bug。现象如图-1.

图-1

而正常的现象应该点击哪里，哪里就清晰。如图-2.

图-2

解决过程

Day-1：自我怀疑

问题是在我的修改之后才引发的，因此这个漏洞还得我来补，回退掉resize的改动，该问题确实消失了，但图片会被拉伸的问题当然又会出来，看来我得找其他方法修正图片拉伸的问题，此时项目经理发出邮件，强调该问题会block产品出货，让尽快处理。顶着压力开始撸一遍代码，梳理了下Refocus的大体过程：

因为问题只出现在4：3比例的图片上，一开始就认为问题出在A过程中，猜测4：3比例的图片接收的touch坐标与图片上的坐标点没有正确对应。排查代码，发现底层算法逻辑是按16：9的图片比例处理景深数据,到此以为找到了root cause,连同图片会被拉伸的问题一并抛给平台，让他们去解。
因为是平台提供的算法问题，而算法核心逻辑平台是以库文件release出来，我们无法修改。问题也抛给了平台，我这边没有压力，只用等平台提供修复patch过来合并就可。然而等待一段时间后，平台给了反馈，我之前为解决图片拉伸引入的resize patch修改方案是可行的，他们修正拉伸问题的改法与我的一样，重点是加上resize的patch该问题在平台的Gallery上没法复现，这无疑将问题抛回给了我。压力指数立马暴增十几个点，如果平台没有问题，那就只可能是我在porting平台gallery的时候出错了。这里说明下项目采用的gallery并不是基于平台Gallery开发的，只是将平台gallery上的refocus相关代码porting进来。如果porting过来的代码产生bug。就有两种可能：

• 平台gallery问题
• porting过程中引入的问题

真出问题了，当然希望是第一类问题，这样最起码还能求助平台，如果是porting不当引发的问题，平台顶多协助分析下，还得自己去一点点嚼回头草，现在如果平台没能复现问题，那么整个压力就又跑到我这边来了。
于是赶紧更新平台的Gallery代码，安装后测试，我擦，明显能复现啊。这是怎么回事呢？又重新拿平台的gallery复测了几遍，确实平台gallery也有该问题。于是下班前再次把现象发邮件给平台，这时距离项目经理发出邮件已经过去了一天。

Day-1后记
不够自信，浪费了很多时间复测平台gallery的现象，由于平台反馈他们加入resize patch都没能复现问题，因此就怀疑自己向平台加入resize的patch不正确，检查了好几遍代码，在加上编译安装测试，浪费了时间。过度的细心，浪费时间，拖慢了进度。

Day-2：逃避

发送给平台的邮件得到回复，平台依然无法复现问题，问题陷入罗生门。我用平台的Gallery能复现问题，但平台却又无法复现。于是又梳理了几个可能导致结果不同的可疑点。

• 复现问题的图片。因为refocus采用的图片依赖Camera拍摄，会不会平台复现问题时所用的图片和我们不一致导致的呢。邮件将我复现用的图片发送给平台方，得知依然无法复现。
• 我加入的resize patch与平台不同。邮件将我的改动发送给平台方，经确认修改地方一致。
• porting时出错。邮件将porting过来的refocus相关文件发送给平台方，帮忙确认porting是否有问题，经确认porting无误。
• 邮件发送log给平台，请其尝试从log排查是否有问题。自己和平台都未看出问题。

问题至此感觉无法进展下去了，平台无法复现问题，也就没法给出解决方案。自己转向去解决其他bug。该问题处于搁置状态。这时距离项目经理发出邮件过去了两天。

Day-2后记
1.沟通不畅，当自己这边复测后现象与平台方不一致，应该及时沟通，这一点在Day-3中通过项目经理的推动才加紧了沟通步伐。
2.没有从正面解决问题。一直围绕问题周边在排查，本来期望这样能快速定位问题，但没能第一时间再次详细梳理代码逻辑。
3.惰性产生。头疼的bug没有一点头绪后，产生懈怠心理。搁置的问题永远是问题，出现了要正面解决。

Day-3：找到原因

项目经理开始不断催促问题进度。但自己仍旧没有头绪，压力指数再次攀升。项目经理催促直接电话跟平台沟通，要加强push平台。自己通过其他渠道拿到平台电话，直接电话沟通。果然电话沟通后很有收获，知道了一种debug方法，能查看点击后通过算法逻辑生成的新Bitmap,赶紧本地debug，这时发现算法逻辑的图片是正常的，也就是图-1中的A步骤执行完成后，结果是正确的，问题出在B步骤上。总算有了明确的分析方向。
A步骤完成后，refocusview将新生成的bitmap上图，跟平台方确认上图的逻辑调用是正确的。看着快要找到问题原因了，但还是进行不下去，相同的逻辑，运行的结果确不一样。诡吊的很。
在次从touch事件开始梳理代码，由于refocus的父类封装在库文件里，这也给排查代码逻辑带来了复杂性。硬着头皮分析出OnTouch主要做了两件事：

1. mRefocusListener.setRefocusImage(mDownRX, mDownRY)。通过接口回调的方式将touch坐标回传给Activity，Activity利用点击坐标生成新的焦点图。

2. requestRender()。方法实现无法看到，从名字猜测像是GLSurfaceView里调用它来渲染图片，重聚焦的过程伴随一个过度动画，有可能就是通过它不断渲染做出来的效果。
   心里大概对这个过程有个一个猜测图。

   
   
   

   继续与平台沟通，确认上述猜测正确。那这里就有个坑了，如果渲染动画结束后，生成的新图才被交给refocusview，那当然不会被更新上来。
   如果上面的流程正确，已经大概猜测到为何添加resize的patch后就会出现该Bug。但还是无法解释为何平台一次都没有复现该问题。
   突然想起来我们的手机是将大核关闭的，那么有可能机器性能不如平台方，导致生成新图的过程太长了。
   赶紧实验。用命令：

adb shell cat /proc/ppm/mode

查看到当前手机处于低功耗模式。

用命令：

echo Performance > /proc/ppm/mode

开启高性能模式。

在复测问题，神奇的事情发生了，bug没有了，完美！

这时距离项目经理发出邮件过去了三天。

Day-4：改了一行代码

已经找到问题原因。之前的疑惑也有了合理的解释。

• 为何平台没有复现问题？平台设备没有关闭大核，生成新图的过程很快，动画结束之前，新图已经成功传给refocusview。
• 为什么加入resize操作问题就报出来了？resize对新图进行了缩放，这个过程耗时，导致动画完成后，新图才传给refocusview。
• 为什么是4:3比例的图片才有这个问题？4:3图片大，生成新图的过程相对其他图片耗时长。

那么有几个方面可以修复该问题。

• 优化算法，缩短生成新图时间。这需要平台去改，难度大，推动也难。直接pass。
• 更改refocusview刷新机制，就算动画结束前，新图没能生成，也应该提供二次刷新的机会。该改动较大，在出货阶段，万一引入新的bug，更头疼。但这应该是该问题最正确的解法。
• 将gallery加入高性能白名单，需要Performance组协助配置。但因为这一个问题，将其配置进白名单，有点小提大作。
• 动态配置CUP频率，在生成新图的过程中对CUP升频。
• 偷机取巧，拉长动画时间。只需变更一个值，风险低。但没能从正面解决。