开发过程中所遇到的一些问题，根据LeakCannary及Lint 检测予以修改并验证修改结果后，总结一些经验
优化
内存泄露
最常见也是最严重的 ：持有Activity 与Context引用，生命周期本该短于应用生命周期，该回收的没被回收掉，导致泄露
检测手段：leakcanary mit等
Handler泄露
new Handler 替换为 静态内部类
将持有当前Activity或Context 对象实例化为WeakReference对象
onDestory 时：handler.removeAllMessageAndCallback(null)
高级方案：仍采用静态内部类，提供CallBack,独立于使用者,避免Activity与Context直接引用
单例泄露
持有的Activity 使用WeakReference ，Context 使用ApplicationContext
去除不必要的Activity引用
泄露不止是Activity 与context,一旦持有比应用生命周期短的其他对象，也会发生泄露
此时需要考虑使用WeakReference
Fragment 之间静态属性引用 泄露
消灭静态属性
静态属性会一直持有当前Activity或Context引用
Fragment之间通讯可使用接口，Activity实现该接口， onAttach 将Activity转换为接口对象
Activity操作Fragmeng方式不变
高级方案：可使用MVVM ，ViewModel方式
Cursor 等游标、流的关闭
数据库操作：增删改查的游标，文件、网络操作流
用后close
List
onDestory销毁List：clear
WebView
onDestory销毁WebView ：removeJavaScript;removeAllView
高级方案：多进程
避免原则
尽可能保证持有的对象及时被回收，必须使用Activity的采用WeakReference,能使用ApplicationContext的不使用 当前Context
其他对象生命周期短于应用的，一旦持有了Context或Activity都有可能发生泄露，尽可能采用WeakReference
代码优化
优化的数据结构
HashMap 替换为SparseArray 等
枚举、匿名内部类、反射等
减少使用
布局，涉及过渡绘制等
背景
窗体背景，多余背景，减少过渡绘制有效手段
过渡绘制
include标签（通常用于公共布局组件）、merge（有效减少层级，但会出现不可控因素，属性失效等问题）、viewsub
减少不必要的层级
控件优化
比较突出的：
ImageView 与TextView 呈上下左右关系时，优先考虑
TextView增加drawable属性，即compoundDrawable
布局设置：drawableLeft ,drawableTop, drawableRight,drawableBoottom
图片文字间距使用：drawablePadding
代码设置：setCompoundDrawablesRelativeWithIntrinsicBounds(left，top,right,bottoom)
内存、网络、电池
BitMap的回收，应用不可见的监听，减少app被系统关闭的几率
安装包与第三方
无用资源，大图，图片适配，减少不必要的图片，png替换为.9,简单图片代码实现优先
lib 文件
开发与测试
架构
业务、实现分离
MVP或MVVM等
viewmodel
代码规则：命名，方法数，自解释
目的：便于维护
流程
测试环节
如：用例覆盖，情景覆盖，功能效果与产品需求匹配度等，数据抓取，可考虑以下方案增强
全员测试
开发阶段
由开发把控，确认主要流程功能完成后打包安排测试，主要为产品确认功能实现情况，及时发现问题，以免后期不断产生功能修改，耽误开发进度
测试阶段
除测试外所有相关人员，包括但不限于：前后端开发、产品、项目负责人
上线前
最后的问题发现修改阶段，也是最后的问题修改阶段，避免上线前后发生重大问题
测试次数
问题修改完一批次之后统一回归，可分为第一轮至第三轮甚至四轮，根据测试及bug情况安排，除第一轮外后续皆主要为回归，最后一轮进行线上环境测试，确认功能与稳定性，正式上线前可考虑发布小范围用户安装包进行用户实际环境测试，俗称灰度
测试用例
测试拿到需求之后可编写测试用例，此用例可指导其他人进行功能验证，减少测试人员压力
目的
控制bug数量，减少测试费时，尽可能的发现隐藏的问题，避免上线后发生重大事故
提升项目质量
数据监控
抓取手法
可使用Charles,Fiddler等
数据类问题可直接由bug测出人员定位，避免其他人浪费时间定位
版本分离
bug分离
上线后的bug确认是否为重大bug是否需要修改，一旦确认可下期修改，则可列为后期版本优先修改内容
api数据分离
最基本的数据稳定性保持方法
api上线时，安装包未必会及时被上传，此时线上环境已经发生变动，而用户所用仍为老版本，一旦数据不兼容，用户无法正常使用
api可根据app的versioncode与平台等多参数进行数据隔离
问题监测
主要为稳定性服务
手段包括但不限于：
真实用户实时崩溃日志：百度等
内嵌的日志收集上传功能
后台统计与收集
开发阶段的崩溃收集：崩溃截取显示上传功能
开发阶段
编写高质量代码
性能优化
leakcanary 内存泄露
findbug bug 、隐藏问题
removed unused resoures 剔除废弃资源
lint 找出隐藏问题，优化代码，重点关注Performance 如泄露，Correctness,Security