背景：纯手写没用三方异步方式网络通讯
现象：execute()之后log出现大量gc，内存总体没有多大变化，频繁出现的gc导致UI等待界面卡顿也着实吓了我一跳。。。
解决思路：
1.断点调试跟踪了一下发现是execute的问题，因为其他交互没有出现过只有某一交互出现，因此尝试更换了请求json来判断是否是某个地方写错了造成OOM等，结果更换其他json正常。
2.交互代码没有问题，断点跟踪没有继续往网络方面深入，手动查看了socket代码，考虑是接收（Read）部分创建了大量新生代造成频繁gc。（因为单单的网络交互不可能频繁gc）
3.多点log看出了问题。
原因：缓冲区太小，小量的json内存够用，当大量的json（比如list有上百个对象），就OOM只能频繁gc。
解决方式：若固定缓冲区的值太浪费内存，所以换成了BufferRead的readLine方式，效率提高百倍，很长的json只出现了一次gc。log的信息会断（不全），但是内存中是全的，显示出来就看到了。
反思：设计接口不要过长，可采用分页的方式获取；获取多用缓存；如果还设计到视频、图片展示之类的推荐直接用第三方。
