欢乐的票圈重构——图片过渡动画(上)

项目重构的Git地址:
https://github.com/razerdp/FriendCircle/tree/main-dev
项目同步更新的文集:
http://www.jianshu.com/notebooks/3224048/latest

上集:欢乐的票圈重构——九宫格控件(下)

本文未经授权,请勿转载。本文唯一更新平台为简书,其余平台皆为未授权,请悉知。


写在前面:

是的,朋友圈的经验文章继续更新,只是不得不加上上面那句提示。。。

嘛,不管他们了,我们更我们的,他们抄他们的,等有一天我们项目在开源区火起来,还怕别人认不出?(虽然不太可能,毕竟我不太会宣传哈哈)。

本文开始将会是朋友圈核心功能点和UI难点的经验分享,很多时候不要小看任何一个小小的动画,这么一个小小的动画可能需要你上千行代码去实现它。

所以交互设计师至今还能在程序员堆里生存下来,我也是觉得他们很厉害。

OK,废话不多少,上预览图(实际效果去Github把项目clone下来体验一番吧,会更好哦):

2017-02-08图片退出动画.gif

介绍:

本控件篇幅较长,将会分为几个章节来讲(具体几个未定,写完我再回来更新)。

本文是第一章,按照惯例,不做代码,不做设计,只做猜想,只做推断。

说到朋友圈,在Android和iOS都有这个图片的过渡动画,也正是因为有了这个过渡动画,才显得看图片的时候有着“丝般顺滑”的享受快感。

那么问题来了,这个动画应该怎么实现呢?

也许,你会不屑的说一句:切,萝莉炮(Lollipop)不就有共享元素么,有多难的东西,一两句话就完成了,有什么好写的?

当然,这么想也无可厚非,毕竟我一开始也是这么想的,只是再回过头来想一下,萝莉炮之后才支持,那萝莉炮之前呢?

而且,对于朋友圈来说,其实共享元素的转场动画,还真他喵的不适用。。。

无图无真相,上图:

共享元素动画

噢,先说一句,因为我懒,所以这个代码改自一个开源项目(没错,百度Android共享元素动画的第一条结果):https://github.com/cnzx219/android-scene-animation,他的对应博客地址是:http://blog.csdn.net/cnzx219/article/details/47143035

回到正题,如动图所示,第一次点击的大萌喵看起来好像很自然诶,第二次点击的大萌喵在回退动画中乍一看还是可以接受的,但最后一次点的图片就不能接受了,在回退的最后一帧很明显的有闪烁。

造成这种结果的原因很简单(划重点啦):

  • 动画前的ImageView是正方形的centerCrop,动画后的ImageView是match_parent且没有scaleType的。

前后两者大小和scaleType不一致就会导致回退动画的不协调。

也许你会好奇怎么会有这么奇葩的需求,哎,别好奇,我们票圈不就是这样么?

总结一下票圈的图片特点:

  • 图片除了单图外,都是一样大小的正方形
  • 缩略图一律centerCrop,大图一律没有scaleType
  • 转场动画没有任何的闪动
  • ps:如果是大图放大过,在回退的时候会先重置为初始大小(1倍值),再进行动画

总的而言,如果说这他喵的就是一个共享元素动画完成的事情,那我劝你不要看文章了,反正有什么不是api不能搞定的?坐等更新不就好了吗。


猜想:

事实上,在很久以前的文章:一起撸个朋友圈吧 - 图片浏览(中)【图片浏览器】,我就初步实现过这个效果,那时候我的技术还是很渣,也就只能想(Google)到Animator来解决,同时大图浏览层和时间线同属于一个Activity,即使我把它封装到一个manager里面,还是不能解决这货臃肿的问题。

同时,在回退动画里我一直觉得不满意,甚至用了Alpha动画来掩盖瑕疵,这样肯定是不行滴。。。。

于是就有了第二篇:
一起撸个微信图片浏览的BaseActivity吧(上)——初步思考与基础结构

这这篇里,我成功的把图片预览放到了另外一个Activity里面做,效果类似于共享元素,原理其实我觉得也差不多,但还是不满意,理由很简单:

  • 他喵的实现太复杂了好咩!!!!
  • 而且只能实现单图的过渡好咩!!!!

一直以来的不满就成就了我们今天的朋友圈和这篇文章,因为篇幅问题(懒的问题),所以对于那两篇文章在这里就不详细谈了,感兴趣的就去看一下吧。

从这两次文章里,我总结一下之前过渡动画的实现方案:

  • 放大阶段:
  • 获取小图的Rect(或者说frame吧),传递到另一个Activity
  • 另一个Activity获取到信息后,通过Animator从传过来的Rect开始做放大动画,直到填充屏幕位置。
  • 缩小(回退)阶段:
  • 没啥好说的,就是放大阶段的倒过来。

其中放大动画其实是没问题的,毕竟简单好用而且妥妥的。。。

但是缩小动画就有点问题了,原因很简单,因为我们针对View来做缩放动画,从而导致了里面的Drawable(或者说bitmap吧)会被强行压缩,但是因为drawable并不总是填满整个ImageView,所以我们又得针对Drawable的大小来做适配。

总的来说,我们要同时兼顾View的缩放和Drawable的缩放。很容易造成顾此失彼,所以也就造成了效果不理想同时代码复杂度爆炸。

总结过之后,其实我们回过头一想,根据一起撸个朋友圈吧 - 图片浏览(中)【图片浏览器】里面我做的AE原理动画,我们知道最终目的是让View缩放到原来的大小。但上面我们说过,做View的缩放就要同时兼顾Drawable。

所以,我们为何不直接对Drawable做缩放动画,而View不做动画呢。

而这,正是我们这个控件的核心所在:Matrix

把以前对View做缩放动画改为对Drawable做缩放动画,也就是通过Matrix来控制Drawable的大小,位置,让其缩放到原来缩略图传递过来的大小即可完美覆盖不闪烁。(当然,同时还有画布的裁剪,毕竟从一个矩形裁剪为一个正方形嘛)

至于如何实现?你可以去github阅读源码,也可以关注《一起撸个朋友圈吧》的最新更新,当然也可以关注我。

最后的最后,请不要客气,尽情的砸issue或者pull request过来吧,照单全收!

推荐阅读更多精彩内容