【Android14 ShellTransitions】（一）开篇

说来忸怩，AndroidU都已经开发这么久了，但是我还没有整理过ShellTransition相关的知识。我本来希望可以或许体系的写一篇关于ShellTransition的条记出来，但是发现一来这是一个比较巨大的模块，二来我个人能力有限，对ShellTransition目前掌握的并不透彻，只是昏黄上大要有一个认知。假如把ShellTransition的方方面面都了解清楚再去写这么一篇条记，google说不定已经不消ShellTransition了，就像我刚刚弄清楚AppTransition和AppTransitionController这块的逻辑，AndroidU就把动画逻辑变成ShellTransition了一样，有点不讲武德了。以是趁ShellTransition还健在，我觉得还是一气呵成吧，哪天看了ShellTransition的代码有点感悟了就去做相关记录，这样做的缺点就是知识点比较零星，写的会比较随意，而且也可能有理解的不到位的地方，但是希望可以靠反面的持续更新来慢慢改善这些不敷，总比ShellTransition坟头草都三米高了才想起来要总结要好。
废话就到这里，现在开始吧。
ShellTransition相关类

网上关于ShellTransition的介绍还是比较少的，这个时间想要立刻可以或许对ShellTransition有一个大概认知，我一般会看注释，以是这里也是先看ShellTransition相关的类的注释。
1 TransitionController

首先是TransitionController，它有点像之前的AppTransitionController，是WMCore这边的动画的控制器调理器之类的，控制动画的生命周期。
另外一提，这里有一个WMCore和WMShell的新概念，好像是和这些的类的包名有关，比如TransitionController这个类，它的目次为：
frameworks/base/services/core/java/com/android/server/wm/TransitionController.java
包名为：com.android.server.wm
它被归纳为WMCore里的。
而下面的Transitions类，它的目次为：
frameworks\base\libs\WindowManager\Shell\src\com\android\wm\shell\transition\Transitions.java
包名为：com.android.wm.shell.transition
它被归纳为WMShell里的。
好了，继承看TransitionController的注释：

1. /**
2. * Handles all the aspects of recording (collecting) and synchronizing transitions. This is only
3. * concerned with the WM changes. The actual animations are handled by the Player.
4. *
5. * Currently, only 1 transition can be the primary "collector" at a time. This is because WM changes
6. * are still performed in a "global" manner. However, collecting can actually be broken into
7. * two phases:
8. *    1. Actually making WM changes and recording the participating containers.
9. *    2. Waiting for the participating containers to become ready (eg. redrawing content).
10. * Because (2) takes most of the time AND doesn't change WM, we can actually have multiple
11. * transitions in phase (2) concurrently with one in phase (1). We refer to this arrangement as
12. * "parallel" collection even though there is still only ever 1 transition actually able to gain
13. * participants.
14. *
15. * Parallel collection happens when the "primary collector" has finished "setup" (phase 1) and is
16. * just waiting. At this point, another transition can start collecting. When this happens, the
17. * first transition is moved to a "waiting" list and the new transition becomes the "primary
18. * collector". If at any time, the "primary collector" moves to playing before one of the waiting
19. * transitions, then the first waiting transition will move back to being the "primary collector".
20. * This maintains the "global"-like abstraction that the rest of WM currently expects.
21. *
22. * When a transition move-to-playing, we check it against all other playing transitions. If it
23. * doesn't overlap with them, it can also animate in parallel. In this case it will be assigned a
24. * new "track". "tracks" are a way to communicate to the player about which transitions need to be
25. * played serially with each-other. So, if we find that a transition overlaps with other transitions
26. * in one track, the transition will be assigned to that track. If, however, the transition overlaps
27. * with transition in >1 track, we will actually just mark it as SYNC meaning it can't actually
28. * play until all prior transition animations finish. This is heavy-handed because it is a fallback
29. * situation and supporting something fancier would be unnecessarily complicated.
30. */
31. class TransitionController

