7 ms·

AsyncDisplayKit – iOS framework that keeps complex user interfaces responsive

80 points by robert-boehnke 12y ago

ratsimihah 12y ago
Doesn't seem available either on Github or Cocoapods yet.
- spicyj 12y ago
  The GitHub page is up now.
  - ratsimihah 12y ago
    Thanks!
- ScottGoodson 12y ago
  Cocoapod should also be up now.
ryandrake 12y ago
On Safari, the entire site seems to have no content and just re-directs to itself in a loop over and over: meta http-equiv="refresh" content="0; http://asyncdisplaykit.org" http://asyncdisplaykit.org"
- jamesgpearce 12y ago
  it's now launched; thanks for your patience :)
jamesgpearce 12y ago
Full blog post announcing the framework is here: https://code.facebook.com/posts/721586784561674/introducing-asyncdisplaykit-for-smooth-and-responsive-apps-on-ios/ https://code.facebook.com/posts/721586784561674/introducing-...
ortuman 12y ago
Awesome stuff, though it's a pity autolayout cannot be used along with this framework. Anyway, it's worth to take a look.
- johnymontana 12y ago
  No autolayout? Sounds like a feature, not a bug...
- mazerackham 12y ago
  Seriously, is autolayout actually used by a lot of people? I tried doing something semi-complex a few weeks back and I spent hours fighting with it. Then I spent 10 minutes writing 10 lines of code and it worked. When you finally grok it, does it become worth it?
  - smackfu 12y ago
    Well, it's certainly encouraged by Apple, and it's getting to the point where they aren't interested that "supporting all these sizes without using AutoLayout is hard."
  - orbitur 12y ago
    How do you optimize for 3 different device sizes? Hardcoding it?
    - archagon 12y ago
      You can perform manual layout in the layoutSubviews method of any UIView. Simply calculate your positions with the current view size in mind, looking up the Size Class if necessary. (And don't use exact pixel positions, obviously.)
      - orbitur 12y ago
        I know you can do that, but it just seems like less work and better results to set the proper constraints in IB.
zackmorgs 12y ago
I'll be using this, but Facebook Paper runs awful on older devices. Just my experience.
rgbrgb 12y ago
Very cool! This bears quite a resemblance to the way React.js constructs a virtual DOM so that it can optimize drawing. Do you guys have a way you're benchmarking performance improvements? Are you just looking at time spent on the main thread?
- ScottGoodson 12y ago
  Yes, there is a broad similarity: abstracting away from performance or threading limitations of common UI building blocks. However, React has a declarative, single-directional data flow model. AsyncDisplayKit is imperative. Declarative code is great for a lot of things, but interactivity and animations are definitely not one of them. Also, ASDisplayNode was designed to be as similar as possible to UIView (also imperative). We don't have a benchmark suite, largely because it is so easy to use Instruments to do CPU traces and look for any chunks of main thread work that threaten frame drops.
LeoNatan25 12y ago
The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to another). Sometimes this is more acceptable but often it is not. If you played with Paper, and felt it was "floaty", now you know why. If it didn't bother you, I guess you are less sensitive to this. Not to say this library is useless, like most things, when not abused, good can come from it.
- ScottGoodson 12y ago
  Curious to better understand what you mean—in my experience, this is not true at all. All touches / gesture handling are direct manipulation with no delays at all. All the asynchronously-prepared content is rendered in advance with a large offscreen buffer, so in general it should be done rendering before it's onscreen. In the cases where you scroll really fast and get to something that hasn't finished rendering, the alternative in a regular app architecture is to simply stutter (block the UI) until it's done rendering. This framework can be used in very flexible ways, such as "try to render everything offscreen, but if it's going to come onscreen and hasn't finished yet, block and wait for it to be done". Even that approach will result in a much more responsive feel while ensuring that you have the same guarantees as a synchronous UI about content being finished rendering when it is visible.
