Transcript
[ Applause ]
>> Good afternoon.
Thank you for coming.
I'm Noah. I'm here with my
colleague Warren and we're going
to talk to you about building
visually-rich user experiences.
So, there's three main areas
that we're going to cover today.
The first is a platform
overview.
Kind of a quick tour, kind of
the lay of the land of what the
graphics frameworks are on our
platforms, what they can do, how
you kind of fit them together.
Next, we're going to kind of
dive deep into one of the more
essential parts of the graphics
platform coordination and some
best practices that you can use
to kind of avoid common pitfalls
that people run into a lot with
CA.
And, finally, we're going to
spend a little more time on some
tips and tricks.
Some kind of small, fun, like,
useful things you can do to
really add some cool visual
flair to your apps.
So, if you spend any time
digging through the
documentation or just reading
just like overflow or anything,
you've probably seen a lot of
concepts kind of come up.
And there are a lot of them and
it would be great to have time
to kind of go into every single
one of these and just basically
spend all day here, but we
aren't really allowed to do
that.
So, instead, we're going to keep
it pretty high level.
Let's talk about what we have on
iOS, macOS, and tvOS.
First off, some of you are
probably already familiar with
UIKit and AppKit are the
frameworks with which you build
the UIs on most of your
applications.
They kind of provide you a
standard set of system controls.
They're customizable to a
degree, so you can make our
sliders look way cooler than
usual ones.
And they also come with some
really useful kind of built-in
behaviors.
You get these standard
appearances and transition
animations and that kind of
thing, but you also get support
for accessibility features and
dynamic type right out of the
box.
So, I said that these let you
customize things to some degree,
but as soon as you want to kind
of go beyond just setting a tint
color or an image override on
something, you might have to
start dropping down into
something like Core Animation.
And, as you might already be
aware, Core Animation underlies
UIKit on iOS and is also pretty
heavily integrated into AppKit
on the Mac.
And so, a view on iOS is
composed of a-- like has a layer
and the stuff that appears in
your application is this
hierarchy of layers kind of all
appearing together.
And that's what CA is good for.
It's kind of-- it's a thing to
take existing content, put it
together, display it in this
hierarchy that can move around
and animate and so on so forth
and finally composite it all
together and get it onscreen.
So, beyond that, there are a
couple other frameworks that we
have for some kind of more
specialized purposes.
Core Graphics is one that you
also might have encountered.
It lets you do kind of really
elaborate customizable 2D
drawings.
So, you can take a path and some
colors and turn them into these
kind of nice message bubbles
over here.
And Core Graphics is what you
use when you need to build
images at runtime.
For something-- for building it,
like beforehand, you probably
use something like Photoshop or
Sketch or Illustrator, but Core
Graphics lets you do that on the
device, you know, as your code
is running.
Which is really useful.
So, Core Graphics is useful for
drawing things, but there's
another framework that we have
for working with images that you
already have and that is
appropriately named Core Image.
And what that does is apply
filters to things.
You provide some set of input
images, you hand that to Core
Image, get a-- and get a filter
that does some thing, and it
produces the final rendered
output of the thing-- of the
filter, rather.
So, you have obviously simple
color transformation effects,
like this kind of nice sepia--
that's not sepia-- I don't know
what to call that.
Don't worry about it.
But you can also do kind of
interesting stylization effects,
like this cartoon drawing kind
of thing.
And what's neat about Core Image
is that it's really heavily
optimized and we kind of do a
lot of the work for you.
So, when you're doing something
more complicated like chaining
multiple filters together, we
kind of can optimize that for
you and instead of having to
kind of go through this process
over and over again on your
images for each filter, we can
kind of pipeline that.
And what's even better is that
all of this stuff can run on
basically whatever
parallelization hardware your
device has.
If you don't have much GPU
resources available, it runs on
the CPU and makes use of Grand
Central Dispatch and all that.
Completely under the hood,
transparent to you.
If it has Metal available, then
it can run using that.
So, that's pretty cool.
There are a couple other kinds
of contents you might want to
get into your apps that we have
some really useful frameworks
for.
And for 3D content, we have this
thing called SceneKit which
basically lets you get your 3D
content into your app and has
some really nicely integrated
tools in Xcode that let you kind
of manipulate it, set up scenes,
do all this.
And you'll see a little bit of
what that looks like a bit later
on.
SpriteKit is another framework
that's kind of built heavily for
games.
It gives you a lot of animation
primitives and that kind of
thing for having things, you
know, move around and interact
with each other onscreen.
So, there's one more framework
that I'd like to talk about
before we move on and that is
one you've probably heard of
called Metal.
And what Metal is is kind of the
fundamental graphics API on our
platforms.
It's what all of these other
things are built on top of.
I mentioned that Core Image can
use Metal, but SceneKit draws
using Metal on devices that
support it, SpriteKit does the
same, and Core Animation itself
is using Metal as well.
And so, Metal is-- it's kind of
hard to describe exactly what
you use it for because you can
do basically anything with it if
you are willing to put the work
in.
But what it lets you do is just
kind of get the fastest possible
access to the lowest level of
the graphics hardware we have
available.
And so, a lot of the times
you're not using Metal directly,
you're using it through one of
these other frameworks, but if
you need to build something
custom, something that isn't
really supported by any of
these, that's what you're using
it for.
As an example, on the iPhone 7--
sorry, the 7 Plus-- we have this
kind of neat depth of field
effect in the camera and that
basically takes the camera
image, does some kind of depth
reconstruction stuff on it, some
math that is way beyond me, and
can figure out kind of the depth
of the pixels in each-- at each
point in the scene and then
apply an intelligent kind of
blur filter to them so you get
this nice soft background.
And that doesn't sound like any
of the other frameworks that I
told you about, right?
So, that was built for iOS 10
and rebuilt for iOS 11.
I don't know if you've noticed
that the effects just got better
in the betas on top of Metal.
So, that was kind of a quick
tour.
We just went down through all
these layers and the idea here
is not to kind of give you an
exhaustive explanation of what
each one does, but I just want
to kind of have you know where
things are.
So, if you have some problem
that you want to solve in your
app, you can kind of look back
and be like I think I heard that
there's a firmware that does
that.
Let me check that out.
So, to give you a little bit
more of an idea of how you use
these and how they work, I'd
like to bring up my colleague,
Warren, for a demo.
[ Applause ]
>> Thanks, Noah.
So, with this series of demos,
I'm going to walk you through
some of the frameworks that Noah
just introduced and we'll start
right at the beginning with
UIKit customization.
I want to say right from the
start that it's not important
for you to pay attention to
every single line that I
highlight or talk about.
The sample is already available
online and you can definitely
pull it down and follow along on
your own time.
But, over the course of the next
several minutes, I'll walk
through some of the platform
features that we have and how
you can use them to enhance the
user experience of your
application.
So, to start, I'll just go ahead
show you what this particular
UIKit customization example
does.
I have here a screen, perhaps
it's from a video-editing
application that allows me to
control the white balance of a
photograph.
As you can see, I've already
customized the UI sliders at the
bottom of this screen with track
tint colors to signify the
purpose of each slider.
So, the slider on top will
control the color temperature
while the slider on bottom will
control the color tint.
And the combined effect of these
sliders will allow us to control
the white point of the
photograph.
But, I might actually want to
punch this up a little bit more
by adding a track image.
I'll go ahead and do that now
and show you the effect.
So, as you can see, I've added a
gradient image to each of these
sliders with rounded end caps.
And this actually creates a much
nicer visual appearance and also
hints a little bit further at
what these sliders actually are
for.
Now, if I adjust these sliders
right now, you'll notice that
the image itself doesn't change.
But, in the next sample, I'll
show you how to actually
implement the effect of
modifying the image.
In the meantime, I'll walk
through this particular example
in a little bit more detail.
So, I instantiate a UI image and
then I-- and then make it
resizable by using one of the
APIs on UI image.
And then I can actually set each
of the images on the sliders.
The minimum track image and then
maximum track image.
And, as I move the slider, it
will be redrawn and use the
appropriate image to draw the
portion of the track to which it
applies.
So, I mentioned that I'd show
you how to actually implement
this effect and that's what I'd
like to do now.
So-- and I'll do that with Core
Image.
So, as you can see, this is the
exact same UI, but now when I
adjust the sliders, which I
might do because this image was
shot underwater and I want to
make it a little bit warmer and
remove some of that green tint
from the algae.
You can see that the image
actually updates in real time.
Let's talk about how we actually
do that.
So, Noah mentioned that Core
Image has numerous different
filters available and the filter
that we'll be using
appropriately enough is the CI
temperature and tint filter.
Now, it bears a mention that CI
filters don't actually do the
hard work of image filtering in
Core Image.
Rather, what does most of the
work is an object called a CI
context.
The CI context is basically the
interface to the underlying
hardware that actually performs
the image filtering.
So, I've already created one of
those and I'll be using it in
this function, but first what I
want to do is instantiate a CI
image that's based on the image
that's currently being displayed
by the UI image view in my
screen.
Now, CI temperature and tint
filter has a couple of different
parameters that allow me to
control the white point and in
particular the-- these
parameters are called the
neutral and target neutral
vectors.
And each of these represents a
particular color temperature and
a color tint.
And so, I know that the
temperature and tint that I'm
shooting for are 6500 degrees
Kelvin and a perfectly neutral
0, neither too magenta nor too
green.
So, I construct a vector with
those parameters and then I
construct another vector with
the parameters that come from
the values of my slider.
I then construct a dictionary
that holds all of these
parameters, including the input
image, and ask CI to create a
filter for me based on the name
CI temperature and tint.
Then, in order to actually
perform the filtering, I'm going
to use a little bit of Grand
Central Dispatch to get off the
main thread because image
processing is a fairly intensive
operation.
So, I'll dispatch to a queue
that I created previously and
then ask my context to create a
CG image based on the output
image of the filter that I just
created, which will have the
effect of pulling the filtered
image through the filter,
applying the effect.
Once that's done, I'll then
dispatch asynchronously back to
the main queue and set the
resulting image on my UI image
view once more.
Now, sometimes using UIKit or
Core Image or many of these
other high-level frameworks is
not quite enough and you
actually want to draw user
interface elements on the fly.
Well, like Noah mentioned, you
can actually use Core Graphics
to do that.
This is a very simple
application of Core Graphics,
but let's say I want to draw a
star polygon.
Now, in order to do that, I'll
actually use an API that was
introduced in iOS 10 called UI
Graphics Image Renderer.
This actually gives me much
easier access to a Core Graphics
context that I can issue drawing
commands into than in the past.
So, in order to use it, I'll
basically determine where I want
to draw the star.
In this case, in the center of
my view.
Create a UI graphics image
renderer at a particular size,
and then call the image method,
which takes a closure in which
I'll actually issue the drawing
commands.
So, it passes me in this render
context and from that I can
retrieve a CG context which
actually has a huge bevy of
methods that allow me to do
things like draw paths, draw
text, draw images, and fill and
stroke paths.
Now, the math here is not all
important.
What is most important is the
API.
So, on that context, I'll set
the fill color, which in this
case is yellow because stars are
yellow, and then I'll go ahead
and position the current point
of the context at the top of the
star with the move method.
Move to method.
And then in a loop I'll go ahead
and add lines between the inner
and outer points of my polygon
and once I'm done I can actually
fill that path, which has the
effect of filling in the star
outline and creating the image
that you saw.
But, of course, nobody wants to
actually just have a gigantic
star sitting in the middle of
their application, so let's go
one step further and talk about
how you can actually use this as
a user interface element in your
own app.
We'll do that with Core
Animation.
Core Animation happens to be
really good at presenting bitmap
content.
So, we can actually use the
image that we just generated as
the contents of a CALayer.
Just to show you the effect that
we're after, I have this button
here and UI buttons are, you
know, very common and their
usage-- their usage varies
depending on the context, but if
I want to add a little bit of
pizazz to this particular UI
button, then I can go for an
effect like this.
Let me show you that one more
time.
Kind of cute, right?
Now, this is a little bit
ostentatious and you probably
wouldn't want to do exactly this
in your app, but this is
strictly for illustrative
purposes.
Let's talk about how to achieve
that effect.
So, I'll configure some
parameters for the stars that I
want to display and then I'll
add an action to my button to
actually call this play star
animation method.
In there, I'll create a loop
that actually loops over the
number of stars that I want to
create and for each of them I'll
create a CALayer.
CALayer is the workhorse of Core
Animation and it's the thing
that actually has a position on
the screen and can be animated,
moved around, and have its
contents set.
So, I'll actually set its
contents to a CG image that
represents one of the stars that
I just rendered using the class
that I introduced previously.
I'll set the initial position of
each star in a circle around the
button and also set its balance
to some initial size.
In order to actually get it to
show up on the screen, I need to
add it as a sublayer of the
button's layer.
Now, you'll notice that of
course the star is animated from
their initial positions to a
position that's further out
along a ray from the center of
the button.
So, I can do a little bit more
math to calculate the final
position of the star, then I can
construct a transform that will
simultaneously rotate, scale,
and translate the layer to its
final position.
I'll use CA basic animation to
interpolate between the initial
position of the CALayer and its
destination.
I could use a more sophisticated
animation like a key frame
animation if I wanted to, for
example, make it move along a
path.
I'll set the from value to the
current transformation of the
layer and the to value to the
transformation that I just
constructed.
And I'll also use a custom
duration because the default
duration of 0.25 seconds is a
little bit-- little bit fast for
the effect that I'm after.
And I'll apply an ease out
function so that as the star
approaches its target position
it will slow down.
And just to be a good citizen so
I don't have a bunch of layers
laying around, after several
seconds I'll go ahead and remove
that layer from its super view
when the animation completes.
Well, that's all well and good,
but sometimes you actually want
to have even more elements
flying around the screen and for
that you might want to use one
of these high-level graphics
frameworks that are intended for
games, but there's no reason you
can't use them in your own apps.
So, let's take a quick look at
SpriteKit.
Well, here's a similar-- here's
a particle effect that I created
in SpriteKit and this could
easily be overlaid in your own
app's contents.
So, let's take a look at how you
can incorporate SpriteKit very
easily into your own app.
That's literally the entire--
the entire code.
And what makes it easy for us to
do this tersely is that we're
actually relying on this SKS
file that I've created
previously.
And Xcode has a really nice
visual editor for particle
systems.
Now, you're not seeing the
texture here because I created
it programmatically, but you'll
notice that if I open up this
inspector in Xcode, I can
actually control many different
parameters of this particular
particle system, including
things like its opacity over
life, initial velocity, and the
distribution parameters for its
velocity and so on.
So, that allows me to very-- to
verify visually the effect that
I'm after with this particle
system and what's great is that
once I'm done with that I don't
have to write any code to
achieve that effect.
It's actually already persisted
in its SKS file.
Let's take one step back and
talk about how to actually
integrate scene-- SpriteKit into
your application.
So, in order for anything to
show up whatsoever, I need to
create an SKScene.
And the SKScene is really just
the stage on which all of your
objects live.
And an SKScene is presented in
your application within SKView.
So, I've created an SKScene
that's the same size as the view
that it's going to be presented
in and I present the scene on
the view.
I then create an SKEmitterNode
that actually loads the particle
system parameters and then will
actually be the thing that
drives the particle animation as
it's running.
I'll go ahead and create one
more of those famous star images
and set it as the texture on my
emitter so that each particle
has that star shape.
And I'll position it in the
middle of the screen.
I'll then go ahead and add the
emitter as a child of that scene
and that's really all there is
to it.
I don't have to start animating.
It just-- SpriteKit takes over
from there and just runs the
animation.
So, 2D is great, but you know
what's really cool, 3D.
So, let's-- as our final
sample-- talk about the basics
of SceneKit.
Well, here's a similar demo,
except that you can see the
stars are flying all over the
place, bouncing off of each
other, and most importantly
they're in 3D and they're lit
realistically.
So, let's walk through the
basics of SceneKit.
Well, there's a similar idea in
SceneKit to the SKScene and it's
called the S-- in SceneKit to--
there's an analogous class in
SceneKit to the SKScene in
SpriteKit which is SC-- which is
SCNScene and, exactly as before,
this is the thing that contains
all of your-- all of your
various objects in your scene.
I'll go ahead and set it to a
nice starfield text-- its
background to a nice starfield
texture, but in order to
actually see anything, we'll go
ahead and also create a node
that represents our vantage
point in SCNCamera.
I can set numerous properties on
this camera, but all I really
care about right now is its
position.
I'll go ahead and position it a
few units back from the origin
so that it's pointing to the
star particle system.
Then I go ahead and add it as a
child node to the scene's root
node.
Now, I don't actually have any
content to display on the screen
yet, so I can go ahead and use
this framework called Model I/O
and Model I/O has a lot of
different facilities for working
with 3D data.
In this case, I'm just going to
go ahead and load a 3D model
that I created previously in the
form of an MDLAsset.
There's a lot of interoperation
between SceneKit and Model I/O,
so I can extract an SCNGeometry,
which is SceneKit's notion of a
3D mesh, from the MDL mesh that
I just loaded.
Now, that particular model
didn't have any material
information associated with it,
so I can programmatically create
an SCNMaterial object and set
the diffuse color to yellow as
before in the previous demos.
Finally, in order to actually
light my objects, I'll create an
SCNLight and associate it with a
node and provide some properties
there, including the position
and the type of light.
SceneKit has a lot of different
types of lights, including
directional, point, and spot,
and you can select the one
that's appropriate for your use.
And I'll go ahead and kickoff
the actual animation by calling
this method start star emitter.
Well, this just creates a timer.
A timer that runs numerous times
per second and actually creates
an SCNNode that has an instance
of this geometry that I just
loaded.
I'll go ahead and add each of
these, as I introduced them to
the scene, to the root node, and
also associate with each one a
physics body so that it gets
physically plausible physical
animation pretty much for free.
I'll also go ahead and create a
random upward velocity just so
that there's a little bit of
variety.
And, finally, I'll remove it--
each star from its parent node
after some number of seconds
just to clean up memory.
So, the purpose of these demos
has been to walk you through the
basic capabilities of the
graphical frameworks that are on
our system and now I'd like to
bring back Noah to talk in-depth
about Core Animation.
[ Applause ]
>> Thanks, Warren.
So, how many of you have used
Core Animation for something?
Good. Glad to hear it.
How many of you have run into
something weird or unexpected
while using it?
Yeah. So, there's a couple of
kind of key concepts to CA,
which are sometimes not entirely
intuitive at first and it's
really easy to get tripped up on
them.
So, I want to take you through
some of those and explain kind
of both what's going on and why
it's happening.
I could just kind of give you
the answer.
In a lot of these cases, the
answer is going to be something
really simple, but I think it's
important to kind of know why
something is happening before
you start dealing with it.
So, let's start out by talking
about animations, which are
pretty core to the-- wow, I did
not intend to say that.
Moving on.
So, there's a behavior that
you'll see pretty often when
you're first starting to play
around with CA animations.
You'll create an animation,
you'll add it to your layer, and
you'll see the layer animate say
from point A to point B and then
it'll jump back and you go
that's weird.
And the reason for this has to
do with what's called the model
and the presentation layers.
There's these kind of two things
that exist at once and knowing
the distinction between them is
kind of crucial to getting why
that's happening.
So, the layout that you're
mostly interacting with, the one
that you're setting properties
on and adding animations to and
so on, is the model layer.
The one that's actually onscreen
is the presentation layer.
And the presentation layer is
sort of a clone of the model
layer that's calculated each
frame from the state of the
model layer and any animations
that are on the model layer at
that time.
So, what's happening in this
previous example is that you
have the animation added at this
time and you can see that, like,
the presentation layer follows
the animation, but once it's
over the animation's gone and so
it goes back to what the model
layer was showing.
And-- so, when you look on the
internet, there will be a
million people telling you to do
exactly the wrong thing here.
What they will say is set the
animation to not be removed on
completion.
Set its film mode to forwards
and forget about it.
And the problem with this comes
from the inconsistency this
introduces because after your
animation is over, the model
layer still has its starting
value.
So, this looks right, but if you
look at the value of the
property on these two graphs,
the presentation layer is
showing something different than
the model layer.
And where that becomes a problem
is when for instance you're
trying to align something to a
layer that you've previously
animated and you set it to the
layer's position and it's the
position that it had like two
minutes ago, which is weird.
Pretty unintuitive, right?
So, the solution to this is
fortunately dead simple.
You can mostly forget about the
entire conceptual stuff that I
just explained there.
All you have to do is when
you're adding your animations to
a layer, set the layer's model
property at the same time.
So, in that case, at the
beginning of the animation, the
model layer jumps to its final
state and the presentation layer
animates smoothly and afterwards
they're consistent.
And, better yet, there isn't
still an animation sitting
around on your model layer,
confusing the state of affairs
and kind of setting you up to be
tripped up later.
So, what that looks like in code
is just this.
You have your animation.
You set your duration, your from
value, your to value, and then
at the same time as you add it
to the layer, you set the value
of the actual property on it.
It's that simple.
Be aware of the model
presentation layer dichotomy and
apply the final state to your
layers when you're adding
animations to them.
So, next, I'd like to talk about
something that I have run into
more times than I would like to
admit, which is the intersection
between transforms and frames.
So, you're pretty familiar with
the idea of the frame.
You set this rectangle that
defines where your layer is and
how big it is.
And so, you have your layer set
up and you decide you want to
scale it down at a transform
that scales it to 25 percent.
Then later on, somewhere else in
your code, you set the frame
back and your layer goes back to
the size that it's supposed to
be.
And all seems well and good,
right?
Well, the problem arises when
you set another transform on the
layer.
In other words, you remove the
transform that's already there
and set something new.
So, say you want to rotate this
layer, you know, keeping it
otherwise the same size and what
not.
So, you set up a
CGAffineTransform and give it a
rotation angle and your lay does
that.
Which is not right.
So, why is this happening?
Well, the thing to know is that
the frame is the layer's size
from outside, the bounds are the
layer's size from inside, and
the-- if you ask the layer where
it's frame is, it's calculated
form the bounds and the
transform.
So, in other words, when your
layer had come back to its
original size, it was actually
four times the size because it
still had that scale transform
on it.
So, you told it onscreen I want
you to be this size and it was
scaled down by four times and so
it's well, like, OK, I need to
be four times bigger than that.
And that seemed fine because you
did-- it looked the same size
onscreen, but then when you
unset that transform, it went
back to its original magnificent
size there.
So, the long and short of this
is-- if you're using transforms,
be really careful about using
the frame property.
It's generally better not to
just set the frame.
Instead, figure out the size and
position that you want the layer
to be at, in other words, in
this case the width and height
of the frame that you wanted and
then the position would be the
center of the frame.
So, it's pretty much just that.
The frame is affected by the
transform, it will interact with
it in weird ways.
If you combine them, you're
probably going to have a bad
time, so just set bounds and
position.
You will save yourself a lot of
headache.
So, for the next couple of
these, I'd like to look at them
in the context of an app.
We have this shiny little app
here that lets you take emoji
and put them all over your
pictures.
It's very original.
I thought of it over a long
period of time.
And there's two things here that
are kind of contributing to the
look of this.
The first is the mask that's
sort of cutting out the edges of
this layer.
And the second is the shadow
underneath it.
First, let's talk about the
mask.
So, what's going on here is that
we have this kind of custom
rounded shape that's clipping
the edges of the emoji.
And the way this works is you
give CA another layer that has
whatever shape you want to be--
to take-- to affect the opacity
of your main layer and-- there
we go.
And CA will take the opacity of
that and use it to cut out the
shape of the layer.
And you can do some kind of cool
interesting things with this.
In a lot of cases, people will
just use a simple shape and you
can kind of fade them out, you
can cut holes in them-- it lets
you do all kinds of interesting
things with your layers.
And so, if you want to achieve
an affect like this where the
emoji are kind of fading out at
the bottom as well as being
clipped by the thing, you might
think, well, OK, I can use a
mask to fade-- to, like, set the
opacity of things.
I can just use two masks here,
right?
Well, you can, but that's not
going to go very well and the
reason is performance.
Each mask has a cost.
So, when you have multiple masks
in a layer, CA has to combine
each one in sequence to produce
the final image that ends up on
screen.
So, you have your emoji layer
here, the kind of fade out mask,
those get combined into the
fading out emoji, then you have
your other layer that is
containing the emoji and that is
getting masked by this other
shape thing and so, like, this
works, but it's suboptimal.
You can see like how much time
could be being spent here just
drawing pixels and figuring out
where things are opaque and so
on and so forth.
So, the problem that this
causes-- because CA has to draw
this stuff offscreen.
Basically, in your normal
drawing path, CA can just like
take the contents of one thing,
put it into the final image, its
composite.
And take the contents of another
and put it in, so on and so
forth.
But, in this case, it's having
to take a-- create a separate
context to draw all this stuff
in and then put it onto the
screen.
And the more of these you have
on there, the more that effect
stacks up.
So, if you want to still achieve
this effect, the best thing to
do is to cheat.
Basically, just to fake the-- at
least one of the masks that
you're using.
In this case, you could get away
with just putting a gradient
overlay on top of this layer and
then including that in the
overall masked thing.
Obviously, there are some cases
in which this won't work.
If your background is not a
solid color, then you can't use
a solid color gradient, but you
can do some other things such as
using-- take-- basically drawing
your background into another
image and then fading that out
and then using that as an
overlay.
And that's-- it's faster to do
that once than to have to make
CA do it every frame.
So, long and short of this is
each mask has a cost.
They are fun and useful, but
kind of expensive.
The size of your layers matters
significantly when you're
masking things.
If you have a really large layer
and you have tiny corner masks
on it, CA is still having to
draw that entire thing, which is
not ideal.
So, wherever you can, use
shortcuts.
That's about it.
Next up, let's talk about
shadows.
So, you're probably familiar
with the CA shadow properties,
shadow opacity, offset, radius,
so on and so forth.
And if you use them, you know,
your shadow shows up, everything
seems to be fine, but if you're
in an app that has a lot of
views that have shadows on them,
you might notice that your
performance starts taking a hit.
And the reason for that is that
CA has to draw the shadow for
each of these individually and
it has to draw it including the
entire hierarchy of layers that
each view contains.
So, what I mean by that is when
you have that layer being
shadowed, CA has to first draw
its background, then draw every
single sublayer-- wait for it--
and then figure out the opacity
of that.
And the result of that is just
this.
So, like, that seems like wasted
time, right?
We just spent all this time
drawing these lovely emoji, but
we're only seeing their opacity.
So, basically when the contents
of the sublayers don't matter,
using the regular shadow system
is kind of a waste of time.
What you want to use instead is
the shadow path property.
And we mentioned earlier that
you can use Core Graphics to
draw paths that have, you know,
varying shapes and then do
things with them.
CG paths are also used elsewhere
in the system for doing path
stuff and, in this case, you
just basically make a path that
is the shape of your layer, hand
that to CA, and it can draw that
and blur it and basically
produce your shadow much faster
than it can by drawing the layer
and all of its sublayers.
So, that's the main performance
advantage of these.
The other is that if you have a
lot of layers using the same
shadow path instance, then CA
doesn't have to redraw the
shadow at all.
It can just reuse them
everywhere and that's a huge
performance boost.
So, when you're working with
layer shadows, be aware that the
blending of the layer and all
its sublayers is really
expensive.
You want to avoid it where you
can, so use shadow paths.
Pretty simple, right?
So, we just took you through
kind of a bunch of CA best
practices.
Some good-- some ways to use the
stuff that you're already using
more effectively.
Let's look at some tips and
tricks.
Let's look at some things that
you might not be using already.
So, CA has a CALayer subclass
called CAShapeLayer and what
that does is take a Core
Graphics path, like the ones I
was mentioning earlier, you give
it a stroke color and a fill
color and it draws your thing.
You may have encountered this
before, but one of the cool
things about CA is that a ton of
the properties that you have on
layers are animatable.
You can change-- you can set up
an animation with pretty much
any of these properties and CA
will do the right thing and
interpolate it over time and
give you an animated layer.
And there are some cool things
you can do with that.
Obviously, you could, you know,
put an animation on the stroke
color or fill color, but
that's-- seems pretty obvious,
right?
What else can we do?
Well, CAShapeLayer has a couple
of properties called strokeStart
and strokeEnd, which let you
create an effect where the layer
draws itself along the length of
the path or undraws itself or
draws itself again.
And that's kind of fun.
You can use that for various
effects in your UI where, you
know, a logo might draw itself
into being and then fill in or
something like that.
You can also do something like
of fun with the line dash mode
property and specifically
animating the lineDashPhase.
If you have layer who-- that's
set to draw its stroke with a
dash pattern, then you can just
animate the lineDashPhase from,
you know, some pixel value to
some other pixel value and it
will shift along the edges of
the shape so you can get this
kind of cool marching antsy sort
of effect.
So, that's shape layers.
Let's talk about gradient
layers.
Again, you might have used these
before, but I would guess you
might not have tried animating
one.
And, again, all these properties
are animatable, so you can just
kind of mess with them and see
what you get.
You might for instance have a
layer that's a gradient layer
that's masked with this star
shape.
And if you animate the start
point and end point from
somewhere off to one side of the
thing to somewhere off on the
other, you get this kind of
shiny, like, metal effect.
Kind of neat, right?
We've actually used that
elsewhere in the iOS UI for--
well, sorry, the watch UI.
If you've used Apple Pay, the
little kind of card swoopy in
thing, that was a gradient
layer.
So, yeah. The last thing that I
want to talk about is layer
speed.
And this one's a kind of fun
trick.
It can be a little bit hard to
use, but you can get some really
cool effects out of it.
So, there's no kind of idea of a
global time in CA.
There's only kind of relative
times from one-- from one layer
to its sublayers and its
sublayers below that.
And so, a layer can have a
different time scale where like
if one second passes in its
super layer, two seconds pass in
the sublayer.
And-- so, the result of that is
that an animation that is added
to one of these layers, if it's
on a layer with speed of two, it
happens twice as fast.
If it's on a layer speed of 0.5,
it happens half as fast.
And what this lets you do,
obviously, is run your
animations more or less slowly,
but that seems kind of
superfluous.
You could just set them to be
that duration in the first
place, right?
But the cool thing happens when
you set the layer speed to zero.
And what happens there is that
the animations don't move.
The animations pause.
And that, again, might not seem
very useful for a thing called
Core Animation, but the thing is
that it gives you control over
the animation's progress through
time with a property called
timeOffset.
So, what that lets you do is let
the user or any other process in
your app scrub through an
animation interactively.
You can have an arbitrarily
complex animation or series of
subanimations and setting the
timeOffset on one layer will
have all of them progress
through according to the--
according to where one-- the
super layer is in its animation.
So, what that lets you do is an
effect something like this
where, as the user drags up and
down, the layer progressively
reveals itself and these things
kind of animate in and out with
that progress.
And-- so, that's kind of cool,
but, like, I could just be
making this up, right?
This could just be a key frame
animation.
So, let's go on and look at this
as a demo.
OK. So, here we have the simple
test app set up.
It's got a basic view subclass
that sets up all these emoji,
lays them out.
Nothing too fancy here.
The key thing about it is that
it vends a list of its-- of the
emoji layers in it so that we
can grab them and animate them
later on.
So, if you look at our view
controller code, there's, again,
not too much going on here.
So, let's change that.
We're first going to just build
the set of animations that make
the panel layer kind of show up
and-- one second-- so, we have a
pair of basic animations here.
One affecting the bound's width,
one affecting the height.
You'll notice that I set the
duration of the first animation
to one because that's kind of
the longest animation that-- in
this sequence and it makes it
really easy to do the math for
like how far in the animation
you are, zero seconds to one
second, zero to one, zero
percent to 100 percent.
So, add these two things to the
layer and when we run this we
see the animation.
And we see it once.
Nothing much happens, right?
And we also notice that the
emoji aren't animating in, which
is no fun at all.
So, change this up a little bit
more.
So, this is pretty
straightforward.
Basically what we're doing is
just setting up a series of
animations, one on each layer,
and giving each one a slightly
later begin time.
And you'll notice that I can't
just set a begin time of, you
know, some number in the future.
I have to actually figure out
the starting time.
The time that the parent layer
thinks that it is to add to
that.
If I just set it to, you know,
zero plus this number, then the
animation started it somewhere
in the past and so everything
will already appear to be done.
So, if we run this again, we now
see that the view animates in,
all the emoji are moving, but
again this is still not
interactive.
Let's fix that.
So, going to set up a variable
here to keep track of how much
the container panel thing is
expanded and then we're going to
set up a simple gesture
recognizer on the view to
control it.
So, what's happening here is
when this pen gesture recognizer
moves in the view, we get the
distance that it's moved since
the last time something
happened.
We scale that from, you know,
some pixel point on the screen
to just a zero to one value and
then we set that value on the
current container expansion.
And, finally, so that we don't
have to keep track of where the
recognizer started, we just set
its translation back to zero.
So, the next time it calls in,
it'll say this is how I-- this
is how far I've moved since you
last set me to zero.
So, that's pretty close to it.
You pretty much from here just
set the container-- the kind of
key final piece-- setting the
container layer speed to zero.
And-- wait for it-- and there
you have it.
I start dragging, it appears.
I drag up; it disappears.
Down, up, down.
Pretty simple, right?
[ Applause ]
So, those were some quick tips
and tricks that you can use with
CA.
Some things you can use in your
applications to make them kind
of more engaging, more visually
rich as one might say.
So, to kind of sum all this up,
first off, broaden your tool
set.
Look through the APIs and kind
of get an idea of where things
are, what you might be able to
use to solve different types of
problems.
If you need 3D, you now know,
oh, I can use SceneKit for that.
You need to filter a bunch of
images, Core Image.
Know the best practices.
It's not essential, but it will
save you so much time and so
much headache and like when
somebody else on your team comes
and says what is this ridiculous
animation thing doing, you'll be
like I know that.
So, pretty useful.
And, finally, experiment with
the API.
I mentioned that like every CA
layer property more or less is
animatable and we only covered
like five of them.
There is so much in there.
There are so many cool effects
you can make if you just kind of
combine things and play with
them and just see what happens
when you put things together.
We have some great sample code
for all of these things that
goes into a lot more detail than
we've been able to here.
So, first off, grab the sample
code from this session.
Take a look at it.
Unfortunately, the-- that demo
is not up there yet, but we will
get it up as soon as possible.
There's a bunch of sessions that
you have unfortunately already
missed, but I highly recommend
going back to look at the videos
for them.
There's some really cool stuff
this year, particularly in UIKit
and SceneKit.
And there is a SpriteKit one
tomorrow if you feel like being
up that early.
I'm not sure I will be.
And that's about it.
I hope to see you all at the
bash.
Thank you.
[ Applause ]