2018-02-25 Android应用优化总结

内存泄漏

最常见也是最严重的 ：持有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