kaeawc.bsky.social
Software Engineer, mostly mobile, sometimes AI/backend/embedded
16 posts
61 followers
178 following
Getting Started
Conversation Starter
comment in response to
post
Not exactly what you were looking for but Jake Wharton's blog about backing up Google data might help or inspire: jakewharton.com/removing-goo...
comment in response to
post
I'd just check that both Gradle and Kotlin JVM processes are getting everything you want them to have before calling it quits on that path.
comment in response to
post
VisualVM is good for quickly and easily checking if the JVM processes are running with your intended args. JConsole is better for non heap memory monitoring.
comment in response to
post
I was actively porting the Hinge app over from Eclipse right around then when I saw the official release. 🥲 Good memories
comment in response to
post
The memory growth is more concerning to me than the threads staying alive. I wonder if this memory growth is also happening during builds and not just when the daemon is idle.
comment in response to
post
Whats also interesting is how putting this in a loop will just keep spawning more and more threads for the Gradle Daemon. Stopping it will eventually see those threads die off... at least some of them.
comment in response to
post
So I went back through Gradle versions 8.10.2, 8.11, etc and the behavior is consistent:
Run a simple build task, can even be ./gradlew tasks, and you'll see the Gradle Daemon slowly but surely grow memory to fill the maximum heap before GC events take it down. But then keep growing again.
comment in response to
post
I'm about to do some build benchmarking myself on the various DI frameworks in both my public tiny build repo as well as much larger ones. Most likely going to check things out in Dagger Anvil (kapt and ksp), Kotlin Inject, and hand rolled. Anything you'd advise besides what you've already written?
comment in response to
post
Video players, like anything expensive to load and keep in memory, should be pooled. You'd probably have an easier time using AndroidX media3 (which is what exoplayer has been migrated to), but dunno if there is yet an RN wrapper for it.
comment in response to
post
I'm specifically calling out the tooling because the overhead you're referring to is in large part due to using old and sometimes deprecated code. npm installing Gradle modules breaks every optimization in the build tooling while restricting you to old versions of the underlying native components.
comment in response to
post
💯 React Native is constantly years behind in tooling for both platforms. Why someone would penalize themselves this way *and* still need to deal with upgrading dependencies constantly anyway as new RN modules get updates is beyond me.
comment in response to
post
Time to bring it back!