ToB企服应用市场:ToB评测及商务社交产业平台

标题: Android 体系省电软件分析 [打印本页]

作者: 金歌 时间: 2024-6-22 09:35
标题: Android 体系省电软件分析
1、硬件耗电

主要有：
1、屏幕
2、CPU
3、WLAN
4、感应器
5、GPS(目前我们没有)
电量其实是目前手持设备最宝贵的资源之一，大多数设备都需要不断的充电来维持继承使用。不幸的是，对于开发者来说，电量优化是他们最后才会考虑的的事情。但是可以确定的是，千万不能让你的应用成为斲丧电量的大户
2、参考

2.1

2.2

Purdue University研究了最受欢迎的一些应用的电量斲丧，平均只有30%左右的电量是被程序最焦点的方法比方绘制图片，摆放布局等等所使用掉的，剩下的70%左右的电量是被上报数据，检查位置信息，定时检索配景广告信息所使用掉的。如何均衡这两者的电量斲丧，就显得非常重要了。

2.3

2.4

3、WIFI耗电

前段时间做的省电主要是针对wifi的，三种情况下结果很显着：
1、桌面待机
2、任何应用Home键待机
3、用欣赏器大概爱奇艺看视频待机，这种结果相称的显着，完全秒杀
小米平板；同时待机86个小时小米平板（6700毫安）：没电主动关机
K1平板(4060毫安) ：还剩68%
如许处置惩罚事后，平板待机时间至少是10天
4、配景应用

目前我们做的做法是配景只保留一个配景程序。后期我们会考虑待机一定时间后，我们会把配景程序清理掉，如许会更省电。
5、APP进步续航

总体原则：进步性能
1、不作没有必要的工作
2、尽量避免内存分配
通常来讲，尽量避免创建短时暂时对象.少的对象创建意味着低频的垃圾接纳。而这对于用户体验产生直接的影响。
例：避免内部的Getters/Setters
在源生语言像C++中，通常做法是用Getters（i=getCount()）取代直接字段访问（
i=mCount）。这是C++中一个好的习惯，因为编译器会内联这些访问，并且如果需要约束大概调试这些域的访问，你可以在任何时间添加代码。
而在Android中，这不是一个好的做法。虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践，在公共接口中使用Getters和Setters是有道理的，但在一个字段经常被访问的类中宜采用直接访问。
无JIT时，直接字段访问大约比调用getter访问快3倍。有JIT时（直接访问字段开销等同于局部变量访问），要快7倍。在Froyo版本中确实云云，但以后版本可能会在JIT中改进Getter方法的内联。
6、布局

总体原则：控件尽量少、尽量减少布局层次
1、Textview +Imageview → Textview+icon（android:drawableXXX）
2、多个LinearLayout→单个RelativeLayout
3、使用标签来减少视图层级结构
4、通过标签来重用layout代码
5、Layout_weight使用时，android:layout_width大概android:layout_height值尽量为0，而不是自适应，为什么？
…
View渲染流程

7、WakeLock

尽量减少唤醒屏幕的次数与持续的时间(屏幕是用电大户)，用WakeLock来处置惩罚唤醒的问题，可以或许正确执行唤醒操作并根据设定实时关闭操作进入就寝状态，使用wakelock.acquice() 方法，一定要加上超时处置惩罚(比方释放锁)。
使用场景：Android中通过各种Lock锁对电源进⾏行控制，比如保持通信和配景续连。
另一种思路：
不消冒着忘记释放Wakelock的风险，交给体系处置惩罚，也不消在manifest中设置权限，只在布局文件XML声明即可，当然也可以用函数：View.setKeepScreenOn()方法控制即可。

8、优化网络

1、设置网络超时时间包括连接超时和请求超时
2、触发网络请求的操作，每次都会保持无线信号持续一段时间，我们可以把零散的网络请求打包进行一次操作，避免过多的无线信号引起的电量斲丧(比方APP的数据采集)。比如我们的大数据和推送等应用。
3、如果没有网络连接，你的应用跳过网络操作；只在有网络连接并且无漫游的情况下更新数据；
4、选择兼容的数据格式，把含有文本数据和二进制数据的请责备部转化成二进制数据格式请求；
5、使用高效的转换工具，多考虑使用流式转换工具，少用树形的转换工具；

很显着，使用流的方式解析效率要高一些，因为DOM解析是在对整个文档读取完后，再根据节点层次等再组织起来。而流的方式是边读取数据边解析，数据读取完后，解析也就完毕了。
在数据格式方面，JSON和Protobuf效率显着比XML好许多，XML和JSON各人都很熟悉，Protobuf是Google提出的，一种语言无关、平台无关、扩展性好的用于通信协议、数据存储的结构化数据串行化方法。
从上面的图中我们可以得出结论就是尽量使用SAX等边读取边解析的方式来解析数据，针对移动设备，最好能使用JSON之类的轻量级数据格式为佳。
6、如果可以的话，请使用framework的GZIP库来压缩文本数据以高效使用CPU资源。

9、调解定时更新的频率

