
Multithreaded rendering on Android - dowhileone
https://code.facebook.com/posts/1985913448333055/multithreaded-rendering-on-android-with-litho-and-infer/
======
binthere
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
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
what alternative adapter implemntations are there ? could you cite anything ?

~~~
BoorishBears
Airbnb's Epoxy is the best one I've used:

[https://medium.com/airbnb-engineering/epoxy-airbnbs-view-
arc...](https://medium.com/airbnb-engineering/epoxy-airbnbs-view-architecture-
on-android-c3e1af150394)

[https://github.com/airbnb/epoxy](https://github.com/airbnb/epoxy)

------
vvanders
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/+/...](https://android.googlesource.com/platform/frameworks/base/+/android-6.0.0_r41/libs/hwui/renderthread/)

~~~
xenadu02
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?

~~~
vvanders
Yup, completely.

It's a really nasty problem too because power usage isn't linear. Chips tend
to have voltage steps[1] as they increase in frequency so if you can do
something longer and at lower frequency it uses less power than the same
workload at a higher frequency for shorter time.

Compound that with the fact that you really want to bring the whole SoC to a
low power state and just keep the display lit since 90% of the time users
aren't actually moving something.

Arm has tried to solve this with big.LITTLE[2] to mixed results. It turns out
that it's hard to build a general purpose scheduler that's power aware much
like it's hard to build a general purpose memory allocator that's fast in
every case.

[1]
[https://en.wikipedia.org/wiki/Dynamic_voltage_scaling](https://en.wikipedia.org/wiki/Dynamic_voltage_scaling)

[2]
[https://en.wikipedia.org/wiki/ARM_big.LITTLE](https://en.wikipedia.org/wiki/ARM_big.LITTLE)

------
rapsey
So FB mixes this and react native in their app?

~~~
dowhileone
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.

------
TeeWEE
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)

------
yegle
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.

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

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

------
reuben_scratton
Yet another steaming pile of overengineering, great.

