Android耗电,代码耗时,ui效率分析

来源:互联网 发布:斐讯k2连接端口失败 编辑:程序博客网 时间:2024/05/16 09:07

耗电:

Android的大耗电量一般由以下四个构成
        a. 频繁的GC,不一定是full GC。 频繁的full GC的话,应用会很卡,一般来说是频繁的young gen GC。
        b. 开GPS,这玩艺尤其耗电
        c. 网络连接,尤其是后台开一堆服务,隔几分钟发起一次网络连接。
        d. 后台服务的数量,开一堆莫名其妙的服务。自动更新一个, 数据库更新一个, nofication一个。
大数据量的传输。
不停的在网络间切换。
解析大量的文本数据。
  并提出了相关的优化建议:
  在需要网络连接的程序中,首先检查网络连接是否正常,如果没有网络连接,那么就不需要执行相应的程序。
  使用效率高的数据格式和解析方法,推荐使用JSON和Protobuf。
  目在进行大数据量下载时,尽量使用GZIP方式下载。
  其它:回收java对象,特别是较大的java对像,使用reset方法;对定位要求不是太高的话尽量不要使用GPS定位,可能使用wifi和移动网络cell定位即可;尽量不要使用浮点运算;获取屏幕尺寸等信息可以使用缓存技术,不需要进行多次请求;使用AlarmManager来定时启动服务替代使用sleep方式的定时任务。

代码耗时:

下面主要介绍为了提高android程序运行效率,程序员在开发过程中应当注意的一些事项。
1在程序的开发过程中,为节省系统资源,有两条基本的原则:
(1)开发过程中,你只实现你所需要的功能;
(2) 能避免占用内存时,就一定不要去占用内存;
以下所应注意的事项都是基于这两条原则上的。
也许有些人会提出,基于此原则将很难达到真正目的的优化。但我们也必须承认,在像开发手机这样的嵌入式设备上,有时,我们没有其它的选择,为了有一些小的优化,很难开发出高效的数据结构和算法的。例如,当你把你的想法在 android的模拟器上来进行实现时,你有可能因为没有注意,写得代码是以耗尽系统几乎所有内存为代价的.当你把程序上传到真机上时,此时,你的程序将运行的效率很低,很难达到用户的要求。
所以,下面要介绍的一些事项能够,它可以在程序开发中,指导我们的编码,只有这样,程序才能安全执行,运行效率才能提高。
避免创建对象
对象的创建都是要占用资源的,如果你在循环程序中创建对象,由于过多的占用内存,你将定时的启动内容回收机制,从而降低了运行速度。
所以,当你不需要时,你应该避免创建类实例,给出以下几个例子作为说明:
尽量避免使用字符串,例如:从JSP或是其他客户端得到某些信息,其中包含int,Date,String类型,尽早把它们转化为自己合适的数据类型。
必须使用字符串时,考虑 当字符串不可变化时,使用String类型;当可变时使用StringBuffer类型。
当需要字符串+时,使用StringBuffer。这些例子大家可以在“动态对象管理”的DAO实现类中找到。

String s = “aaa” + “bbb”;
上面的语句实际上创建了三个String对象,性能受损。
StringBuffer s= new StringBuffer();
s.append(“aaa”);
s.append(“bbb”);
上面仅仅创建一个对象。
多使用原始的方法
当处理字符串时,应该多的使用像String.indexOf(),String.lastIndex(),以及与它们同等的方法。
4 Prefer virtual over interface
当你要声明一个HashMap对象时,你可以声明它为一个HashMap类,或一个Map 类:
Map myMap1 = new HashMap();  
HashMap myMap2 = new HashMap();
哪一个更好的呢?
在Pc机编程中,你应该更倾向与声明为Map,因为你可以调用Map中提供的接口来实现更多的功能。但是在手机开发中,通过此种方法的调用,比直接调用方法多花费一倍多的时间。所以,当你用HashMap类,而且它满足自己的需要,就不需要用声明为Map的方法。
5 避免在类内部进行Getters/Setters
在C++语言中,经常使用getters(eg. i=getCount())而不用局部变量的形式(i=mCount).在C++中这是一个很好的习惯,因为编译器可以通过内联进入getters。
但是在Android中,此习惯是不好的,因为调用虚拟机的代价很高,比直接使用局部变量费时的多.所以,在公共的接口中定义getters、setters是可取的,当时,在类中,你应该直接通过局部变量来访问。
for (int i = 0; i < this.getCount();i++)
      dumpItem(mItems[i]);