复制代码

处理记录（网络）和同步Transition的全部方面。 这仅涉及WM更改。 现实的动画由Player处理。
目前，一次只能有 1 个Transition成为重要“网络器”。 这是因为 WM 更改仍旧以“全局”方式实行。 然而，网络现实上可以分为两个阶段：
1. 现实进行WM更改并记录参与的容器。
2. 等待参与容器准备停当（比方重绘内容）。
因为 (2) 耗费了大部分时间而且不会改变 WM，以是我们现实上可以在阶段 (2) 中同时进行多个Transition，同时在阶段 (1) 中进行一个Transition。 我们将这种安排称为“并行”网络，只管现实上仍旧只有 1 个Transition可以或许获得参与者。
当“主网络器”完成“设置”（第 1 阶段）并等待时，会发生并行网络。 此时，另一个Transition可以开始网络。 发生这种情况时，第一个Transition将移至“等待”列表，新Transition将成为“主网络器”。 假如在任何时间，“主网络器”在其中一个等待Transition之前开始播放，则第一个等待Transition将变回“主网络器”。 这维持了 WM 其余部分当前所盼望的“全局”抽象。
当一个Transition移动到播放时，我们会根据全部其他播放Transition进行检查。 假如它不与它们重叠，它也可以并行动画。 在这种情况下，它将被分配一个新的“轨道”。 “轨道”是一种与Player沟通哪些Transition必要相互串行播放的方式。 因此，假如我们发现一个Transition与一个轨道中的其他Transition重叠，则该Transition将被分配给该轨道。 但是，假如Transition与 大于1个轨道中的Transition重叠，我们现实上会将其标记为 SYNC，这意味着在全部先前的Transition动画完成之前它无法现实播放。 这是一种笨拙的做法，因为这是一种后备情况，支持更高级的东西会变得不须要的复杂。
2 Transitions

1. /**
2. * Plays transition animations. Within this player, each transition has a lifecycle.
3. * 1. When a transition is directly started or requested, it is added to "pending" state.
4. * 2. Once WMCore applies the transition and notifies, the transition moves to "ready" state.
5. * 3. When a transition starts animating, it is moved to the "active" state.
6. *
7. * Basically: --start--> PENDING --onTransitionReady--> READY --play--> ACTIVE --finish--> |
8. *                                                            --merge--> MERGED --^
9. *
10. * The READY and beyond lifecycle is managed per "track". Within a track, all the animations are
11. * serialized as described; however, multiple tracks can play simultaneously. This implies that,
12. * within a track, only one transition can be animating ("active") at a time.
13. *
14. * While a transition is animating in a track, transitions dispatched to the track will be queued
15. * in the "ready" state for their turn. At the same time, whenever a transition makes it to the
16. * head of the "ready" queue, it will attempt to merge to with the "active" transition. If the
17. * merge succeeds, it will be moved to the "active" transition's "merged" list and then the next
18. * "ready" transition can attempt to merge. Once the "active" transition animation is finished,
19. * the next "ready" transition can play.
20. *
21. * Track assignments are expected to be provided by WMCore and this generally tries to maintain
22. * the same assignments. If, however, WMCore decides that a transition conflicts with >1 active
23. * track, it will be marked as SYNC. This means that all currently active tracks must be flushed
24. * before the SYNC transition can play.
25. */
26. public class Transitions

复制代码

