个人做营利性质网站会怎么样,免费下载app并安装,网站建设需求分析报告撰写,wordpress 查件1、硬件耗电 主要有#xff1a; 1、屏幕 2、CPU 3、WLAN 4、感应器 5、GPS(目前我们没有) 电量其实是目前手持设备最宝贵的资源之一#xff0c;大多数设备都需要不断的充电来维持继续使用。不幸的是#xff0c;对于开发者来说#xff0c;电量优化是他们最后才会考虑的的事情…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中通常做法是用GettersigetCount()代替直接字段访问 imCount。这是C中一个好的习惯因为编译器会内联这些访问并且如果需要约束或者调试这些域的访问你可以在任何时间添加代码。 而在Android中这不是一个好的做法。虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践在公共接口中使用Getters和Setters是有道理的但在一个字段经常被访问的类中宜采用直接访问。 无JIT时直接字段访问大约比调用getter访问快3倍。有JIT时直接访问字段开销等同于局部变量访问要快7倍。在Froyo版本中确实如此但以后版本可能会在JIT中改进Getter方法的内联。
6、布局 总体原则控件尽量少、尽量减少布局层次 1、Textview Imageview → Textviewiconandroid: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的回收机制给开发人员带来很大的好处不用时刻处理对象的分配与回收可以更加专注于更加高级的代码实现。相比起JavaC与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是没有必要的。 161000/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、清理缓存和垃圾文件 . . .
觉得本文对您有用麻烦点赞、关注、收藏您的肯定是我创作的无限动力谢谢
