– 英语/中文 双语歌词

歌词与翻译

[中文]

...

嗨。

我是 Chet Haase，一名工程师 Android UI 工具包团队。

今天我要讲的是 关于 KitKat 版本中的新动画

功能。

这称为转换。

所以这个想法 转换实际上是

背后的想法 我们所做的很多事情

都试图 让事情变得更轻松，

的开发者 Android 应用程序，

以获得更丰富的体验 对于您的用户来说，

希望可以减少工作量。

转换，它是 这是一个简单的想法。

这基本上是您的一种方式 描述应用程序中的不同场景

预先作为布局资源

文件，或动态地作为事物 在应用程序中更改

，然后使用转换 无论

这些更改是什么，都以动画方式显示更改。

然后你就可以出去了 顺便说一下，只需

让转换 自动运行

，无需 更多地参与

并运行这些手册

更属于典型模型的动画 在 UI 中对事物进行动画处理。

希望在 一天结束时，

你会变得更富有 通过让更多的事情继续进行，应用程序体验

以直观的方式显示在屏幕上。

您的用户将获得 更丰富的经历。

他们得到了 更好地了解

您的应用程序如何 实际上有效

，因为你可以

在这些不同的之间自然过渡 您的应用程序的场景。

还有更多 我一直很喜欢的世界上的动画

。

好的。

那么我们来看看 看一些幻灯片。

我们将快速浏览一下 API 工作原理的概述，

不同部分的含义。

有很多细节 我在这里跳过，

，但你是自由的， 鼓励您查看

中的详细信息 参考文档

和相关文章 developer.android.com、

以及 API 演示 我们稍后会看到。

我们来看看 其中的一些代码。

好的。

首先，我们开始 带着场景的想法。

你可以想到 这是一个布局。

这基本上是一个 查看层次结构

描述了这是什么 特定的场景看起来像。

这可能是场景 特定屏幕中的整个应用程序

，或者 可能是一些子层次结构。

在这个特定的情况下 案例中，场景

描述了这一点 我们

有一个文本视图的情况， 编辑文本和一个按钮。

相当简单。

然后我们就有了 我们

可能描述过的另一个场景 一些其他布局文件。

我们有不同的文本视图 那里有一些更丰富的

文本，还有更长的详细信息。

但我们再次进行了修改 文本字段和一个按钮。

也许这些是 共享组件。

也许他们搬了位置， 可能改变尺寸。

但它们实际上是共享的 两个场景之间。

如果你这样不是很好吗 可以帮助用户理解，

，当他们从场景一移动到 应用程序中的场景二，

发生的更改 淡出那些已经消失的东西，

淡出那些已经消失的东西 应运而生，并移动

并调整共享大小 这些场景之间的元素？

就是这样 过渡是关于。

您指定这些 不同的场景。

然后当你去 一个场景，过渡

自动开始并且 运行必要的动画

以实现这一点 更改，以及

以动画形式随时间的变化。

那么让我们看一下场景。

这些是 您为应用程序定义的

模块， 不同的屏幕，如果您

愿意的话，当然您的 应用程序将随着时间的推移通过

。

你可以构建这些 以不同的方式呈现场景。

首先，场景总是 有一个与之关联的根或 ViewGroup

这基本上是

下的层次结构 场景所在的

以及过渡 将发生。

这样你就可以构建一个场景 直接用那个根。

然后你就可以 设置 EnterAction。

每当那时 进入场景后，

你会收到回调 进入您的 Runnable

，您可以运行 无论代码是什么，你

想要做什么 您想要的操作

查看层次结构。

相当简单。

多一点手动操作 与其他方式

相比，您可以创建场景。

例如，您可以创建 相反，它来自 ViewGroup。

假设您已经夸大了 来自某些布局 ID 的层次结构。

您拥有此 ViewGroup 坐在那里。

您可以创建场景 与该 ViewGroup。

所以你基本上给出了 两个 ViewGroup。

您可以使用 场景层次结构的根，

以及根 场景本身。

所以您将其传入。

您已经创建了一个场景。

一切顺利。

所以现在当 进入场景后，

它只会改变场景 改为查看 ViewGroup

。

你不需要 告诉它要做什么

来操纵层次结构。

它获取该信息 来自您传递的 ViewGroup

