应用优化开发探索实践总结

开发过程中所遇到的一些问题，根据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