#AndroidDev anybody else getting terrible battery life after the android 16 update?
24.06.2025 06:17
π 1
π 0
π¬ 0
π 0
#AndroidDev anybody else getting terrible battery life after the android 16 update?
Being able to reply like that is priceless, though
Hey Jorge, I was looking at a trace today and I wondered... In android compose, does it make sense to render the view ahead of time, as a parallel to asynchronous inflation? Let's say I keep the compose root hidden until the network data arrives. Does compose reuse views internally on android?
Halo
Pretty sure many Android devs are still around on this platform.
Reply saying hi π so everyone can find you.
This will help people find a big bunch of colleagues to follow ππ
RT this for more reach! π
Damn. Not KMP too.
At @mdevcamp.bsky.social, our own Filip DolnΓk is flipping the scriptβbringing the iOS developerβs perspective on using KMP in production. π‘
If you're an #iOSDev exploring #KMP, this is your talk.
Real talk. Real lessons. Real Kotlin on iOS.
π Prague
ποΈ June 3
π mdevcamp.eu#filip-dolnik...
... You can deal with the data in the same fashion you do now, have react read it from native, as a prop (stateless function parameter in compose). Then you can compare against a stateless compose version
It does not really make sense to go from compose to react. Compose fixes stuff affecting react, and kotlin allows to truly separate declarative UI code from everything else. So it will feel weird. Maybe try adding a RN screen/component to a compose app...
I would argue we had all that, even without Rx. The difference is, you don't need much effort to pick up coroutines, and that's their biggest selling point. JVM concurrency is powerful, but it does need lots of practice.
If Compose Multiplatform is drawing directly on iOs (like, through Core Graphics or similar), it would be more reliable, since the output would be pretty much guaranteed. If it is just repurposing SwiftUI/UIKit underneath, it would be as reliable as RN, perhaps more given the shared memory access
You live the life made for you by the person you were 10 years ago. And there is a moment when you need to invest in things that aren't your career. Nobody gets younger while time passes.
Damn that's me.
But I'd like to point out, we were using regular java libraries. It was super fun to see your code explode after swapping out from Ant to Maven.
But it was fun.
The saddest part is, that actually happens sometimes
"ship it, ship it, ship it" oriented development.
The baeldung blog would be a good starting point, it is very approachable, then you move into books and documentation.
New blog post! If you are a Kotlin or Java Android developer, this one should make you go π€―.
www.romainguy.dev/posts/2024/n...
I'm not even sorry.
throughly enjoying @astrokatie.com & @johngreensbluesky.bsky.social talking cosmology from big bang to universe's end βΊοΈ
i'm so exhausted and this is so fascinating & soothing
on YT & podcast RSS: feeds.simplecast.com/ASAdCBih
youtu.be/L5YO9nmojo4?...
JetBrains just merged my contribution to the Kotlin standard library. It's a rewrite of String.toFloatOrNull() to eliminate all allocations (~940 per call!) and go 225x faster on a Pixel 6. If you want to see how it was done: github.com/JetBrains/ko...
tl;dr regex out, hand-written parser in
The CPU profiler, The Debug class traces and custom markers are the best way to diagnose this. I'll try to take a look.
... It means your tasks are too serialized, forcing the app to wait all the time. Like a McDonalds with 10 doors and 1 cashier. Usually this points to the amount of JS callbacks. No matter the architecture, if you are running a callback from native, the others are not running.
The CPU type can play a role too. An A12 has a 4+4 CPU. Android reduces both frequency and amount of awoke cores to save up energy. So, CPUs with multicore clusters tend to underperform with single thread tasks. Try a 1+3+4 or similar CPU. If the results are super different...
Native operations need to delegate the actual work to dedicated threadpools, and leave the module thread alone. That makes a huge difference.
You also need to consider the type of operation you are waiting for. If you are using the keystore for example, that adds a ton of time.
Do you have a specific feed to reproduce? For this kind of issue, the dataset is critical.
There are a ton of things to look for here.
I would start by profiling the CPU activity and check how optimal the associated native operations are.
Everything eats CPU time. You need to balance the workload to ensure background work can't take over the entire CPU, and balance the background workload so no single work lane takes over the entire CPU portion dedicated to background work
Madurez es la peor razΓ³n para optar por RN. No sΓ³lo sigue siendo beta, sino que Meta pone cada vez menos esfuerzos en mantenerlo y delega en la comunidad, que estΓ‘ compuesta por gente que evita activamente adquirir el conocimiento necesario para mantener librerΓas.