在构造函数中。

最后，我们有一些东西 与上一篇非常相似。

但不是递 它是一个 ViewGroup，

你给它一个 布局资源 ID。

当进入那个场景时， 它会使资源膨胀。

它会继续进行 将其添加到场景根目录中。

简单明了。

布局资源 如果您创建场景，也会启动

隐式地存在于资源

中，我们将看到 稍后。

您可以进行过渡 自动

隐式膨胀场景的管理器， 给定布局资源 ID。

并且它使用相同的 引擎盖下的机制。

接下来，我们可以采取 看看过渡。

这些是引擎 负责声明

你想要什么 当场景从一个场景到另一个场景发生变化时执行

在您的应用程序中。

所以这些基本上都是听的 对于之前和之后的更改，

并比较这些值。

然后根据变化 场景层次结构中任何视图

发生的情况， 他们将创建一个动画师

，然后运行 使这些变化变得生动起来。

有一些不同的 创建过渡的方法。

您只需创建 直接这些东西。

我们在其中定义了一些 框架已经有了。

有一个 ChangeBounds 这将移动

个发生变化的对象并调整其大小 场景之间。

有一种褪色会褪色 事物进出根据

来或来 在场景变化之间切换。

然后就是 还有一个 TransitionSet

，它是一种过渡 相当于 AnimatorSet。

它基本上是一个团体。

这是一种编排方式 几种不同的过渡。

您可以创建一个 TransitionSet 然后

告诉它是否对于所有 其过渡子级，

将它们一起运行 或按顺序。

也可以是 集合的层次结构。

这样你就可以拥有很多 运行多个转换的更复杂的机制

并行或一个

一个接一个地获得 更有趣的动画

体验。

最后，你 可以从资源文件加载转换

，如果 这就是你要走的路。

如果你想运行 从资源中获取，

这就是你可以做到的。

例如，这个， 是一个被加载的 TransitionSet

，它有两个 孩子们会自动添加

来监听 可见性、

以及大小和位置的变化。

资源文件， 也许这不是

你想做的事情 代码，因为您已经在 UV 代码中

。

创建起来很容易 这些事情是即时发生的。

另一方面， 这是 Transition 使用的机制

管理器在膨胀

信息图表时 我们很快就会看到，

，但这张幻灯片上还没有。

最后，有一个想法 自定义过渡。

因此，正如我所说，我们定义了 几个规范转换

其中自动转换 将即时使用。

有 ChangeBounds 移动视图并调整其大小。

还有褪色 处理可见性

信息，淡入淡出 事物进出。

相当简单。

可能的行为 大多数情况下你想要的。

但是如果您想定义您的 自己的转换 - 例如，

if 当某事 出现了，

你不希望它淡入 在它所在的屏幕中间

，但是 你实际上希望

将其滑入 右边，那么

你可以写一个 自定义过渡。

您只需子类化 过渡阶级本身。

然后你覆盖 三个方法

执行此操作 是你想做的事。

有两种捕获方法。

捕获值 当应用程序

代码说“好的，我准备好了”时开始 进行过渡。

这就是重点 您将

接到您的电话 captureStartValues 方法。

你会继续 只需从视图对象

读取您想要的任何内容 影响了你的转变。

这样你就可以阅读布局 位置，例如

或可见性信息 你关心的。

然后你接到电话 交易时的 captureEndValues

实际上想要运行，

当它想要启动时。

然后你终于 之后

接到 createAnimator 的电话 然后可以

比较这些值的函数 并说，好吧，

这个可见性值发生了变化。

就是这样 我关心的。

因此，我要 创建一个动画

执行以下操作-- 从右侧滑入

或其他任何位置。

返回该动画师。

然后是过渡 系统运行它。

所以有很多 我们刚刚的东西

随框架一起提供 免费，您可以简单地

隐式使用 你运行一个转换。

但如果你想创建 自定义转换，相当简单

。

...

好的。

现在您已经有了场景。

您已经完成了转换。

你实际上怎么样 改变场景？

你如何从 从一个场景到另一个场景？

您可以直接进入一个场景。

没有过渡 涉及那里。

你基本上是 只是说，这是我希望您加载的

场景。

它会做到这一点。