ldn_tech_exec1 12y ago
Would it be possible to build an alternative to AutoLayout that works with AsyncDisplayKit? How could it this be done?
coldcode 12y ago
I have no desire to layout everything in code (I know some people like this, I don't) so it's not very interesting to me. It would seem to require you to write your app in a completely different way. I wonder what debugging would be like with it, given that threaded code is always more painful. It might be more interesting once people release actual apps with it (outside of FB).
- tsycho 12y ago
  Most iOS UI at Google is laid out in code as well. It makes it much easier to review code, see diffs, and have multiple people working on the same part of the app without causing crazy merge conflicts.
  - acmecorps 12y ago
    Yeah. I acknowledged that storyboard is easier and faster for simple to moderate UI, but merging using git/vcs is horrible. Plus, it's difficult to build cool animations with those.
cmyr 12y ago
It's really neat to see facebook's iOS team releasing so much of their work. This framework is probably not going to be that relevant to tons of use-cases, but even if you'll never use it you'll probably get a lot out of looking at it closely and thinking about why it makes the decisions it does.

Doesn't seem available either on Github or Cocoapods yet.

spicyj 12y ago
The GitHub page is up now.
- ratsimihah 12y ago
  Thanks!
ScottGoodson 12y ago
Cocoapod should also be up now.

On Safari, the entire site seems to have no content and just re-directs to itself in a loop over and over: meta http-equiv="refresh" content="0; http://asyncdisplaykit.org" http://asyncdisplaykit.org"

jamesgpearce 12y ago
it's now launched; thanks for your patience :)

jamesgpearce 12y ago

Full blog post announcing the framework is here: https://code.facebook.com/posts/721586784561674/introducing-asyncdisplaykit-for-smooth-and-responsive-apps-on-ios/ https://code.facebook.com/posts/721586784561674/introducing-...

ortuman 12y ago

Awesome stuff, though it's a pity autolayout cannot be used along with this framework. Anyway, it's worth to take a look.

johnymontana 12y ago
No autolayout? Sounds like a feature, not a bug...
mazerackham 12y ago
Seriously, is autolayout actually used by a lot of people? I tried doing something semi-complex a few weeks back and I spent hours fighting with it. Then I spent 10 minutes writing 10 lines of code and it worked. When you finally grok it, does it become worth it?
- smackfu 12y ago
  Well, it's certainly encouraged by Apple, and it's getting to the point where they aren't interested that "supporting all these sizes without using AutoLayout is hard."
- orbitur 12y ago
  How do you optimize for 3 different device sizes? Hardcoding it?
  - archagon 12y ago
    You can perform manual layout in the layoutSubviews method of any UIView. Simply calculate your positions with the current view size in mind, looking up the Size Class if necessary. (And don't use exact pixel positions, obviously.)
    - orbitur 12y ago
      I know you can do that, but it just seems like less work and better results to set the proper constraints in IB.

zackmorgs 12y ago

I'll be using this, but Facebook Paper runs awful on older devices. Just my experience.

rgbrgb 12y ago

Very cool! This bears quite a resemblance to the way React.js constructs a virtual DOM so that it can optimize drawing. Do you guys have a way you're benchmarking performance improvements? Are you just looking at time spent on the main thread?

ScottGoodson 12y ago
Yes, there is a broad similarity: abstracting away from performance or threading limitations of common UI building blocks. However, React has a declarative, single-directional data flow model. AsyncDisplayKit is imperative. Declarative code is great for a lot of things, but interactivity and animations are definitely not one of them. Also, ASDisplayNode was designed to be as similar as possible to UIView (also imperative). We don't have a benchmark suite, largely because it is so easy to use Instruments to do CPU traces and look for any chunks of main thread work that threaten frame drops.

LeoNatan25 12y ago

The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to another). Sometimes this is more acceptable but often it is not. If you played with Paper, and felt it was "floaty", now you know why. If it didn't bother you, I guess you are less sensitive to this. Not to say this library is useless, like most things, when not abused, good can come from it.

ScottGoodson 12y ago
Curious to better understand what you mean—in my experience, this is not true at all. All touches / gesture handling are direct manipulation with no delays at all. All the asynchronously-prepared content is rendered in advance with a large offscreen buffer, so in general it should be done rendering before it's onscreen. In the cases where you scroll really fast and get to something that hasn't finished rendering, the alternative in a regular app architecture is to simply stutter (block the UI) until it's done rendering. This framework can be used in very flexible ways, such as "try to render everything offscreen, but if it's going to come onscreen and hasn't finished yet, block and wait for it to be done". Even that approach will result in a much more responsive feel while ensuring that you have the same guarantees as a synchronous UI about content being finished rendering when it is visible.

ldn_tech_exec1 12y ago

Would it be possible to build an alternative to AutoLayout that works with AsyncDisplayKit? How could it this be done?

coldcode 12y ago

I have no desire to layout everything in code (I know some people like this, I don't) so it's not very interesting to me. It would seem to require you to write your app in a completely different way. I wonder what debugging would be like with it, given that threaded code is always more painful. It might be more interesting once people release actual apps with it (outside of FB).

tsycho 12y ago
Most iOS UI at Google is laid out in code as well. It makes it much easier to review code, see diffs, and have multiple people working on the same part of the app without causing crazy merge conflicts.
- acmecorps 12y ago
  Yeah. I acknowledged that storyboard is easier and faster for simple to moderate UI, but merging using git/vcs is horrible. Plus, it's difficult to build cool animations with those.

cmyr 12y ago

It's really neat to see facebook's iOS team releasing so much of their work. This framework is probably not going to be that relevant to tons of use-cases, but even if you'll never use it you'll probably get a lot out of looking at it closely and thinking about why it makes the decisions it does.