某版本延期总结
问题:
技术方面:
OOM:风控SDK的lifelistener,导致持有activity,内存无法释放
多次操作下单流程,程序崩溃:线程管理混乱,导致线程不断创建,内存OOM(具体的原因没有定位到,只是看到的表象)
并发的读写文件:多线程的文件读写,引发出来的流问题
暴露出来的问题:
SDK的测试验证过程与业务开发不同,而且影响面更大(原先的业务测试流程无法适用),隐蔽性更大
没有紧跟bugly,没有及时发现问题
没有关注app的性能与内存
try,catch并没有及时暴露出问题
代码方案,需要审核
未删除不用的资源与代码
需要做的事情:
排查所有出现线上crash的代码
SDK测试监控,流程更完善
B,C端的app性能监控,优化
学到的东西:
开发,测试流程必须规范
activitylifelistener的慎重使用,建议使用弱引用
并发文件的读写
需要及时的反馈(反馈的重要性)
第三方的框架使用更理性
JVM的知识需要深入
线程的知识需要深入
性能优化的知识需要深入
SDK发布流程:
阶段一--开发自测:
关注代码功能的跑通
关注exception的问题
阶段二--业务方引入:
日志记录
关注SDK的引入,有没有引出新的exception
是否引起了crash
是否引起了内存泄漏,OOM
线程数的泛滥
是否引起了app的卡顿
此阶段的SDK为SNAPSHOT版本,这个阶段的代码不做try,catch,尽可能得让他崩溃,且SDK的catch(有些代码必须防止try cache的,比如文件读写)的excepton,上传到bugly
阶段三--上线:
发布前,改用正式版本
此阶段的SDK为release版本,会做try catch处理,同时移除exception的bugly的上传
关注线上的crash
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。