它将运行以下代码 在你的 Runnable 中。

它会膨胀布局 你给它的资源文件，

等等。

它将进入场景。

那里没什么事情发生。

当然不是 有趣的动画。

或者你可以告诉 Transition 经理去现场。

在此过程中 这样做时，

它将使用默认值 一路过渡。

它会说，好的，我走了 就变成了这个场景。

与此同时，我 转到 captureStartValues、

captureEndValues，然后运行 系统的默认转换

。

或者您可以使用以下命令运行它 自定义过渡。

你可以说，好吧，我已经定义了 我想要这个可爱的过渡

当我要在这个特定场景之间

时使用 组合，现在继续

并使用进行转换 TransitionTo

或 go 方法之一 过渡经理。

它实际上会 加载新场景

，然后运行您的自定义 一路过渡。

在我们开始之前 过渡，简化，

还有一件事 我在这里没有提到

，这是的想法 过渡经理。

您通常仅将其用于 您说的一次性的事情，

过渡经理，我 想要进入这个场景

并使用我的自定义 在这里过渡。

另一件事 它可以做的是

保留整个图表 的信息

关于所有 您想要的所有过渡组合

您所在的场景组合

您的申请。

我们会看到一些 稍后在演示中。

但我确实想指出 最后一件事是关于这最后令人兴奋的事情

幻灯片是带有所有这些信息的

， 考虑一下所有这些不同的类

， 你有场景

并且有过渡， 但实际上，

的想法是让动画更简单 对于大多数开发案例。

所以一般来说，唯一的 您可能

会关心的方法 关于这个

叫做 TransitionManager.beginDelayedTransition。

然后给它 您

要运行过渡的场景根。

这就是踢球 在

将捕获的所有过程中 当前值。

然后它就会生成 布局和渲染运行。

然后在 该帧的中间，

它将捕获 最终值，

找出事物的位置 是，然后为您运行

自动转换。

在大多数情况下，这就是全部 你真正关心的。

这基本上是一个动态变化。

您可以将其视为 创建

动态场景并为其设置动画。

所以不要有 这些来自布局资源 ID 的预烘焙场景

， 你基本上可以说，

好的，我希望你运行一个 过渡，所以做好准备。

然后在 与此同时，我将

进行一系列更改。

然后到那时 变化实际上已经开始

，测量 布局已运行，

并且系统已准备就绪 绘制新框架。

然后，过渡开始 找出增量，

找出变化， 并创建动画，

并启动 动画运行。

相当简单。

一行代码。

不错。

好的。

现在，我们来看看 快速看一下演示。

这是 API 之一 KitKat 附带的演示。

所以我鼓励您 从示例中下载它。

你可以运行这个 并随心所欲地玩它

。

完全复杂 和有趣的演示。

所以我们在这里定义了四个场景。

并且场景使用自定义视图。

所以没有什么特别的原因。

这些可以是按钮。

我碰巧做了它们 彩色矩形代替。

所以当我们改变时 在场景之间，

你可以看到我们 调整大小后，我们

重新定位这些东西。

我们可以 即时改变。

我们要取消。

我们打扰了。

我们正在运行其他转换。

非常简单。

现在我们来看看 该演示的代码。

所以有一些 这里有不同的作品。

首先，有 一些布局文件。

所以我们有过渡场景一。

这只有一个布局。

它有四个 里面的视图，

位置适当。

过渡场景两种外观 与此非常相似。

只是尺寸不同 以及彩色矩形的不同位置

。

过渡三 增加了同样具有这些灰度的复杂性

自定义视图位于中间

。

所以没什么真正有趣的 在布局资源

文件中进行。

但您会看到它们被引用 稍后在我们膨胀的资源

中 过渡经理。

我们有一些自定义 我们定义的转换。

这只是一个 ChangeBounds。

这里没有什么真正有趣的。

这只是 我们将要运行的标准 ChangeBounds

。

但我们指的是 稍后

当我们膨胀时该资源 过渡经理。

这里有一点 更有趣的一个。

这是一个 TransitionSet。

它将运行 在默认模式

中，所有转换 并行运行。

它将运行 在运行时同时

更改边界 淡入淡出过渡。

褪色将会是 针对特定的视图。

我们使用 ID 来 与观点相关联。

