Android性能优化全方位覆盖

Android作为一种移动设备,无论是内存还是CPU性能都会有一定的限制,无法和PC设备相比拟,有鉴于此,Android程序不可能无限制的使用内存和CPU。过多的使用内存会导致程序每寸溢出即OOM,而过多的使用CPU资源(比如做大量耗时任务)会导致手机变得卡顿甚至出现程序无响应(即ANR)的情况。所以作为Androider,我们对性能优化的技能就尤为重要,这里主要从【布局优化】、【绘制优化】、【内存泄漏优化】、【响应速度优化】、【列表优化】、【Bitmap优化】、【线程优化】及等方面进行优化。

一、布局优化

  1. 尽量保持布局层级的扁平化,避免出现重复的嵌套布局
  2. 在Android中单独的布局性能: FrameLayout>LinearLayout>RelativeLayout
  3. 安卓SDK中有一个Hierarchy Viewer工具可以帮助你优化自己的布局

二、绘制优化

绘制优化主要是指View的onDraw方法避免执行大量的操作以及避免过度绘制:

  1. onDraw方法中不要创建新的局部对象。这是因为onDraw方法可能会被频繁的调用,这样就会在一瞬间产生大量的临时对象,这不仅会占用更多的内存而且还会导致系统更加频繁gc,降低了程序的执行效率
  2. onDraw方法中不要做耗时任务,也不要执行太多次的循环操作。这样会造成View的绘制不流畅。
  3. 移除掉window的默认纯色背景
    【在setContentView()之后调用getWindow().setBackgroundDrawable(null)】或者【在theme中添加 android:windowbackground="null" 】
  4. 移除XML布局文件中非必需的Background
  5. 合理使用draw9patch
  6. 能不用Alpha尽量不要用Alpha,因为它会绘制俩次
  7. 按需显示占位背景图片
  8. 通过减少invalidate()方法的调用来减少onDraw()方法的调用,同时,尽可能的使用四个参数的invalidate()方法,如果是没有参数的invalidate()方法会绘制整个view
  9. 可以的话 使用硬件加速
更多布局及绘制优化方案请查看我的另一篇博客

三、内存的优化

  • 内存泄漏:是指程序在申请内存后,无法释放已申请的内存空间。内存泄漏简单地说就是申请了一块内存空间,使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长,占用内存越多,最终用尽全部内存,整个系统崩溃。由程序申请的一块内存,且没有任何一个指针指向它,那么这块内存就泄露了。内存泄漏一般不会导致程序异常,但它会导致程序的内存占用过大,这将提高内存溢出的几率。所以,内存泄露是内存溢出的一种诱因,不是唯一因素。
    内存泄漏是造成应用程序OOM的主要原因之一
  • 内存溢出:是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory;比如申请了一个integer,但给它存了long才能存下的数,那就是内存溢出。

导致内存泄漏的原因及解决方案:

1、静态变量导致的内存泄漏

静态变量:静态变量是在类被load的时候分配内存的,并且存在于方法区。当类被卸载的时候,静态变量被销毁。只要静态变量没有被销毁也没有置null,其对象一直被保持引用,也即引用计数不可能是0,因此不会被垃圾回收。

2、单列模式导致的内存泄漏

当单列中传入一个Activity的Context后,该单列就持有Activity的引用,我们知道单例的生命周期和Application的一样长,所以当Activity退出时它的内存并不会被回收。
所以,单例中的Context最好使用Application的Context,这样可以有效防止内存泄漏

3、属性动画导致的内存泄漏

属性动画中有一类无限循环的动画,如果在Activity中播放此动画且没有在onDestory中停止动画,即使已经无法在界面上看到动画效果,动画也会一直播放下去,并且这个时候Activity的View会被动画持有,而View有持有了Activity,最终导致Activity无法释放。这种泄漏的解决办法是在onDestory中调用animator.cancal()来停止动画。

4、Handler造成的内存泄漏

大家平时开发中喜欢在Activity中直接new一个Handler的匿名内部类,在Java中,非静态的内部类或者匿名类会隐式的持有其外部类的引用,而静态的内部类则不会。这样造成匿名内部类持有一个外部类(通常是Activity)的引用(不然怎么更新ui),但是Handler常常伴随着一个执行耗时操作的异步线程(如下载多张图片),如果在完成耗时操作之前,Activity退出,异步线程持有handler的引用,handler持有Activity的引用,从而导致内存泄漏

5、上下文对象导致的内存泄漏
  • 使用application的context来替代activity相关的context。
    尽量避免activity的context在自己的范围外被使用,这样会导致activity无法释放。不要让生命周期长于Activity的对象持有到Activity的引用
  • 在Android中,Application Context的生命周期和应用的生命周期一样长,而不是取决于某个Activity的生命周期。
    如果想保持一个长期生命的对象,并且这个对象需要一个 Context,就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者 Activity.getApplication()方法来获得Application对象。
  • Drawable的对象的内部Callback持有activity的引用,当Activity finish()之后,静态成员drawable始终持有这个Activity的引用,导致内存释放不了。
  • Activity内部如果有一个Context的成员变量,将导致Context引用指向的Activity对象释放不了,见上文:静态变量导致的内存泄漏
6、线程造成的内存泄漏
7、webview导致的内存泄漏优化

请参考:http://lipeng1667.github.io/2016/08/06/memory-optimisation-for-webview-in-android/

