这是一个创建于 3646 天前的主题，其中的信息可能已经有所发展或是发生改变。
先上视频，1.5x 过渡时间便于展示
S3:
http://goo.gl/SbsQbB
YouTube:
(Chrome 打开 60fps)
性能：Nexus 4 表现——
https://s3.amazonaws.com/pushbullet-uploads/ujEcd63eUE0-isE9dtzJsbUkDqinIvSj1a9iiuqnom4e/Screenshot_2015-01-02-12-01-09.png
即使用上 bitmap，动画也是妥妥的60帧 :)
坑：
* shared element 会遮挡 Toolbar, NavBar 和 StatusBar的 background，有时候会闪烁。
* 参与 transition 的元素太长的时候（比方说 1000dp ）art 会报错，transition 会失效甚至 Activity 会 crash，完全摸不着头脑。我的解决方法是先用 animator 把长元素缩短，然后 remove， 之后再执行 Activity transition。
* 如果 parent ViewGroup 含有背景的话 child 是不能分别 transit 的
不是坑的坑：
* transition 会拖慢页面到页面的转换速度，对于有些手速超群的用户可能不能忍受？
S3:
http://goo.gl/SbsQbB
YouTube:
(Chrome 打开 60fps)
性能：Nexus 4 表现——
https://s3.amazonaws.com/pushbullet-uploads/ujEcd63eUE0-isE9dtzJsbUkDqinIvSj1a9iiuqnom4e/Screenshot_2015-01-02-12-01-09.png
即使用上 bitmap，动画也是妥妥的60帧 :)
坑：
* shared element 会遮挡 Toolbar, NavBar 和 StatusBar的 background，有时候会闪烁。
* 参与 transition 的元素太长的时候（比方说 1000dp ）art 会报错，transition 会失效甚至 Activity 会 crash，完全摸不着头脑。我的解决方法是先用 animator 把长元素缩短，然后 remove， 之后再执行 Activity transition。
* 如果 parent ViewGroup 含有背景的话 child 是不能分别 transit 的
不是坑的坑：
* transition 会拖慢页面到页面的转换速度，对于有些手速超群的用户可能不能忍受？
第 1 条附言 · 2015-01-03 00:26:24 +08:00
楼下有些人认为动画是浪费时间浪费资源的不必要元素。我把我的回复附加在主题之后，希望大家能够多多指点：
*注：视频中的的速度是为了便于展示而放大时间轴 1.5 倍的，实际速度会快 1/3。除了蓝色的部分，其余色块都是动态加载的。
1. 点击蓝色部分（一张图片）启用一个 Shared Element 过渡，耗时和 KitKat 及之前的 Fade 效果耗时是一样的。这部分并不浪费时间。
2. 绿色部分可能是标题，描述等，往往从数据库获得，并不在内存中，因此需要时间去加载，等加载完成出现一个从下的 Appending 效果。
3. 橘色部分可能是具体的 detail，往往不在数据库中，需要一个网络请求去获取，然后加入数据库再显示出来，因此速度最慢，所以最后加载，应用一个底部 Appending 的效果。
4. 红色 FAB 绝大多数情况下是一个 Like （赞）的按钮，自身是带有状态的（赞与不赞），也是需要从网络请求获取的（你可以考虑下多个终端的情况）。在从服务器获取信息前就显示一个状态是完全不优雅的。因此也是后来才加载的。
5. 说退出，FAB 和 绿色橘色部分首先消失完全是因为 Android L的一个问题：Shared Element 会覆盖一切，造成 Material Design 中的 z 轴层级逻辑混乱。
6. 绿色和橘色是一起下滑的，不会浪费时间。
我觉得在实际操作中，是浪费不了多少时间的，逻辑还更加清晰，比方说你知道FAB 是可以交互的，你知道整个 view 是可以向下滚动的，你知道你的图片是因为点击了列表而来的。
*注：视频中的的速度是为了便于展示而放大时间轴 1.5 倍的，实际速度会快 1/3。除了蓝色的部分，其余色块都是动态加载的。
1. 点击蓝色部分（一张图片）启用一个 Shared Element 过渡，耗时和 KitKat 及之前的 Fade 效果耗时是一样的。这部分并不浪费时间。
2. 绿色部分可能是标题，描述等，往往从数据库获得，并不在内存中，因此需要时间去加载，等加载完成出现一个从下的 Appending 效果。
3. 橘色部分可能是具体的 detail，往往不在数据库中，需要一个网络请求去获取，然后加入数据库再显示出来，因此速度最慢，所以最后加载，应用一个底部 Appending 的效果。
4. 红色 FAB 绝大多数情况下是一个 Like （赞）的按钮，自身是带有状态的（赞与不赞），也是需要从网络请求获取的（你可以考虑下多个终端的情况）。在从服务器获取信息前就显示一个状态是完全不优雅的。因此也是后来才加载的。
5. 说退出，FAB 和 绿色橘色部分首先消失完全是因为 Android L的一个问题：Shared Element 会覆盖一切，造成 Material Design 中的 z 轴层级逻辑混乱。
6. 绿色和橘色是一起下滑的，不会浪费时间。
我觉得在实际操作中，是浪费不了多少时间的，逻辑还更加清晰，比方说你知道FAB 是可以交互的，你知道整个 view 是可以向下滚动的，你知道你的图片是因为点击了列表而来的。
12 条回复 • 2015-01-12 09:43:12 +08:00
 |
