记一次android Bug解决的曲折心路历程（java.net.ProtocolException: expected 0 bytes but received 2048）

问题描述：
上周四的一天，产品经理找到我，说学校里面有几个用户在使用我们的一款应用（我们应用是教学软件）的过程中拍照后上传图片一直提交失败。

第一波心理历程：
当时我听到这个问题的第一反应就是，去后台看看对应用户的操作路径，看看操作路径上的埋点以及收集上来的用户设备信息，内存信息，报错的堆栈信息等等。从而分析出哪个步骤出问题了，以便能够找到复现的步骤，定位问题的真正原因。

可是理想很丰满，现实很骨感！

这个老破项目，哪里有什么用户数据收集模块。唯一庆幸的是后来接入了Bugly, ，但是这种老的java项目，写的代码都是能把功能做通就算完活了。 那管你什么代码规范，异常处理啥的。如果有个异常能给 try，catch{}一下就是对的起你了。 说不准catch的时候，连异常打印都不打印….

所以，想查看日志啥的就别做梦了。醒醒吧！ 不过好在我们是做定制的，就是应用搭配着Pad一起卖，所以用户使用的Pad是固定的设备， 所以去测试部拿了一台设备，按照用户的描述进行操作，操作了一番。复现啦！！！ 开心了一会，这就好办了。能复现的话，我的水平还是可以解决的！！

注：设备为 联想TB4-X704F， Android系统版本7.1.1。

第二波心理历程：
复现的过程也挺波折的，因为是定制产品，所以我们会有定制Rom。这个问题在复现的过程中，只在某一版的Rom中有问题，而这一版Rom偏偏不能进行debug. 只能不断的打log… 。 最后发现提交的时候抛出了这个异常(java.net.ProtocolException: expected 0 bytes but received 2048）。
这里插一句“程序员一定要冷静的分析问题，打点的时候也是，要不就是做无用功！事倍功半”，当时一看到这个异常，第一反应就是这个是网络异常了呀！ 再一看使用的是okhttp请求的网络，稍稍安心了一点，okhttp的使用我还是熟悉的。定位问题也好定位。 再一看，不对呀，okhttp的版本怎么是3.2.1。 我靠现在都3.9了。 这怎么还是这么老的版本呢？ 原来是用了一个开源库okhttputils中引用的okhttp, 而这okhttputils中引用的okhttp的版本比较老。所以就这样了！ 当时我想，如果这个是网络问题，我要分析网络问题，怎么也得跟着okhttp的源码去定位一个这个异常的位置和原因呀。 但我用这么老的版本，万一okhttp版本迭代的过程中已经修复了这个问题，那我不是白白浪费自己的时候了。 所以我决定把okhttp升级到最新版本， 但是有点尴尬的是，项目对于这个第3方库的依赖已经相当深了。如果我直接替换okhttp版本，意味着我要手动修改这个开源库基于okhttp实现的部分。。 想到这点… 真的是…。 但是我的思路还是没有我的手快， 我直接上手替换了。 … 这明显就是copy代码多了导致的条件反射！！ 万幸的是okhttp是一个优秀的开源库， api的向下兼容性很好，我并没有替换什么。 还有就是gradle很方便，只一行代码就更改了项目的依赖！！ 替换以后还是抛出这个异常， 这个时候我的思维回到了正常轨道。而正好这个时候Rom商也基于这个问题版本给我了一个可以调试的版本。

第三波心理历程：
我直接debug的时候发现，拍完照后，onActivityResult中使用okhttp上传这个图片文件之前。图片文件的大小竟然为零。
这尼玛… 我才知道我错了，这和网络没有半毛钱关系。 文件都没有创建成功，你让人家上传什么！ok. 既然问题回到了调用相机拍照的问题，那就好办了， 我根本就不相信这个老项目的代码，所以直接上官网去重新回顾了一下调用相机