项目重构的Git地址：
https://github.com/razerdp/FriendCircle/tree/main-dev
项目同步更新的文集：
http://www.jianshu.com/notebooks/3224048/latest
本文未经授权，请勿转载。本文唯一更新平台为简书，其余平台皆为未授权，请悉知。
写在前面：
是的，朋友圈的经验文章继续更新，只是不得不加上上面那句提示。。。
嘛，不管他们了，我们更我们的，他们抄他们的，等有一天我们项目在开源区火起来，还怕别人认不出？（虽然不太可能，毕竟我不太会宣传哈哈）。
本文开始将会是朋友圈核心功能点和UI难点的经验分享，很多时候不要小看任何一个小小的动画，这么一个小小的动画可能需要你上千行代码去实现它。
所以交互设计师至今还能在程序员堆里生存下来，我也是觉得他们很厉害。
OK，废话不多少，上预览图（实际效果去Github把项目clone下来体验一番吧，会更好哦）：
介绍：
本控件篇幅较长，将会分为几个章节来讲（具体几个未定，写完我再回来更新）。
本文是第一章，按照惯例，不做代码，不做设计，只做猜想，只做推断。
说到朋友圈，在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过来吧，照单全收！
