emmmm,这次来梳理一下 Activity 切换动画的研究。首先,老规矩,看一下效果图:
效果图
这次要实现的动画效果就是类似于上图那样,点击某个 view,就从那个 view 展开下个 Activity,Activity 退出时原路返回,即缩放到点击的那个 view。
实现思路
emmm,如果要你来做这样一个效果,你会怎么做呢?
我们就一步步的来思考。
首先来说说,要给 Activity 的切换写动画的话,可以通过什么来实现?也许这种场景比较少,但相信大家多多少少知道一些,嗯,如果你还是不大清楚的话,可以先看看这篇实现Activity跳转动画的五种方式,这个大神总结了几种方式,大概过一下有哪些方案即可,我也没深入阅读,感兴趣的话再慢慢看就可以了。
这里就大概总结一下几种方式:
1.使用 style 的方式定义 Activity 的切换动画
2.使用 overridePendingTransition 方法实现 Activity 跳转动画
3.使用 ActivityOptions 切换动画实现 Activity 跳转动画(部分动画可支持到 api >= 16)
4.使用 ActivityOptions 动画共享组件的方式实现跳转 Activity 动画(api >= 21)
目前我了解的也大概就是以上几种方式,前两种使用方式很简单,只需要在 xml 中写相应的动画(滑进滑出动画、渐变动画、放大动画等),然后应用到相应的 activity 即可。而且还不需要考虑兼容低版本问题。
<!--style方式--><item name="android:activityOpenEnterAnimation">@anim/anim_activity_enter</item><item name="android:activityCloseExitAnimation">@anim/anim_activity_exit</item>//代码方式 startActivity(intent) overridePendingTransition(R.anim.anim_activity_enter, R.anim.anim_activity_exit); //anim_activity_enter.xml 和 anim_activity_exit.xml 就是在 xml 中写动画
上述两种方式使用很简单,效果也很好。缺点就是,不够灵活,只能实现 xml 写出的动画,即平移、渐变、缩放等基本动画的组合,无法实现炫酷的动画。
所以,显然,我们开头效果图展示的动画,用这两种 xml 实现的动画方式并没有办法做到,因为放大动画的中心点位置是需要动态计算的。xml 中写缩放动画时,中心点只能是写死的。
这样的话, style 的动画方案和 overridePendingTransition 的方案就只能先抛弃了,那么再继续看看其他的方案。
ActivityOptions 动画实现方案应该是 Google 在 Android 5.0 之后推出 Material Design 系列里的一个转场动画方案。当然,Google 在后续也推出了一些内置动画,方便开发者直接使用。
上图就是 Google 推出的 Material Design 规范的动画实现里一个示例。关于 Android 5.0 后的动画,网上一大堆相关文章,我也没在这方面里去深入研究过,所以这里就不打算介绍动画要怎么用(不然误导大家就不好了),感兴趣的可以自己去网上找找哈,这里就说下如果要实现开头介绍的动画,用这种方式可行不可行,可行的话又该怎么做。
Android 5.0+ Activity 转场动画
开个小标题,因为觉得下面会讲比较多的东西。
开头效果图的动画:新的 Activity 在点击的 View 的中心点放大。
看上图 MaterialDesign 动画示例中,好像动画效果也是某个 View 展开下个 Activity?那这么说的话,这种方式应该就是可行的了?
对 5.0+ 动画有所了解的话,示例中的动画应该有个名称叫:共享元素切换动画。意思就是字面上说的,两个 Activity 切换,可以设置它们的共享元素,也就是可以让上个界面的某个 View 在下个界面上做动画的一种效果。
既然这样,我们就先来看看 5.0+ 动画,用代码怎么写。
那些动画要怎么实现的我们就不看了,直接看怎么使用。上图的代码是个例子,如果要使用 5.0+ 的 Activity 转场动画,那就不能再继续使用 startActivity(Intent intent) 了,而是要使用 startActivity(Intent intent, Bundle options) 这个方法了。而 options 参数要传入的就通过 ActivityOptions 类指定的一些转场动画了,Google 为我们封装了一些动画接口,我们就来看看它支持哪些转场。
所以,下面就来讲讲 makeScaleUpAnimation() 放大动画和 makeSceneTransitionAnimation() 共享元素动画。因为好像只有这两个可以实现开头效果图展示的动画效果。
对了,上上图中的 ActivityOptionsCompat 类作用的 ActivityOptions 一样,只是前者是 Google 为我们提供的一个兼容实现,因为这是 5.0+ 动画,那么在 5.0 以下的版本就不能使用了,所以 Google 提供了兼容处理,让有些动画可以支持更低版本,动画效果都一致,至于内部具体是怎么实现,有兴趣可以去看看。但也不是所有的动画都做到兼容处理的,像 ActivityOptions 提供的几种动画,基本都可以兼容,但共享元素动画就不行了。至于哪些动画可以兼容,哪些不行,打开 ActivityOptionsCompat 类就清楚了,这个类在 support v4包里,下面就贴张图看看:
makeScaleUpAnimation()
接口参数的作用都在上图里注释了,理解了之后有没有发现,这个接口实现的动画效果就是我们想要的!!从哪放大,宽高从多少开始放大都可以自己设定,完美是不是!
不是的,还是别高兴太早了,这个接口确实可以实现点击哪个 View,就从哪个 View 放大的效果。但是返回呢,Activity 退出时要按原路缩小至点击的 View,这个要怎么做?是吧,找遍了所有接口都没有。
不止这点,还有我们常见的 setDuration() 有找到么,setInterpolator() 有找到么?没有,都没有,也就是说如果要用这个接口做动画的话,动画的执行时间,还有插值器我们都没办法设置,那这肯定没法满足产品的需求啊,哪里有不修改执行时间和插值器的动画!所以,这个方案也抛弃。
makeSceneTransitionAnimation()
共享元素动画就复杂多了,不管是我们要使用它的方式还是它内部做的事。总之,我对这个接触也不多,这里就大概概括一下使用的一些步骤:
需要对共享的元素设置 transitionName,在 xml 中设置 android:transitionName 或代码里调用 View.setTransitionName()。
startActivity(Intent) 换成 startActivity(Intent intent, Bundle options),options 需要通过 ActivityOptions.makeSceneTransitionAnimation() 设置。
优点和缺点一会再说,先看看效果:
效果貌似就是我们想要的,那我们就来说说这种方式的优缺点,然后再做决定。
优点:
进入和退出时的动画都是由内部实现了,我们只需要设置参数就行。
缺点:
共享的元素需要设置相同的 transitionName,我们点击的 View 和打开的 Activity 是动态的,不确定性的。所以,如果对这些 View 都设置相同的 transitionName 不知道会不会有新的问题产生。
新 Activity 的起始宽高和位置无法设置,默认位置是共享的 View,也可以理解成点击的 View,这点没问题。但起始宽高默认是点击 View 的大小,上面 gif 图演示可能效果不太好。也就是说,放大动画开始时,新 Activity 是从点击 View 的宽高作为起始放大至全屏,返回时从全屏缩小至点击 View 的宽高。上图中点击的 view 都很小,所以看不出什么,但在 Tv 应用的页面中,经常有那种特别大的 view,如果是这种情况,那动画就很难看了。
第2点缺点也许可以自己继承 Transition 写动画来解决,但没研究过共享动画的原理,还不懂怎么修改。
最大的缺点是只支持 api >= 21 的。
基于目前能力不够,不足以解决以上缺点所列问题,所以暂时抛弃该方案,但后期会利用时间来学习下 5.0+ 转场动画原理。
emmm,这样一来,岂不是就没办法实现效果图所需要的动画了?别急,方案还是有的,继续往下看。
Github 开源库方案
其实,Github 上有很多这种动画效果的开源库,我找了几个把项目下载下来看了下代码,发现有的人思路是这样的:
Activity 跳转时,先把当前界面截图,然后将这张图传给下个 Activity,然后下个 Activity 打开时将背景设置成上个界面截图传过来的图片,然后再对根布局做放大动画,动画结束后将背景取消掉。
Activity 退出时有两种方案:
方案一:将当前 Activity 背景设置成上个界面的截图(这需要对这张图片进行缓存处理,不然图片很大可能已经被回收了),然后对根布局做缩小动画,动画结束之后再执行真正的 finish() 操作。
方案二:将当前 Activity 界面截图,然后传给新展示到界面的 Activity,然后做缩小动画。(这需要 Activity 有一个置于顶层的 View 来设置截图为背景,然后对这个 View 做动画。
用 View 动画来实现 Activity 转场动画效果
(该集中注意力啦,亲爱的读者们,上面其实都是废话啦,就是我自己在做这个动画效果过程中的一些摸索阶段啦,跟本篇要讲的动画实现方案其实关系不大了,不想看废话的可以略过,但下面就是本篇要讲的 Activity 切换动画的实现方案了)
受到了 Github 上大神开源库的启发,我在想,Activity 界面其实也就是个 View,那既然这样我要打开的 Activity 设置成透明的,然后对根布局做放大动画,这样不就行了?
想到就做,先是在 style.xml 中设置透明:
<item name="android:windowBackground">@android:color/transparent</item>
然后实例化一个放大动画:
ScaleAnimation scaleAnimation = new ScaleAnimation(0.0f, 1.0f, 0.0f, 1.0f, x, y);
宽高从 0 开始放大至全屏,x,y 是放大的中心点,这个可以根据点击的 View 来计算,先看看效果行不行,x,y 就先随便传个值。
动画也有了,那需要找到 Activity 的根布局。想了下,这动画的代码要么是写在基类里,要么是写个专门的辅助类,不管怎样,代码都需要有共用性,那怎么用相同的代码找到所有不同 Activity 的根布局呢?
规定一个相同的 id,然后设置到每个 Activity 布局文件的第一个 ViewGroup 里?---是可行,但太麻烦了,要改动的地方也太多了。
别忘了,每个 Activity 最底层就是一个 DecorView,虽然这个 DecorView 没有 id,但我们可以通过 getWindow().getDecorView() 来获取到它的引用啊。
再不然,我们 setContentLayout() 都是将自己写的布局文件设置到一个 FrameLayout 里,记得吧,这个 FrameLayout 是有 id 的,是 Window 的一个静态常量 ID_ANDROID_CONTENT, 所以我们可以通过下面方式来获取到:
View view = activity.findViewById(activity.getWindow().ID_ANDROID_CONTENT);//View view = activity.getWindow().getDecorView();
透明属性,动画,View 都有了,那接下去就是执行了,在哪里执行好呢,onCreate() 里或 onStart() 里应该都可以。那就先在 onCreate() 里执行试试看好了。
噢,对了,很重要一点,别忘了,Activity 转场是有默认动画的,不同系统可能实现的不同,所以得把这个默认动画关掉,所以可以在 BaseActivity 里重写下 startActivity(),如下:
@Overridepublic void startActivity(Intent intent) { super.startActivity(intent); overridePendingTransition(0, 0); }
overridePendingTransition(0, 0) 传入 0 表示不执行切换动画,呈现出来的效果就是下个 Activity 瞬间就显示在屏幕上了,而我们又对下个 Activity 设置了宽高从 0 开始放大的效果,那么理想中实现的效果应该是:当前 Activity 呈现在界面上,然后下个 Activity 逐渐放大到覆盖住全屏。
好,运行,看下效果:
咦~,为什么周围会是黑色的呢,都设置了 windowBackground 是透明的了啊,emmm,上网查了下,发现还需要一个半透明属性 windowIsTranslucent,所以去 style.xml 中再加上:
<item name="android:windowBackground">@android:color/transparent</item><item name="android:windowIsTranslucent">true</item>
再运行试一下,看下效果:
嗯,效果出来了。那就下去就是退出时的动画了。退出动画跟打开动画其实就是反过程,动画变成缩小动画:
ScaleAnimation scaleAnimation = new ScaleAnimation(1.0f, 0.0f, 1.0f, 0.0f, x, y);
之前从 0 开始放大,现在换成从全屏开始缩小,x,y 就保存在 intent 携带的数据里。那么也就只剩最后一个问题,缩小动画该什么时候执行呢?
我们退出一个页面时一般都是用 finish() 的吧,既然这样,在基类里重写一下这个方法:
@Overridepublic void finish() { ActivityAnimationHelper.animScaleDown(this, new AbsAnimationListener() { @Override public void onAnimationEnd() { BaseActivity.super.finish(); } }); }
x,y 的计算,动画的实现、执行我都是写在一个辅助类里,然后在 BaseActivity 里调用。这个不重要,思想比较重要。我们重写了 finish(),然后去执行缩小动画,同样动画是应用在 Activity 的根布局,然后写一个动画进度的回调,但动画结束时再去调用 super.finish()。也就是说,但调用了 finish() 时,实际上 Activity 并没有 finish() 掉,而是先去执行缩小动画,动画执行完毕再真正的去执行 finish() 操作。
至此,开头所展示的效果图的动画效果已经实现。
但你以为事情做完了么?不,填坑之路才刚开始!(哭丧脸)
优化之路,又名填坑之路
我前面说过,这种方案只能算是一种暂时性的替代方案,知道我什么这么说么?因为这种方案实现是会碰到太多坑了。
1.动画的流畅性问题
首先是动画的流畅性问题,本篇里演示的 gif 图之所以看起来还很流畅,是因为切换的两个 Activity 界面都太简单了,但界面布局复杂一点时,打开一个 Activity 界面的测量、布局、绘制以及我们在 onCreate() 里写的一些加载数据、网络请求操作跟放大动画都挤到一起去了,甚至网络请求回来后更新界面时动画都还有可能在执行中,这样动画的流畅性就更惨了。
在优化时,找到一个大神的一篇文章:一种新的Activity转换动画实现方式
这篇文章里讲的实现原理正是本篇介绍的方案,而且讲得更详细,可以继续去这篇看一下,相信你对本篇介绍的方案会更理解。
有一点不同的是,大神的放大动画的执行时机是在 onPreDraw() 时机开启的,如下:
view.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() { @Override public boolean onPreDraw() { view.getViewTreeObserver().removeOnPreDrawListener(this); if (view.getAnimation() == animation && !animation.hasEnded()) { return false; } view.startAnimation(animation); return true; } });
emmm,说实话,这个回调第一次见,我也不大清楚它的回调时机是什么,作用是什么,网上的解释也摸棱两可,没看明白,待后续有时间自己看看源码好了。
但我可以跟你们肯定的是,我看了一部分 5.0+ 动画源码,它内部也是在一个 Activity 的 onStart() 方法里注册了 onPreDraw() 回调监听,然后在回调时执行 5.0+ 的动画。但它内部做的事,远不止这些,实在是太多了,估计是进行的一些优化操作,我目前是还没有能力去搞懂。
但我们动画执行的时机是需要换一下了,想一下也知道,在 onCreate() 里做动画,听着就感觉有点奇怪。既然大神,还有 Google 官方都是在 onPreDraw() 里执行,那我们当然可以模仿学习。
看 5.0+ 源码过程中,发现它在动画开始和结束前会调用一个 ViewGroup 的 suppressLayout() 方法,这个方法是隐藏的:
这是一个隐藏的方法,我们要调用的话,就需要通过反射的方式。这个方法的注释大概是说禁止 ViewGroup 进行 layout() 操作。这样的话,我们有一个可以优化的地方,我们可以在动画开始时调用这个方法禁止 layout() 操作,动画结束时恢复。
这样做的好处是,动画执行过程中,如果网络或本地数据已经回调,通知 adapter 去刷新 view 时,这样会导致动画很卡顿。所以,当我们用 suppressLayout() 做了优化之后,就只有等动画结束的时候界面才会去重新 layout 刷新布局,优化动画流畅性。
但这样做也有一个问题是,如果你在 onCreate() 或 onResume() 之类的方法发起一个 requestFocus() 操作的话,很有可能这个操作会被丢弃掉,导致界面理应获得焦点的 view 发生错乱问题。
至于原因,因为对 suppressLayout() 也还不是很理解,打算等对 onPreDraw() 理解了之后一起研究一下。
2.windowIsTranslucent 半透明引发的问题
哇,这个属性,真的是。。。
你们好奇的话,就网上搜一下这个半透明属性,一堆各种问题。但其实,网上碰到的那些问题,我基本都没遇到过,但我遇到的是更奇葩,网上没找到解决方案的问题,哭瞎。
emmm,我是做 Tv 应用开发的,windowIsTranslucent 这个在不同的盒子上表现的效果不一样,简直了。
在设置了 android:windowIsTranslucent=true 时,有的盒子界面就会是透明的,即使你设置了一张不透明的背景图,但透明度不会很明显。
有的盒子则是在新的 Activity 打开时,如果 view 没有完全加载出来,则会显示上个 Activity 的界面,造成的现象就是打开新 Activity 时,会一瞬间闪过上个界面的画面。
还有,Tv 应用一般都会跟视频播放有关,那就涉及到播放器。而播放器需要一个 surfaceview,而 surfaceview 遇到半透明属性时,问题更多。
原因,都不清楚(哎,可悲)。但只要不使用半透明这个属性,就一切正常了,但如果不用这个属性,本篇介绍的动画方案又没法实现。这真的是鱼和熊掌不可兼得啊。
所以,我就在想,既然 windowIsTranslucent 为 false 时,一切正常;为 true 时,动画正常。那是否有办法在动画过程中设置为 true,动画结束之后设置为 false 呢?如果可以的话,按理来说应该正好解决问题。
但找了半天,没有找到相关的接口来动态设置这个属性的值,这个半透明属性值是设置在 style.xml 里的。网上有一些介绍说:在代码动态修改 style 的,但打开那些文章你会发现,说的是动态修改,但基本都要求要么在 super.onCreate() 之前调用,要么在 setContentLayout() 之前,要么重写 setTheme(),这么多限制,那哪里有用。
后来,在找播放器黑屏的问题时,找到一篇大神写的博客:Android版与微信Activity侧滑后退效果完全相同的SwipeBackLayout。
题目虽然看起来跟本篇一点关系都没有,但作者遇到的问题跟我的问题本质上是一个的,也是 windowIsTranslucent 属性导致的问题。很开心的是,作者介绍了利用反射去调用 Activity 里的 convertFromTranslucent() 和 convertToTranslucent() 方法来动态修改这个半透明属性值,这两个方法是对外隐藏的。
后来,我很好奇 5.0+ 的动画到底是怎么实现的这种动画效果,因为它明明不需要设置 windowIsTranslucent 为 true,但它的动画,Activity 在跳转时,上个 Activity 是可见的,这是怎么做到的。
我跟踪了一部分源码,也很开心的发现,原来它内部也是用的 Activity 里的这两个方法,在动画开始前将 Activity 设置成半透明的,动画结束后设置回去。当然,内部它有权限调用 Activity 的方法,而我们没有权限,所以只能通过反射来调用。
开心,问题解决了。我们只要通过反射,在动画开始之前调用 Activity 的 convertToTranslucent() 将 Activity 设置成半透明的,动画结束再调用 convertFromTranslucent() 设置回去,这样动画的效果达到了,又不会因为设置了 windowIsTranslucent 为 true 而引入各种问题。
但是,测试时发现,在 api 21 以下的盒子上,这个方法没启作用。
我去查看,比较了下 21 以上和以下 Activity 的代码,发现 convertToTranslucent() 这个方法它的内部实现是不一样的,21及以上是一套代码,21以下至19是一套代码,19以下则是没有这两个方法。
后来又仔细看了上面大神那篇文章,发现说,原来 19-21 的版本,这两个方法要能够生效的话,需要默认在 style.xml 先将 Activity 设置成半透明的,而 21 及以上的,则不需要。至于19以下的,就完全不能用这个方法了。
解决方法也很简单,那就在 style.xml 默认设置 Activity 是半透明的,这样动画结束之后再设回去就可以了。
但是,这样播放器就会有问题---黑屏。原因是因为调用了 convertFromTranslucent() 设置不透明,一旦调用这个方法,如果该界面有播放器,那么就会黑屏。至于具体原因,还是不清楚,上面那个大神的文章里也提到了这个现象,但他也不知道如何解决,我也不知道。
最后,为了解决黑屏的问题,只能是如果界面有播放器的话,那个这个界面的动画就换另外一种方法来实现,至于是什么方案也可以实现开头介绍的动画效果,我就不说了,Github 上很多,但都有同一个特点,那就是贼麻烦。
稍微总结一下,本篇提的动画方案适用于以下几种场景:
如果你的应用设置了 windowIsTranslucent 为 true 时,没有发现什么问题的话,那恭喜你,该动画方案可以兼容各种版本。
如果你的应用设置了 windowIsTranslucent 为 true 时会有一些问题,但你的应用里没有播放器的话,那恭喜你,该动画方案可以兼容 19 及以上版本。
如果你的应用设置了 windowIsTranslucent 为 true 时会有一些问题,而且应用里也有播放器的话,那如果你实在走投无路想使用该动画方案的话,那你再来找我吧,在研究出其他方案之前,咱们一起来慢慢填坑。
注:本篇侧重点是介绍一种 Activity 动画方案的实现思路,注意,是思路!因为本篇所介绍的动画方案并不成熟,仍有很多坑,所以,学习、探讨就可以,慎用!
Github 链接
上传了一个 demo,如果对这种动画方案感兴趣的话,可以去看看代码。跟动画有关的代码都在 ui/anim 文件夹里。
一种 Activity 转场动画----点击哪里从哪放大
遗留问题
老样子,最后再留几个问题给大家思考一下(其实我也不懂,还望有大神能解答一下)
Q1:overridePendingTransition() 实现的转场动画一点都不卡,但用 View 动画方案来实现 Activity 转场动画有时会有些卡顿,感觉是 Activity 启动做的那一大堆事跟动画挤一起了,那 overridePendingTransition() 原理到底是怎么实现?跟着源码跳进去看感觉有点懵,有时间得再研究一下这部分的源码。
Q2:Activity 切换时,一般下个 Activity 直接覆盖在本 Activity 上了,按我的理解,如果对要打开的 Activity 的 window 设置成透明属性,那应该就可以看到下层的 Activity 才对,为什么不行呢?为什么一定要设置 android:windowIsTranslucent = true 才可以呢?android 5.0 的共享元素动画很明显可以看到下个 Activity 在缩放时,上个 Activity 是可见的,那么它又是怎么实现的呢?原理是什么呢?这部分源码看了一部分了,等理解透了点,在梳理出来。