1
kmvan 2015-01-02 20:24:10 +08:00 via Android
全关掉就是了，纯浪费时间电量的效果
|
|
3
kmvan 2015-01-02 21:13:38 +08:00
@allan1st 囧.... 各路设计师都要痛哭流涕了。以后就算是网页也把 css、js 都取消算了。
这是事实。各种过渡动画，都是消耗更多额外电量的。cpu或gpu要一帧一帧去渲染，本来手机电量就不够用，还弄这些玩意，就是浪费资源的表现。不然win7在用电池模式的时候也不会默认把关闭aero效果吧。你试试把gpu渲染显示灯开出来，你就知道gpu多可怜了... 关闭所有动画，打开程序就是爽，一点即显示，爽！哪像IP那些，选上减少动态效果，还渐变来渐变去，浪费电量浪费人生啊。 顺便提一下，css3的transition效果，很耗CPU。 |
 |
4
allan1st OP @kmvan 不会『浪费』多少电量的，你自己对比一下就知道了，如果这也不能接受的话，列表的滚动是不是也算『浪费』电量？
对用户电量负责是程序员的职责，需要和设计师去沟通的。你的想法太极端：渐变、甚至滚动都是需要一帧帧渲染的，按照你的说法 App 都放弃滚动，做成的『上一页』和『下一页』算了。 其实你的需求也有相应的产品：e-ink。你可以去看下那台俄罗斯的 YotaPhone，但是它也没有完全抛弃滚动和过渡。 |
|
7
kmvan 2015-01-02 23:37:39 +08:00
@allan1st 列表的滚动是不是也算『浪费』电量？
列表滚动跟过场动画是两回事，列表滚动我认为是必须的，手指在那，内容就在哪。但过场动画从软件界面按home返回桌面，瞬间完成的难道你不觉得很爽吗？使用软件中，突然想运行另外的app，立马返回桌面点击，一气呵成。特别是萝莉炮的点击效果，差点没笑死我。点击一下，有“涟漪“！有涟漪就算了，但在五儿子上，出现涟漪的瞬间进行其他操作，涟漪经常会卡一下或掉帧。那么我想问，这种所谓的动画，真的有用吗？花销和实用性，谁更高？ 萝莉炮的动画设计初衷是好的，”要让用户知道自己的行为对内容产生了什么影响“，但这涟漪效果真不敢恭维，随便弄个反色都比他强。 虽然说物质世界的运动都是有”动画“的，但操作软件界面，跟物质世界不同的啊。点击一个图标，我要的就是马上打开软件显示内容，而不是先出现涟漪效果，然后慢慢把软件的界面从最小放大到全屏，这何必呢。我又不是坐车从A城市到B城市，况且说不定几千年后，A城市到B城市，也就是几毫秒的事情，还需要坐公交车慢慢跑吗？ 说动画效果，就不得不提 WP 系统了，WP 系统的动画效果没得取消也没得”减少“，每一次过场，图标都从天边飘来，飘来时的300～500毫秒内，就算知道那个图标在什么地方，也是没法点击的，一定要让他飘完定住才能点击。每个动作都浪费这么300毫秒，玩起来真累。 |
 |
