一、UI优化
1.布局优化
1.1 减少嵌套层级 ,页面比较简单时可以使用merge来减少层级,当页面层级很多时,可以考虑使用ConstraintLayout来减少层级嵌套;
1.2 当层级相同时,优先使用FrameLayout、LinerLayout其次时RelativeLayout,因为FrameLayout的渲染速度最快,其次是LinerLayout,然后是RelativeLayout;
1.3 布局复用,使用<include>标签重用layout;
1.4 提高显示速度,使用<ViewStub>延迟View加载;
1.5 注意使用wrap_content,会增加measure计算成本;
2.避免过度渲染
2.1 移除 XML 中非必须的背景,移除 Window 默认的背景、按需显示占位背景图片
2.2 自定义View优化,使用 canvas.clipRect()来帮助系统识别那些可见的区域,只有在这个区域内才会被绘制
二、内存优化
1. 内存泄漏的主要原因的长生命周期的变量持有短生命周期对象的引用,导致短生命周期的对象不能及时被回收。
2. 减少全局变量的使用,因为全局变量的生命周期较长。
3. 使用SparseArray代替HashMap。
4. bitmap加载前没有进行压缩处理,导致OOM,或者加载后没有释放,导致内存泄漏。
5. listview优化:convertView复用,不要在getView中创建对象,滑动时不加载图片。
6. 单例模式造成内存泄漏,单例的静态特性使得它的生命周期跟APP的生命周期一样长,如果一个对象已经没有用了,但是单例还持有它的引用,则会造成内存泄漏。构造单例尽量别使用Activity的引用,改用Application的context。
7. 非静态内部类造成内存泄漏,非静态内部类会持有外部类的引用,如果外部类的生命周期比内部类短,就会导致外部类无法被回收,从而造成内存泄漏。常见Handler就会造成这个问题,解决办法:使用弱引用,并在Activity销毁时清空Handler中的消息。
8. 资源对象及时关闭导致内存泄漏:IO流没有关闭,sql 中的cursor没有关闭。
9. 未取消注册或回调导致内存泄漏:如广播没有反注册,导致广播一直存在系统中。
10. 动画导致内存泄漏:动画是一个耗时操作,如果启动了动画后,在页面或视图销毁时没有调用cancle销毁动画,这个动画虽然看不见了但会一直不断地播下去,动画引用的view,view引用的activity无法正常释放造成内存泄漏。
11. webview没有及时销毁造成内存泄漏。
三、网络优化
待完善。。。
四、APK瘦身
先了解apk的组成部分:
文件或目录 | 作用 |
---|---|
META-INF/ | 也就是一个 manifest ,从 java jar 文件引入的描述包信息的目录 |
res/ | 资源文件目录 |
libs/ | 存放 ndk 编出来的 so 库 |
AndroidManifest.xml | 程序全局配置文件 |
classes.dex | dalvik 字节码 |
resources.ars | 编译后的二进制资源文件 |
其中res和libs以及classes.dex的体积较大,所以我们应该想办法减少这几个文件的大小。
- 代码混淆,使用proGuard 代码混淆器工具,它包括压缩、优化、混淆等功能。
- 资源优化,比如使用 Android Lint 删除冗余资源,资源文件最少化等。
- 图片优化,使用webp格式,支持有损和无损压缩,支持透明通道和多帧动画,4.0以上是开发首选,Google官方测试,WebP比PNG能减少45%大小,即便PNG经过压缩,也能相比PNG减小28%
- 去除不必要的平台ABI的so文件,不是特别要求,可以只保留armeabi-v7a 的so。
其他优化:
电量优化,启动优化,刷新优化待完善。。。