Placeholder Image

字幕表 動画を再生する

  • (inspiring jingle music)

  • (scattered applause)

  • - Hello, everyone.

  • Okay, cool, the mic's working.

  • So, yes, welcome to this talk

  • about efficient Android layouts.

  • If you've never met me before,

  • I've been doing Android drawup for about seven years,

  • first the Travel App company, the Expedia,

  • then currently at Trello.

  • As per usual, my thing doesn't work.

  • All right, I'm gonna give my presentation over here.

  • You know, you can click to engage, to rate sessions,

  • and ask questions, of which I will probably then answer

  • the questions at the end if you ask them.

  • Anyways, so this talks about efficient Android layouts,

  • and when I was writing it, what I found that

  • I was really interested in wasn't so much so

  • the efficiency in terms of performance,

  • but the efficiency in terms of leverage that you have

  • as a developer, and so I started thinking about it

  • in the way that Archimedes was referring to, like,

  • how fulcrums work, where, like, if you just give him

  • a proper place to stand, he can move the Earth,

  • and so that's sort of the focus of this talk,

  • is like, how to get the most leverage

  • as a developer, because a lot of Android teams

  • are fairly small, and you're asked to do a lot of things.

  • And so in my case, it would be if you give me a

  • a standing desk, I will write you an Android app,

  • and I hope that you're not expecting me to make

  • any more terrible jokes this entire time,

  • 'cause it won't happen.

  • So, this is really just kind of a mish-mash of things,

  • there's no narrative, so I'm just trying to cover up

  • the fact that I have no transition here.

  • Let's talk about ViewGroups.

  • In particular, picking ViewGroups,

  • which ViewGroup are you gonna use for

  • any particular layout, and I think the main thing

  • is the simpler the ViewGroup you can get away with,

  • generally, the better, because the more complex ones

  • require a lot more maintenance, and you can run

  • into a lot more bugs, and so on the higher end of things,

  • I'd say probably RelativeLayout's one of the most complex.

  • ConstraintLayout is yet to be seen, but it looks like

  • it's probably going to be more complex

  • than RelativeLayout when it's finally done.

  • Somewhere in the middle of there is LinearLayout,

  • and then down there at the bottom is FrameLayout,

  • which is one my favorites, because it's so simple.

  • And there's a lot of other views in between,

  • but these are the main building blocks

  • for most applications.

  • So RelativeLayout and ConstraintLayout,

  • they sort of occupy the same space in Android right now,

  • which is that they position views relative to each other,

  • and RelativeLayout's sort of limited in this regard,

  • but it's what we've had since the beginning,

  • whereas ConstraintLayout is new and can do,

  • like, all these amazing things,

  • but there's some key problems with both of them

  • besides the fact that they're fairly complex.

  • One of them is that RelativeLayout is fairly slow,

  • and then the issue with ConstraintLayout

  • is that it's fairly alpha-ish at the moment.

  • They haven't officially released it yet,

  • So there's alpha out on Maven central, but a few times

  • they've completely changed the API around, so it's not

  • necessarily production ready.

  • I mean, you could play around with it now, and you could

  • use it if you want, but you're gonna end up with

  • some of that cutting-edge problems that you end up when

  • you're trying to experimental technology.

  • LinearLayout is great, stacking views vertically and

  • horizontally, you can distribute the weight, so this is a

  • simple view, so rows are stacked vertically, and then also

  • I distributed the weight between those

  • two spinners equally.

  • I'm actually fairly okay with nested linear layouts

  • as an opposition to RelativeLayout, and I actually,

  • last time I told someone this, this was like by far

  • the biggest question that I got, is everyone coming

  • to me later saying, "But I love my RelativeLayouts,

  • that's all I use,

  • I was then that nested LinearLayouts are the worst

  • things in existence and so I can't believe that

  • you just said that."

  • SO to head off that question that I was going

  • to be getting on the sessions thing, is that LinearLayouts

  • are sometimes slow.

  • So if you use layout wait, and you nest them pretty

  • deep, then they an get pretty slow, but that's only

  • a sometimes thing, whereas by opposition, RelativeLayout

  • always has to do two passes, it's always slow.

  • So the hope is that eventually ConstraintLayout

  • will be our savior and save us from the situation

  • of having to decide between the two of them.

  • But in the meantime, I think really what's most

  • important is just to focus on profiling.

  • So whatever layout that you do end up with just turn

  • on profile GPU rendering, and see if things are

  • running fast enough on whatever test device

  • that you're using, hopefully like

  • a really slow one.

  • And if you've never used profile GPU rendering,

  • I highly recommend Googling that and looking into

  • that, 'cause then you get these nice bars that

  • show you whether or not you're hitting

  • 60 frames a second, and what sort of things you're

  • spending too much time on if you don't.

  • But really I talked about all that, so I can talk

  • about FrameLayout, which is my favorite layout in

  • the world, because it's so incredibly simple.

  • All it can do is position things based

  • on the parent bounds.

  • So that is, you can position things inside the center

  • of the FrameLayout, or you can position things on one

  • of the eight cardinal directions of the FrameLayout.

  • Wait, am I getting that right?

  • Yeah, eight.

  • So, but there's a lot you can do with this.

  • It turns out that a lot of layouts, if you just wanna

  • have like say, a simple progress bar in the center

  • of some large screen, like that's a FrameLayout,

  • you don't have to do anything complicated with

  • RelativeLayout or what have you.

  • It's also really great as a simple layout for overlapping

  • views, so if you need two views to be on top of each

  • other, FrameLayout is a great container for that.

  • It's also good for things like clickable item backgrounds,

  • so if you have some image that takes up a very small amount

  • of space, but if you wanna have multiple views that

  • compose a single thing that you click, it's good to have

  • like a FrameLayout as the parent of that, that can

  • actually have the click detection so when you click

  • on it, it actually looks like something is happening.

  • So a good example of this, like in the Trello application,

  • is the notification bar in the upper right corner.

  • So this always present on the screen, it's a single

  • FrameLayout, and there's a icon inside of it that,

  • that white icon is always present, and then if you have

  • unread messages, it'll put that little red thing

  • on top of it.

  • And so, the white icon centered and the red icon is

  • actually pegged to the upper right corner, but then

  • you can use the margin or to push it in so it doesn't

  • just ram up against the sides.

  • And on top of all of that, I can just have these views

  • be very simply positioned, and then pair with clickable

  • item background behind that, so when you actually

  • click on it something happens.

  • Another thing I really like using FrameLayouts for is

  • what I'm calling "toggle containers", so if you have

  • two different states that you toggle between, sometimes

  • you just have a single view that you actually change,

  • sometimes I've found it more handy to have multiple

  • views that you can switch between.

  • And so a FrameLayout's a good way to contain two things

  • in exactly the same spot, and then toggle between them.

  • So a good example of that in the Trello app is

  • the avatar view.

  • So this is whenever you represent a member of a card

  • or something like that, if the user has their avatar

  • Seth and we wanna show that, if they've never taken

  • a picture, then we wanna show their initials.

  • And so it's essentially choosing between an image

  • view or a text view.

  • Littler fancier versions of which that allow you to

  • render a circle, but basically lets you toggle

  • between these two.

  • So the avatar view brings up the next thing I wanna

  • talk about, which is view reuse.

  • We use this avatar view all over the application,

  • so these are just three screens, like the Trello

  • board, a open Trello card, some activity on the side,

  • and there's actually I think, three or four other

  • locations we use an avatar view within the application.

  • And so the question becomes, how do I reuse this

  • in multiple places without having to rewrite

  • the code everywhere, 'cause that would be kind of dumb.

  • So the most obvious way is to use

  • something called an include.

  • So if you've never seen it before, the include tag

  • allows you to point to a direct layout, and then it's

  • as if that layout was just copy and pasted into the

  • code right there.

  • And you can't modify much of what you're including,

  • but you can modify any of the layout params, that's

  • any of the things that starts with layout_, so that's

  • a nice way to be able to include something that may

  • have been may have been match-paired, but you don't

  • quite want it to be in the end.

  • But the problem here is that okay, you get the XML

  • in every single location, but you don't get

  • any of the logic.

  • So now I have to come up with some way to then apply

  • like, find these particular views that were in the

  • include, and then add the logic for actually

  • binding that to the view.

  • So what I actually prefer these days is

  • using custom view.

  • So with a custom view, I call, instead of include,

  • I actually just have the view in reference directly,

  • and then you need to write the actual custom view

  • itself, but it's not very hard, because this isn't

  • a custom view that's doing custom drawing or

  • anything like that, it's just taking the place

  • of what would have been in that include.

  • And so with this custom avatar view, I'm extending

  • Framelayout, so I'm saying the topmost is gonna be

  • a Framelayout, remember I'm toggling between

  • the two states.

  • I've got an image view and a text view, and then

  • inside of a constructor itself, it actually inflates

  • all the views that are underneath it.

  • So I don't need to, as a parent using avatar view,

  • I don't have to worry about what's inside of it.

  • It's handling all of that for me.

  • And then I can have this one nice bind method where

  • I take my member object and figure out whether I

  • should be loading an icon or loading the text.

  • So this makes my life a lot easier.

  • One thing worth noting though, if you're using

  • this sort of custom view setup, this is like

  • a very hand-wavy version of what would

  • be the included XML.

  • But if you include the XML like this, you end up

  • with a view hierarchy that looks like this.

  • You wend up with an avatarview on the top, it's a

  • FrameLayout, and then it inflates another FrameLayout, which

  • then has the text view and image view.

  • So obviously, this middle FrameLayout is pointless,

  • we don't really need it, the lint check in Android

  • is particularly harsh when you do this, something like

  • "has no reason to live" or something like that,

  • "has no reason to exist".

  • So we wanna get rid of that, and the way that we do

  • that is through a layout inflator trick.

  • Which is normally when you're using layout inflator,

  • everywhere you'll see it, there'll be a third parameter

  • there, and it'll be false.

  • And that's because most of the time that's what you want.

  • But in this one particular case, you want it to

  • be true, which happens to be the default.

  • And when it's true, what happens is that the XML

  • that's inflated tries to attach itself to the

  • view group that you passed in as the second parameter.

  • In this case, it's this.

  • And then in the XML, if you use something called

  • the merge tag instead of a FrameLayout, what happens

  • is, it tries to then merge these views into the

  • parent view group without any

  • interstitial frame layout.

  • And then so you end up with the hierarchy that

  • you actually want no unnecessary FrameLayouts involved.

  • A third view-specific piece of advice I had to do is

  • with custom drawing.

  • So this is useful in cases of, particularly complex

  • views, you can can save a lot of time by just

  • drawing yourself instead of trying to figure out

  • how to wedge these views into what you want

  • it to look like into normal views.

  • So a good example of this in the Trello app is the

  • labels, so there's these green and blue and red

  • and yellow and purple labels that are

  • on these cards.

  • So when we first had the Trello app out, there was like

  • six colors, and that was it, that was the most you

  • could apply to any card.

  • And whoever was working on it back in the day

  • did not know about custom drawing, and decided that

  • those would just be six views.

  • So that meant that every single card potentially

  • have six views inflated.

  • But then later on, Trello changed this, that it allowed

  • any number of labels to be drawn, so then you could

  • end up with this nightmare scenario, where every single

  • card could have dozens of labels on them if someone's

  • going really crazy.

  • And then we were talking about recycling those views,

  • it just gets really slow, and if you talk about

  • putting something like this on a tablet, it gets really,

  • really slow because you can see even more cards,

  • and it's rendering even more views.

  • So it was much simpler, then to just take all of those

  • views that were being rendered, and instead, have one

  • custom view that draws really simple shapes.

  • So there's sort of two steps to it, and custom views

  • used to be very intimidating to me, I used to be very

  • scared of custom views, 'cause I thought they looked

  • really hard, but they really are not.

  • And the first step is just telling the custom view

  • how big it should be.

  • That is, how much space does it need to take up?

  • 'Cause I have my label view, which is really nice,

  • but no one knows exactly how much space it's

  • going to take up.

  • So on measure is what you use to tell any parent

  • view group how much space you need.

  • And it turns out, a lot of the times, you can actually

  • skip this whole step entirely.

  • And the reason I say that is because in any view,

  • you can specify, "I want this view to be 48 dp by 48 dp."

  • If it turns out that your custom view is just always

  • going to be the same size, like skip this entirely,

  • just define it in your XML, and you don't have to

  • worry about that.

  • In this particular case because the size varies based

  • on the number of labels, I had to write my own measure.

  • And so a quick way of going going through onMeasure,

  • the message signature that gets called, you have these

  • width measureSpec, and height measureSpec, which was

  • sort of confusing to me at first, but it turns out

  • that these are just packed integers.

  • So it's a single integer that, these two parameters

  • basically take the place of four parameters,

  • which is that a width mode in size and a height

  • mode in size.

  • So the size is just a dimension value, the mode though

  • is telling you how it wants you to handle

  • that particular size that it passed.

  • And there's three different MeasureSpecs for the mode.

  • One is exactly, which means the parent view group

  • wants you to be this exact size.

  • The other is at_most, so it take up as much space

  • as possible, and undefined means you get to define

  • whatever ideal width you would like in the situation.

  • And so your typical onMeasure looks something like

  • this, where you grab, and this is just for the

  • width, and then you would copy the same code

  • for the height.

  • You'd grab the mode and the size, if the measure spec

  • is exactly, you probably just wanna pass back the

  • size that it gave you.

  • You don't wanna screw up the parent view group

  • too much, or else it might get confused.

  • Otherwise, calculate what your desired width is,

  • and if the width spec is at most, then make

  • sure that whatever your desire width is not larger

  • than that size.

  • Otherwise, if it's undefined, you just get

  • to pick whatever desired width you want.

  • Then, once you've done this for both the width

  • and the height, you are by contract required to

  • call set measure set dimension, in order to tell

  • the view what you decided for the width and height.

  • 'Cause there's no return value for onMeasure,

  • you just actually have to call this measure at the end.

  • So that's measuring how big the view is, and the second

  • is onDraw, and this one is pretty simple, it just

  • gives you a canvas, and you draw.

  • And so I'm gonna leave this up to you, because what am

  • I gonna say about canvas?

  • This is not a talk about how to use canvas.

  • Another thing worth considering, is maybe in some cases,

  • you don't actually need a custom view, you could just

  • write your own custom drawable.

  • And the advantage here is there you could take

  • this custom-written code and apply it to any different view.

  • So that's good if you want so me special custom

  • background of sorts.

  • In that case, onmeasure just becomes something like

  • get intrinsic height and get intrinsic width

  • on a drawable, and then ondraw becomes draw.

  • But again, I don't wanna spent do much time on this,

  • you can research more about it later, I highly recommend

  • Cyril Motier gave a talk about Android drawables a

  • few years ago, and I highly recommend that talk if

  • you wanna learn more about that later.

  • And I'll be posting these slides too, if you wanna

  • get the links.

  • Alright, styles, let's move away from views,

  • well, not that far from views.

  • But talk about kind of another layer above views,

  • which is styles.

  • So if you are applying XML to a view,

  • this view has no style.

  • Not because it's uncool, but because there is

  • no style tag on it.

  • And then, if you have a style, all it does is I'm

  • creating some style resources, which has the same

  • attribute inside of it, and then the view itself

  • then applies that style on top of whatever, actually,

  • the style's applied first and then whatever attributes

  • are applied on top of it.

  • But essentially then, in the same way that includes

  • or taking layout XML and just stuffing it into

  • a view group, styles basically take a bunch of

  • attributes and stuff it into a view.

  • And so where is this useful?

  • It's very efficient when you need to style a bunch

  • of what I call, semantically identical views the same way.

  • And so what I mean by semantically-identically is that

  • each view does exactly the same thing in your hierarchy.

  • So a good example of this is a calculator, because in

  • a calculator you want all these buttons, or at least

  • the main number ones to look the same.

  • Another way to put it is that all the style views

  • should change at once.

  • So whenever you wanna change something.

  • So if I wanna change the text size of one of those

  • buttons, my expectation is that all of them

  • change at once.

  • So that saves me a whole bundle of time.

  • I see a lot of people though, myself in the past,

  • especially, misusing styles in very inefficient ways,

  • ways that end up biting you in the long-run.

  • And one way is single-use styles, so that is you have

  • a view that's representing a style, and that style's

  • only used once.

  • I feel like that's just extra work that didn't

  • need to be there.

  • Some people really like separating all this code

  • out, but it's so easy to refactor later and create a style.

  • There's even a refactoring option in Android Studio

  • that lets you do this.

  • So, not really necessary.

  • But more importantly, is where you have two views

  • that are coincidentally using the same attributes.

  • So I've got these two text views, and I say, "Oh look,

  • they're using the same text color and text color hint,

  • great, I'll use a style here."

  • But if you look at the ids, you can tell that these

  • two mean something very different from each other,

  • one's supposed to be title, and one's the body.

  • And so what happens is, suppose later on I

  • decide, "Oh I want the title to be like

  • a different color."

  • Well, if I change the color of the title now, that

  • also incidentally changes the body.

  • And so this style which was supposed to be handy

  • is now just a hindrance, because it's very hard to modify

  • that style without having some

  • unintended consequences later.

  • I liken this to in Java, imagine I have two constants,

  • one is like the number of columns I'm gonna show

  • in some grid.

  • And the other is the number of retries I'll do

  • in some http request if it fails.

  • And so I think, "Aw, these are the same value, I'm

  • gonna optimize this and have a single constant."

  • And problematic for two reasons, one is that three

  • is already a constant, but the other is I've lost

  • all semantic meaning.

  • These meant something very different; if I wanna

  • increase the number of retries for http, suddenly now

  • I've changed how my UI looks as well, incidentally.

  • So that's mistakes people can make with styles.

  • So themes are sort of like styles on steroids.

  • Styles you can apply to individual views.

  • Themes are essentially things that you can

  • apply to multiple views at once.

  • And so that can be a view group, it can be an

  • activity, or it can be the entire application.

  • It allows you to apply default styles as well,

  • so if I come up with, I want all of my buttons to

  • look slightly different across the app, without themes

  • I would have to go take that style and actually add it

  • to all of my XML.

  • Whereas with themes I can say, I would just like to

  • have a default style for all buttons, and it automatically

  • gets inflated for everything.

  • And then the last lazy thing that it helps you

  • with, at least in the context of my talk, it allows you

  • to configure your system-created views.

  • So if you've got popup windows or toolbars or something

  • that the system creates, and that's one fewer thing

  • you have to create.

  • But before you could theme on a view level, there was

  • a lot of problems with oh, I have to create some attributes

  • that affect just this one weird popup, but then it screws

  • up another part of my app.

  • But it's very useful for configuring just things that

  • the system will create.

  • So there's three ways to apply it, you can apply it like

  • I said to the entire application, you can apply it to

  • individual activity, if you do that, it ends up overriding

  • whatever's in the application.

  • And on top of that, you can apply to an individual view.

  • And in the view case, it ends up actually overlaying,

  • so you can just overlay like a few changes to it,

  • an individual views theme.

  • And the view themeing is very, very handy.

  • I don't know if anyone here's worked in the days

  • of Holo probably remembers that there was a

  • holo.light.width action bar, and that was because

  • there was no way to theme just the action bar part

  • of the screen differently.

  • So you have to say in the theme, I want to define

  • most of the screen to be light, but I want this one

  • part of it to be dark.

  • Whereas nowadays, you can say, "I would like just

  • a light theme," and then manually apply a dark theme

  • to the tool bar itself, so it makes things so much easier.

  • So in terms of theming, I highly-recommend people look

  • into AppCompat, which is one of the support libraries

  • that Google puts out.

  • If you're not already using it, amongst other things

  • it makes theming a lot easier.

  • For one thing, it gives you material on all devices,

  • like that's the latest design language from Google,

  • and without this, there's a lot of subtle differences

  • between Holo and Material, in terms of spacing, and

  • also in terms of just the visual metaphors

  • that they're using.

  • And so it's so much easier to start from one single

  • baseline, and then theme from there.

  • Another thing is, it gives you all these baseline

  • themes and styles.

  • So you might wanna change the default look of all

  • your buttons, but you don't wanna have to actually

  • go and define a style, which defines every single

  • attribute that a button has to have.

  • You just wanna take the main one and tweak it a little bit,

  • like add a little padding to all of your buttons.

  • And so AppCompat makes it easy then, to take the

  • AppCompat button style and extend from that,

  • and then modify it.

  • Without that, it becomes sort of a nightmare,

  • especially between Holo and Material.

  • And the third really important thing it enables

  • is that it allows you to do view theming pre-Lollipop,

  • in XML, and that was one of my favorite things,

  • because Lollipop had this view theming which seemed

  • really cool, but I was like, "Oh, but you can't

  • get it backported."

  • They actually did manage to backport that all

  • the way back to I think, some API that you shouldn't

  • even be using anymore.

  • I think 11.

  • Sorry people who are still having to support

  • apps on 11.

  • So a few examples of things you can do with themes,

  • the one that gets touted everywhere is the color

  • theming, so in this case, instead of having to use

  • individual drawables for everything, I can just set

  • up colors, and most of the things in Android will just

  • get colored automatically.

  • So bam, it's like a broad brushstroke you can make.

  • These are some examples of applying default styles.

  • So, just in case you've never seen this before,

  • so for example the top line, defines the button style

  • for the entire application, so that gets applied

  • to every button.

  • The spinner item style is handy because what if I

  • just wanna use the built-in spinner item layout

  • row that Android provides, but I still wanna

  • style it a little bit, I can use that here.

  • Text appearance is nice because then the text

  • appearance can apply to text views, and then you

  • can still apply another style on top of that.

  • Another useful thing you can do with themes is

  • that you can set up attributes which are then

  • referenced in your XML.

  • So in these case selectable item background, which is

  • like one of my favorite attributes, if you refer to it

  • with that ?attribute/ instead of the @drawable that you

  • normally use, then it derives that value from the

  • theme instead of going to it directly.

  • So why is this useful, if you happen to have

  • an app that supports multiple themes, it makes it

  • very easy then to swap between those values, but more

  • importantly, your system might have multiple

  • ideas of what a selectable item backgrounds it's,

  • because pre-Lollipop, here wasn't any Ripple drawables.

  • It was just usually just a flat color that you

  • changed to whenever you click on something, whereas

  • post-Lollipop, you wanna have these ripples because

  • it looks really cool.

  • And so if you use a selectable item background,

  • then the theme can automatically figure out which

  • one it wants to take.

  • Alright, I'm gonna do a quick water break before

  • I move on to the next section.

  • Sorry.

  • Alright, resources, so, resources are you know,

  • all the things that go into your app that aren't

  • just pure Java code.

  • And before I can talk about resources, I wanna talk

  • about device configurations.

  • So if we look at this screenshot there's like a whole

  • bunch of things that one can derive about it in terms

  • of its configuration.

  • So for example, I can say it's in portrait orientation,

  • it's got a height of 731 density in a pint of pixels,

  • it's got a width of 411 of them, it's a Nexus 6p,

  • so it's got a density of xxxhdpi, it happens to

  • be in English right now, the English locale,

  • so it's showing English U.S. and it's version 24 'cause

  • it's running the latest n builds.

  • So these are all things that the Android system knows

  • about the device, and you can query this all manually

  • on your own if you want, but actually with resources

  • you can just have it select things automatically.

  • And some of these device things will change throughout

  • execution, some of them won't.

  • So portrait vs. landscape, unless you're locking

  • your orientation, that can change very rapidly.

  • You change the locale, people probably won't change

  • that often, but they can change it while your app's running.

  • And then some things like the density and what operating

  • system version probably aren't going to be changing

  • while you're running your app.

  • So what sort of things do you wanna vary on this?

  • Well landscape versus portrait, I think is a classic

  • example, because it usually presents a different

  • mode of operation.

  • The built-in calculator app, when it's in portrait,

  • only shows four rows, but when it's got more space

  • to stretch out, it can possibly show some of the

  • more cool functions, just by default.

  • Locale is a very easy one, you wanna have your app

  • translated in a different languages, you just have

  • have it select different text strings based on the

  • locale, so on the left it's in English, on the right

  • it's in Japanese.

  • You can have things break on the width of the screen,

  • so on the phone the card when it's opened is small

  • enough that it just decides to take up the full width,

  • whereas at some point, if the device gets large enough,

  • it just looks kind of ridiculous having it be full

  • width, and so we start having a break point at some

  • moment with width.

  • And another example of that would be like our search

  • results, we have the staggered grid view, and again,

  • on the wide tablet it wouldn't make sense to have

  • a single column, it makes sense to fill it up as much

  • as possible, and so we can vary the number of columns

  • based on that.

  • And then also on the mobile phone you can see the top

  • result is some small board display, because it's a

  • small device, whereas on the larger tablet, we can show

  • the nice big rectangle, which would look nicer if that

  • actually had a background, but whatever.

  • So you could do this all in Java code like I said

  • earlier, but it's a lot easier if you just leverage

  • the resource qualifier system.

  • And what this system does is you define alternative

  • resources for different device configuration and then

  • at run time Android will automatically pick the

  • correct resource based on the device configuration.

  • So it's go through an query everything and figure

  • out which of the resources you defined makes most

  • sense in this situation.

  • And so you define this by the names of the folders,

  • so in your resources directory if you have something

  • that's just the default values, that means it has no

  • resource qualifiers attached to it, it's the default

  • fallback in all cases.

  • Whereas if you do a single dash and then a resource

  • qualifier, so this one has one resource qualifier,

  • it's xxxhdpi, and you can have multiple qualifiers

  • if you want.

  • You can actually apply as many qualifiers as you

  • want to a single value, although usually it isn't

  • handy if you do it to many different values.

  • And one other thing worth noting is that if you do

  • have multiple qualifiers, they have to go in a particular

  • order, so look up the documentation, the documentation

  • has this huge table of all the different qualifiers that

  • you can use, and you have to put them in the order

  • of that table for Android to parse it correctly.

  • So that same documentation page also lists

  • out the algorithm, but pretty much it's just

  • like a process of elimination.

  • It tries to find the most specific resource, given the

  • current configuration.

  • So imagine I start with some value, and I've got something

  • in values with smallest width 600dp, smallest width

  • means that regardless of orientation, what is the smallest

  • width that you can possibly have for the device, which

  • is useful for figuring out kind of the device class,

  • like tablet versus phone.

  • And it also has to be in portrait.

  • So then it would select from this if those are true,

  • but if it turns out one or the other isn't true,

  • then it'll start looking to see other things

  • it can eliminate.

  • So then it'll look maybe for just the single

  • sw 600 dp, oh, it turns out the phone doesn't qualify

  • for that, so then it'll see is the phone in portrait,

  • and if it doesn't qualify for that, then it'll fall

  • back to the base values here.

  • So that's why it's hand to have a default value

  • for everything, the only thing you don't really need

  • a default value for is drawables because the way

  • that Android works it'll automatically scale if you don't

  • have something in the right directory.

  • So if you only have xxxhdpi assets and your device

  • happens to be mpi, it'll just scale everything down,

  • which isn't great performance-wise, 'cause having to

  • do all that extra work, but at least you don't have

  • to worry about that when you're developing quickly.

  • So in terms of using resource qualifiers in the correct

  • way, what I think is important is to think

  • of these resources as code.

  • In particular, to think of each resource that you're

  • inserting somewhere as a parameter to some method

  • function, a method or function, and that the parameter's

  • determined based on the device configuration.

  • So for example, if you're thinking about this in terms

  • of code, the code on the left is insane and dumb

  • because I'd have to write a new square function per

  • number that I want to square, whereas the one on the right

  • has this parameter.

  • So you wanna think of it more in terms of the things

  • on the right.

  • So one simple example, on that I like to use a lot,

  • is actually letting the resource qualifier system

  • determine some Boolean logic for me.

  • So this is a simple one where I basically just wanna

  • know whether it's in portrait or not.

  • Yes, you could query this from resources fairly

  • easily, but this is just an example.

  • So I could say, "By default, is portrait is false,

  • and then in particular, when it is in portrait,

  • then it's true."

  • And then I can get this Boolean value out.

  • But this is really handy if you have multiple

  • different configurations and multiple ways that

  • that Boolean could run, it could do all that calculation

  • for you, you don't have to think about it.

  • A more classic example is using it for different layouts.

  • So I could say I'm gonna call set content view, and I

  • have these three different versions of layout, one that's

  • the default, one that shows up in landscape orientation,

  • and one that shows up in portrait orientation.

  • And I made this slide far before I realized it's very

  • improbably to actually end up ever without it being

  • in landscape or portrait, you'd have to have a

  • square screen for that.

  • But basically, it's select the right one of these,

  • but would be more clever, 'cause this you'll probably

  • end up with some duplicated code.

  • 'Cause chances are, there's not that much that

  • changes between portrait and landscape, so it's then

  • if you can use that code reuse, the include, and then

  • it can switch on just that part of the code that changes.

  • So I've got my LinearLayout, and inside of it somewhere

  • there's an include, and that's the only part that

  • changes based on orientation.

  • So now I can have a single activity main, and I can

  • have a layout that's the default one, and then the

  • layout that just modifies in the portrait.

  • Along the same lines, let's look inside that include,

  • suppose both those includes have text view which are

  • supposed to be pretty much the same thing, but all

  • that they really modify on is what the text size is.

  • But this again, this seems kind of like a waste

  • to have two different layouts here, if all I really

  • wanna modify is the text size.

  • So here what I can do is I can then reference a dimension,

  • and then that dimension can be then determined based

  • on the qualifiers as well.

  • And then to take this even a step further, let's suppose

  • we have style somewhere in the application, that's the

  • same sort of thing, all that modified is the text

  • size, so I can again, have this be a dimension,

  • but now this style can be applied all over the

  • the application instead of applying that dimension

  • trick to just one particular view.

  • So in this example, I have an activity main on top,

  • and then by default to go to to one include, but if it

  • happens to be in portrait, it'll go to a different include.

  • Both of those include a text view, which is supposed

  • to be ostensibly the same between both, so they use

  • the same style.

  • And then that style, based on the current configuration

  • determines what the text size is.

  • So you can really go pretty deep with this and

  • write very little duplicated code between all

  • of your layouts, if all that you're doing is changing

  • things based on device configuration.

  • And as an aside, this is why generally speaking,

  • you shouldn't override config changes on Android.

  • That's a pretty common beginner way to get

  • around the problem of, oh, I rotate my phone and then

  • my activity got destroyed and I didn't want that to

  • happen, 'cause where did my all my data go?

  • And then someone says, "Hey, if you just override

  • config changes, everything works out, and all

  • of your data stays around."

  • there's two problems with that, one is that it doesn't

  • necessarily help you because you probably only override

  • config changes for orientation changes, but there's

  • a lot of other ways that the configuration could

  • change on the fly.

  • But for two, it means that you bypass this system

  • entirely, cause you're basically telling the Android

  • system, "I've got this, don't worry about it."

  • This whole resource qualifier system is a major

  • part of the reason why when you rotate your

  • phone, the activity gets destroyed and recreated again,

  • because it wants you to re-inflate everything, because

  • when you re inflate everything something might have

  • changed based on selecting a different layout.

  • Alright, drawables, so this is, let's see how much

  • time I have, good.

  • Alright, so drawables is the last section I wanna

  • talk about, and I wanna outline sort of a nightmare

  • scenario that you may or may not have gone through.

  • I certainly gone through this, many times.

  • So imagine I'm interacting with design, and they

  • send me a mock-up of a new screen.

  • And in particular this is the login screen, and they

  • wanted to add this login with SSL thing at the bottom.

  • So then I look at this, and I start working on it,

  • but then I tell design, "I need this asset, 'cause I'm

  • not good at design or anything, I need you to give

  • this to me."

  • So design says, "Okay, sure, no problem."

  • So they send you over a zip file, you unzip it,

  • and you get this one file that is who knows how big

  • this is supposed to be.

  • So you tell design. "Okay, this isn't enough, I need

  • more than this, I need one in all the different densities."

  • And design says, "Oh sure," they go do some research

  • on how that works, and then they send you back a

  • file like this, and a zip that contains this.

  • So now you've got all the assets that you need,

  • but then you have to go through an rename everything

  • and put it in the right folders, and then import

  • into your project, it's kind of just a pain.

  • And that's a real pain to do with every asset,

  • and then the kicker on top of all of this is that

  • at the very end, design says, "Actually, I wanna

  • tweak the color, and here's a new set of assets."

  • And so now you have to go through this whole process

  • again, and it's a gigantic pain in the ass.

  • So my recommendation here, I've been working with

  • the design team at Trello, and we figured out a whole

  • bunch of ways to reduce all of this pain and all

  • this friction.

  • And it's just made things so much simpler, and it's

  • basically to think of assets as code, as much as possible.

  • Don't think of them as bitmaps that you get from

  • design as much as you can, think of it as things that

  • you can execute in your application.

  • Because then it's so much faster to tweak and change

  • things on the fly.

  • So the first example of this is drawable XML, which has

  • been in Android since the very beginning.

  • And drawable XML are resources that you can define,

  • you can do things like draw simple shapes, you can do

  • things like set up state selectors, so that's where

  • if you press a button and it looks slightly different,

  • that's a state selector.

  • You can use it as a layer list, and this is really

  • handy because if you have two drawables that you

  • actually wanna layer on top of each other with multiple

  • states in between both of them, you might have thought,

  • "Okay, now I need to design to composite all of these

  • images for me."

  • Actually, you can just set up a layer list, and then

  • change the two layers independently, you get that

  • nice composition going on.

  • So a detailed example for this are the login buttons

  • that I worked on once.

  • And so these login buttons are entirely done

  • through drawable XML.

  • So the first step to making these login buttons work is

  • that I need to create that button outline.

  • And the button outline itself is just its own file.

  • So we're not worrying about the click state right now.

  • And it uses a shape drawable, the first important part

  • is you can tell it what type of shape you want, you can

  • also make ovals and stuff like that.

  • But you're limited to very simple shapes with drawable XML.

  • I wanna say that it's mostly filled with transparent

  • space, in fact, that should be the default, but on some

  • older versions of Android it was not defaulting to

  • transparent for solid, I don't remember exactly why.

  • Then I do want that white outline though, so I give it

  • a stroke, which then determines that outline,

  • and I would like to have a small radius on it so it

  • gets that nice little pretty button look.

  • So that's just creating the outline, the blue actually

  • comes from the background of the entire screen, I just

  • put it there 'cause otherwise it would be really hard

  • to see with my white background on the slides.

  • So then we need to add some behavior to it.

  • When I click it, I wanna actually be able to tell

  • that I clicked it, and so we need to add a selector

  • to it, which you can see in this beautiful little

  • two frame GIF.

  • And so the way that I'm doing this is actually layering

  • a selector on top of that outline I just talked about.

  • So I'm using a layer list, and that layer list allows

  • me to take two drawables and put one on top of the other.

  • And I'm saying the top layer is that outline that I just

  • showed you, that's the previous code that I showed

  • you, is what's going on top.,

  • So that's always going to be drawn.

  • And then the other layer is a selector, and the selector

  • just has two states in it, and one of those states

  • is when it's pressed, then I want you to draw

  • this other shape.

  • So again, I'm using another shape drawable in order

  • to determine what should be drawn inside of it,

  • and in this case it's a little simpler, 'cause I can

  • just say, "I want you to have a solid color, but then

  • again, also have the corner so it doesn't end

  • up bleeding out of the corners."

  • And then when it's not pressed and in the default state,

  • then it'll just be transparent.

  • So that's great an all, but then in version 21 of Android

  • they added these nice ripple drawables which look really

  • pretty and doing that requires a while different

  • set of code.

  • And so for that, you end up using something that's

  • a ripple XML, something we added in version 21.

  • And that inside there is where you say what the color

  • of the ripple should be.

  • And then after that, I add, okay, I still have the same

  • button outline as what's actually being drawn in that

  • ripple, but then the last part of this is that I

  • define a mask.

  • And that mask basically says, "This is the outline

  • of where the ripple should appear."

  • And so then the actual solid color inside of it

  • doesn't really matter, it's just the fact that this

  • drawable will draw to this particular area that matters.

  • And so I was able to get away with all of this and

  • have a different version for different versions of Android,

  • by using the resource qualifier system, so at the

  • bottom there's this outline that I'm always going

  • to be using, but then the default button uses the state

  • selector, which will always work all the way back to

  • version one of Android, I think.

  • And then drawable v.21 for that ripple drawable,

  • I can use there.

  • So drawable XML, a fairly good way to skip a lot of work.

  • And then I just had to ask design for the colors, I didn't

  • have to ask them for anything else in particular.

  • Vector drawables, so like I said, the shape drawables

  • lets you draw very simple shapes, nothing complicated.

  • Vector drawables lets you do any sort of vector

  • drawing you want, or most vector drawing that you want.

  • And so it allows you to do very complex shapes, and

  • the advantage here to using a vector is that you

  • don't have to then worry about density of the

  • screen all that much.

  • 'Cause before I was having to get these PNGs from

  • design that was in all the different densities,

  • here they can just give you a single vector,

  • and then it's automatically drawn at whatever's

  • the best resolution for that screen.

  • So that's a huge time-saver, but there is one

  • problem with the way that Android

  • implemented vector drawable.

  • Oh, so another point is that vector drawables

  • were added recently in Android, but there was

  • a back compatible library in the support libraries

  • for using vectors all the way back to I think,

  • 14 or something like that.

  • But there is a big problem with the way that Android

  • did it, which is that they came up with their own

  • vector drawable format that is not actually SVG.

  • And if your designers are anything like my designers,

  • they know how to speak SVG really well, all of their

  • tool know how to output in SVG, and none of them know

  • how to output as vector drawables.

  • So you need some way to convert these SVGs that your

  • designers are giving you into vector drawables in the app.

  • So there's sort of two ways of doing that, yeah, sad

  • design, there's two ways of doing this.

  • And one is in Android Studio you can say, "I want a new

  • vector asset," and that'll bring up this nice little

  • wizard, and then you can pass in the SVG and it'll

  • convert that into a vector drawable as best it can.

  • There are some SVGs that it doesn't work very well

  • with and won't convert.

  • So that's good, but I still am even lazier than this,

  • because I don't wanna have to go through a wizard

  • every time I import a new asset.

  • So instead, we wrote his before all the vector drawable

  • back compat stuff happened, but we're still using

  • it, which is this Android plugin that we

  • wrote called Victor.

  • And what Victor does, is you define any number of source

  • sets, anywhere that you have your SVGs, and it'll just

  • slurp all those up, and then output something that

  • the system can render.

  • And for awhile it just output PNGs but then eventually

  • we were able to get to actually grab the code that

  • is in this new vector asset stuff and then use

  • that to convert it straight into vector drawables.

  • So that's great because actually with Trello,

  • our designers have their own Git repository, which is

  • where they put all of their compiled SVGs, and then

  • we can just have that as a Git submodule, and import

  • it, and then we just have to update a commit pointer

  • to get new assets from design, that's great.

  • And then so the last thing I'd like to say about

  • drawables that has really saved a lot of time

  • recently, is that difference between skeuomorphic

  • and flat design.

  • So skeumorphic design is where you have things

  • that look exactly like what they're supposed to be,

  • and so on the left is Andie Graph, which is an app

  • that my friend wrote, which makes your phone act

  • exactly like any TI-83, Ti-84, whatever,

  • and look exactly like it.

  • So it looks very realistic, that's very skeumorphic,

  • whereas on the right you have the normal calculator,

  • which is flat, and every button is just this flat color.

  • And what's really nice here is that as nice as the

  • thing on the left looks, on the right all the icons and

  • all the text is just a flat color.

  • And what that means is that it's very easy to tint

  • those colors and change them on the fly.

  • With the buttons on the left, it would be very

  • hard to tint them in any way that would be reasonable.

  • So actually, in the Trello app, all of our assets

  • are flat black colors.

  • So they're black on alpha, and then in code, we take

  • any of those, and tint it whatever color we want.

  • And so that's super-handy from the perspective of

  • design, because they don't have to create multiple assets

  • for whatever color they want.

  • Every time they wanna change the colors, we can just say,

  • "Oh, that's easy, let's go change it in code,"

  • and then we're done.

  • So in terms of tinting images, there's sort of a few

  • ways to do it, one is to do it via XML, but besides

  • the fact that image view has had this tint attribute

  • forever, which doesn't quite work all that well,

  • it's not backwards compatible.

  • It got added into recent versions of Android to be

  • able to tint drawables in XML, but they haven't figured

  • out any way to actually backport that functionality.

  • So I ended up doing actually most of the tinting

  • in code, it's very simple with image view and drawables,

  • you can call set colorfilter, and then you just pass

  • in the color.

  • And then it turns out that for a black icon on alpha,

  • you wanna use the Porter/Duff mode of source in.

  • That's actually why the XML imageview of the tint

  • attribute there, I don't like it very much, 'cause it

  • uses a Porter/Duff mode that isn't compatible.

  • I think you have to create white icons on alpha,

  • which we're not doing at the moment.

  • Now if you want a really comprehensive solution,

  • this exists in the support libraries is drawable

  • compat, and with that you actually wrap the drawable,

  • and then you can call set tint, or set tint list

  • on that wrapped drawable.

  • And main advantage that has over just calling color

  • filter directly is that it can handle tint lists,

  • so you can have multiple different selected states

  • for that wrapped drawable in color, and you can

  • tint all of it equally.

  • But since we're not actually using that in the

  • app, we don't end up doing that very often, and so

  • set color filter's just a faster, easier way of doing it.

  • Anyways, so that was all that I've got.

  • This was a slide I was told to put up as well,

  • to let us know what you think, click the happy face

  • if you liked it or the sad face if didn't like it.

  • And thanks very much for coming to listen to the talk,

  • the middle link is to my blog, where I've written

  • more about some of these things and then some

  • parts of this talk were taken from other talks

  • that were more detailed, in particularly the styles

  • and themes, I went into much more detail on that.

  • So you can look at my old speaker deck to find those

  • talks if you're more interested in learning some

  • of the more nitty-gritty details there.

  • And thank you very much.

  • (audience applause)

  • Were there any questions?

  • - Yes, actually there was one of them, and the

  • question was, whether performance was lost in virtual

  • machines and the.

  • My take on it is that, well, the question might

  • mean that if you use like an emulator, and you're doing

  • this, you'll have a slide with the graphics performance

  • in different layouts, will it affect emulators, do you

  • know that, if?

  • - So yeah, so let's see here.

  • - I guess that's what--

  • - I think you're talking about this one--

  • - [Interviewer] (Mumbles) Yeah.

  • Could you actually find out that your layout

  • are kind of--

  • - Through an emulator?

  • No, I'd use a real device for this.

  • - [Interviewer] Yeah, you'd use a real device.

  • - Yeah so I wouldn't, for things like profiling,

  • the emulator can really make things awkward because

  • it could be the case that you have this GPU, if you're

  • working on a Windows desktop or something, you're gonna

  • have a GPU that's bigger than your phone,

  • running the rendering.

  • And that's gonna throw things off a little bit, obviously.

  • Or it could be the case that whatever, I think it used

  • to be that it was translating from ARM into x86,

  • and then that would be really slow, and so all the CPU

  • operations would be really slow.

  • Basically yeah, I would use an actual device for all

  • sort of profiling purposes.

  • - Okay, and do you, you touched upon

  • this new ConstraintLayout, is that something you

  • played with or?

  • - Yeah, I played with ConstraintLayout.

  • - You believe it's the savior, or?

  • - I hope so, 'cause it does a lot of things

  • that, it's sort of like this composite of RelativeLayout

  • and LinearLayout right now, that allows you to create

  • very complex layouts without having too much nesting.

  • And so the hope is that you'll be able to create

  • these complex layouts without much nesting, and that

  • through the constraint system, it can better figure

  • out what are the more performing way to lay

  • things out quickly.

  • So I'm hoping that it saves us from having to

  • use RelativeLayout more often. (laughs)

  • - [Interviewer] Yeah, I think you have more questions.

  • Please come down and talk with them afterwards.

  • - Yeah.

  • - [Interviewer] But thank you very much, Dan, and remember

  • to rate the session and I can see some of the speakers

  • here from the Android track, so thank you very much,

  • it has been a pleasure.

  • And yeah, please give him a hand.

  • (audience applause)

  • - Thank you.

(inspiring jingle music)

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

GOTO 2016 - 効率的なAndroidレイアウト - ダニエル・ルー (GOTO 2016 • Efficient Android Layouts • Daniel Lew)

  • 56 5
    colin に公開 2021 年 01 月 14 日
動画の中の単語