背景
现在安卓系统无论是性能还是体验上其实都不输于iOS,只是因为手机厂商多而杂,他们会改源码,自定义系统,最后又过一遍不同开发水平工程师的手,导致很多手机即使在机器上面的跑分非常高,里面的APP运行也有卡顿现象。
而且这种卡顿会随着产品的更新迭代,功能的越发复杂,UI页面的越发丰富,变得更加严重。
但是,产品功能的更新需求,新功能的开发和UI的丰富都是用户的需求,是不可逆的趋势。在这样的情况下,优秀的性能优化人才一直是几大头部互联网公司高价竞聘的对象。
性能优化的目的
- 流畅(解决:卡顿)
- 稳定(解决:内存溢出、崩溃)
- 低耗损(解决:耗电快、流量大、网络慢)
- 小安装包(解决:APK过大)
性能优化的方向
- 布局优化
- 绘制优化
- 网络优化
- APK优化
- 内存优化
- 卡顿优化
- 耗电优化
- ListView/RecycleView及Bitmap/图片优化
- 数据库SQLite优化
- 启动优化
- 数据结构优化
- 稳定性优化
性能优化方案
布局优化
本质:减少View的层级,提高测量、布局和绘制的速度。
常用方案:
- 优先选择LinearLayout布局可以减少View的层级(注意相同组件可能RelativeLayout绘制时间长);
- 使用 < include > 标签抽取常用的布局组件中的共同部分(便于复用);
- 用 < ViewStub > 标签加载不常用的布局,延迟加载(需要的时候在activity中加载出来);
- 用 < Merge > 标签减少布局的嵌套层次
绘制优化
本质:View的onDraw方法要避免执行大量的操作
常用方案:
onDraw中不要创建新的局部对象(避免产生大量的临时对象占用过多内存);
onDraw方法中不要做耗时的任务(尽量降低onDraw方法中的复杂度)
网络优化
本质:减少流量消耗、电量消耗、用户等待时间,提高用户体验。
常用方案:
- 尽量减少网络请求,能够合并的就尽量合并
- 避免DNS解析,根据域名查询可能会耗费上百毫秒的时间,也可能存在DNS劫持的风险。可以根据业务需求采用增加动态更新IP的方式,或者在IP方式访问失败时-
切换到域名访问方式。- 大量数据的加载采用分页的方式
- 网络数据传输采用GZIP压缩
- 加入网络数据的缓存,避免频繁请求网络
- 上传图片时,在必要的时候压缩图片
APK优化
本质:减少安装包体积。
常用方案:
- 减少应用中不必要的资源文件,比如图片,在不影响APP效果的情况下尽量压缩图片,有一定的效果
- 在使用了SO库的时候优先保留v7版本的SO库,删掉其他版本的SO库。
- res资源优化
- 代码优化
- lib资源优化
- assets资源优化
- 代码混淆
- 插件化
- 7z极限压缩
PS:详细具体的操作实现实现原理,后文另外有专门的分析。
内存优化
本质:避免内存泄漏、扩大内存。
常用方案(从不同方向讨论):
扩大内存:
- 一个是在清单文件中的Application下添加largeHeap="true"这个属性,另一个就是同一个应用开启多个进程来扩大一个应用的总内存空间。
- 第二种方法其实就很常见了,比方说我使用过个推的SDK,个推的Service其实就是处在另外一个单独的进程中。
内存泄漏(多方向讨论):
静态变量导致的内存泄漏
办法:将内部类设为静态内部类或独立出来;使用context.getApplicationContext()。
单例模式导致的内存泄漏
方案:传参context.getApplicationContext()。
属性动画导致的内存泄漏
方案:在Activity.onDestroy()中调用Animator.cancel()停止动画。
Handler导致的内存泄漏
方案:使用静态内部类+WeakReference弱引用;当外部类结束生命周期时清空消息队列。
线程导致的内存泄漏
方案:将AsyncTask和Runnable设为静态内部类或独立出来;在线程内部采用弱引用保存Context引用。
资源未关闭导致的内存泄漏
方案:在Activity销毁的时候要及时关闭或者注销。例如:
① BraodcastReceiver:调用unregisterReceiver()注销;
②Cursor,Stream、File:调用close()关闭;
③Bitmap:调用recycle()释放内存(2.3版本后无需手动)。
Adapter导致的内存泄漏
方案:在构造Adapter时使用缓存的convertView。
WebView导致的内存泄漏
方案:其实避免WebView导致内存泄漏的最好方法就是让WebView所在的Activity处于另一个进程中,当这个Activity结束时杀死当前WebView所处的进程即可,我记得阿里钉钉的WebView就是另外开启的一个进程,应该也是采用这种方法避免内存泄漏。
集合类泄漏
方案:在onDestry时回收不需要的集合。
PS:为什么会导致泄漏,以及泄漏的具体情况,更多原理,后文另外有专门的分析整理。
卡顿优化
本质:优化UI、提高启动跳转还有响应的速度。
常用方案:
- 不在主线程进行网络访问/大文件的IO操作
- 绘制UI尽量减少绘制UI层次;减少不必要的view嵌套,可以用Hierarchy Viewer工具来检测,后面会详细讲;
- 当布局是用的FrameLayout,可以把它改成merge,可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)
- 提高显示速度,使用ViewStub:当加载的时候才会占用。不加载的时候就是隐藏的,仅仅占用位置。
- 在view层级相同的情况下,尽量使用 LinerLayout而不是RelativeLayout;因为RelativeLayout在测量的时候会测量二次,而LinerLayout测量一次,可以看下它们的源码;
- 删除控件中无用的属性;
- 布局复用.比如listView 布局复用
- 尽量避免过度绘制(overdraw),比如:背景经常容易造成过度绘制。由于我们布局设置了背景,同时用到的MaterialDesign的主题会默认给一个背景。这时应该把主题添加的背景去掉;还有移除
- XML 中非必须的背景
- 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域,只有在这个区域内才会被绘制。也是避免过度绘制.
- 启动优化,启动速度的监控,发现影响启动速度的问题所在,优化启动逻辑,提高应用的启动速度。比如闪屏页面,合理优化布局,加载逻辑优化,数据准备.
- 合理的刷新机制,尽量减少刷新次数,尽量避免后台有高的 CPU 线程运行,缩小刷新区域。
耗电优化
本质:减少电量消耗。
常用方案:
- 合理的使用wake_lock锁,wake_lock锁主要是相对系统的休眠(这里就是为了省电,才做休)而言的,意思就是我的程序给CPU加了这个锁那系统就不会休眠了,这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题,比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了wake_lock锁。
- 使用jobScheduler2,集中处理一些网络请求,有些不用很及时的处理可以放在充电的时候处理,比如,图片的处理,APP下载更新等等;
- 计算优化,避开浮点运算等。
- 数据在网络上传输时,尽量压缩数据后再传输,建议用FlatBuffer序列化技术,这个比json效率高很多倍,不了解FlatBuffer,建议找资料学习一下。
现如今,国内移动互联网红利期已过,Android 开发也从最初的一人难求,到后来的一个岗位百人竞投,僧多粥少的情况直接导致整个行业对求职者的要求越来越高,Android 开发越来越规范,间接导致项目对质量要求的提升。启动优化、内存优化、App 崩溃监控等性能调优也逐渐成了人手必备的技能。
学习资源和路线
我这里就分享一份由大佬亲自收录整理的性能优化学习笔记,另外还有Android学习PDF+架构视频+面试文档+Android开发面试专题资料,高级进阶架构资料和视频。
![](https://i-blog.csdnimg.cn/blog_migrate/f49e6db7af5701b4dbd38aad611c4411.jpeg)
总结
这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理,帮助大家在未来取得一份不错的答卷。
希望能帮助大家在技术的道路上更进一步。当然,你也可以拿去查漏补缺,提升自身的竞争力。真心希望可以帮助到大家,Android路漫漫,共勉!
由于文章篇幅有限,文档资料内容较多,有需要这份《Android性能优化—实战解析》完整版可以扫我们的官方二维码,希望能够共同进步,共勉!