5 ms·

Multithreaded rendering on Android

87 points by dowhileone 9y ago

rapsey 9y ago
So FB mixes this and react native in their app?
- dowhileone 9y ago
  We use both at Facebook! React Native works cross platform whereas Litho provides performance that beats the Android Toolkit - so they are each beneficial for different use cases. Litho is heavily inspired from RN so the programming model should be familiar.
- s73ver_ 9y ago
  If I remember right, this was created before React Native. And, they still do have a lot of Android code in the app, even with RN.
binthere 9y ago
This is really nice, but it would be good if they could release some metrics for their example such as the News Feed. How much did it improve the scroll performance? The main reason is because I'd like to know if the extra complexity is worth the effort. I'm sure that from Facebook scale any improvement is important but how good is it? It is mentioned in the article that Android documentation does not recommend doing multithreading optimizations since the UI Toolkit itself is not thread-safe, does this mean that Android's own UI Toolkit cannot be used within this context? What is the level of integration that Litho and Android's UI Toolkit can have? Also, in regards to Android's Accessibility APIs, does Litho components handle/have that capability? I guess I should have done a bit more research/experimentation on Litho, but these are some questions I have. I'd really love to use it though.
- BoorishBears 9y ago
  For the record, I prefer Litho regardless of performance characteristics. The immutable data model works really well with AutoValue, which in turn works well with lots of things in Android and I find the API a lot cleaner than the default RecyclerView API (there are alternative Adapter implementations for RecyclerView that bring it's API closer to Litho)
  - sandGorgon 9y ago
    what alternative adapter implemntations are there ? could you cite anything ?
    - BoorishBears 9y ago
      Airbnb's Epoxy is the best one I've used: https://medium.com/airbnb-engineering/epoxy-airbnbs-view-architecture-on-android-c3e1af150394 https://medium.com/airbnb-engineering/epoxy-airbnbs-view-arc... https://github.com/airbnb/epoxy https://github.com/airbnb/epoxy
    - deleted 9y ago
      [deleted]
- dowhileone 9y ago
  > How much did it improve the scroll performance? We are still have some more work to do in News Feed but on other surfaces in the app we have seen a 42% improvement in skipped frames when converting from Views to Litho. This is measured by sampling skipped frames while scrolling in production. > does this mean that Android's own UI Toolkit cannot be used within this context? Views should not be accessed on a background thread according to the Android documentation. Litho renders inside of a light weight wrapper view and interacts with this wrapper view on the UI thread. Nevertheless, Litho moves most of the heavy lifting from rendering to the background. > What is the level of integration that Litho and Android's UI Toolkit can have? During the conversion to Litho, News Feed rendered with some standard views and some Litho >in regards to Android's Accessibility APIs, does Litho components handle/have that capability? Yup! It's a full featured UI framework. Animations are under active development though.
sandGorgon 9y ago
Are there any examples of how to convert an existing project to Litho ?
- lucasr 9y ago
  We've been doing a lot of that at Facebook and we do want to document this process a bit better. Stay tuned :-)
vvanders 9y ago
Erm, android already does multi-threaded rendering via HWUI[1] at the Canvas level. What they're talking about doing here is multi-threaded layout which isn't nearly that impressive. Heck, you can call measure()/layout() off-thread right now on views, there's just an invalidate when they get inserted into the hierarchy. Also something not mentioned is that each CPU core you spin up is eating into XX% of your battery life. So you may get a faster layout but your users may see worse battery usage because of it. [1] - https://android.googlesource.com/platform/frameworks/base/+/android-6.0.0_r41/libs/hwui/renderthread/ https://android.googlesource.com/platform/frameworks/base/+/...
- yslak 9y ago
  That is not correct. There is only one HWUI render thread per app. HWUI doesn't use multithreaded rendering. You can verify this easily running "ps -t".
  - vvanders 9y ago
    Yup, but it's different from the UI thread which is what counts for me. For what it's worth unless you're on Vulkan(which few Android devices support) you're going to be limited to a single dispatch thread by GLES' threading semantics anyway. I still rest my point that they're doing layout, which is fine but doesn't consist of multi-threaded rendering. Using their approach they're still going to have to set some sort of absolute layout views which must go through a measure and layout pass on the UI thread.
  - kllrnohj 9y ago
    HWUI does have 2 helper threads that it uses to off-load some work (hwuiTask1 & 2). But otherwise yes it's largely dominated by one thread.
- xenadu02 9y ago
  Indeed, moving to multiple cores is about doing more work faster which has a direct impact on battery life. You'd have to measure whether this allows you to race-to-sleep faster or not which is a delicate balancing act. It is telling that battery life is almost never mentioned or discussed in depth anywhere. What is the battery impact of React Native? Or of this solution?
yegle 9y ago
I'm not sure if I'm the only one, but since from the recent patent grant debate, the first thing I do on a Facebook git repository is to check whether there's a PATENTS file.
TeeWEE 9y ago
The Android Framework is a bit of an old framework, not using reactive elements. Google knows this, and is building flutter a reactive UI toolkit. Also android developers are using Reactive components more and more, but the UI is still very much statefull. So i see a bright future for this approach (maybe not the facebook library, but the approach itself)
reuben_scratton 9y ago
Yet another steaming pile of overengineering, great.

87 points by dowhileone 9y ago

rapsey 9y ago

So FB mixes this and react native in their app?

dowhileone 9y ago
We use both at Facebook! React Native works cross platform whereas Litho provides performance that beats the Android Toolkit - so they are each beneficial for different use cases. Litho is heavily inspired from RN so the programming model should be familiar.
s73ver_ 9y ago
If I remember right, this was created before React Native. And, they still do have a lot of Android code in the app, even with RN.

binthere 9y ago

This is really nice, but it would be good if they could release some metrics for their example such as the News Feed. How much did it improve the scroll performance? The main reason is because I'd like to know if the extra complexity is worth the effort. I'm sure that from Facebook scale any improvement is important but how good is it? It is mentioned in the article that Android documentation does not recommend doing multithreading optimizations since the UI Toolkit itself is not thread-safe, does this mean that Android's own UI Toolkit cannot be used within this context? What is the level of integration that Litho and Android's UI Toolkit can have? Also, in regards to Android's Accessibility APIs, does Litho components handle/have that capability? I guess I should have done a bit more research/experimentation on Litho, but these are some questions I have. I'd really love to use it though.

BoorishBears 9y ago
For the record, I prefer Litho regardless of performance characteristics. The immutable data model works really well with AutoValue, which in turn works well with lots of things in Android and I find the API a lot cleaner than the default RecyclerView API (there are alternative Adapter implementations for RecyclerView that bring it's API closer to Litho)
- sandGorgon 9y ago
  what alternative adapter implemntations are there ? could you cite anything ?
  - BoorishBears 9y ago
    Airbnb's Epoxy is the best one I've used: https://medium.com/airbnb-engineering/epoxy-airbnbs-view-architecture-on-android-c3e1af150394 https://medium.com/airbnb-engineering/epoxy-airbnbs-view-arc... https://github.com/airbnb/epoxy https://github.com/airbnb/epoxy
  - deleted 9y ago
    [deleted]
dowhileone 9y ago
> How much did it improve the scroll performance? We are still have some more work to do in News Feed but on other surfaces in the app we have seen a 42% improvement in skipped frames when converting from Views to Litho. This is measured by sampling skipped frames while scrolling in production. > does this mean that Android's own UI Toolkit cannot be used within this context? Views should not be accessed on a background thread according to the Android documentation. Litho renders inside of a light weight wrapper view and interacts with this wrapper view on the UI thread. Nevertheless, Litho moves most of the heavy lifting from rendering to the background. > What is the level of integration that Litho and Android's UI Toolkit can have? During the conversion to Litho, News Feed rendered with some standard views and some Litho >in regards to Android's Accessibility APIs, does Litho components handle/have that capability? Yup! It's a full featured UI framework. Animations are under active development though.

sandGorgon 9y ago

Are there any examples of how to convert an existing project to Litho ?

lucasr 9y ago
We've been doing a lot of that at Facebook and we do want to document this process a bit better. Stay tuned :-)

vvanders 9y ago

Erm, android already does multi-threaded rendering via HWUI[1] at the Canvas level. What they're talking about doing here is multi-threaded layout which isn't nearly that impressive. Heck, you can call measure()/layout() off-thread right now on views, there's just an invalidate when they get inserted into the hierarchy. Also something not mentioned is that each CPU core you spin up is eating into XX% of your battery life. So you may get a faster layout but your users may see worse battery usage because of it. [1] - https://android.googlesource.com/platform/frameworks/base/+/android-6.0.0_r41/libs/hwui/renderthread/ https://android.googlesource.com/platform/frameworks/base/+/...

yslak 9y ago
That is not correct. There is only one HWUI render thread per app. HWUI doesn't use multithreaded rendering. You can verify this easily running "ps -t".
- vvanders 9y ago
  Yup, but it's different from the UI thread which is what counts for me. For what it's worth unless you're on Vulkan(which few Android devices support) you're going to be limited to a single dispatch thread by GLES' threading semantics anyway. I still rest my point that they're doing layout, which is fine but doesn't consist of multi-threaded rendering. Using their approach they're still going to have to set some sort of absolute layout views which must go through a measure and layout pass on the UI thread.
- kllrnohj 9y ago
  HWUI does have 2 helper threads that it uses to off-load some work (hwuiTask1 & 2). But otherwise yes it's largely dominated by one thread.
xenadu02 9y ago
Indeed, moving to multiple cores is about doing more work faster which has a direct impact on battery life. You'd have to measure whether this allows you to race-to-sleep faster or not which is a delicate balancing act. It is telling that battery life is almost never mentioned or discussed in depth anywhere. What is the battery impact of React Native? Or of this solution?

yegle 9y ago

I'm not sure if I'm the only one, but since from the recent patent grant debate, the first thing I do on a Facebook git repository is to check whether there's a PATENTS file.

TeeWEE 9y ago

The Android Framework is a bit of an old framework, not using reactive elements. Google knows this, and is building flutter a reactive UI toolkit. Also android developers are using Reactive components more and more, but the UI is still very much statefull. So i see a bright future for this approach (maybe not the facebook library, but the approach itself)

reuben_scratton 9y ago

Yet another steaming pile of overengineering, great.