3 ms·

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

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?
- vvanders 9y ago
  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
- on_and_off 9y ago
  Battery life has been a major focus 2 or 3 iterations of Android ago. Google released the tool they created in order to benchmark it (battery historian). btw, releasing the tool they created for a specific improvement is what they do each time they focus on improving one aspect of the platform, and that's an excellent practice. Google probably cares to some extent about battery life. I doubt that the mobile team behind let's say Youtube cares, but the framework team does. Third party devs tend to do not worry at all about battery life .. unless they use a really excessive amount of battery and are shamed for it

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?

vvanders 9y ago
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
on_and_off 9y ago
Battery life has been a major focus 2 or 3 iterations of Android ago. Google released the tool they created in order to benchmark it (battery historian). btw, releasing the tool they created for a specific improvement is what they do each time they focus on improving one aspect of the platform, and that's an excellent practice. Google probably cares to some extent about battery life. I doubt that the mobile team behind let's say Youtube cares, but the framework team does. Third party devs tend to do not worry at all about battery life .. unless they use a really excessive amount of battery and are shamed for it