应该写为:
int mCount = this.getCount();
for (int i = 0; i < mCount; i++)
      dumpItems(items[i]);
静态成员优于非静态的
在编写程序过程中,因为静态成员的访问不需要构建类的实例。例如,QuyuDAOFactory的getDAO()方法,直接从类进行访问即可。
7精确数据计算时,不要使用float或是double类型
使用int或是long进行精确数据计算,自己管理小数位。
当数目不超过9位时,使用int类型;当数目不超过18位时,使用long;如果超过了18位,使用BigDecimal(注意它是对象,不是基本数据类型)。
8避免创建重复对象
Strings= new String("guojun");//永远不要这么干!
Strongs = "guojun";//可以接受的改进
9组合优于继承
当确实需要继承时才采用继承,否则使用类组合来完成。
10接口优于抽象类
两种机制最明显的区别是抽象类容许包含某些方法的实现,而接口不行。
如:com.zte.resmaster.helpers.AbstractDAOImpl,就是抽象类,它具有得到数据库连接和清除数据库资源的方法,但是怎么实现具体的DAO操作必须是其子类实现。
如果设计成抽象类,一旦子类要求继承其他类时就没有办法实现,因为Java中不能多重继承(extends),但是可以多重实现(implements)。换句话说就是接口是定义混合类型的理想选择。
接口允许非层次类型框架的构造。
接口通过封装类方式,能够获得安全、强大的功能。
当然抽象类有另一个优势:改进抽象类比改进接口更加容易。一旦某个方法的实现发生了变化,仅仅需要更改一个地方;当新加一个方法时,所有子类都具有了该方法。
11尽量使用内部类
如果该类仅仅在某个调用者使用,那么把它设计成调用者的内部类。具体的例子,参见:com.zte.resmaster.system.rescomp.dao.RescompDAOOracle。不会暴露该内部类,避免滥用而导致的维护问题。
12最小化局部变量的作用域
最小化局部变量最有效的方法是在它第一次使用时声明。
几乎每个局部变量声明都应该包含一个初始值,否则编译也通不过。
方法小而集中,每个方法仅仅处理一种活动。
13了解和使用库
Java提供了强大而复杂的类库,在完成某个常用功能之前,看看Java类库中是否已经存在类似功能的类库。一方面减少工作量,一方面使得自己的程序更加简洁高效。
例如:向量(Collection,Set,List…)中字符串的排序:Collections.sort(v);
忽略大小写的排序:Collections.sort(v,String.CASE_INSENSITIVE_ORDER)
14通过接口访问对象
如果存在合适的接口类型,那么参数、返回值、变量和域应该用接口类型声明。
如果没有合适的接口,那么通过类而不是接口访问对象,是完全合适的。
15接口优于反射
失去在编译期间进行类型检查提供的好处。
代码笨拙而冗长。
性能损失。反射比正常的方法调用慢40倍左右(JDK1.3)。
有的时候,付出代价是值得的,因为能够得到更多的益处;一般而言,可以通过反射创建一个实例,然后通过他们的接口或是超类正常访问他们。
例如:DAO的Factory设计模式中的通过配置实现数据库实现类的平滑移植。
14实现功能后在想如何优化是一个比较好的策略。
15遵循普遍接受的命名规则。
备注:这里所说的是一些事项,它们不是真理。大家在开发的过程发现自己会了解更多,望大家对该文档能提出批评意见或是补充。

3.ui效率

http://blog.csdn.net/startfromweb/article/details/7641807

4.其他优化