8、其他一些导致内存泄漏的原因

1、Bitmap对象使用完后,忘记了调用recycle()方法销毁;
2、解析图片的时候忘记了设置采样率 详见下文
3、自定义View时TypedArray使用完后忘记调用recycle()方法释放内存
4、ListView的适配器类中没有复用convertView
5、未采用软引用等

  • 软引用:
    如果一个对象只具有软引用,那么如果内存空间足够,垃圾回收器就不会回收它;如果内存 空间不足了,就会回收这些对象的内存。只要垃圾回收器没有回收它,该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队 列(ReferenceQueue)联合使用,如果软引用所引用的对象被垃圾回收,Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
  • 弱引用:
    如果一个对象只具有弱引用,那么在垃圾回收器线程扫描的过程中,一旦发现了只具有弱引 用的对象,不管当前内存空间足够与否,都会回收它的内存。不过,由于垃圾回收器是一个优先级很低的线程,因此不一定会很快发现那些只具有弱引用的对象。弱 引用也可以和一个引用队列(ReferenceQueue)联合使用,如果弱引用所引用的对象被垃圾回收,Java虚拟机就会把这个弱引用加入到与之关联 的引用队列中。
  • 弱引用与软引用的根本区别在于:
    只具有弱引用的对象拥有更短暂的生命周期,可能随时被回收。而只具有软引用的对象只有当内存不够的时候才被回收,在内存足够的时候,通常不被回收。

6、即时关闭InputStream/OutputStream。
7、注册某个对象后没有注销,如广播
8、集合对象没清理造成的内存泄漏。把大量对象的引用放入集合中,但我们不需要该对象时,记得从集合中将不需要的引用清理掉,同理,当对象不需要时,记得将对象的引用设置为null。
9、资源文件未关闭造成内存泄漏。最常见的是文件流执行完读写操作后,忘记关闭了输入流,输出流;数据库、Content Provider操作完后Cursor忘记了close等等。

如何避免内存溢出:

减小对象的内存占用

避免OOM的第一步就是要尽量减少新分配出来的对象占用内存的大小,尽量使用更加轻量的对象

  1. 使用更加轻量的数据结构
  2. 避免在Android里面使用Enum
  3. 减小Bitmap对象的内存占用
    • inSampleSize:缩放比例,在把图片载入内存之前,我们需要先计算出一个合适的缩放比例,避免不必要的大图载入。
    • decode format:解码格式,选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8,存在很大差异。
内存对象的重复利用,减少对象的重复创建,从而减少内存的分配与回收
  1. 复用系统自带的资源
    字符串/颜色/图片/动画/样式以及简单布局等这些都可以重复利用
  2. 列表中ConvertView的复用
  3. Bitmap对象的复用
    在ListView与GridView等显示大量图片的控件里面需要使用LRU的机制来缓存处理好的Bitmap
  4. 避免在onDraw方法里面执行对象的创建
  5. 善用 StringBuilder

关于内存优化请查看我的另一篇较详细的博客

四、响应速度优化

ANR (Application Not Responding)出现的原因:
  • activity如果5秒内无法响应屏幕触摸事件或者键盘输入事件;
  • BroadcastRecever10秒内还未执行完操作
ANR解决方法:
  • 尽量不要在主线程中耗时操作。运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方法(如onCreate()和onResume())里尽可能少的去做创建操作。
  • 应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。
  • 避免在Intent Receiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广 播时需要向用户展示什么,你应该使用Notification Manager来实现。

响应速度的优化思想是避免在主线程中做耗时操作,可以把耗时操作放到子线程中执行,即采用异步处理。当程序anr时,系统会在/data/anr/目录下创建一个traces.txt,通过分析此文件从而获取造成anr的原因。导出此文件的方法:adb pull /data/anr/traces.txt

五、列表优化

1、复用convertView,减少findViewById的次数
2、避免在getView方法中做耗时操作
3、采用ViewHolder模式缓存item条目的引用
4、给listView设置滚动监听器 根据不同状态 不同处理数据 分批分页加载 根据listView的状态去操作,比如当列表快速滑动时不去开启大量的异步任务去请求图片
5、listview每个item层级结构不要太复杂
6、listview每个item中异步加载图片,并对图片加载做优化
7、listview每个item中不要创建线程
8、采用硬件加速来使ListView的滑动更流畅
更多列表内容

六、线程优化

线程的优化思想是采用线程池,避免程序中出现大量的Thread,线程池可以重用内部的线程,从而避免了线程的创建和销毁带来的性能开销,同时线程池还能有效的控制线程的最大并发数,避免大量的线程因抢占系统资源从而导致线程阻塞的发生

七、Bitmap优化

Android中的Bitmap
Bitmap缓存策略

八、其他的一些性能优化建议

  1. 避免创建过多的对象
  2. 不要过多的使用枚举,枚举占用的内存空间要比整型大
  3. 常量请使用static final来修饰
  4. 使用一些Android特有的数据结构,比如SparseArray和Pair等,他们都具有更好的性能
  5. 适当的使用软银用和弱引用
  6. 采用内存缓存和磁盘缓存
  7. 尽量采用静态内部类,这样可以避免潜在的由于内部类导致的内存泄漏

避免内存溢出参考文章:http://hukai.me/android-performance-oom/
推荐文章:https://realm.io/cn/news/droidcon-farber-improving-android-app-performance/

IT文库 » Android性能优化全方位覆盖
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址