项目经验(1): 手游宝一年的总结 - clarkehe/Android GitHub Wiki
工作要点
每日：
- 版本crash率，特别是灰度版本。
- 灯塔协议成功率等质量数据。
- DAU等产品MTA数据。
- FindBugs扫描结果。
- 金刚扫描结果。
其他定期任务：
- 工程无用资源、代码扫描。
- 用户反馈关注：邮件反馈，应用宝反馈，其他产品的反馈渠道。
需求评审：
- 评审会叫上所有人，需求还是从头开始了解。
- 需求分配后，需要有针对性对需求进行细评（也可开发找产品单独确认），确认细节。
迭代：
- 每日进度。
- bug修改情况。(包括适配bug, FindBugs的bug)
- 关注每个人的代码提交，看修改点，实现思路、协议。
- 关注平台的功能，特别是代码交互的功能，除了看功能是否正常外，还是看接口调用的细节。
- 要求平台迟早返回需求专区处理的问题，不要等到最后或发布前。
开发：
- 自己改或修改的代码最好跑一遍、看日志，还最好单步执行一遍。
- java中类型强制不安全，有些机型可以，有些可能就不行。加 is instanceof？
- 技术方案确认？
- 技术方案与IOS同步。
转测：
- 测试点要列全，每个点要注意的地方要加上（开发人员列、需求单）;
- 其他优化、重构的点。
- 测试要点要RTX甚至口头确认。
- 平台专区交叉的点在确认，谁负责测试。
- 发布前的提交要慎重，没有必要修改代码的可以不提交。
- 已经稳定的模块如果没有必要，不修改；修改了也要充分自测，并提交测试回归。
- 旧版本兼容性测试。服务器发布前用旧客户端测试兼容。
- 适配测试。一般在灰度期间，使用稳定Release包测试，不用稳定版本会测出一些功能BUG, 使用测试重点不在兼容性上。需要测试提前预约安排。
测试：
- 需求评审、项目迭代没有叫上测试人员；
- 测试用例还是很有必要，避免回归时遗漏一些点。
- 平台、专区交叉需求，导致两边都没有关注。
- 提crash的bug时，除带了log文件外，还带上crash文件。
发布：
- Bug清理.
- RDM上的CRASH清理。
- FindBugs清理。
- 发布前，在功能稳定的前提下，尽量不要重构、优化代码。
这个问题说过很多次，其实一直在犯这个错误。多次情况都证明，
这种重构会带来问题。
其他经验：
- pb协议定义，返回码使用：int result。
- XML布局文件，字体大小使用dp，不是sp。
- 效果图及标准：尺寸＝1280x720, dpi＝2。
- 小图标使用字体文件。IconFontTextView
- 服务器更新图片，要改名。本地缓存是以名字为KEY.
- 图片资源尽可能的使用JPG格式，文件小一点。
质量监控及优化：
- crash：RDM
- ANR: RDM
- 产品数据：MTA
- 协议成功率（Web及图片加载）：灯塔
- FindBugs及金刚扫描：邮件
- 启动速度？wxPerformance：布局、逻辑优化
- 流畅度？ 过度绘制、布局优化
- 内存泄漏。LeakCanary
- 内存占用？
- 流量使用？
- 包大小？：无用资源及代码扫描。gradle lintClean