优化总结
2016-08-21 21:56
176 查看
布局优化:
关键点在于减少布局的深度层级,因为加载xml文件是一个递归的过程,布局越深,效率越低。
方法:1:使用标签include重用View防止重复创建, 使用merge合并相同布局减少深度层级,使用viewstub占位,延迟加载。
2:尽量减少过度绘制, 将手机打开开发者模式 打开“显示GPU视图更新” 在打开app 红色部分为过度渲染部分,可以根据这个适当更改。因为有些时候为了业务需求,过度渲染是不能避免的,因此只能尽量不免。
组件的优化:
在使用一些复合组件和图片组合使用时通常需要优化组件来提高性能。
例如listview的优化
1:重用converview
listview缓存视图减少view的绘制
layoutinflate属于IO操作,减少遍历viewtree。
2:使用staticviewholder减少findviewbyid 属于遍历viewtree
3:如果有图片 使用异步加载机制 加载图片 使用lrucache缓存图片
4:设置滑动监听事件 静止则加载 否则不加载
5:listview继承自abslistview而abslistview在view的topand bottom自带动画效果 可以使用setverticalfadingedgenabed(false);
图片优化:图片的优化
内存泄漏优化:
内存泄漏的原因:这个引用已经不会在被用到了,可是并没有清空导致引用的实例没有被释放。引用实例的生命周期大于他的作用范围。
常见的实例:1:静态属性引用实例被static修饰的变量属于类的属性。他的生命周期是从类加载到卸载,属于全局的。
2:在全局的单例管理类,或者集合类中添加注册实例 执行完操作没有取消。
3:view的属性动画开始,没有结束。属性动画持有这个view的引用,这个view持有整个activity的应用导致整个activity不能被释放。
4:在使用fragment时,fragment内部持有外部关联的activity引用,也可能导致内存泄漏。
相应速度优化:
相应速度慢,让人感觉卡顿,根本原因主线程任务过度,我们应该尽量让主线程执行UI更新与用户相应,其他操作尽量放到工作线程。
卡顿可能是多方面的原因。上面的几点都可能导致卡顿。
除以上几点外在举几个例子:
单独activity A 或者单独activity B时并不卡顿。但在A 启动B时感觉卡顿,这可能是因为 在A的onpsue()中执行的操作太多 因为a启动b的生命周期为
A :oncreate ->onstart->onresume->onpause B:oncreate ->onstart->on resume
如果A的onpasue没有执行完成是不会执行B的oncreate方法的(这也是为什么在保存数据的时候一定要在onpause里完成而不是在onstop里完成的原因),
所以onpause如果执行耗时操作会导致卡顿,或者在b的oncreate里面执行操作太多也会导致卡顿。
线程优化:因为线程的创建与销毁也是有性能开销的,因此应该尽量减少大量线程的创建与销毁。
可以使用线程池来代替,可以减少性能的开销,也可以调度管理线程防止大量线程争夺资源阻塞。
关于android线程与线程池
关键点在于减少布局的深度层级,因为加载xml文件是一个递归的过程,布局越深,效率越低。
方法:1:使用标签include重用View防止重复创建, 使用merge合并相同布局减少深度层级,使用viewstub占位,延迟加载。
2:尽量减少过度绘制, 将手机打开开发者模式 打开“显示GPU视图更新” 在打开app 红色部分为过度渲染部分,可以根据这个适当更改。因为有些时候为了业务需求,过度渲染是不能避免的,因此只能尽量不免。
组件的优化:
在使用一些复合组件和图片组合使用时通常需要优化组件来提高性能。
例如listview的优化
1:重用converview
listview缓存视图减少view的绘制
layoutinflate属于IO操作,减少遍历viewtree。
2:使用staticviewholder减少findviewbyid 属于遍历viewtree
3:如果有图片 使用异步加载机制 加载图片 使用lrucache缓存图片
4:设置滑动监听事件 静止则加载 否则不加载
5:listview继承自abslistview而abslistview在view的topand bottom自带动画效果 可以使用setverticalfadingedgenabed(false);
图片优化:图片的优化
内存泄漏优化:
内存泄漏的原因:这个引用已经不会在被用到了,可是并没有清空导致引用的实例没有被释放。引用实例的生命周期大于他的作用范围。
常见的实例:1:静态属性引用实例被static修饰的变量属于类的属性。他的生命周期是从类加载到卸载,属于全局的。
2:在全局的单例管理类,或者集合类中添加注册实例 执行完操作没有取消。
3:view的属性动画开始,没有结束。属性动画持有这个view的引用,这个view持有整个activity的应用导致整个activity不能被释放。
4:在使用fragment时,fragment内部持有外部关联的activity引用,也可能导致内存泄漏。
相应速度优化:
相应速度慢,让人感觉卡顿,根本原因主线程任务过度,我们应该尽量让主线程执行UI更新与用户相应,其他操作尽量放到工作线程。
卡顿可能是多方面的原因。上面的几点都可能导致卡顿。
除以上几点外在举几个例子:
单独activity A 或者单独activity B时并不卡顿。但在A 启动B时感觉卡顿,这可能是因为 在A的onpsue()中执行的操作太多 因为a启动b的生命周期为
A :oncreate ->onstart->onresume->onpause B:oncreate ->onstart->on resume
如果A的onpasue没有执行完成是不会执行B的oncreate方法的(这也是为什么在保存数据的时候一定要在onpause里完成而不是在onstop里完成的原因),
所以onpause如果执行耗时操作会导致卡顿,或者在b的oncreate里面执行操作太多也会导致卡顿。
线程优化:因为线程的创建与销毁也是有性能开销的,因此应该尽量减少大量线程的创建与销毁。
可以使用线程池来代替,可以减少性能的开销,也可以调度管理线程防止大量线程争夺资源阻塞。
关于android线程与线程池
相关文章推荐
- 在即将离开工作了四年的软件业前[zt,一位前辈关于代码优化的总结]
- Asp.net性能优化总结(一)
- mips1处理器内存操作优化总结
- Java性能优化技巧总结
- C++代码优化方法总结
- Asp.net性能优化总结(二)
- Asp.net性能优化-性能优化总结
- php代码优化及php相关问题总结
- PHP问题总结:PHP优化及高效提速问题小结
- Asp.net性能优化总结(二)
- 关系数据库的查询优化策略----总结了一些查询优化的方法,希望可以对大家有所帮助(原创)
- Asp.net性能优化总结(二)
- Asp.net性能优化总结
- 总结dudu目前优化cnblogs的方法和一些建议
- SQL语句中的优化提示Hints的总结
- C++代码优化方法总结
- java性能优化总结(1)
- JavaScript优化总结
- 总结:今天在MSN Group里面和一些朋友谈ASP.net程序的性能优化
- C++代码优化方法总结