android 项目之优化--app卡顿

随着android技术的提升,app在性能优化方面做的越来越好,在公司做项目的时间内,或多或少学了一些初级优化的方案,在这里分享给大家看,不过大多数都是前人的经验教训总结,在这里进行重述罢了。

每一个项目里面都不可缺少的app的组件 activity,站在开发人员的角度来说,其实就是一个可视化界面,所做的功能就是绘制界面,填写数据,和用户进行交互。看起来在activity里面做的事情特别的多,优化也成了一大难题,但我们可以慢慢来拆分一下。

首先要了解的是android系统按照app的优先级别给每个app都分配的有不同大小的内存,所以一旦超出了这部分的内存,就是我们最郁闷的OOM问题。故而我们最简单最直接最粗暴的方式,回收。将不需要再次饮用的对象置空,通过system.gc(),可这都只是一个指标不治本的办法。那何谓治本?

第一步,要提到的一个词语:渲染,在我看来,基础的渲染工作就是android将你的xml布局文件绘制到屏幕上。如果xml太过于复杂,造成的后果当然就是渲染时间过长,app卡顿现象严重,于是优化方案一就出来了,

一、简化布局,尽量使用相对布局,减少嵌套;

在写布局的时候,尽量做到能不嵌套布局的不要嵌套,也不是说整个页面都不进行多层嵌套,而是省去那些不必要进行的潜逃,尽量处理好控件的位置关系,做到能做到的最优方案。而使用相对布局比线性布局更好的原因是在于,在渲染过程中,使用线性布局使得在绘制这个布局的时候会先去查看里面的所有子元素,然后计算出他们所占的大小,尤其在设置了weight这个参数的时候,他们会被反复的测量大小,那么尤其在在adapterview绘制的时候,无疑减慢了运行速度,而且更多的耗费了性能。

第二步,依旧是渲染层面的,这个时候不能不提到一个关键,图片。在一个页面中,对于图片的优化更是重中之重,因为图片对app的性能起到了最重要的作用,尤其是大量图片展示的那种app,当图片本身的体积太过庞大,那么就会使app被分配的内存一点点的占满,一旦超出这个值域,后果就是崩溃。那么对于图片的优化有什么方案呢?

二、尽量减少drawable图片的体积,加载网络图片的时候别忘了对图片本身进行压缩

压缩图片显然在这里是重点,当图片的体积非常之轻的时候,那也就意味着你可以加载更多的图片,也可以毫无压力的减轻app卡顿的问题。但是压缩只是处理的第一步。很多人喜欢使用background设置图片背景,那么这里就要注意了,在xml使用的图片背景可以优化的那就大胆的优化,当然要保持和产品原型一致,但是你所做的工作就是选择合适图片进行加载设置。还有一个地方的陷阱--bitmap,当你的页面使用了bitmap的时候,那么回收就是必不可少的,这也是老生常谈了。

第三步,android中还有一个不知道是另开发者痛苦还是让使用者舒适的一个设定,页面缓存机制。也就是说当我们在调用finifsh的时候,表面上看页面被销毁了,那么,这个页面所创建的内存就应该被回收才对。其实不然,页面看似被finish掉了,但是存储页面的栈并没有对activity移除,这是一个缓存机制,为了使用户在短时间内再次访问这个页面的时候,可以快速的被重现该页面。带来的痛苦就是,打开的页面过多时,消耗的内存也是相当的可观的。所以我们可以对页面进行页面管理,

三、通过创建stack<object>等,进行页面管理。

建立BaseActivity,通过继承BaseActivity,建立页面管理。于此同时,BaseActivity也可以写一些公共方法,也是一个非常好的代码习惯。

第四步,更是我们平时写代码中必不可少的习惯啦,adapter的复用更是不得不做的事情。

四、adapter的复用

不知道各位小伙伴们的复用模式是否正确?并且在adapter的方法getView的方法内尽量不要重复大量的用类.getInstance()这种方式获取对象,最佳的选择就是提取出来成为adapter的自身属性了。

以上只是对于一个新手来说所需要明白掌握的优化方案,在这种情况下,app优化出来的效果明显提升了很多。

发布了23 篇原创文章 · 获赞 10 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/byxyrq/article/details/48790237
今日推荐