8
bigzhu 2015-01-03 00:18:06 +08:00
@kmvan 完全赞同, 但是悲剧的是人类就是个视觉动物. 苹果手机也惯出了一大批没有滑动效果就觉得整个人都不好了的用户.
各种坑爹的滑动效果, 浪费电, 浪费时间. 滑来滑去眼睛不花么? 遗憾的来说, 这个事情跟人的进化有关系. 原始的大脑需要看到一个东西从哪里来, 到哪里去, 对于突然蹦出来的东西, 总是想着去分泌肾上腺素. 带来的不适感是让人难以忍受的. 必要的, 引导性的, 消除这种不适感的动画还是有存在必要的, 因为我们毕竟还进化的不完全. 即便是自己点击的按钮, 突然蹦出来还是会吓一跳, 尤其是进化的不够, 吓得就更厉害. 所以为了照顾这些没进化好的人类, 还是得有动画. 对那些滥用动画, 浪费时间的, 必须要坚决鄙视. |
|
9
allan1st OP @kmvan 按 Home 键返回默认是没有过场效果的，只有一个向底部的 Slide 啊，这个也接受不了啊？涟漪效果在立即启动一个新的 Activity 的时候你只能看到开始，甚至是看不到的，只有你在长按的时候或者你按下去需要一定时间来后台处理是才能看到，你可以去 Play Store 主页试试看。
我来解释一下我的视频：前提——良好的 Android App UI 必须是非阻塞的，也就是在后台加载的时候并不影响主线程的 UI。 以我的 Demo 为例： 1. 点击蓝色部分（一张图片）启用一个 Shared Element 过渡，耗时和 KitKat 及之前的 Fade 效果耗时是一样的。这部分并不浪费时间。 2. 绿色部分可能是标题，描述等，往往从数据库获得，并不在内存中，因此需要时间去加载，等加载完成出现一个从下的 Appending 效果。 3. 橘色部分可能是具体的 detail，往往不在数据库中，需要一个网络请求去获取，然后加入数据库再显示出来，因此速度最慢，所以最后加载，应用一个底部 Appending 的效果。 4. 红色 FAB 绝大多数情况下是一个 Like （赞）的按钮，自身是带有状态的（赞与不赞），也是需要从网络请求获取的（你可以考虑下多个终端的情况）。在从服务器获取信息前就显示一个状态是完全不优雅的。因此也是后来才加载的。 5. 说退出，FAB 和 绿色橘色部分首先消失完全是因为 Android L的一个问题：Shared Element 会覆盖一切，造成 Material Design 中的 z 轴层级逻辑混乱。 6. 绿色和橘色是一起下滑的，不会浪费时间。 你可以把 2-6 用首先显示 place holder 然后异步替换的方式做到，但是这个逻辑性比较差。 我觉得在实际操作中，是浪费不了多少时间的，逻辑还更加清晰，比方说你知道FAB 是可以交互的，你知道整个 view 是可以向下滚动的，你知道你的图片是因为点击了列表而来的。当然你喜欢那种唐突的切换效果也可以自己在 Developer 选项中关掉，不影响使用。 |
 |
10
wohenyingyu01 2015-01-03 08:53:46 +08:00
@kmvan 用彩屏也是浪费电，用黑白屏吧，智能机更是浪费电，功能机多好
|
|
11
kmvan 2015-01-03 10:26:10 +08:00 via Android
@wohenyingyu01 用彩屏也是浪费电，用黑白屏吧，智能机更是浪费电，功能机多好
所以星有个超级省电模式，开了就是黑自屏，消除任何动画，能打电话上网发信息。还好我没钱买三星，不然肯定24小时开着超省模式了。 |
 |
12
Stof 2015-01-12 09:43:12 +08:00 via iPhone
总结一下楼上的发言：
那么多动画太费电，不要了吧😃 哎呀屏幕那么费电，不用了吧😃 开车费油太费钱了，不开了吧😃 看电视对眼睛不好，不看了吧😃 你是男的又有孩子，要你干嘛😄 |
Select Language