...

所以这意味着淡入淡出 通常不会将

应用于 屏幕，但我们说，

嘿，我想让你跑 此特定视图上的此特定转换

在层次结构中。

淡出非常相似。

虽然在这个 在这种情况下，将

运行转换 依次。

所以它将运行 对任何

改变位置和大小的事物进行 ChangeBounds。

完成后， 它会逐渐消失。

最后，我们 有一个我们没有的转换管理器

还真见过。

这是对象 保存一个图表，显示您希望发生的

在应用程序中从一个场景转到另一个场景

。

您可以在这里定义 - 我的意思是， 如果您不需要任何自定义

转换，那么您就不需要 关心过渡经理。

您只需运行转换即可。

但如果你关心这一点，当你 从场景一到场景二，

你想要这个特定的自定义 过渡，但从场景二

到场景三 想要一个不同的，

这就是您的定义方式 它，至少在资源文件中。

所以你创建了一个 过渡经理。

然后你有几个 定义的过渡对象

您想要在其中任何一个中

进行互动 特定的场景变化。

所以我们有一个 fromScene 指布局文件。

这就是隐式的 将膨胀

该布局资源文件 并从中创建一个场景。

我们有一个 toScene。

同样的事情。

它将创建一个 该布局文件中的场景。

然后我们就有了

将在其中引用的转换 另一个类似的转换资源

文件 我们刚刚看过。

这就是全部 资源的东西。

现在让我们看一下代码 它位于transitions.java 中。

在 API 演示中， 你会看到这个

在动画目录中。

它的名字叫 简单的过渡。

就在这里。

这里没有太多代码。

我们膨胀 过渡经理。

好吧，我们得到了 过渡充气机。

然后我们膨胀 过渡经理在这里。

我们还创建了三个 沿途的场景。

您会注意到，我们 只创建了三个场景，

但实际上有 演示中有四个。

我们很快就会说明原因。

我们这样做的唯一原因 需要代码

中的场景，这里是这样的 我们指定

他们要转换的位置 到一个特定的场景。

我们已经说过 转换管理器

要运行哪些转换 当我们从一个场景到另一个场景时。

在这里，我们实际上得到了 引用这些场景

并说，好吧， 现在我想将

移至场景一，场景 二、场景三。

我们在这里这样做。

当我们点击 演示中的单选按钮，

我们接到电话 其中一项。

我们说，好吧， 过渡经理，我

希望您过渡 到下一个场景。

一切都会过去。

它将加载场景。

它会找出变化 并运行我们在中指定的转换

我们看到的转换管理器资源

文件。

最后，还有一个 第四个场景

无关 使用我们膨胀的这些场景对象

。

但是，这个 就是我之前提到的

动态场景 因为我们基本上是

改变视图 动态层次结构

并具有 过渡管理器

或过渡 一般来说，系统

基本上是自动的 为那里的所有变化赋予动画效果。

我们称之为魔术方法， 调用开始延迟转换。

我们给它一个场景根 我们要进行手术。

我们称之为助手 方法称为 Set newSize。

基本上，我们 在视图层次结构内进行任意更改

。

这是在这里。

它设置了一些新的布局 视图上的参数。

这将产生一个请求 内部布局。

场景根内的事物 最终将被转发

并重新渲染。

当这种情况发生时， 转换系统

注意到事情 已更改，

并且它运行转换 自动。

正如您在演示中看到的， 物体移动，

物体随之调整大小 单行代码。

这就是转换。

这是 KitKat 中的一项新功能。

我预计它会起作用 随着时间的推移，更多。

这相当简单 现在很简单。

希望能有更多 重要的是，简单的

供您使用 更丰富的Android应用程序。

谢谢。

...

[英语]

Hi.

I'm Chet Haase, an engineer on the Android UI Toolkit team.

Today, I'm going to talk about a new animation

feature in the KitKat release.

It's called transitions.

So the idea with transitions is actually

the idea behind a lot of the stuff

that we do which is trying to make things easier for you,

the developers of Android applications,

to get richer experiences for your users,

hopefully with less effort.

Transitions, it's kind of a simple idea.

It's basically a way for you to describe the different scenes

in your application, either beforehand as layout resource

files, or dynamically, as things change in the application,