耗电或者内存占用等影响产品效率的每一个问题都会影响App的成功。这就是为什么在开发中确保最优化、运行流畅而且不会使Android系统出问题是至关重要的了。这里不需要讨论高效编程,因为我们不会关心你写的代码是否能够经得起测试。即使高效的代码也是需要时间来运行。今天这篇文章我们就讲讲怎么尽可能地缩短运行时间
高效地利用线程
建议一:怎么在后台取消一些线程中的动作
我们知道App运行过程中所有的操作都默认在主线程(UI线程)中进行的,这样App的响应速度就会受到影响。会导致程序陷入卡顿、死掉甚至会发生系统错误。
为了加快响应速度,需要把费时的操作(比如网络请求、数据库操作或者复杂的计算)从主线程移动到一个单独的线程中。最高效的方式就是在类这一级完成这项操作,可以使用AsyncTask或者IntentService来创建后台操作。如果选择使用IntentService,它会在需要的时候启动起来,然后通过一个工作线程来处理请求(Intent)。
使用IntentService时需要注意以下几点限制:
这个类不要给UI传递信息,如果要向用户展示处理结果信息请用Activity;每次只能处理一个请求;每一个处理请求过程都不能中断;
建议二:怎么保持响应不发生ANR
从UI线程中移除费时操作这个方式还可以防止用户操作出现系统不响应(ANR)对话框。需要做的就是继承AsyncTask来创建一个后台工作线程,并实现doInBackground()方法。
还有一种方式就是自己创建一个Thread类或者HandlerThread类。需要注意这样也会使App变慢,因为默认的线程优先级和主线程的优先级是一样的,除非你明确设定线程的优先级。
建议三:怎么在线程中初始化查询操作
当查询操作正在后台处理时,展示数据也不是即时的,但是你可以使用CursorLoader对象来加快速度,这个操作可以使Activity和用户之间的互动不受影响。
使用这个对象后,你的App会为ContentProvider初始化一个独立的后台线程进行查询,当查询结束后就会给调用查询的Activity返回结果。
建议四:其它需要注意的方面
使用StrictMode来检查UI线程中可能潜在的费时操作;使用一些特殊的工具如Systrace或者Traceview来寻找在你的应用中的瓶颈;用进度条向用户展示操作进度;如果初始化操作很费时,请展示一个欢迎界面。
优化设备的电池寿命
如果应用很费电,请不要责怪用户卸载了你的应用。对于电池使用来说,主要费电情况如下:
更新数据时经常唤醒程序;用EDGE或者3G来传递数据;文本数据转换,进行非JIT正则表达式操作。
建议五:怎么优化网络
如果没有网络连接,请让你的应用跳过网络操作;只在有网络连接并且无漫游的情况下更新数据;选择兼容的数据格式,把含有文本数据和二进制数据的请求全部转化成二进制数据格式请求;使用高效的转换工具,多考虑使用流式转换工具,少用树形的转换工具;为了更快的用户体验,请减少重复访问服务器的操作;如果可以的话,请使用framework的GZIP库来压缩文本数据以高效使用CPU资源。
建议六:怎么优化应用在前端的工作
如果考虑使用wakelocks,尽量设置为最小的级别;为了防止潜在的bug导致的电量消耗,请明确指定超时时间;启用 android:keepScreenOn属性;除了系统的GC操作,多考虑手动回收Java对象,比如XmlPullParserFactory和BitmapFactory。还有正则表达式的Matcher.reset(newString)操作、StringBuilder.setLength(0)操作;要注意同步的问题,尽管在主线程中是安全的;在Listview中要多采用重复利用策略;如果允许的话多使用粗略的网络定位而不用GPS,对比一下GPS需要1mAh(25s * 140 mA),而一般网络只用0.1mAh(2s * 180mA);确保注销GPS的位置更新操作,因为这个更新操作在onPause()中也是会继续的。当所有的应用都注销了这个操作,用户可以在系统设置中重新启用GPS而不浪费电量;请考虑在大量数理运算中使用低精度变量并在用DisplayMetrics进行DPI任务时缓存变量值;
建议七:怎么优化工作在前台的应用
请确保service生命周期都是短暂的,因为每个进程都需要2MB的内存,而在前台程序需要内存时也会重新启动;保持内存的使用量不要太大;如果要应用每30分钟更新一次,请在设备处于唤醒状态下进行;Service在pull或者sleep状态都是不好的,这就是为什么在服务结束时要使用AlarmManager或者配置属性stopSelf()的原因。
建议八:其它注意事项
在进行整体更新之前检查电池的状态和网络状态,等待最好的状态在进行大幅度装换操作;让用户看到用电情况,比如更新周期,后台操作的时候;
实现低内存占用UI
建议九:怎么找到布局显示问题
当我们为布局单独创建UI的时候,就是在创建滥用内存的App,它在UI中会出现可恶的延时。要实现一个流畅的、低内存占用的UI,第一步就是搜索你的应用找出潜在的瓶颈布局。使用Android SDK/tools/中自带的Hierarchy Viewer Tool工具。
还有一个很好的工具就是Lint,它会扫描应用的源码去寻找可能存在的bug,并为控件结果进行优化。
建议十:如何解决问题
如果布局显示结果发现了问题,你可以考虑简化布局结构。可以把LinearLayout类型转化成RelativeLayout类型,降低布局的层级结构。
做到更加完美并不断优化
5.traceview使用

http://www.cnblogs.com/sunzn/p/3192231.html

http://blog.jobbole.com/78995/

6.ANR

http://blog.csdn.net/dadoneo/article/details/8270107



0 0
原创粉丝点击