Android性能优化之APP性能优化原则总结

  使用过Android系统手机的同学都知道,Android手机越用越卡,这个卡主要体现在手机系统越用越卡,打开APP的速度越来越慢。Android手机越用越卡的原因主要有:1、Android系统源码是开放的,像国内的几大手机厂商,都是对系统进入定制开发,这样就会引发一系列问题,比如说著名的系统碎片化问题;2、APP开发人员要对各个系统做各种适配,开发人员的水平参次不齐,开发出来的APP就会出现这样那样的问题。

  Android应用的性能优化是每个Android开发人员必然会遇到的,也是跳槽面试时基本必问的问题。下面是笔者总结的一些APP性能优化原则,如果能遵循下面这些优化原则,那么开发出来的APP肯定会更流畅一点、用户体验更好一点、更稳定一点。

1.布局优化

  思想概述: 尽量减少布局文件的层次(android绘制时的工作量减小,性能提高),避免过渡绘制。
  首先删除布局中无用的控件和层级,其次有选择地使用性能较低的ViewGroup,比如LinearLayout。如果布局中有的布局既可以用LinearLayout也可以用RelativeLayout,那就用LinearLayout,这是因为RelativeLayout比较复杂,他的布局过程花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup,因此可以考虑使用他们,但是很多时候,单纯的通过一个LinearLayout或者FrameLayout无法实现产品的效果,需要通过嵌套的方式来完成,这种情况建议采用RelativeLayout,因为ViewGroup的嵌套就相当于增加了布局的层级,同样会降低程序的性能。
  布局优化的另一种手段是采用<merge>标签、<include>标签和ViewStub:

  1. <merge>标签:如果当前布局和包含的布局中都是竖直方向,那么使用<merge>标签可以去掉多余的LinearLayout,一般和<include>标签一起使用,从而减少布局的层级;
  2. <include>标签:布局重用,不用把已经写过的布局重新写一遍,代码的复用;
  3. ViewStub:继承view,非常轻量级且宽高都是0,自己不参加任何布局的绘制过程,提供了按需加载功能,当需要时才将ViewStub中的布局加载到内存,这提高了程序的初始化效率。

2.绘制优化

  思想概述:View的onDraw方法避免大量的操作,onDraw方法中不要创建新的局部对象(onDraw方法可能被频繁调用,会产生大量的临时对象,导致系统更加频繁的gc,降低程序的执行效率),onDraw方法中不要做耗时的任务,不能执行成千上万次的循环操作(抢占cpu的时间片,造成View绘制过程不够流畅,每帧的绘制时间不超过16ms)。

3.内存泄露优化

  内存泄露的优化的思路主要分为两个方面:一方面是在开发过程中避免写出内存泄露的代码,另一方面通过一些分析工具比如MAT、LeakCanry或Android Profiler等来找出潜在的内存泄露继而解决。
  常见的内存泄露举例:

  1. Context使用不当造成内存泄露:不要对一个Activity、 Context保持长生命周期的引用,尽量在一切可以使用应用ApplicationContext代替Context的地方进行替换);
  2. 静态变量导致内存泄露:如果我们将activity的context对象赋值给activity的全局的静态变量。那么就会造成activity无法正常销毁,因为静态变量在引用它;
  3. 单例模式导致的内存泄漏:如果我们在单例模式中实现了观察者模式,监听实现了接口的对象,当我们在Activity中注册了监听方法以后,而没有进行解注册,就会引起内存泄漏;在单例模式初始化是,如果传入Activity或Context实例,也会引起内存泄露;
  4. 属性动画导致的内存泄露:属性动画中有一类无限循环的动画,如果在Activity中播放此类动画而没有在onDestory中停止动画,那么动画会一直播放下去,尽管无法在界面上看到动画效果了,而且这个时候,Activity的View会被动画持有,而View有持有了Activity,最终导致Activity无法释放;
  5. 警惕线程未终止造成的内存泄露:譬如在Activity中关联了一个生命周期超过Activity的Thread,在退出Activity时切记要结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环,它不会自己结束,线程的生命周期超过了Activity生命周期,我们必须手动在Activity的销毁方法中调用handlerThread.quit()才不会泄露;
  6. 对象的注册与反注册没有成对出现造成的内存泄露;譬如注册广播接收器、注册观察者(典型的譬如数据库的监听)等;
  7. 创建与关闭没有成对出现造成的泄露;如Cursor资源必须手动关闭,WebView必须手动销毁,流等对象必须手动关闭等;
  8. 非静态内部类的静态实例容易造成内存泄漏;即一个类中如果你不能够控制它其中内部类的生命周期(譬如Activity中的一些特殊Handler等),则尽量使用静态类和弱引用来处理(譬如ViewRoot的实现);
  9. 不要在执行频率很高的方法或者循环中创建对象,可以使用HashTable等创建一组对象容器从容器中取那些对象,而不用每次new与释放;
  10. 注意WebView的泄漏:Android中的WebView存在很大的兼容性问题,解决方法是:让onDetachedFromWindow先走,在主动调用destroy()之前,把webview从它的parent上面移除掉,具体代码如下:
@Override
protected void onDestroy() {
    if( mWebView!=null) {
        // 如果先调用destroy()方法,则会命中if (isDestroyed()) return;这一行代码,需要先onDetachedFromWindow(),再
        // destory()
        ViewParent parent = mWebView.getParent();
        if (parent != null) {
            ((ViewGroup) parent).removeView(mWebView);
        }

        mWebView.stopLoading();
        // 退出时调用此方法,移除绑定的服务,否则某些特定系统会报错
        mWebView.getSettings().setJavaScriptEnabled(false);
        mWebView.clearHistory();
        mWebView.clearView();
        mWebView.removeAllViews();
        mWebView.destroy();

    }
    super.on Destroy();
}

PS:内存泄露和内存溢出OOM的关系:内存泄露小范围积累不能释放会导致卡顿,内存泄露长期不能释放,累积超过阈值会引起OOM,如果瞬间申请的内存超过应用允许的阈值也会引起OOM(如应用的某些逻辑操作疯狂的消耗掉大量内存(譬如加载一张不经过处理的超大超高清图片等)导致超过阈值引起OOM),可见两者是交集关系。内存溢出(OutOfMemoryError)的核心原因就是应用的内存超过阈值了。

4.响应速度优化

  响应速度优化的核心是避免在主线程中做耗时操作,而是将这些耗时操作放在子线程中去执行,即采用异步的方式去执行。响应速度过慢体现在Activity的启动画面上,如果在主线程中做太多的事情,会导致Activity启动时出现黑屏的现象,甚至出现ANR。当发生了ANR以后。系统会在/data/anr目录创建一个文件traces.txt(PS:不同的手机存储的路径可能会有不同),通过分析trace文件,可以进一步定位ANR的原因。

5.ListView的优化

  ListView的优化很简单,其思想概述:首先采用ViewHolder并避免在getView中执行耗时操作;其次要根据列表的滑动状态来控制任务的执行频率,比如当列表快速滑动时显然是不太适合开启大量的异步任务;最后,可以尝试开启硬件加速来使ListView的滑动更加流畅。

  ListView的优化现在最流行的方式是用RecyclerView代替,若用RecyclerView代替ListView显示列表数据,可以忽略该原则。

6.Bitmap优化

  Bitmap优化同样比较简单,其思想概述:1、通过BitMapFactory.Options来根据需要对图片进行采样,采样过程主要用到了BitmapFactory.Options的inSampleSize参数;2、利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率上的提升,使用该变量可以复用旧的Bitmap的内存而不用重新分配以及销毁旧Bitmap,进而改善运行效率,即复用了内存减少了内存占用(只要新的Bitmap的内存小于旧Bitmap的内存大小,即可进行复用的操作;Glide内部也使用了inBitmap作为缓存复用的一种方式。)。

7.线程优化

  思想概述:采用线程池,避免程序中存在大量的Thread。线程池可以重用内部的线程,从而避免了线程的创建和销毁所带来的性能开销。同时线程池还能有效的控制线程池的最大并发数,避免大量的线程互相抢占系统资源从而导致阻塞现象发生。

8.其他性能优化原则

  1. 避免创建过多的对象;
  2. 不要过多的使用枚举,因为枚举占用的内存空间要比标准类型大;
  3. 常量使用static final修饰;
  4. 采用内存缓存和磁盘缓存;
  5. 使用更小的图片:尽量使用更小的图片资源;
  6. 采用静态内部类,这样可以避免潜在的由于内部类而导致的内存泄漏;
  7. 用好Lint工具:AndroidStudio自带的Lint工具可以检查出APP代码里面潜在的更多的优化建议;
  8. 使用ProGuard来剔除不需要的代码:ProGuard能够通过移除不需要的代码,重命名类,域与方法等等对代码进行压缩,优化与混淆。使用ProGuard可以使得你的代码更加紧凑,这样能够减少mapping代码所需要的内存空间。

  如果感觉我的文章对您有所帮助,麻烦动动小手给个喜欢,如果有疑问,也欢迎在下方留言,谢谢!!!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,445评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,889评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,047评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,760评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,745评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,638评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,011评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,669评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,923评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,655评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,740评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,406评论 4 320
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,995评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,961评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,023评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,483评论 2 342