and then use transitions to animate the changes no matter

what those changes were.

And you can step out of the way and just

let the transitions run automatically

without having to get more involved

and run these manual animations which

are more of the typical model of animating things in a UI.

Hopefully, at the end of the day,

you get richer applications experiences

by having more stuff move on the screen in an intuitive way.

Your users get richer experiences.

And they get a better understanding

of how your application actually works

because you can transition naturally

between these different scenes of your application.

And there's more animations in the world

which I'm always in favor of.

OK.

So let's take a look at some slides.

And we'll go over a very quick overview of how the API works,

what the different pieces are.

There's a lot of details that I'm skipping here,

but you are free and encouraged to check out

the details in the reference docs

and articles on developer.android.com,

and also API demos which we'll see a little bit later.

We'll take a look at some code in that.

OK.

So first, we start out with the idea of a scene.

You can think of this as a layout.

It's basically a view hierarchy that

describes what this particular scene looks like.

This could be the scene of the entire application

in a particular screen, or it could be some sub-hierarchy.

In this particular case, the scene

describes this situation where we

have a text view, an edit text, and a button.

Fairly simple.

And then we have another scene that we've

described through possibly some other layout file.

We have different text views in there, a little bit richer

text, longer details there.

But we have, again, an edit text field and a button.

And maybe these are shared components.

Maybe they moved location, possibly changed size.

But they're actually shared between the two scenes.

Wouldn't it be nice if you could help the user understand,

as they move from scene one to scene two in your application,

the changes that had occurred by fading things out that go away,

fading things in that have come into being, and moving

and resizing the shared elements between these scenes?

That's what transitions are about.

You specify these different scenes.

And then when you go to a scene, the transition

automatically kicks in and runs the necessary animations

in order to make that change, as well as

to animate the change over time.

So let's take a look at scenes.

These are the modules that you've

defined for your application, the different screens, if you

will, of state that your application will move through

over time.

You can construct these scenes in different ways.

First of all, scenes always have a root or a ViewGroup

associated with them which is basically

the hierarchy under which the scene lives

and in which transitions will take place.

So you can construct a scene directly with that root.

And then you can set an EnterAction.

And whenever that scene is entered,

you will get a callback into your Runnable

and you can run whatever code, you

want to make whatever manipulations

you want to to the view hierarchy.

Fairly straightforward.

A little bit more manual than the other ways

you can create scenes.

For example, you can create it from a ViewGroup instead.

Let's say you have inflated a hierarchy from some layout ID.

You have this ViewGroup sitting there.

You can create a scene with that ViewGroup.

So you give it basically two ViewGroups.

You can create with the root of the scene hierarchy,

as well as the root of the scene itself.

So you pass that in.

You've created a scene.

You're good to go.

So now when the scene is entered,

it will simply change the scene to be looking at that ViewGroup

instead.

You don't need to tell it what to do

to manipulate the hierarchy.

It gets that information from the ViewGroup

that you passed it in the constructor.

Finally, we have something very similar to the last one.

But instead of handing it a ViewGroup,

you hand it a layout resource ID.

And when that scene is entered, it will inflate the resource.

And it will go ahead and add that to the scene root.

Straightforward.

The layout resource also kicks in

if you create scenes implicitly in resources

which we'll see a little bit later.

You can have a Transition Manager that automatically

inflates scenes implicitly, given layout resource IDs.

And it uses the same mechanism under the hood.

Next, we can take a look at transitions.

These are the engine responsible for declaring

what it is you want to do when things change

from scene to scene in your application.

So these basically listen for changes before and after,

and compare those values.

And then based on changes that occurred to any view

in the scene hierarchy, they'll create an animator

that then gets run to animate those changes.

There's a few different ways to create transitions.

You can just create these things directly.

We have some defined in the framework already.

There's a ChangeBounds which will move and resize

objects that change between scenes.

There's a fade that will fade things in and out according

to whether they come or go between scene changes.

And then there's also a TransitionSet

which is kind of the transition equivalent of AnimatorSet.

It's basically a group.

It's a way of choreographing several different transitions.

You can create a TransitionSet and then

tell it whether, for all of its transition children,

to run those together or sequentially.

And it can also be a hierarchy of sets.

So you can have a much more complicated mechanism

