你的位置:首页 > 操作系统

[操作系统]android 性能优化


本章介绍android高级开发中,对于性能方面的处理。主要包括电量,视图,内存三个性能方面的知识点。

1.视图性能

(1)Overdraw简介

    Overdraw就是过度绘制,是指在一帧的时间内(16.67ms)像素被绘制了多次,理论上一个像素每次只绘制一次是最优的,但是由于重叠的布 局导致一些像素会被多次绘制,而每次绘制都会对应到CPU的一组绘图命令和GPU的一些操作,当这个操作耗时超过16.67ms时,就会出现掉帧现象,表现为应用卡顿,所以对重叠不可见元素的重复绘制会产生额外的开销,需要尽量减少Overdraw的发生。

(2)Overdraw检测

    Android提供了测量Overdraw的选项,在开发者选项-调试GPU过度绘制(Show GPU Overdraw),打开选项就可以看到当前页面Overdraw的状态,就可以观察屏幕的绘制状态。该工具会使用三种不同的颜色绘制屏幕,来指示 overdraw发生在哪里以及程度如何,其中:

  • 没有颜色: 意味着没有overdraw。像素只画了一次。
  • 蓝色: 意味着overdraw 1倍。像素绘制了两次。大片的蓝色还是可以接受的(若整个窗口是蓝色的,可以摆脱一层)。
  • 绿色: 意味着overdraw 2倍。像素绘制了三次。中等大小的绿色区域是可以接受的但你应该尝试优化、减少它们。
  • 浅红: 意味着overdraw 3倍。像素绘制了四次,小范围可以接受。
  • 暗红: 意味着overdraw 4倍。像素绘制了五次或者更多。这是错误的,要修复它们。

3)去掉其他不必要的背景

    父容器若已经有了背景,可不设置对应子控件的背景,及大的布局背景已经设置,应避免设置局部重复的背景。

4)自定义View处理

    对于自定义的view视图,可以通过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域,只有在这个区域内才会被绘制,其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源,在clipRect区域之外的绘制指令都不会被执行,那些部分内容在矩形区域内的组件,仍然会得到绘制。除了clipRect方法之外,我们还可以使用canvas.quickreject()来判断是否没和某个矩形相交,从而跳过那些非矩形区域内的绘制操作。

5)ViewStub高效占位符

    当遇到这样的情况,运行时动态根据条件来决定显示哪个View或布局。常用的做法是把View都写在上面,先把它们的可见性都设为 View.GONE,然后在代码中动态的更改它的可见性。这种模式的缺点是耗费资源。虽然把View 的初始View.GONE但是在Inflate布局的时候View仍然会被Inflate,程序运行时仍然会创建对象,会被实例化,会被设置属性,会耗费内存等资源。

    推荐的做法是使用android.view.ViewStub,ViewStub是一个轻量级的View,它一个看不见的,不占布局位置,占用资源非常小的控件。可以为ViewStub指定一个布局,在Inflate布局的时候,只有ViewStub会被初始化,然后当ViewStub被设置为可见的时候,或是调用了ViewStub.inflate()的时候,ViewStub所向的布局就会被Inflate和实例化,然后ViewStub的布局属性都会传给它所指向的布局。这样,就可以使用ViewStub来方便的在运行时,要还是不要显示某个布局。

6)善用draw9patch

    给ImageView加一个边框,通常在ImageView后面设置一张背景图,露出边框便完美解决问题,此时这个 ImageView,设置了两层drawable,两层drawable的重叠区域去绘制了两次,导致 overdraw。优化方案: 将背景drawable制作成draw9patch,并且将和前景重叠的部分设置为透明。由于Android的2D渲染器会优化draw9patch中的透明区域,从而优化了这次overdraw。

7)Merge 

    使用Merge标签来做容器控件。第一种子视图不需要指定任何针对父视图的布局属性,就是说父容器仅仅是个容器,子视图只需要直接添加到父视图上用于显示 就 行。另外一种是假如需要在LinearLayout里面嵌入一个布局 (或者视图),而恰恰这个布局(或者视图)的根节点也是LinearLayout,这样就多了一层没有用的嵌套,无疑这样只会拖慢程序速度。而这个时候如 果我们使用merge根标签就可以避免那样的问题。

2.内存性能

