00:01 Facebook has had to change themselves to think of a mobile engineering company first. We'll talk about how we made that journey. 02:03 Two talks today: 1) How we scaled broadly on Android 2) A small team creating Paper app for iOS 03:00 We couldn't keep up developing mobile features fast enough. Now at FB we don't have a mobile engineering team -- mobile engineering is in all of our product teams. 07:03 Jenny Yeun will talk about 1) coding at scale and 2) releasing to the world. 07:45 The app was very unstable and crashed a lot so we enforced two things: 1) use testing to avoid brittle code 2) break dependencies amongst teams 08:50 We introduced dependency injection. This encourages modularity, testability, and scalability. 11:38 You might have heard that dependency injection causes a performance problem. We can create all the dependencies upon initialization of the app but this can take some non-trivial amount of time. A different way is to hard code these dependencies at compile time. This is much faster. 17:40 Our release process and what happens after release. We have staged releases. 1) employee dogfood 2) alpha testing with 100k+ testers 3) beta testing with 1M+ testers 4) release to world 22:00 We receive a lot of data about our crashes and bugs and it's hard to sift through them. We use data analytics with natural language processing to cluster and rank our top bugs.
It's worth clarifying the feature called "rage shake" which is briefly mentioned at approx 19:00. The feature is excellent and I've seen it mentioned in other FB Developers videos. Basically, in test builds which are being dogfooded by internal Facebook employees if something goes wrong the employee using the mobile device can shake the phone or mobile device as if in a rage. The device detects this and takes metrics such as call stacks, screen shots and so on along with a bug report. The clever part about rage shake is that it means users do not need to touch the screen of the device or swap to some other app in order to record a problem thus avoiding potential interference with the app being tested which could impact the actual problem like some sort of app version of Schrödinger's cat. A great neat idea. Kudos to Facebook.
31:30 iOS SDKs were not designed for fluid, dynamic interactions. Optimized for "fire and forget" animations. 33:20 First challenge was physics-simulating animations. We introduced Pop library for that. 33:40 But the more interesting problem was performance (e.g. dropped frames). Pop allowed these animations but they still had performance problems. 34:20 iOS SDK was designed where single core chips were the norm. So all animations and gestures are processed on the main thread. 35:15 So what causes main thread stall? 1) Text measurement & layout 2) Rendering: text, images, drawing, decoding images. 3) System objects: creating, manipulating, destroying. 38:00 We created thread-safe UI object called the Node that wraps a UIView in the same way a UIView wraps a CALayer. 43:20 Technical takeaways: 1) Don't always divide & conquer. Instead, unify & abstract. 2) Accept challenge of ambitious design 3) Don't reinvent the wheel (UIKit) as it will slow you down.
00:01 Facebook has had to change themselves to think of a mobile engineering company first. We'll talk about how we made that journey.
02:03 Two talks today: 1) How we scaled broadly on Android 2) A small team creating Paper app for iOS
03:00 We couldn't keep up developing mobile features fast enough. Now at FB we don't have a mobile engineering team -- mobile engineering is in all of our product teams.
07:03 Jenny Yeun will talk about 1) coding at scale and 2) releasing to the world.
07:45 The app was very unstable and crashed a lot so we enforced two things: 1) use testing to avoid brittle code 2) break dependencies amongst teams
08:50 We introduced dependency injection. This encourages modularity, testability, and scalability.
11:38 You might have heard that dependency injection causes a performance problem. We can create all the dependencies upon initialization of the app but this can take some non-trivial amount of time. A different way is to hard code these dependencies at compile time. This is much faster.
17:40 Our release process and what happens after release. We have staged releases. 1) employee dogfood 2) alpha testing with 100k+ testers 3) beta testing with 1M+ testers 4) release to world
22:00 We receive a lot of data about our crashes and bugs and it's hard to sift through them. We use data analytics with natural language processing to cluster and rank our top bugs.
It's worth clarifying the feature called "rage shake" which is briefly mentioned at approx 19:00. The feature is excellent and I've seen it mentioned in other FB Developers videos. Basically, in test builds which are being dogfooded by internal Facebook employees if something goes wrong the employee using the mobile device can shake the phone or mobile device as if in a rage. The device detects this and takes metrics such as call stacks, screen shots and so on along with a bug report.
The clever part about rage shake is that it means users do not need to touch the screen of the device or swap to some other app in order to record a problem thus avoiding potential interference with the app being tested which could impact the actual problem like some sort of app version of Schrödinger's cat.
A great neat idea. Kudos to Facebook.
I think the idea is already implemented in Google maps
31:30 iOS SDKs were not designed for fluid, dynamic interactions. Optimized for "fire and forget" animations.
33:20 First challenge was physics-simulating animations. We introduced Pop library for that.
33:40 But the more interesting problem was performance (e.g. dropped frames). Pop allowed these animations but they still had performance problems.
34:20 iOS SDK was designed where single core chips were the norm. So all animations and gestures are processed on the main thread.
35:15 So what causes main thread stall? 1) Text measurement & layout 2) Rendering: text, images, drawing, decoding images. 3) System objects: creating, manipulating, destroying.
38:00 We created thread-safe UI object called the Node that wraps a UIView in the same way a UIView wraps a CALayer.
43:20 Technical takeaways: 1) Don't always divide & conquer. Instead, unify & abstract. 2) Accept challenge of ambitious design 3) Don't reinvent the wheel (UIKit) as it will slow you down.