that runs several transitions in parallel or one

after another to get a more interesting animation

experience.

And finally, you can load transitions

from resource files, if that's the way you go.

If you want to run it from resources,

this is how you can do it.

This one, for example, is a TransitionSet

that gets loaded that has two children automatically added

to it to listen for changes in visibility,

as well as size and location.

The resource file, maybe it's not

something you want to do from code because you're already

in code in UV.

It's easy enough to create these things on the fly.

On the other hand, this is the mechanism

that is used by Transition Manager when it inflates

a graph of the information which we'll see soon,

but not on this slide yet.

Finally, there's an idea of custom transition.

So we've defined, as I said, a couple of canonical transitions

which automatic transition will use on the fly.

There's ChangeBounds which moves and resizes views.

And there's also fade which deals with visibility

information, fades things in and out.

Fairly straightforward.

Probably the behavior you want in most cases.

But if you want to define your own transition-- for example,

if when something comes into being,

you didn't want it to fade in in the middle of the screen

where it lives, but you actually want

to slide it in from the right, then

you can write a custom transition.

You would simply subclass the transition class itself.

And then you override the three methods

that do what it is you want to do.

There's two capture methods.

One captures the values at the start when the application

code said, OK, I'm ready to do a transition.

That's the point at which you would

get a call to your captureStartValues method.

And you would go ahead and just read from the view objects

anything you wanted to that affected your transition.

So you could read the layout position, for example,

or the visibility information that you care about.

And then you get a call to the captureEndValues

when the transaction actually wants to run,

when it wants to start.

And then you finally get a call right

after that to the createAnimator function which can then

compare those values and say, OK, well,

this visibility value changed.

And that's something that I care about.

Therefore, I'm going to create an animation that

does the following-- slides in from the right

or whatever it is.

Returns that animator.

And then the transition system runs it.

So there's a lot of stuff that we just

ship with the framework for free and you can simply

use implicitly when you run a transition.

But if you want to create custom transitions, fairly

straightforward to do that.

OK.

So now you've got your scenes.

You've got your transitions.

How do you actually change scenes?

How do you go from one scene to another?

You could just enter a scene.

There's no transition involved there.

You're basically just saying, here's

the scene I want you to load.

And it will do that.

It will run the code that was in your Runnable.

It will inflate the layout resource file that you gave it,

whatever.

It'll enter the scene.

Nothing much going on there.

Certainly no interesting animations.

Or you can tell the Transition Manager to go to a scene.

And in the process of doing that,

it will use a default transition along the way.

It'll say, OK, I'm going to change into this scene.

And in the meantime, I'm going to captureStartValues,

captureEndValues, and run the default transition

for the system.

Or you can run it with a custom transition.

You can say, OK, I've defined this lovely transition

that I want to use when I'm going

between this particular scene combination, and now go ahead

and transition using one of the TransitionTo

or the go methods in the Transition Manager.

And it will actually load that new scene

and then run your custom transition along the way.

Before we get to Transitions, Simplified,

there's one other thing that I haven't mentioned here

which is the idea of a Transition Manager.

You'll usually use this just for a one-off thing where you say,

Transition Manager, I want to go to this scene

and use my custom transition here.

The other thing that it can do is

keep a whole graph of information

about all the transition combinations

that you want for all the scene combinations

that you have in your application.

We'll see a little bit of that in the demo later.

But I did want to point out one final thing here

on this last exciting slide is that

with all this information, all these different classes

to think about it, and you've got scenes

and you got transitions, but really, the idea

was to make animations simpler for most development cases.

So in general, the only method that you probably

are going to care about is this one

called TransitionManager.beginDelayedTransition.

And then give it the scene root that you

want to run the transition on.

What that does is kicks in all of the process that

is going to capture the current values.

And then it's going to spawn a layout and rendering run.

And then in the middle of that frame,

it's going to capture the end values,

figure out where things are, and then run

an automatic transition for you.

In most cases, this is all that you actually care about.

It's basically a dynamic change.

You can think of this as creating and animating

a dynamic scene.

So instead of having these pre-baked scenes

from layout resource IDs, you can basically say,

OK, I want you to run a transition, so get ready.

And then in the meantime, I'm going

to make a bunch of changes.

