Onelong

分享知识,与你一起进步......
RSS icon Home icon
  • 满满的收获

    post by onelong / 2016-8-19 21:09 Friday [android]

    好久没有做Android的项目了,一直刻意去回避,都在折腾iOS的项目,好多人问是不是转型了,其实也不是吧,只是觉得iOS会纯粹一点,再加上以前在iOS上的实践太少了,没有足以让我无比自信的去面对所有面试。最近因为特殊情况,让我回到刚毕业的时候,熬了4个晚上优化一个项目,给自己交上满意的答卷。这4个晚上,用了洪荒之力,鬼知道我经历了什么呢。。。。。哈哈,没那么夸张。其实看着师弟惆怅了一个月,种种跌宕起伏,之前给他做这项目的哥们,用了洪荒之力都跪了,一方面看着那个app做的太丑了,另一方面出于好奇,同时想证实自己给那个哥们的建议,于是自己找苦来吃了。结果呢,好屌。。。。。
    这次优化都用了哪些技术和工具呢?首先是应该有一个好的思维,我打个不太恰当的比喻吧,你拿到一块地,地上有一堆牛粪,那个哥们呢,喜欢在牛粪上差点鲜花,鲜花的华丽虽然掩盖了牛粪,但是终究是不够优雅。而我就想着先清理那堆牛粪,然后再种上鲜花。所以第一步,我做了代码清理,把一些重复,多余的框架去掉,一个项目3个图片加载框架,2个网络请求框架,费不费劲呀?一样一个就够了。那哥们说Facebook的fresco很好,不要用Universal-Image-Loader,按照他的意思是因为Universal-Image-Loader性能不好,导致app频繁崩溃了,好明显是没有找到原因,胡乱搬库,以往用好了就说是自己的经验了,的确android开发者很多就处于这种水平。这个问题恰恰反映这个问题。
    我解决问题的过程是怎样的呢?首先询问师弟运营的数据,例如android用户在集中在那个版本上,毫不意外,基本没有android2.3的用户了,都是android4以上了。这样意味着不需要兼容android2.3了,也就是直接可以app的largeheep,打开了之后,崩溃已经明显少了,但是用了10-20分钟,还是出现内存溢出。经过计算10-15张560x560的图片,内存最多才20m,而app监控到了180m内存,很显然内存泄漏了。于是我自己手动管理图片的内存,但是依然无效。android内存泄漏一直以来都是开发的难点,面试经常有人问的。之前用过MAT,完全看不懂,后来试了一下facebook的LeakCanary,果然好用了,的的确确发现一堆堆内存泄漏,一泄漏就是10多m,妈的。。。。。得益于这个工具,很快就找到问题了,大部分是因为没有正确使用hander,线程导致的,activity退出应该清理没用的数据,移除没用的消息。经过一番折腾,内存明显可控了,峰值最多120m,我看了支付宝有时候内存占用都180m,所以我断定可以了。结果发给师弟它们测试,玩了20分钟,没啥问题,这是算完了?不是的,这么多图片好卡,于是我适当做了延时加载和缓存,真个界面就流畅起来了。
    想着既然做了,那就一优到底吧,把里面支付的,图片加载的,网络的库都升级到最新的,这样更好兼容android6.0吧,网络还是用我比较熟悉的volley+okhttp,不过这次用了okhttp3,之前在案场用了okhttp2.0。换库发现
    volley本身有内存泄漏,也是这样我发现了好神奇的东西,java无用的对象尽可能置为null,加速gc。发现列表滚得卡顿,于是再优化了一下,列表滑动时不加载图片,果然流畅了,这次的优化也结束了。
    为什么用volley,没有用retrofit呢,原因1:这个项目从android-async-http切换到retrofit比较麻烦,可能是我不熟的原因吧,原因2:volley代码少,我很容易做到有问题快速库,一切都在掌握之中。对于recyclerview,还没开始用,我觉得复杂的列表界面应该切换到recyclerview,在recyclerview我看到很多优点,很灵活。LeakCanary是个神器,建议大家用。
    送上几个截屏吧,二手iPhone,找靓机。哈哈,开发用二手机不错哇。。。

    点击查看原图点击查看原图

    引用地址:
     

    我要评论