int alarmType = AlarmManager.ELAPSED_REALTIME；
long interval = AlarmManager.INTERVAL_HOUR；
long start = System.currentTimeMillis() + interval；
alarmManager.setInexactRepeating(alarmType, start, interval, pi)；

复制代码

如果可以，请设置提醒的类型为ELAPSED_REALTIME or RTC而不是_WAKEUP;如许在体系就寝的时间不会唤醒CPU。
10、数据库使用事件

1、起首Android数据库操作（特殊是写操作）是非常慢的，将全部操作打包成一个事件能大大进步处置惩罚速度。
2、在setTransactionSuccessful和endTransaction之间不进行任何数据库操作。

11、Adapter标准

12、广播接收

1、尽量能不消静态注册就不要静态注册
2、尽量在onResume()和onPause()中进行注册与注销
3、广播用完后一定要记得注销
13、接纳对象

JVM的接纳机制给开发人员带来很大的好处，不消时刻处置惩罚对象的分配与接纳，可以更加专注于更加高级的代码实现。相比起Java，C与C++等语言具备更高的执行效率，他们需要开发人员本身关注对象的分配与接纳。
固然Java有主动接纳的机制，这不意味着Java中不存在内存走漏的问题，在一个庞大的体系当中，照旧免不了经常发生部分对象忘记接纳的情况，而内存走漏会很轻易导致严重的性能问题。
内存走漏指的是那些程序不再使用的对象无法被GC识别，如许就导致这个对象一直留在内存当中，占用了宝贵的内存空间。显然，这还使得每级Generation的内存区域可用空间变小，GC就会更轻易被触发，从而引起性能问题。
寻找内存走漏并修复这个毛病是件很棘手的事情，你需要对执行的代码很熟悉，清楚的知道在特定环境下是如何运行的，然后过细排查。
原始JVM中的GC机制在Android中得到了很大水平上的优化。Android里面是一个三级Generation的内存模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间到达一定水平，它会被移动到Old Generation，最后到Permanent Generation区域。

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。从设计师的角度，他们希望App可以或许有更多的动画，图片等时尚元素来实现流通的用户体验。但是Android体系很有可能无法实时完成那些复杂的界面渲染操作。Android体系每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都乐成，如许就可以或许到达流通的画面所需要的60fps，为了可以或许实现60fps，这意味着程序的大多数操作都必须在16ms内完成。
我们通常都会提到60fps与16ms，可是知道为何会是以程序是否到达60fps来作为App性能的衡量标准吗？这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。
12fps大概类似手动快速翻动书籍的帧率，这显着是可以感知到不够顺滑的。24fps使得人眼感知的是一连线性的活动，这其实是归功于活动模糊的结果。24fps是影戏胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分影戏画面需要表达的内容，同时可以或许最大的减少费用支出。但是低于30fps是无法顺畅体现壮丽的画面内容的，此时就需要用到60fps来到达想要的结果，当然超过60fps是没有必要的。
16=1000/60
通常来说，单个的GC并不会占用太多时间，但是大量不停的GC操作则会显著占用帧隔断时间(16ms)。如果在帧隔断时间里面做了过多的GC操作，那么自然其他类似计算，渲染等操作的可用时间就变得少了。
Android对GC做了大量的优化操作，固然执行GC操作的时间会暂停其他使命，可是大多数情况下，GC操作照旧相对很安静并且高效的。但是如果我们对内存的使用不恰当，导致GC频繁执行，如许就会引起不小的性能问题
有些对象的接纳不能依靠体系GC，比如：XmlPullParserFactory and BitmapFactory …
14、onDraw方法

自界说View中的onDraw方法也需要引起注意，每次屏幕发生绘制以及动画执行过程中，onDraw方法都会被调用到，避免在onDraw方法里面执行复杂的操作，避免创建对象。对于那些无法避免需要创建对象的情况，我们可以考虑对象池模型，通过对象池来解决频繁创建与烧毁的问题，但是这里需要注意结束使用之后，需要手动释放对象池中的对象。
但是不幸的是，对于那些过于复杂的自界说的View(重写了onDraw方法)，Android体系无法检测具体在onDraw里面会执行什么操作，体系无法监控并主动优化，也就无法避免Overdraw了。但是我们可以通过canvas.clipRect()来帮助体系识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自界说View来控制显示的区域。同时clipRect方法还可以帮助节省CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍旧会得到绘制。

15、工具

15.1、hierarchyviewer

15.2、Lint(官方代码优化利器)

Android Lint是SDK Tools 16 (ADT 16)之后才引入的工具，通过它对Android工程源代码进行扫描和检查，可发现潜伏的问题，以便程序员及早修正这个问题。Android Lint提供了下令行方式执行，还可与IDE（如Eclipse）集成，并提供了html形式的输出报告。
官网：http://tools.android.com/tips/lint

16、其他

1、动画
2、传感器
3、清理缓存和垃圾文件
.
.
.
以为本文对您有用，麻烦点赞、关注、收藏，您的肯定是我创作的无限动力，谢谢！！！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)