And then by the time those changes have actually

kicked in, measure and layout has run,

and the system is ready to draw the new frame.

Then, the transitions kick in, figure out the deltas,

figure out the changes, and create the animations,

and start the animations running.

Fairly straightforward.

One line of code.

Nice.

OK.

So now, let's take a quick look at a demo.

And this is one of the API demos that ships with KitKat.

So I would encourage you to download this from the samples.

And you can run this and play with it

to your heart's content.

Totally complicated and interesting demo.

So we defined four scenes here.

And the scenes use custom views.

So no particular reason why.

These could be buttons.

I happened to make them colored rectangles instead.

So as we change between the scenes,

you can see we're resizing, we're

repositioning these things.

And we can just change on the fly.

We're canceling.

We're interrupting.

We're running other transitions.

So fairly straightforward.

Now let's take a look at the code for that demo.

So there's a few different pieces here.

First, there's some layout files.

So we have Transition Scene One.

This just has a layout.

And it has four views inside there,

positioned appropriately.

Transition Scene Two looks very similar to that.

It's just different sizes and different positions

for the colored rectangles.

Transition Three adds the complication

of also having those gray scale custom views in the middle

there.

So nothing really interesting going on in the layout resource

files.

But you'll see them referred to later in the resources

that we inflate for the Transition Manager.

We have some custom transition that we've defined.

This is simply a ChangeBounds.

Nothing really interesting here.

It's just the standard ChangeBounds

that we're going to run.

But we refer to this resource later

when we inflate the Transition Manager.

Here's a little bit more interesting one.

This is a TransitionSet.

It's going to run in the default mode

where all the transitions run in parallel.

It's going to run a ChangeBounds at the same time

as it's going to run a fade transition.

And the fade is going to be targeted at a specific view.

And we use IDs to associate with views.

So that means the fade is not generally applied

to everything on the screen, but we're saying,

hey, I want you to run this specific transition

on this specific view in the hierarchy.

Fade-out is very similar.

Although in this case, it's going

to run the transition sequentially.

So it's going to run the ChangeBounds on any things that

change position and size.

And after that's done, it's going to run the fade.

And then finally, we have a Transition Manager

which we haven't really seen yet.

This is the object that keeps a graph of what

you want to happen as you go from scene to scene

in your application.

You can define here-- I mean, if you don't need any custom

transitions, then you wouldn't care about Transition Manager.

You would just run transitions.

But if you care that when you go from scene one to scene two,

you want this particular custom transition, but from scene two

to scene three you want a different one,

this is how you would define it, at least in resource files.

So you create a Transition Manager.

And then you have several transition objects

that define the interaction you want

in any of these particular scene changes.

So we have a fromScene that refers to a layout file.

And that's implicitly going to inflate

that layout resource file and create a scene out of it.

We have a toScene.

Same thing.

It's going to create a scene from that layout file.

And then we have the transition that it's

going to refer to in another transition resource

file like the ones that we just looked at.

So that's all the resource stuff.

Now let's look at the code which is in transitions.java.

And in the API demos, you'll see this

in the Animations directory.

And it's called Simple Transitions.

And here it is.

Not a lot of code going on here.

We inflate the Transition Manager.

Well, we get the Transition Inflator.

And then we inflate the Transition Manager down here.

And we also create three scenes along the way.

And you'll note, we're only creating three scenes,

but there were actually four in the demo.

And we'll show why in a minute.

The only reason that we need the scenes in the code

here is that this is where we specified

they were going to transition to a particular scene.

We've already told the Transition Manager

what transitions to run as we go scene to scene.

And here, we're actually getting a reference to those scenes

and saying, OK, now I want to move

to scene one, scene two, scene three.

And we do that down here.

When we click on the radio button in the demo,

we get a call to one of these items.

And we say, OK, Transition Manager, I

want you to transition to the next scene.

And it'll go.

It'll load the scene.

It'll figure out the changes and run the transition

that we specified in the Transition Manager resource

file that we saw.

Finally, there is a fourth scene in there

that has nothing to do with these scene objects

that we inflated.

But instead, this is what I referred

to before as a dynamic scene because we're basically

changing the view hierarchy on the fly

and having the Transition Manager

or the transition system, in general,

basically automatically animate all the changes there.

