Is Jetpack Compose suitable for POS devices like t...
# compose
m
Is Jetpack Compose suitable for POS devices like the PAX A920 or A35? I developed an application that runs smoothly on my Android 10 phone, but when testing it on these devices A920 or A35 (which have only 1GB RAM), I encounter significant rendering issues, lag, and skipped frames. Has anyone else experienced similar problems on low-spec POS hardware? or i need to shipped to XML?
👀 1
j
Are you testing a release APK? Are you running R8?
z
have you profiled to find out if the long frames are due to your own code, if you're allocating too much, etc.?
r
@Zach Klippenstein (he/him) [MOD] Compose allocates too much 😝
m
@jw Yes , Same issue
@Zach Klippenstein (he/him) [MOD] I’m not running any high-performance tasks—just testing with a bottom navigation bar and three simple screens with basic buttons. Despite that, it’s causing lag issues. I believe the main reason is that 1 GB of RAM isn’t sufficient for this setup. I might need to switch back to using XML instead.
@romainguy Yes, every simple composeable taking too much memory that an other logs that I can see.
Can any senior guide me this is POS app that need to deliver in next month, can I move to XML that may be right decision for me?
r
The problem is not the ram. The A920 runs a Cortex A7. That's a 14 years old CPU, still 32 bits
m
Thanks for each information, could suggest me solution or better approach ?
r
And the A35 uses a cluster of Cortex A53 CPUs, which are usually the "little" cores used for power savings in phones, not the main cores.
So yeah in your case I'd stick to XML/Views
✔️ 1
👀 1
m
@romainguy Thanks again, I do prefer your approach to convert it into XML. ♥️
n
You’ll likely get better performance and smoother rendering with traditional XML Views on such devices.
With constraints layout
j
I’ve been working with POS devices, and based on my experience, Jetpack Compose can be noticeably slow in debug mode, specially on lower-end hardware. I recommend testing it with a release build instead. the performance is significantly better and the rendering issues are often reduced
🧵 2
n
yes you are right
z
That’s true for basically any device, debug builds of compose UI apps are almost always gonna be janky.
m
I also try on release mode.
I didn’t experience any lag or frame drops on the Samsung Note 9, whether in debug or release mode, as it has sufficient storage. The issues only occurred on Cortex-A7 devices, as @romainguy mentioned Sach informative info.
j
Why would XML perform better than Compose on lower end devices? I thought both use the same SKIA APIs to submit drawing commands to the GPU.
m
Cortex-A7 - CPU 32 bit has a limited cache and slower instruction processing, which means : • Interpreting and executing Compose logic is slower than simple XML rendering Most of this happens on the main thread, which causes frame drops and UI lag. XML (View-based (imperative)) Renderding . Compose (Declarative) required GPU also.
r
@Jonathan It's not a GPU problem but a CPU one (although GPU could be an issue too on those devices, but I doubt it).
j
What makes Compose CPU heavy compared to XML?
r
It's a question with a long answer, but basically the View system was written for low-powered devices and goes to great lengths to micro-optimize a lot of things (down to avoiding method calls, allocating as little as possible, avoiding abstractions, etc.)
j
Ahh, the age-old Android motto of not allocating during
draw(Canvas)
and the like.. Was/is this something the Compose team are working towards as well?
r
A lot of optimizations went into Compose over the past couple of years, see:
image.png
❤️ 1