在测试APP的时候，经常需要考虑弱网下APP的表现。笔者最近就遇到一个问题，即在弱网情况下快速切换APP底部tab页面的时候，APP就会频繁弹出网络异常的提示，非常影响用户体验。
针对这个问题，我们希望的解决方案，是在保证用户体验的情况下，修改工作量越小越好。
开发人员针对这个问题提出了一个建议：增加响应时间，增加响应提示间隔。他们举了一个例子：比如说控制一分钟之内最多弹出一个网络异常的提示。
深入分析：
听到这个方案之后，我想象不出具体的场景。而且我希望从整体上、根本上进行终端传输策略的优化，而不是仅仅解决这个弹窗的问题。因为我觉得，如果只是通过控制网络异常弹出的间隔来解决这个问题，相当于治标不治本。
于是我开始在弱网下操作APP，尝试找出哪些功能页面在弱网下表现较差，哪些操作会操作频繁弹出网络异常的提示。
同时体验了一下诸如360手机助手、网易新闻等APP在弱网下的表现。最终花了几天时间列出了一个比较详尽（自我感觉）的优化方案。
结果并不美好，因为这个方案修改工作量超过一周，违背了初衷，最终还是选择了开发人员提出的方案。
不过我在研究的过程中看到《移动APP性能评测与优化》这本书中，描述的一个“鱼翅”的案例挺不错，很有必要跟大家分享一下，里面分析问题、解决问题的思路很有借鉴意义。
鱼翅项目：（解决QQ传图片经常失败的问题）
研发团队的做法：
参考其他应用在弱网下的处理（上滑、下滑、列表、详情页、H5页、tab页、文件上传等），了解每个产品设计中的可取之处、以及也没解决好的问题。然后把它们各自的“闪光点”集中到一起作为一个基础。同时，针对其他产品没有处理好的一些问题思考解决方案。部分要点和相关考虑罗列如下：
1、后台是否支持断点续传，若否则小片传输一个图片（已有处理，断电续传），把一个较大的图片分成一个一个小片进行传输。---或者UI图是否可以进行处理，让其变小。
2、不同类型的移动互联网下的分片初始大小不同。理由：不同网络类型的带宽和稳定性差异较大，使用不同大小的初始分片应该能更好的适应对应类型的网络。
3、在上传一个图片的过程中，尽可能动态增大分片大小（例如后一片是前一片的N倍），以减少分片数量。理由：分片动作会带来不少额外开销，比如终端拆分与合并分片的时间、传输时额外流量、每个分片的的RTT等，所以需要尽可能的减少分片带来的开销。
4、确定每个分片是否要继续增大之前，要检查网络类型是否发生了变化，一旦跟前一片传输的网络变得不同，则新的一片不能继续增大而是根据新网络类型下的初始分片大小进行传输。
5、分片一旦传输失败，应该使用该网络下的初始分片大小进行重试。
6、每个分片都有一定次数的失败重试机会，当一个分片的所有重传都失败了，才定义为图片传输失败。
7、配合后台服务器的能力，待手动用户再次重试失败传输的图片时，能断电续传。
疑问：
1、是否所有的网络都支持http的keep-alive这样的常见模式
2、需要考虑每种网络类型下最适合的初始分片大小和最大分片大小，若没有最大分片，岂不是越到后来传输失败的概率越大？
3、分片传输的目的是为了提升传输成功率和减少流量浪费。但是分片引入的开销必然导致传输速度会有下降，怎么办？
4、分片传输若是失败，失败的原因有哪些？最主要的是什么？若能解决这些问题，又可以大大提升图片传输的成功率。
5、当前的失败重传策略是否奏效？是否是最好的？如果不是，那么还不如不重传，因为如果重传成功率低，必然带来新的浪费。
他们的解决方案可以看看这本书。