播放Transition动画。 在这个Players中，每个Transition都有一个生命周期。
1. 当直接启动或请求Transition时，将其添加到“PENDING ”状态。
2. 一旦 WMCore 应用Transition并发出通知，Transition就会转至“READY ”状态。
3. 当Transition开始动画时，它会转至“ACTIVE ”状态。
基本上：–start–> PENDING --onTransitionReady–> READY --play–> ACTIVE --finish–> --merge–> MERGED –
READY 及以后的生命周期按“轨道”进行管理。 在一个轨道中，全部动画都按形貌的方式串行排列； 但是，多个轨道可以同时播放。 这意味着，在一个轨道内，一次只能有一个Transition处于动画状态（“ACTIVE ”）。
当一个Transition在一个轨道中进行动画时，分派到该轨道的Transition将以“READY ”状态排队等待轮到。 同时，每当Transition到达“READY ”队列的头部时，它将尝试与“ACTIVE ”Transition合并。 假如合并乐成，它将被移动到“ACTIVE ”Transition的“合并”列表，然后下一个“READY ”Transition可以尝试合并。 一旦“ACTIVE ”过渡动画完成，就可以播放下一个“READY ”Transition。
轨道分配预计由 WMCore 提供，这通常会尝试保持雷同的分配。 但是，假如 WMCore 确定Transition与大于1个活动轨道冲突，则会将其标记为 SYNC。 这意味着在 SYNC Transition可以播放之前，必须革新全部当前活动的轨道。
3 Transition

1. /**
2. * Represents a logical transition. This keeps track of all the changes associated with a logical
3. * WM state -> state transition.
4. * @see TransitionController
5. *
6. * In addition to tracking individual container changes, this also tracks ordering-changes (just
7. * on-top for now). However, since order is a "global" property, the mechanics of order-change
8. * detection/reporting is non-trivial when transitions are collecting in parallel. See
9. * {@link #collectOrderChanges} for more details.
10. */
11. class Transition implements BLASTSyncEngine.TransactionReadyListener

复制代码

代表一个逻辑转换。这会跟踪与逻辑WM状态->状态转换相关的全部更改。
除了跟踪单个容器更改之外，这还跟踪排序更改（目前仅在顶部）。然而，由于顺序是一个“全局”属性，当转换并行网络时，顺序更改检测/报告的机制并不简单。
4 小结

看了注释实在还是挺懵b的，重点看下这块：
start–> PENDING --onTransitionReady–> READY --play–> ACTIVE --finish–> --merge–> MERGED
这里说下我个人的理解。
首先Transition是有一个状态集的：

• STATE_PENDING，当Transition刚被创建的时间就是这个状态。
  
• STATE_COLLECTING，当Transition开始网络动画参与者的时间，就会被置为这个状态。
  
• STATE_STARTED，Transition已经被正式启动，它仍在网络中，但一旦全部参与者准备好进行动画（完成绘制），它将停止。结合STATE_COLLECTING，这里的意思应该就是说，假如Transition没有被start，那么它将不停处于网络参与者的状态，及时全部参与者都已经完成绘制可以开始动画了，但是因为当前Transition没有被启动，以是也无法进行下一步。
  
• STATE_PLAYING，Transition正在实行动画，而且不能再继承网络了，也不能被改变。也就是说此时谁谁谁要实行动画已经确定了，而且这些参与者已经开始进行动画了，以是就不能再去网络新的参与者了，而且也不能对当前Transition进行修改了。
  
• STATE_FINISHED，Transition已经乐成实行完了动画。
  
• STATE_ABORTED，Transition正在被中断或者已经中断，不会实行任何动画，也不会将任何内容发给player。
  

看到实在代码中是没有界说注释中说的那些READY、MERGED的状态的。
我们重要关注除STATE_ABORT的状态，既然是状态，那一般就是某段时间中Transition所处的一个状态，Transition不停处于这种状态，直到某个时间点发生了一些标志性事件，导致了Transition进入下一个状态。
1）、创建Transition，Transition的最初状态，STATE_PENDING状态。
2）、moveToCollecting，Transition进入STATE_COLLECTING状态。
3）、requestStartTransition，Transition进入STATE_STARTED状态。
4）、onTransitionReady，Transition进入STATE_PLAYING状态。
5）、finishTransition ，Transition进入STATE_FINISHED状态。
接下来我们以在Launcher界面点击App图标启动某个App为例，来分析一般过程，但是无法面面俱到，一些细节希望靠后续的系列文章可以补充。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。