移动应用07Android优化和性能提高.ppt

Android 优化和性能提高 目录 -???????? 概览 -???????? 原因 -???????? 从设计开始做起 -???????? 和普通 Java 理念不同 -???????? 常用优化要点 -???????? 本地代码指令 -???????? 执行不同指令所需时间的对比 为什么我们要关心性能 摩尔定律 摩尔定律不适用移动设备 手机越来越小 功耗会越来越低 电池的持续的时间越来越长 CPU限制 不可能有无限快的CPU CPU越快，电池消耗越大 多个应用程序可能会在同一时间争夺 内存和电源限制 记忆体在移动世界里是珍贵资源 8G或16G记忆体是指闪存记忆 没有无限大的电池或永远连着的电源 应用程序必须尽量节省电池使用 Android应用程序要快、要有效 模拟器 ！=真正的移动设备 将内存分配保持在最低水平 紧凑的风格 尽量少用计算能力和数据存储 适合小屏幕 延长有限的电池寿命 性能优化的原则 原则 设计上的优化永远优于代码上的优化 不要做不必要的事 不要分配不必要的内存 用户体验 程序是否响应快速而灵活 不要寄希望于JIT编译器 体系结构上的优化 是最具影响力的 不取决于那个系统 使用本机代码 编译的C / C + + 一个字：快 Android NDK JNI 在极少数情况下 可能需要ARM汇编代码 只在一个很有限的范围内考虑使用本机代 或尽可能地使用Android提供的本机代码 NDK可能会比较难学习 本机代码很难编程 本机代码很难调试 本机代码能很难移植 本机代码可能很难融入现有的代码和框架 重新设计算法 好算法一个顶一万个 如冒泡和快速排序 适应Android的规定 很多用起来很别扭 没办法， Live with it 后台任务 使用Android 的Service体系结构 前台Activity的生命周期 退出前台时关闭不必要的资源 onDestroy() 时关闭一切资源使用 在OnCreate（）时重新创建资源的使用 Android 的内存限制 Android应用程序只能用有限的内存 16M for（G1） 方法 避免建立对象 避免创建短命的临时对象 防止周期性的垃圾回收 减少对用户体验的影响 int数组比Integer数组好 把多维数组分成多个一维数组 Android的内存泄漏问题 复杂且隐蔽 保持长期存在的Context 造成 来源于Android的设计 如@Override protected void onCreate(Bundle state) { super.onCreate(state); TextView label = new TextView(this); label.setText(Leaks are bad); setContentView(label); } 容易泄漏整个活动 活动Activity 被重新创建 Android内存泄漏的解决方法 避免在本Method之外以外该Context 不要用静态内部类的引用 不要保存长期存在的Context或Activity引用 是使用Application Context(应用程序上下文) 调用Context.getApplicationContext（） 或Activity.getApplication（） 记住Garbage Collector对此类内存泄漏无效 Garbage Collector -垃圾收集器的影响 垃圾收集器被启动时会暂时停止应用程序 大多数情况下发生得够快的话没有人会注意到 但是在性能敏感的代码路径如游戏或绘制视图 用户会感觉 ‘卡’ 通常垃圾收集有可能会需要以100至200毫秒 顺畅的动画需要在16至33毫秒中画每个帧 Android的垃圾收集器，还没有能够进行优化 用户的体验始终是最优先的事项 对用户来数，使用的顺畅是第一优先 解决方法 将小对象的分配放在关键代码之后，或之前 或将许多小对象的分配合并为大对象的分配。 调试和优化工具 DDMS （Dalvik 调试监测）工具 多个工具的组合 内存分配跟踪器 VM 内存堆 内存信息图 CPU负载图 性能分析工具Traceview 将函数的调用情况以及调用时间保存到一个log文件中 DDMS Eclipse 集成 Eclipse 设备视图 内存分配跟踪器（Allocation Tracker） VM 内存堆 当前运行的应用程序的内存分配 CPU 负载 性能分析工具Traceview 创建跟踪文件 生成包含您要跟踪信息的日志文件 在您的代码中加上 Debug类 调用startMethodTracing（）方