We call the magic method, call beginDelayedTransition.

We hand it a scene root that we're going to operate on.

We call this helper method called Set newSize.

And basically, we make arbitrary changes

inside the view hierarchy.

This comes in here.

It sets some new layout parameters on the views.

This will spawn a request layout internally.

Things inside the scene root will end up being relayed out

and rerendered.

And when that happens, Transition System

noticed that things have changed,

and it runs transitions automatically.

As you saw in the demo, things move around,

things resize with this single line of code.

So that's transitions.

It's a new feature in KitKat.

I anticipate it will be worked on more as time goes on.

It's fairly straightforward and simple for now.

And hopefully, more importantly, simple

for you to use to make richer Android applications.

Thanks.

重点词汇

词汇	含义
animation /ˌæniˈmeɪʃən/ B1	noun - 动画 (dònghuà)
feature /ˈfiːtʃər/ A2	noun - 特点 (tèdiǎn)
release /rɪˈliːs/ A2	noun - 发布 (fābù)
transitions /trænˈzɪʃənz/ B1	noun - 过渡 (guòdù)
developers /dɪˈveləpərz/ B1	noun - 开发者 (kāifāzhě)
applications /ˌæplɪˈkeɪʃənz/ B1	noun - 应用程序 (yìngyòng chéngxù)
experiences /ɪkˈspɪəriənsɪz/ B1	noun - 体验 (tǐyàn)
dynamically /daɪˈnæmɪkli/ B2	adverb - 动态地 (dòngtài de)
animate /ˈænɪmeɪt/ B1	verb - 使动画 (shǐ dònghuà)
hierarchy /ˈhaɪərɑːrki/ B2	noun - 层次 (céngcì)
automatically /ˌɔːtəˈmætɪkli/ A2	adverb - 自动地 (zìdòng de)
intuitive /ɪnˈtjuːɪtɪv/ B2	adjective - 直觉的 (zhíjué de)
involved /ɪnˈvɒlvd/ B1	adjective - 涉及 (shèjí)
model /ˈmɒdəl/ B1	noun - 模型 (móxíng)
intuitive /ɪnˈtjuːɪtɪv/ B2	adjective - 直观的 (zhíguān de)
screens /skriːnz/ A2	noun - 屏幕 (píngmù)

重点语法结构

• Today, I'm going to talk about a new animation feature in the KitKat release.

  ➔ 现在进行时

  ➔ 短语 "I'm going to talk" 使用现在进行时来表示一个计划或安排的未来动作。

• It's called transitions.

  ➔ 一般现在时

  ➔ 短语 "It's called" 使用一般现在时来陈述一个事实或永久性的情况。

• So the idea with transitions is actually the idea behind a lot of the stuff that we do which is trying to make things easier for you, the developers of Android applications, to get richer experiences for your users, hopefully with less effort.

  ➔ 关系从句

  ➔ 短语 "which is trying to make things easier" 是一个关系从句，修饰 "the idea behind a lot of the stuff."

• You can think of this as a layout.

  ➔ 情态动词 (can)

  ➔ 动词 "can" 用于表达能力或可能性。

• It will simply change the scene to be looking at that ViewGroup instead.

  ➔ 一般将来时

  ➔ 短语 "It will simply change" 使用一般将来时来描述一个将在未来发生的动作。

• There's a lot of details that I'm skipping here, but you are free and encouraged to check out the details in the reference docs and articles on developer.android.com, and also API demos which we'll see a little bit later.

  ➔ 被动语态

  ➔ 短语 "you are encouraged to check out" 使用被动语态来强调动作而不是行为者。

• You would simply subclass the transition class itself.

  ➔ 第一类条件句

  ➔ 短语 "You would simply subclass" 使用第一类条件句来描述一个假设的情况及其可能的结果。

• And it will actually load that new scene and then run your custom transition along the way.

  ➔ 用 'will' 和 'then' 表示的将来

  ➔ 短语 "And it will actually load... and then run" 使用 'will' 来表示将来的动作，使用 'then' 来表示事件顺序。

• Fairly straightforward. One line of code. Nice.

  ➔ 状语短语

  ➔ 短语 "Fairly straightforward" 是一个状语短语，修饰动词 "is" 来描述动作的方式。