Onelong

分享知识,与你一起进步......
RSS icon Home icon
  • Android 优化

    post by onelong / 2016-12-4 16:44 Sunday [android]
    一直以来都没怎么做android方面的优化,使用的时候时候不卡就算了,也没有一些指标。或者是因为过往项目的缘故吧,总是没有一群专业的人员去测试,甚至只有靠自己去测试。每次面对性能优化的问题,都是没有很明确的指标,随着硬件的升级,其实出现卡顿的时候也会越来越少了,甚至有人去推测,原生迟早被h5替代的,哈哈,这个就是其他问题了。市场需求是多样化的,就像我们常常觉得一个卖二手机平台为什么要自己做,反正目标是卖出更多的手机而已,平台是啥都不重要,例如淘宝,微信等,普遍认为这种二手机平台是没有用户粘性的,买完之后可能一年内都不会再买了,用完即走的意思。可是我在评论上缺看到很多回头客,甚至有人买了8台。无论技术怎样发展,品牌是才是最重要的。技术只是一个工具,工具是否要变革,是市场需求决定的,当手机还在拼命增量的时候,我们就去推断移动互联网已经过去了,大数据来了。其实我们的终端还是在增量,而且没有被替代趋向,我们怎么会觉得Android和iOS就会死掉呢?从过往的我有个想法就差一个程序员,到现在细分,深度垂直发展。我相信对于技术和市场需求的挖掘都是不够的。洗牌之前,我们或许可以看到很多赚快钱的企业,洗牌之后我们只能看到一堆真枪实干的企业。开发者过剩的问题也是同样,由于以前要求过低,入门门槛低,涌入大量开发者,当市场需求趋向饱和的时候,优胜劣汰就来了。
     对于技术,始终要相信“科技是第一生产力”,一个不注重技术或不注重技术变革的企业是走不远的。Google,苹果等就不说了,国内看看阿里,华为。大数据,云平台,人工智能最终展现给用户的是终端,而市场需求总是多样化的。除了工作,我基本不会用到pc,以前有事没事都是大卡pc,二手机浏览器呢,也是同样,在需要百度查资料的时候才会用,而平时都是app。微信和网页是在app基础上多了一种方式而已,并不能说它们是未来,我相信任何人都是一样的,不喜欢只靠着一个大企业而生存,这样没有安全感。所以没有必要去担忧微信未来替代啥啥的,看重大厂app的主要是流量,例如罗一笑事件,就可以理解为什么那么多想赚快钱的人那么喜欢微信了。就像以前经常说的,php弄死了java,可以SOA,微服务又让java火起来了,技术是重要的,也是不重要的。技术作为基础平台,很多时候它的价值是不明显的,也就是这样大家就觉得平台能用就行了。好了,扯了那么多,入正题吧。
    说到android方面的优化,每次我都无奈了,gc优化,内存优化,网络优化,布局渲染优化,动画优化,自定义View优化,电量优化
    等的优化,内存嘛,OOM,对象池,内存泄漏等,通常都会扯到BItmap那一块去的。有时候觉得这方面的东西没什么可说的,java本身有垃圾回收,优化无非就是改变一些不良的习惯,别动不动就用静态,我经常看到静态的Context,Bitmap,甚至是一个集合。我更喜欢用单例,的确单例本质也是静态的,封装成一个对象比例零散的静态变量,在管理上比较方便,生命周期控制上也是会比较方便。经常造成内存泄漏的肯定是我们很熟悉的handler,这个就不用多说了,好的习惯就是在onDestroy时,handler.removeMessageAndCallback(null)。容易出现内存泄漏地方:
    1、静态
    2、
    handler的延时调用
    3、线程
    对应的优化方案就是:少用静态,
    handler.removeMessageAndCallback(null),取消线程,为了加速垃圾回收,我们还可以在onDestroy设置xxObj=null,减少gc,用ArrayMap,对象池,重用,StringBuilder,避免在onDraw方法里面执行对象的创建等主要减少对象数。
    电量用优化主要是在网络,传感器,蓝牙方面,蜂窝数据很费电的,当手机进入后台时,批量操作,延迟操作,为什么呢,启动的过程总是很费电的。传感器的频率调低,甚至关闭。优化关键次:JobScheduler,AlarmManager,网络请求队列,预加载,数据压缩,按场景加载等。充电时操作,用户点亮屏幕时操作,有Wi-Fi时操作,甚至在WiFi,4G,3G等不同的网络下设计不同大小的预取数据量。
    布局渲染优化:布局加载也是需要耗时的,虽然是二进制的xml,说白了就是简化布局,选择合适的布局,简单从效率上来看线性布局和帧布局会比较高效,但是要衡量可读性和可维护性,控制overdraw,overdraw上面大多数减少不必要的背景。建议关键次:Fragment,include,megre,ViewStub。这一块的优化内容很多,也很无奈。我们不能在非主线程上布局和渲染,也不像iOS那样可以监听Runloop推出的事件做后台渲染,android的消息机制和UI无关,所以很难做到平滑16ms,总会加载一个页面时,GPU耗时猛增,我对比了一下淘宝,qq,qq空间等app,都做不到很平滑。overdraw基本都是蓝色,所以我优化的目标也是overdraw蓝色,无色确实比较难做到了,而且也容易出现兼容性问题。至于动画的话,PropertyAnimation,ViewAnimation性能会好些。自定义View的优化,我就不说了,这方面的经验比较少。

    View -> GPU能识别的格式->cache as Display List->GPU Render

    蓝色(更新显示列表):onDraw, invalidate

    红色(执行显示列表):Android 2D渲染引擎(OpenGL)执行display list的时间。为了将变化绘制在屏幕上,Android需要使用OpenGL ES API来绘制这些display list信息,OpenGL最终将数据传给了GPU,然后GPU渲染到屏幕上。View越复杂,OpenGL绘制所需要的命令也越复杂。如果红色这一段比较高,复杂的view都可能是罪魁祸首。还有值得注意的是比较大的峰值,这说明有些view重复提交了,也就是绘制了多次,而它们可能并不需要重绘。

    橙色(处理):CPU告诉GPU渲染已经完成的时间。这部分是阻塞的,CPU会等待GPU知道确认收到了命令,如果这里比较高,说明GPU做的任务太多了,通常是由于很多复杂的view绘制从而需要过多的OpenGL渲染命令去处理。

     
    相关资料,希望有需要的人细读:http://hukai.me   
    http://blog.csdn.net/xu_fu/article/details/45008779 

    引用地址:
     

    我要评论