Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
Faster is Better. Making Native Apps Sing
32:45 with Jonathan Karon79% of mobile app users will give your app a bad review for freezing up. 98% of users say performance matters, and the apps it matters most for - banking, mobile payments, and shopping - are where the money is. One in five users will abandon your app forever if it freezes for five seconds! App performance is critical, and it's also hard. New Relic's specialty is bringing you the data you need to fix the real problems your users are having with your production app. In this session we will explore common performance problems that plague even the best built and tested native iOS and Android apps. You will learn recipes for gracefully handling unexpected data volume, misbehaving third party network APIs, and other circumstances outside of your control. We'll also cover some simple tricks that will make your app scream, including a layperson's guide to optimal threading strategies and proper parallelization of network requests. Leave this session with a performance cheat sheet you can use every time you design a new feature or want to level up your app.
-
0:01
So good afternoon, my name is Jonathan Karon there are actually
-
0:07
two Jonathan Karon's on the internet, hate to admit that, one in
-
0:10
Massachusetts who's a lawyer and one in Oregon who's a software person.
-
0:15
I'm the software person and I hate to admit it
-
0:17
but the lawyer actually has me beat on page rank.
-
0:20
So, you can help me out by just going and linking
-
0:24
to Tapester.com right now, that'd be great, we'll solve that, I'll wait.
-
0:31
No?
-
0:31
Okay.
-
0:31
So clearly I don't blog enough but that's not why we're here.
-
0:36
It's Friday afternoon and you've all graciously stuck around for
-
0:39
the end of the conference so that's kind of exciting.
-
0:42
If you're someone who's into mobile applications
-
0:44
or understanding and tinkering with like big
-
0:46
and complex systems then I think this is gonna be a really good talk for
-
0:49
you ,I'm excited, if you're not into that stuff then you should probably just, like,
-
0:55
enjoy Vegas and, you know, all of that, so, no one's leaving, that's good.
-
1:02
So did anyone catch Carl's keynote yesterday?
-
1:05
On the lemonade stand and all of that fun stuff?
-
1:08
[COUGH] this will make sense in a minute.
-
1:11
I've talked a bunch about monitoring
-
1:13
mobile apps and software tuning and performance.
-
1:17
And one day I was out walking my dog in the woods, like Carl told us we should.
-
1:20
And I realized that I'm not talking about the right thing.
-
1:25
That, you know, there's so much more
-
1:28
important to mobile application performance than just
-
1:30
writing optimal code, So I'm excited to give you this talk because it's super new.
-
1:35
I haven't given it before, and it's kind
-
1:38
of like the biggest, newest idea in my head.
-
1:40
So hopefully, this will be like catching a
-
1:42
good punk band before the producers mess everything up.
-
1:47
so, I'm here to talk about mobile performance, performance of mobile apps.
-
1:51
My background is more in native mobile apps but
-
1:53
I think this will apply to pretty much everything.
-
1:56
The first time I did a talk on
-
1:57
mobile performance, a bunch of marketing folks showed up.
-
2:00
And they were trying to figure out how to improve their
-
2:02
campaign conversion rates and deliver more push messages to your pockets.
-
2:06
So that kind of bummed me out, cuz that wasn't what I was talking about.
-
2:11
So let's start with what do I mean by performance?
-
2:15
To me, performance is the creation of a frustration-free user experience.
-
2:21
it's, it's pretty simple really, right, our jobs as app developers is to
-
2:25
make people feel like they are having a really good time using our apps.
-
2:32
so, you know, this gets into how people are happy
-
2:35
with our apps and how not so let's review some statistics.
-
2:39
98% of users say that performance matters.
-
2:43
And the apps where it matters most for those people are things like banking,
-
2:46
mobile payments, e-commerce, and shopping and those
-
2:49
are where all the money is, right?
-
2:51
So the more important the app the more important the
-
2:54
performance is and that shows in the way people get frustrated
-
2:59
by these things.
-
3:01
79% of users will give your app a bad review for freezing up.
-
3:06
And one in five will delete the app forever if
-
3:08
they are left there sitting for more than five seconds.
-
3:12
That is like, some serious performance anxiety, because five seconds is
-
3:17
not a long time, and our users are very, very mercurial.
-
3:22
So looking at retention and good will,
-
3:23
you're actually better off if your app crashes.
-
3:26
Then if it locks up and makes someone wait for something to happen.
-
3:31
Because it makes people feel like you're wasting their time, right?
-
3:34
And there's nothing worse than sitting there,
-
3:36
waiting for your, like, you know, dopamine cycle
-
3:38
to kick in because you got your little treat in the app, and it not happening.
-
3:44
The, you know, but reflecting on these
-
3:45
statistics, I started hearing a common theme.
-
3:49
They don't really have anything to do with code optimization.
-
3:53
Right, as long as we don't exhaust available
-
3:54
memory, people don't care if our apps are hogs.
-
3:57
They don't care whether we're using one core, or six cores, or whatever
-
4:00
the phone has, or if you spend a week hand-coding assembly to do something.
-
4:05
They care about a smooth experience, where
-
4:09
their expectations are met and things happen.
-
4:14
They're not sitting there waiting.
-
4:15
So our job as craftspeople is to prevent hiccups.
-
4:19
Basically to keep things moving at a nice pace.
-
4:23
But how do we know what's important and
-
4:24
what's misdirected effort when we're building out an app?
-
4:27
Right?
-
4:27
Eventually we'll get there with testing and feedback and all that stuff.
-
4:31
But early on is where, you know, you listen to all
-
4:33
of the rules about design up front and you know, test
-
4:37
early and often and, and you know it's way, way cheaper
-
4:40
to make changes early on in a product lifecycle than later.
-
4:45
So when you're designing a product, you have all these great
-
4:48
techniques of like, research and user fast, focused design and, right?
-
4:53
And you can figure out how to deliver the right
-
4:56
experiences for people so that they can get the job done.
-
4:59
We spend describing what an interaction with our software should accomplish.
-
5:03
Right, we create these user stories.
-
5:06
And if you caught Luke's talk this morning, you saw what
-
5:08
an amazing difference of good, thoughtful user experience can make, right.
-
5:14
Fewer taps on the screen, fewer times the keyboard comes up and you
-
5:17
gotta switch from thumb to two fingered mode and all of that stuff.
-
5:21
All right, so the design process and really
-
5:24
thinking through the interaction can make a big difference.
-
5:27
But, as you probably learned, implementing that stuff is non trivial.
-
5:33
Right?
-
5:34
I've been building these connected location
-
5:36
aware mobile apps for 17 years now.
-
5:39
Which is ridiculous.
-
5:40
The first one was an Apple Newton with a cell modem, and I still struggle
-
5:45
with these things right, every time I have an app there's something in it that
-
5:48
I don't realize is gonna be a problem and one person out of 20 calls
-
5:52
me up and says hey, this is stupid and I spent 20 minutes not doing anything.
-
5:56
So even if you're a really great software architect.
-
6:01
You, and you know the mobile devices
-
6:03
really well, you're still gonna get into trouble.
-
6:06
And you're gonna spend all of your time
-
6:08
trying to fix problems that you can't reproduce.
-
6:11
All right, when you could be building something awesome like the
-
6:13
next new feature or going to future insights and hanging out.
-
6:18
So we get to the point.
-
6:19
Mobile apps are a bricolage of different pieces that we put together with code.
-
6:26
You can optimize the code all day long but if you
-
6:28
start thinking about that too early you're just doing everything wrong.
-
6:32
Right, because most of the time the slow things aren't under your control.
-
6:36
You can't speed them up.
-
6:38
But you can orchestrate them and make them feel better.
-
6:43
So there are tricks to eking the last nugget of speed out of a phone, right?
-
6:46
You can optimize your code and do this or that, and think about all
-
6:50
sorts of technical things, but we can get to those another day right, the
-
6:53
first job is to solve the 80% problem of accommodating how things are going
-
6:59
to work under most cases and not worrying too much about those last 20% speed.
-
7:06
So instead of that I'm gonna talk about orchestrating
-
7:09
the symphony, right, you have all these components that play
-
7:13
in the app and your job Is to create some
-
7:17
kind of really tremendous first class experience out of that.
-
7:20
So there's time when an app is slow because someone didn't write good code.
-
7:25
That's happened.
-
7:27
But a lot of the problems are things you can't really solve.
-
7:31
You just have to learn how to dance with that.
-
7:37
You know, the analogy that I sometimes use is that it's like a ugly house next door.
-
7:41
You can do landscape design and kinda hide it and people won't really notice it.
-
7:46
But then the analogy starts to fall apart because mobile
-
7:48
issues don't really sit still like a house next door.
-
7:51
It's more like you've got fifty houses scattered over your lawn.
-
7:55
Some of 'em right in front of your front door.
-
7:58
And they tend to jump around and change shape and color.
-
8:01
And sometimes they knock on the door at 2:00 AM
-
8:03
yelling like, hey I just came back from Vegas, what's up?
-
8:07
[LAUGH] So, a simple app, right?
-
8:13
A simple, simple mobile app.
-
8:15
Can rival the complexity of an entire data center.
-
8:21
This is an app that we built for a conference called Future Stack last year.
-
8:24
Which has nothing to do with Future Insights.
-
8:27
We just overloaded the future thing.
-
8:31
If you step back far enough, and think
-
8:32
about this stuff like a systems management person.
-
8:36
This is what your app kind of looks
-
8:37
like right, it's, it's this broad, distributed, connected system.
-
8:43
And in systems management you start by optimizing for the
-
8:46
through put and the performance of the median case, right?
-
8:49
If 50% of my users are having a good experience at this level,
-
8:52
awesome, that's great, our servers are running,
-
8:54
and our network is not bogged down.
-
8:57
But as we all know in mobile you tend not to talk about the typical user experience.
-
9:03
You talk about the one person who had a really horrible time and is
-
9:08
trashing your brand on the app store and Twitter and all of these places.
-
9:12
Right because it really matters, like each one of
-
9:15
those people as individual and their experience is vastly different.
-
9:18
And you can't just log into their phone and
-
9:20
tune the database or figure out why things aren't working.
-
9:24
So let's zoom in and consider that single
-
9:26
copy of the app, right, running on one phone.
-
9:28
The way the app performs for individual users is really variable.
-
9:34
Well why is that?
-
9:37
The bricks that make up the app have a range of characteristics.
-
9:40
Right, you know, on the one hand you have these, like multi-core
-
9:44
high performance CPU's, that are really
-
9:46
great at crunching through certain data sets.
-
9:49
And, you also have three year old commodity phones,
-
9:53
that have a tenth of the power of that, right.
-
9:55
So there's a, there's a huge breadth in how quickly
-
9:58
you're gonna be able to accomplish any data processing task.
-
10:02
And then you have fairly slow flash storage and phone
-
10:05
components like the camera and the screen, which have inertia.
-
10:08
Right.
-
10:08
They take time to, to come up to power and to update.
-
10:13
And then at the very far end, you've got really slow cellular network connections.
-
10:21
Right, you've got Bluetooth.
-
10:22
And then you end with these large data sets
-
10:24
that you have to deal with because your building
-
10:26
modern connected apps and people are sharing video and
-
10:29
downloading thousands of bits of content and this and that.
-
10:33
And these aren't things you can tune in your code right?
-
10:36
They're just facts of life and bits of reality.
-
10:40
But they are things you can reason about and design for.
-
10:45
So how do we do that?
-
10:48
Most of this stuff doesn't really measure consistently.
-
10:50
Right, you can build a great user experience, but how do you compensate
-
10:55
for something that could take a 100 milliseconds, or it could take 30 seconds.
-
11:00
That's not the same thing as tuning code.
-
11:05
My answer lies in this discipline called systems theory.
-
11:09
And the way it's applied in practice is typically called systems modeling.
-
11:15
So, Russell Ackoff, who is an operations theorist.
-
11:17
Once said that, managers don't actually solve problems, they manage messes.
-
11:22
And I have a suggestion.
-
11:24
Which is that this holds the same for mobile developers.
-
11:28
That, as app developers, what we do, is we manage messes of pieces.
-
11:34
So, as a software engineer, you're conditioned to
-
11:36
think about processing data with this reliable, testable process.
-
11:40
You know, predictability and building things
-
11:42
that are easy to understand and test.
-
11:44
But if you're like most mobile developers I
-
11:46
know, that's like the first half of your job.
-
11:49
All right, the second half involves tweaking your order
-
11:52
of operations of things, and fiddling with poorly documented API's.
-
11:55
And generally poking your app with a stick to try and make it do what you want.
-
12:00
You want consistent and reliability out of your flow
-
12:03
of events but that's never ever what you really get.
-
12:08
So that's what i mean by a mess.
-
12:10
Does anyone here now about Six Sigma?
-
12:15
Okay, it's a management practice.
-
12:18
And there are all sorts of courses and books and things that
-
12:21
you can take to you know, learn about it, but I am
-
12:23
gonna reduce it to two really simple goals and probably get my
-
12:26
butt kicked by the Six Sigma black belt guy in the back.
-
12:31
first, reduce the standard deviation and then increase the mean.
-
12:38
So what does that mean?
-
12:39
It means first focus on reducing the variability in your process.
-
12:44
Then once you've achieved consistency focus
-
12:47
on increasing the speed of the process.
-
12:51
Because you can't reliably improve something that's
-
12:53
out of control .That's just optimizing the mess.
-
12:56
It doesn't work, it ca, it just, you know, you spend
-
12:59
a lot of time and energy and at the end of
-
13:00
the day there are still people out there who are just
-
13:02
frustrated because things don't work the way you think they do.
-
13:06
So this is where systems theory comes in.
-
13:09
Using systems modeling, we can address the variability problem head
-
13:13
on before we start actually designing our code and writing things.
-
13:17
So systems theory is a science for
-
13:19
modeling and understanding pretty much any dynamic system.
-
13:23
It turns out that you can model almost
-
13:25
anything natural mechanical whatever with four basic elements.
-
13:30
You've go stocks, flows, feedback and delays.
-
13:34
[BLANK_AUDIO]
-
13:37
So let's step back and talk about systems.
-
13:39
Every system has a purpose, right?
-
13:41
A restaurant is a system intended to put food
-
13:43
in your mouth, or put you to sleep at lunch.
-
13:47
A football team is a system intended to score goals and enrage fans.
-
13:52
And the mobile app, I'll call it a collection of systems.
-
13:55
You know, each of those systems is intended
-
13:57
to deliver some bit of functionality to your user.
-
14:02
You know, there's a system for every user story, right?
-
14:04
This, we call them flows for a reason.
-
14:07
And using systems models, you can help build reliably performant mobile apps.
-
14:13
But first let's simplify things a little bit, because it gets complicated.
-
14:17
Feedback and delays, we can let those happen
-
14:19
during testing and, and user acceptance and revisions.
-
14:23
So we won't worry about those in our initial modeling.
-
14:26
Which leaves us with stocks and flows.
-
14:29
So what are these things?
-
14:30
Stocks are the content that our app processes.
-
14:34
Okay, essentially buckets full of data.
-
14:37
Flows are the algorithms, or the services, or the system components,
-
14:41
or the IO operations that act on the stocks of data.
-
14:45
Think of them as pipes right, they handle the inflow of data
-
14:47
into a stock and the out flow of data out of a stock.
-
14:51
A thin pipe will take a long time to fill or
-
14:53
drain a big bucket, whereas, a collection of thick diameter pipes.
-
14:57
Can move that data much more quickly.
-
15:01
So we can model a user activity in an app as a system of stocks and flows.
-
15:06
Why?
-
15:07
The goal is to estimate the overall relative complexity of
-
15:13
each piece so that we know how it's gonna impact the overall experience of the user.
-
15:20
We can represent the complexity of data with different sizes.
-
15:23
The stocks the data we're processing are defined by the
-
15:26
size and complexity that we expect that data to have.
-
15:30
Alright, so text, a pretty small thing.
-
15:32
A text message is what?
-
15:34
A few hundred bytes.
-
15:36
It's simple, a video is gonna be big, it's gonna have a lot of inertia, it's
-
15:41
gonna take a long time to move through our app if we're doing anything to it.
-
15:44
And then something like tweets are pretty small,
-
15:48
right, but they're structured data, there's a lot
-
15:50
of meta data in there and when you go and fetch a list of Tweets from Twitter.
-
15:55
You may get hundreds or thousands of them.
-
15:57
Right?
-
15:57
That implies more work for us than just a simple block of text.
-
16:03
So we'll kind of put that in the middle as sort of a medium sized bit of data.
-
16:08
And then we represent the flows with thickness, like pipes.
-
16:12
And parallelism as multiple pipes.
-
16:15
In a, in a group.
-
16:17
So things like system API's, and data processing, and communication that
-
16:20
we orch, orchestrate, right, these are all different kinds of flows.
-
16:23
And we can size them appropriately.
-
16:26
You know, cellular connections, especially when
-
16:28
you're on marginal, or 3G, or whatnot.
-
16:31
They're really small, right?
-
16:32
You can sometimes get three, maybe four concurrent network operations in place
-
16:38
before things really start to collapse and they can take a long time.
-
16:41
Lot of latency.
-
16:41
File I/O, kind of in the middle, right?
-
16:46
Writing to a file can be pretty quick, but you can't do
-
16:49
a lot of it at the same time or you start thrashing.
-
16:51
And then CPU well, you know, these chips
-
16:55
that we have these days can be pretty fast.
-
16:57
So, you know, we'll model a four core CPU as
-
16:59
something with a lot of ability to more data thru it.
-
17:02
So let's deconstruct a simple user flow.
-
17:06
The act of taking and tagging and sharing a photo, something that a lot of apps do.
-
17:11
In this flow the user takes a picture, adds a title, selects a
-
17:15
place where they are, and then shares it to a website or something.
-
17:20
All right, but there's a lot more going on underneath this.
-
17:22
In there you know, you're gonna use a
-
17:24
GPS to get your location, we're gonna connect out
-
17:27
to Foursquare to get a list of the places
-
17:29
so the user doesn't have to type everything in.
-
17:31
We're gonna maybe apply an image processing filter to the photo and then
-
17:35
you've got to upload it which we know could take a long time intuitively.
-
17:40
So the stocks in this case, right, you've got the title of the photo,
-
17:43
you've got the place name, those are small things, the image could be pretty big.
-
17:48
And then this place list, right as I was saying you know,
-
17:50
that structured data, you could get a hundred places back from the API.
-
17:54
So we'll make that kind of a medium sized thing.
-
17:58
And then the flows.
-
17:59
All right, again the flows are the ways we move that data through our application.
-
18:02
So there's camera access, which.
-
18:06
Is sometimes kinda bulky and slow, but usually
-
18:10
not too bad, especially on a newer phone.
-
18:12
GPS takes a long time to lock, right?
-
18:14
And so remember that the thicker this pipe, the faster it's gonna execute.
-
18:19
Place look-up is a network request, could take a little while, but it's
-
18:23
a small amount of data and, you know, Foursquare tends to be pretty quick.
-
18:27
Image processing, well we've got the whole CPU and we've probably
-
18:30
got a system library already that's pretty optimized for doing that.
-
18:33
And then the image upload again, probably gonna take a while because
-
18:37
it's a big image trying to move it over a slow cell connection.
-
18:42
So when you put all that together this is what our image sharing flow looks like.
-
18:48
Right?
-
18:48
I know some of you heard the phrase image processing and
-
18:50
you immediately started thinking like oh man, that's gonna take a while.
-
18:52
We're gonna have to work on that.
-
18:54
And it might.
-
18:54
Right?
-
18:55
But is that the right thing to focus on first?
-
18:58
Let's first start by improving this map.
-
19:01
Right?
-
19:02
And make it easier to reason with.
-
19:03
What I want is more like a visual timeline.
-
19:06
That gives me a reference check for how long this stuff is gonna take.
-
19:10
So we'll do a little research and measure you know, how long
-
19:12
does it take for a camera to start up on the phone.
-
19:14
How long does the GPS lock take under different scenarios?
-
19:18
And then i'll pencil in approximations for how long those
-
19:21
things will take and scale the widths of those flows accordingly.
-
19:26
All right, and what I realize is that this
-
19:28
is a really long, slow, and frustrating process for someone.
-
19:33
And I won't stand here and act out the whole
-
19:35
minute and a half of it cuz then you'll just leave.
-
19:37
Or beat me up.
-
19:38
[BLANK_AUDIO]
-
19:39
so, I've proven that this user experience is probably gonna suck.
-
19:45
Right.
-
19:45
The good news is we've done that in ten minutes
-
19:47
instead of going out and writing code for ten hours.
-
19:50
But then what do we do, right?
-
19:53
So I can quickly look at the model
-
19:56
and start reasoning through the trouble spots, right.
-
19:58
The image is big, it's way at the
-
20:00
beginning of this flow, that means I'm gonna have
-
20:02
to move it through a lot of parts in
-
20:03
my application and it's gonna take a long time.
-
20:06
But I also need to pay attention to that places list.
-
20:09
It's gonna take a while to get that on to the phone.
-
20:11
Off of the network and the GPS and the upload flows are gonna take a long time.
-
20:16
And in this case you know, I don't really need to
-
20:20
worry about this image processing step cuz I can barely see it.
-
20:25
Even though it's half a second.
-
20:26
All right, it's not the low hanging fruit in this case.
-
20:30
So now that I can visually reason about the system I can start improving it.
-
20:36
How do I do that?
-
20:37
The system model makes it easy to map out the dependencies in this flow.
-
20:41
So let's break it down into dependency chains and
-
20:44
start seeing how the different parts of this flow interact.
-
20:49
first, there's the image pipeline, which I'll code in blue.
-
20:51
And I apologize if anyone is color blind.
-
20:55
And if we had some of those cool color blind-correcting glasses
-
20:58
they were talking about this morning, I would hand them out.
-
21:02
We've got the camera, the image
-
21:03
processing, the uploading of that data, right?
-
21:05
Those all have to happen in order.
-
21:07
So they are dependent on each other and they're operating on that big blob
-
21:11
of image data so i worry about that whole chain taking a long time.
-
21:14
Then there is the place selection process.
-
21:17
Which i'll code in green here.
-
21:20
You've go the GPS and the Four Square
-
21:21
requests and those have to happen one after another.
-
21:23
And then the user can't actually pick a location.
-
21:27
Until we have that stuff.
-
21:31
And the photo title can stay off by itself because
-
21:33
that's just gonna be a text box that someone types in.
-
21:36
So by separating these out into
-
21:38
independent sub-processes, I can start optimizing things.
-
21:42
In fact, I may be able to start some things,
-
21:44
like the GPS, before the user even enters this flow.
-
21:48
Right, you can start getting a GPS lock as soon as they
-
21:51
launch the app, and because of the way people use apps it's
-
21:54
more than likely that you know, if they don't actually share anything,
-
21:59
okay, you know, we got a GPS lock, and throw it away.
-
22:02
If they do share something they're not gonna have moved very far from
-
22:05
where they fired up the app 'cause they'll close the app in the meantime.
-
22:09
If they're actually going to a different place.
-
22:12
So in this process, we've also discovered some hidden dependencies, right?
-
22:16
There are stocks of data that are orphaned in this flow, right?
-
22:19
The title and the location don't have any way of getting up to our server.
-
22:25
So, with a system model its easy to reason about those and I can add a
-
22:29
couple of little short upload requests to make
-
22:32
sure that data hits the server or I can
-
22:34
go one step better and bundle the title in with the place name and do one network
-
22:38
request that does both of those things and
-
22:40
initiates the share if the image is already uploaded.
-
22:44
And something magical just happened here.
-
22:47
That I didn't even anticipate the first time I went through this process.
-
22:51
Because we just defined the server API that our app
-
22:54
needs in order to share a photo with your friends.
-
22:58
Right?
-
22:59
We didn't have to think about it, it just happened,
-
23:02
because we can see which data goes into which network request.
-
23:05
And when it's gonna hit the server in the life cycle of this.
-
23:10
So, this isn't always a necessary process.
-
23:14
Right?
-
23:14
You're an experienced software developer, you can probably figure
-
23:17
out most of the bottlenecks in this image sharing flow.
-
23:21
But not all performance problems will show up in a model like this.
-
23:25
But our brains are really not good
-
23:28
at thinking about and reasoning about software performance.
-
23:32
It's, it's really easy to build software with emergent
-
23:34
properties that are so complex no one sees them coming.
-
23:38
And your user stories may be more complex than you will.
-
23:42
You know, than you think and as they get more and more
-
23:44
complicated you're less and less likely to anticipate where the problems are.
-
23:51
So this, this is, I call this story my coffee debugging story.
-
23:55
I was building a mobile app that had a you know, friends feature in it and what
-
24:01
we decided to do was use Facebook Connect
-
24:03
for our directory list so you'd log into Facebook.
-
24:06
And the app would pull down all of your friends, and then it
-
24:08
would make sure that it had a local cache of all those cache.
-
24:11
All right?
-
24:12
And spend a bunch of time optimizing the,
-
24:15
the database I/O and all of that process, right?
-
24:18
So that you log in, the app goes and fetches your current friends
-
24:22
list from Facebook, see if there's any
-
24:24
changes to people, like, they've, you know,.
-
24:26
People have been removed or added or they have a new, like, picture or whatever.
-
24:30
Right?
-
24:30
And we synced all those changes to the little database on
-
24:33
the phone and then went about your business of doing stuff.
-
24:37
And because we knew that it could take time to go out
-
24:40
and fetch your friend's list and process that, it happened in the background.
-
24:44
And the only part of the app that didn't work until
-
24:46
that was done was the send a message to someone feature, right?
-
24:50
That just, we decided to have that sort of disabled until that process was complete.
-
24:56
Cuz we wanted to make sure you were up to date on who you could send a message to.
-
25:00
So what happened?
-
25:02
We did this app it was really cool, we had a bunch of beta testers.
-
25:05
One of them was this really important guy in
-
25:07
San Francisco, who was really excited about the project.
-
25:11
One day he called me up and he was like, hey this app sucks.
-
25:15
And I'm like, what do you mean?
-
25:16
Well, the first time I installed it and run it, it's great.
-
25:19
But then I close and I run it again and I can't share a message for like 45 seconds.
-
25:25
And that's stupid because the whole point is like I wanna send someone something.
-
25:31
So we did the like, okay, uninstall it, reinstall it.
-
25:35
First time great, after that.
-
25:37
Took forever.
-
25:38
okay, log out, log back in, right?
-
25:40
Nothing worked, and we did some server side data
-
25:42
logging and I even sent him, like, an app build
-
25:45
that was, had all of this custom instrumentation in it
-
25:48
and it would send me logs of everything that happened.
-
25:51
And it turned out yeah, it was taking like 45 seconds.
-
25:54
It wasn't taking 45 seconds to go and get data from Facebook, that was really quick.
-
25:59
Right, it was taking like 45 seconds after it had his friends list before
-
26:04
it would unlock the share feature and I happen to be flying down to San
-
26:09
Francisco to do some other stuff so I called him up, I'm like hey can
-
26:12
we just get together and maybe look at your phone and I'll figure something out.
-
26:16
And so that's exactly what we did, right?
-
26:18
Flew down to San Francisco, did stuff, texted him a bunch.
-
26:21
We figured out a time when we could meet.
-
26:23
Met at a coffee shop, sat down, I plugged his
-
26:26
phone into my laptop, fired up the app, and boom.
-
26:28
The answer was right there in front of my face.
-
26:31
Then I turned to him and I said so.
-
26:36
How many Facebook friends do you have?
-
26:37
What do
-
26:40
you think?
-
26:40
Guesses?
-
26:44
10,000?
-
26:46
That's a pretty good guess.
-
26:47
10,000 friends on Facebook.
-
26:51
I didn't know it was possible, but apparently it is.
-
26:54
And so you know it turns out that statistically if you have 10,000 friends
-
27:00
on Facebook, every hour there's gonna be hundreds of profile updates
-
27:06
from all those people and so every time he launched that app
-
27:10
it was going and getting a summary of all of his Facebook friends.
-
27:13
And then the app was sitting there going, well I got 300 friends, I've got
-
27:17
to synchronize I'll insert an update, insert
-
27:20
an update, insert an update, insert an update.
-
27:23
Right and those were like, they were pretty fast.
-
27:25
You know, we were really proud of our 50 millisecond, like record
-
27:28
update speed on that stuff, cuz that stuff can be really hard.
-
27:32
But there was no way to do that at the
-
27:35
scale that this particular user's data was talking about, right?
-
27:38
And that was the catch, was we just didn't
-
27:40
realize the complexity of the data that we were handling.
-
27:44
So, you know, fixing this wasn't that hard.
-
27:47
We were like.
-
27:47
Well.
-
27:48
It's really fast to just insert a bunch of bold records,
-
27:51
so why don't we delete everything that's changed and reinsert it, right?
-
27:54
And it went down to like a half second.
-
27:56
Great.
-
27:57
But that on top of like pissing off this beta tester and flying
-
28:02
to San Francisco and spending an hour in traffic and all of that.
-
28:06
Not the best time.
-
28:08
And so the point is that you really, you'd
-
28:10
never know where you're gonna get hung up and
-
28:13
it can be the stupidest things, but unless you're
-
28:16
modeling out like it's, it's like risk modeling, right?
-
28:19
This bucket, well, you know, it's my Facebook friend's
-
28:22
list so it's kinda structured and it's small, except
-
28:24
that like you know, some people have a lot
-
28:26
of friends, so maybe we should make it big, right?
-
28:28
Then it's up there, with like, the videos and
-
28:32
other big chunks of data that your app is
-
28:34
gonna have to move around, and it shows up on the map, and it's easy to reason about.
-
28:37
And you can say, huh.
-
28:39
This could be something we need to worry about.
-
28:41
[BLANK_AUDIO]
-
28:44
So, the practice also leads to a lot of awesome stuff.
-
28:47
We saw that it makes API design easy.
-
28:49
Because you can see what things need to hit your API at the
-
28:52
same time and what things need be different and if there's two things
-
28:56
running in parallel, you know, you gotta figure out how to trigger the
-
28:58
right server side action after the second one lands, whichever one that might be.
-
29:03
All right, and that's not an easy problem but even knowing
-
29:06
that you have that problem can be hard to find out.
-
29:09
But what about other things?
-
29:10
What about fault tolerance?
-
29:11
Right?
-
29:11
Modeling what happens if a network request fails.
-
29:14
What do I do then?
-
29:16
Or working out the dependency analysis for complex activities.
-
29:19
Right?
-
29:19
Or you know, you can compare these.
-
29:21
Right?
-
29:21
You can take this and you can resize
-
29:24
things to look at the range of possibilities, right?
-
29:28
I could look at a Nexus 5 CPU VS a 3
-
29:31
year old you know little throw away android phone and say.
-
29:36
Hm, these pipes are a lot smaller on an older device I better think about how that
-
29:42
data is gonna get out of that particular
-
29:44
stock and through the rest of the user flow.
-
29:48
And once you have that complexity and the
-
29:49
performance modeled down to the component level, you can
-
29:53
wander down all these great avenues of thinking
-
29:55
about how to arrange things and orchestrate that, right.
-
29:59
And create the dance that makes people happy to use your app.
-
30:02
[BLANK_AUDIO]
-
30:11
Hm.
-
30:11
Technical failure.
-
30:12
[LAUGH] Too much fancy stuff.
-
30:17
So to summarize, you'll begin with the user stories, right?
-
30:21
Begin with the things that describe how your app is going to work.
-
30:25
What it's going to do.
-
30:26
And every designer I know sits there and hammers into me, like you need to do
-
30:31
user-centric design before you start writing any code, or designing screens.
-
30:36
And then model the stocks and the flows in each of those user interactions.
-
30:43
And identify the data and the processes that are gonna happen to them in a way
-
30:46
that allows you to visually reason with them
-
30:49
easily, rather than keeping it all in your head.
-
30:53
And then finally focus on understanding and accommodating
-
30:56
the very ability that's inherent in those systems.
-
30:59
So once you've done that.
-
31:01
Once you've reduced the variability, accommodated it
-
31:05
and created something that's really awesome, then
-
31:07
you can start poking the app with a stick when you need to, right?
-
31:11
You may find that yeah, we're really allocating too
-
31:14
many objects and we're gonna have to create an
-
31:15
object pool or, you know, we've got all of
-
31:18
these thread synchronization problems that are stalling things out.
-
31:21
We're gonna have to re-architect that internal code.
-
31:23
But until you've gotten rid of the concerns about unknown variance,
-
31:29
that's all just you know, you're, you're just optimizing the mess.
-
31:33
Right.
-
31:36
And if you find this systems theory stuff
-
31:38
interesting, I cannot recommend this book highly enough.
-
31:41
Thinking in Systems by Donna Meadows.
-
31:44
Its a really quick read and it will make you start seeing systems everywhere.
-
31:50
Literally everywhere.
-
31:51
Everything from pollution, to traffic to software engineering to why
-
31:55
the executives at your company do the things they do.
-
31:59
It all comes out of this systems modeling stuff.
-
32:03
And then, we get to the feedback part.
-
32:05
I would really love to hear whether this is something that helps you out.
-
32:09
Cause as I said it's a pretty new idea in my head, I'm really excited about it.
-
32:13
yeah, I hope it's gonna be a great thing.
-
32:18
And so, thank you very much.
-
32:20
We obviously have a little bit of time extra,
-
32:22
so any questions, thoughts, complaints about mobile app development?
-
32:27
[BLANK_AUDIO]
-
32:32
Yeah?
-
32:36
Hm?
-
32:37
All right.
-
32:40
No thumbs down.
-
32:40
[SOUND] That's excellent.
-
32:43
Thank you very much.
You need to sign up for Treehouse in order to download course files.
Sign up