Android性能典范:拯救计划
Posted 扈扈哈嘿
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android性能典范:拯救计划相关的知识,希望对你有一定的参考价值。
现如今的app都离不开动画,复杂的切换和自己定义View,用户体验必须直观的而且在任何设备上保持一致。这些模式会帮助你去构建一个平滑的,敏捷的用电尽可能少的app,它包括微优化可以提高应用程序的整体性能。
避免糟糕表现的模式
- 避免阻塞主线程
- 避免不必要的失效引发更多的失效
- 在高的层次结构中作用RelativeLayout
- 避免在LinearLayout中嵌套Weight(会导致子控件被测量两次)
- 避免自定View不正确
- 避免创建不必要的对象
- 用static final 修饰常量(static 要快15%-20%)
- 使用原生类型(像Integer和Float这些封装类要慢2倍)
- 避免内部的Getters/Setters方法(直接访问字段要快3倍)
- 使用增强性循环语句(foreach)
- 当有内部类访问外部类字段的时候考虑使用包级访问代替私有访问对外部类字段的修饰(编译器会增加方法来不访问外部类中的私有字段)
- 小心使用Native方法
自定义View
- 尽量保持简单
- 用merge标签作为你的Layout的根布局(避免inflation额外的ViewGroup)
- 使用inclue标签(重复使用共用的布局)
- 避免不必要的layout
- 不要将内存分配和过重的操作放在onDraw方法里
- 移除不必要的invalidate()方法的调用
- 考虑写你自己的ViewGroup
- 使用RecyclerView代替ListView和GridView
避免内存扰动
- 避免创建出大量不必要的对象,如下
* 不可改变的类(String)*
* 自己装箱:Integer,Boolean*- 考虑使用对象池和缓存来减少扰动
- 注意枚举的开销(一个枚举的常量引用占用4个字节)
避免内存泄露
- 避免Context引起的内存泄露
- 不要在activity中泄露view
- 尽量用静态内部类代替非静态内部类
- 不要使用WeakHashMap作为缓存。只有键是WeakPeference
CPU
- 不要嵌套多重布局
- 在复杂的数据被需要时才计算它
- 缓存经过复杂计算的结果来为重用做准备
- 要考虑渲染脚本的性能
- 主线程能随时工作
避免过渡渲染
- 精简你的drawables
- 具体情况下使用.9.png
- 在你的view里面小心设置alpha值
- 从你的view中移除不用的背景
Bitmaps
- 解码bitmaps到想要的尺寸:BitmapFactory.Options(inSampleSize,inDensity,inTargetDensity)
- 在bitmap将在显示时加载加到内存中
- 如果你不需要就不要去缩放(createScaledBitmap(bitmap,int ,int))
- 使用LRU缓存
Service
- 当这个service不再工作的时候就不要让它运行,当它工作完成后也要小心的关闭它
- 系统会优先保持服务进程的正常运行。RAM会被service使用而不能被其它使用或Service不能被paged out。
- 限制你service的寿命最好的方法就是使用IntentService,一旦执行完调用它的intent的时候就会尽快地finish自己的。
- 让一个不需要运行的service运行的是一个糟糕的内存管理错误。
Thread
- 在一个线程的run方法里面使用Process.setThreadPriority() ,用THREAD_PRIORITY_BACKGROUND.来设置该方法,这个办法可以减少其它线程和主线程之间的资源竞争。
- 如果你没有将线程设置为低优先级,那么这个线程可能会拖慢你的程序因为它默认的优先级与注线程的一样
- 存储这个线程的引用方便你去中断这个线程,比如:如果连网失败你可以取消这个线程的操作。
避免ANR
- 尽量让主线程少做事。
- 如果你的app在后台响应用户的输入,显示出这个操作的进展(比如显示出ProgressBar).
- 使用Systrace和Traceview这类的性能工具来表明你的app在响应过程中碰到的瓶颈。
- 如果你的应用在初始化阶段有耗时操作,考虑使用加载界面或者尽快的渲染主界面,表明正在加载和异步地填充信息。
以上是关于Android性能典范:拯救计划的主要内容,如果未能解决你的问题,请参考以下文章