(1)内存分配与回收

    每一个进程的Dalvik Heap都反映了使用内存的占用范围。这就是通常逻辑意义上提到的Dalvik Heap Size,它可以随着需要进行增长,但是增长行为会有一个系统为它设定上限。

    逻辑上讲的Heap Size和实际物理意义上使用的内存大小是不对等的,Proportional Set Size(PSS)记录了应用程序自身占用以及与其他进程进行共享的内存。

    Android 系统并不会对Heap中空闲内存区域做碎片整理。系统仅仅会在新的内存分配之前判断Heap的尾端剩余空间是否足够,如果空间不够会触发GC操作,从而腾 出更多空闲的内存空间。在Android的高级系统版本里面针对Heap空间有一个Generational Heap Memory的模型,最近分配的对象会存放在Young Generation区域。当这个对象在该区域停留的时间达到一定程度,它会被移动到Old Generation,最后累积一定时间再移动到Permanent Generation区域。系统会根据内存中不同的内存数据类型分别执行不同的GC操作。例如,刚分配到Young Generation区域的对象通常更容易被销毁回收,同时在Young Generation区域的GC操作速度会比Old Generation区域的GC操作速度更快(如图1所示)。

 图1  根据不同内存数据类型执行不同GC操作

    每一个Generation的内存区域都有固定的大小。随着新的对象陆续被分配到此区域,当对象总的大小临近这一级别内存区域的阀值时,会触发GC操作,以便腾出空间来存放其他新的对象(如图2所示)。

图2  对象值临近阀值触发GC操作

    通常情况下,GC发生的时候,所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系,Young Generation中的每次GC操作时间是最短的,Old Generation其次,Permanent Generation最长。执行时间的长短也和当前Generation中的对象数量有关,遍历树结构查找20000个对象比起遍历50个对象自然是要慢 很多的。

(2)内存测试插件

1)LeakCanary简介

    LeakCanary是一个用于检测内存泄漏的工具,可以用于Java和Android,是由著名开源组织Square贡献。

    电量其实是目前手持设备最宝贵的资源之一,大多数设备都需要不断的充电来维持继续使用。不幸的是,对于开发者来说,电量优化是他们最后才会考虑的的事情。但是可以确定的是,千万不能让你的应用成为消耗电量的大户。

有下面一些措施能够显著减少电量的消耗:

  • 我们应该尽量减少唤醒屏幕的次数与持续的时间,使用WakeLock来处理唤醒的问题,能够正确执行唤醒操作并根据设定及时关闭操作进入睡眠状态。
  • 某些非必须马上执行的操作,例如上传歌曲,图片处理等,可以等到设备处于充电状态或者电量充足的时候才进行。
  • 触发网络请求的操作,每次都会保持无线信号持续一段时间,我们可以把零散的网络请求打包进行一次操作,避免过多的无线信号引起的电量消耗。关于网络请求引起无线信号的电量消耗。

1)消耗电量的几个主要原因、功能

  • 大数据量的网络传输(网络)
  • 不停的网络切换(网络)
  • 解析大量的数据(CPU)

2)关于网络方面的优化

  • 网络请求之前,检查网络连接。没有网络连接不进行请求
  • 判断网络类型,针对特定的数据在特定的网络下请求。例如:大量数据传输的时候,在wifi下请求。wifi下下载数据耗电量只有2、3、4G的1/3.
  • 使用效率高的解析工具。根据具体业务数据量的大小,选择合适的解析工具。例如android上面的协议解析一般推荐json。
  • 使用GZIP压缩方式下载数据,能减少网络流量,缩短下载时间
  • 合理使用缓存,避免重复操作
  • 使用推送,代替循环请求
  • 触发网络请求的操作,每次都会保持无线信号持续一段时间,我们可以把零散的网络请求打包进行一次操作,避免过多的无线信号引起的电量消耗。
  • 是JobScheduler API所做的事情。它会根据当前的情况与任务,组合出理想的唤醒时间,例如等到正在充电或者连接到WiFi的时候,或者集中任务一起执行。我们可以通过这个API实现很多免费的调度算法。

3)电量优化策略

  • 检查全部唤醒锁, 是否存在冗余或者无用的位置.
  • 集中相关的数据请求, 统一发送; 精简数据, 减少无用数据的传输.
  • 分析和统计等非重要操作, 可以在电量充足或连接WIFI时进行, 参考JobScheduler.
  • 精简冗余的服务(Service), 避免长时间执行耗电操作.
  • 注意定位信息的获取, 使用后及时关闭.