Android support v4中的Fragment和app包中的Fragment

Fragment是Android3.0之后加入的新特性,需要API11以上的SDK版本才能兼容,然而市面上有很多手机依然是3.0以下的系统,谷歌为了兼容低版本,于是开发了Android support v4包,里面的Fragment能够在最低API4的版本下运行,而且v4里面的Fragment还能嵌在一个名叫ViewPager的控件中,形成多页侧滑的效果。


我们一般的APP中,主要的界面有很多都是底部多标签切换的形式,这种形式我们很自然的想到通过ViewPager来构建一个多页面侧滑的效果,并可以和底部的RadioGroup实现联动。我的确一直都是这么做的,当时也并未想到有什么不妥,直到今天在一个包含五个Fragment的Activity上做操作时,发现视图的加载很不流畅,尤其是我加入了一个下拉刷新的功能之后,发现下拉刷新的下拉动作变得非常困难。如何解释这种困难,大约就是当我费尽心思用手指在屏幕上滑动时,根本看不到下拉的效果,或者是手指滑过整个屏幕,但是却仅仅把视图下拉了非常微小和距离,而且在下拉动画一点都不流畅,有明显的掉帧和卡顿现象。


我百思不得其解,最初认为是在主线程中执行了太多的操作导致的,于是将所有加载数据的动作全部禁用,仅保留基本视图的加载,经过这样处理,结果收效甚微,几乎看不到明显的改善。我越发疑惑,仅仅是加载几个空的布局而已,况且布局并不复杂,为什么视觉效果上还是这么卡顿?于是换一种方式来检测原因,保留所有的数据加载,但是不使用Fragment,全部在Activity中执行,将这5个Fragment中的内容全部迁移到Activity中来。先不说结果,估且设想一下,没有了Fragment分摊Activity的工作,视图的加载理应变得更慢才是。


结果自然出乎我的意料,Activity的加载虽然没有变得十分之快,但较之5个Fragment时期却反而流畅了一些。我想可能是Activity主线程加载布局太多,毕竟我之前的5个Fragment每个都有整屏幕的内容,5合1,各种重叠,我几乎看不清它们之中的任何一个,慢也是正常的,但比5个Fragment的时候快,我于是想到可能是ViewPager的原因了。


ViewPager下的Fragment是v4包中的Fragment,为了兼容低版本而存在,则必然要牺牲某些性能以实现兼容,另外我认为自己并不是很需要ViewPager的侧滑效果,甚至是需要取消这种效果,基于这些原因,我删除了项目中的ViewPager,并使用普通的app包中的Fragment,其他和之前完全一样,仅仅是v4中的Fragment换成了API11以上才能使用的普通app包中的Fragment,令人振奋的是,下拉的动画变得流畅许多,从叫人完全不能接受的卡顿变成了完全可以接受的流畅度。


具体原因暂时没有仔细研究源码,猜想原因大约有以下几点:

1.普通的Fragment比v4包中的Fragment性能要好,毕竟按常理来说,兼容性必然是以牺牲某些性能作为代价的。

2.ViewPager有页面缓存,在使用ViewPager管理Fragment的时候往往容易忽略对Fragment本身的管理,而且ViewPager管理下的Fragment生命周期和普通的Fragment的生命周期有区别。

3.ViewPager+Fragment,如果每个Fragment都占一屏的话,根据ViewPager的缓存,它实际上会同时加载左右两边缓存的页面,除了数据,视图也会同时加载,等于是一个Activity承担几个Activity面积的视图加载任务,这种缓存不可取消,最少也得有左右相邻各一个同时加载,或许这一点才是视图卡顿的真正原因。


使用普通的Fragment之后再对其生命周期进行管控,适当的销毁和重用某些视图,就能实现较为流畅的视觉效果了。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值