针对Android的性能优化,主要有如下几个有效的优化方法:html
1.布局优化java
2.绘制优化android
3.内存泄漏优化git
4.响应速度优化程序员
5.ListView/RecycleView及Bitmap优化github
6.线程优化面试
7.其余性能优化的建议缓存
下面咱们具体来介绍关于以上这几个方面优化的具体思路及解决方案。性能优化
关于布局优化的思想很简单,就是尽可能减小布局文件的层级。这个道理很浅显,布局中的层级少了,就意味着Android绘制时的工做量少了,那么程序的性能天然就提升了。数据结构
①删除布局中无用的控件和层次,其次有选择地使用性能比较低的ViewGroup。
关于有选择地使用性能比较低的ViewGroup,这就须要咱们开发就实际灵活选择了。
例如:若是布局中既可使用LinearLayout也可使用RelativeLayout,那么就采用LinearLayout,这是由于RelativeLayout的功能比较复杂,它的布局过程须要花费更多的CPU时间。FrameLayout和LinearLayout同样都是一种简单高效的ViewGroup,所以能够考虑使用它们,可是不少时候单纯经过一个LinearLayout或者FrameLayout没法实现产品效果,须要经过嵌套的方式来完成。这种状况下仍是建议采用RelativeLayout,由于ViewGroup的嵌套就至关于增长了布局的层级,一样会下降程序的性能。
②采用标签: include,merge,ViewStub
标签主要用于布局重用。
标签通常要配合使用,能够下降减小布局的层级。
ViewStub提供了按需加载的功能,当须要时才会将ViewStub中的布局加载到内存,提升了程序初始化效率。
③避免多度绘制
过分绘制(Overdraw)描述的是屏幕上的某个像素在同一帧的时间内被绘制了屡次。在多层次重叠的 UI 结构里面,若是不可见的 UI 也在作绘制的操做,会致使某些像素区域被绘制了屡次,同时也会浪费大量的 CPU 以及 GPU 资源。
以下所示,有些部分在布局时,会被重复绘制。
关于过分绘制产生的通常场景及解决方案,参考:Android 过分绘制优化
绘制优化是指View的onDraw方法要避免执行大量的操做,这主要体如今两个方面:
①onDraw中不要建立新的局部对象。
由于onDraw方法可能会被频繁调用,这样就会在一瞬间产生大量的临时对象,这不只占用了过多的内存并且还会致使系统更加频繁gc,下降了程序的执行效率。
②onDraw方法中不要作耗时的任务,也不能执行成千上万次的循环操做,尽管每次循环都很轻量级,可是大量的循环仍然十分抢占CPU的时间片,这会形成View的绘制过程不流畅。
按照Google官方给出的性能优化典范中的标准,View的绘制频率保证60fps是最佳的,这就要求每帧绘制时间不超过16ms(16ms = 1000/60),虽然程序很难保证16ms这个时间,可是尽可能下降onDraw方法中的复杂度老是切实有效的。
内存泄漏是开发过程当中的一个须要重视的问题,可是因为内存泄露问题对开发人员的经验和开发意识有较高的要求,所以也是开发人员最容易犯的错误之一。
内存泄露的优化分为两个方面:
①在开发过程当中避免写出有内存泄漏的代码
②经过一些分析工具好比MAT来找出潜在的内存泄露,而后解决。
对应于两种不一样状况,一个是了解内存泄漏的可能场景以及如何规避,二是怎么查找内存泄漏。
你们都知道,java是有垃圾回收机制的,这使得java程序员比C++程序员轻松了许多,存储申请了,不用心心念念要加一句释放,java虚拟机会派出一些回收线程兢兢业业不定时地回收那些再也不被须要的内存空间(注意回收的不是对象自己,而是对象占据的内存空间)。
Q1:什么叫再也不被须要的内存空间?
答:Java没有指针,全凭引用来和对象进行关联,经过引用来操做对象。若是一个对象没有与任何引用关联,那么这个对象也就不太可能被使用到了,回收器即是把这些“无任何引用的对象”做为目标,回收了它们占据的内存空间。
Q2:如何分辨为对象无引用?
答:2种方法
引用计数法直接计数,简单高效,Python即是采用该方法。可是若是出现 两个对象相互引用,即便它们都没法被外界访问到,计数器不为0它们也始终不会被回收。为了解决该问题,java采用的是b方法。
可达性分析法这个方法设置了一系列的“GC Roots”对象做为索引发点,若是一个对象 与起点对象之间均无可达路径,那么这个不可达的对象就会成为回收对象。这种方法处理 两个对象相互引用的问题,若是两个对象均没有外部引用,会被判断为不可达对象进而被回收(以下图)。
Q3:有了回收机制,放心大胆用不会有内存泄漏?
答:答案固然是No!
虽然垃圾回收器会帮咱们干掉大部分无用的内存空间,可是对于还保持着引用,但逻辑上已经不会再用到的对象,垃圾回收器不会回收它们。这些对象积累在内存中,直到程序结束,就是咱们所说的“内存泄漏”。 固然了,用户对单次的内存泄漏并无什么感知,但当泄漏积累到内存都被消耗完,就会致使卡顿,崩溃。
下面这张图能够帮助咱们更好地理解对象的状态,以及内存泄漏的状况
左边未引用的对象是会被GC回收的,右边被引用的对象不会被GC回收,可是未使用的对象中除了未引用的对象,还包括已被引用的一部分对象,那么内存泄漏久发生这部分已被引用但未使用的对象。
①集合类泄漏 ②单例/静态变量形成的内存泄漏 ③匿名内部类/非静态内部类 ④资源未关闭形成的内存泄漏
大概能够分为以上几类,还有一些常常会听到的Hanlder,Thread,AsyncTask引发内存泄漏,都属于上述③中的状况。
那么上述四种状况是怎么形成的内存泄漏,具体是什么缘由,以及Android中一些知名的引发内存泄漏的缘由,以及解决方法是怎么样的?
上面介绍了内存泄漏的场景,对应的有一些解决方案。
那么在内存泄漏已经发生的状况下,咱们该如何解决呢?
咱们能够经过MAT(Memory Analyzer Tool),或者 LeakCanary来检测Android中的内存泄漏。
响应速度优化的核心思想就是避免在主线程中作耗时操做。
若是有耗时操做,能够开启子线程执行,即采用异步的方式来执行耗时操做。
若是在主线程中作太多事情,会致使Activity启动时出现黑屏现象,甚至ANR。
Android规定,Activity若是5秒钟以内没法响应屏幕触摸事件或者键盘输入事件就会出现ANR,而BroadcastReceiver若是10秒钟以内还未执行完操做也会出现ANR。
为了不ANR,能够开启子线程执行耗时操做,可是子线程不能更新UI,因此须要子线程与主线程进行通讯来解决子线程执行耗时任务后,通知主线程更新UI的场景。关于这部分,须要掌握Handler消息机制,AsyncTask,IntentService等内容。
然而,在实际开发中,ANR仍然不可避免的发生了,并且很难从代码上发现,这时候就要用到ANR日志分析。当一个进程发生了ANR以后,系统会在/data/anr目录下建立一个文件traces.txt,经过分析这个文件就能定位出ANR的缘由。
ListView/RecycleView的优化思想主要从如下几个方面入手:
①使用ViewHolder模式来提升效率
②异步加载:耗时的操做放在异步线程中
③ListView/RecycleView的滑动时中止加载和分页加载
具体优化建议及详情,参考:ListView的优化
Bitmap优化
主要是对加载图片进行压缩,避免加载图片多大致使OOM出现。
线程优化的思想就是****采用线程池,避免程序中存在大量的Thread。线程池能够重用内部的线程,从而避免了线程的建立和销毁锁带来的性能开销,同时线程池还能有效地控制线程池的最大并法术,避免大量的线程因互相抢占系统资源从而致使阻塞现象的发生。所以在实际开发中,尽可能采用线程池,而不是每次都要建立一个Thread对象。
①避免过分的建立对象
②不要过分使用枚举,枚举占用的内存空间要比整型大
③常量请使用static final来修饰
④使用一些Android特有的数据结构,好比SparseArray和Pair等
⑤适当采用软引用和弱引用
⑥采用内存缓存和磁盘缓存
⑦尽可能采用静态内部类,这样能够避免潜在的因为内部类而致使的内存泄漏。
以上是关于Android性能优化方面,咱们一些入手点。从这些方面,咱们能够在平时的开发中注意,避免相似错误,提升Android程序的性能,可是其中一些方面的要求则须要咱们不断的学习,以及平时良好的意识与习惯。因为本身开发经验几乎为0,没办法根据实际经验来讲明,只能写下这篇文章来提醒本身之后开发的时候须要注意和培养的地方。
关于Android优化的所有学习内容,咱们这边都有系统的知识体系以及进阶视频资料,有须要的朋友能够加群免费领取安卓进阶视频教程,源码,面试资料,群内有大牛一块儿交流讨论技术;点击连接加入群聊【腾讯@Android高级架构】
(包括自定义控件、NDK、架构设计、混合式开发工程师(React native,Weex)、性能优化、完整商业项目开发等)