4 ms·

If you call malloc/free in the inner loop of a C program you'll have the same problems. Android has a RecyclerView for the exact reasons that you call out. The

If you call malloc/free in the inner loop of a C program you'll have the same problems. Android has a RecyclerView for the exact reasons that you call out. The framework is far from perfect but at least from the details you listed I don't see why you had to drop to C.

g_p 6y ago
Just for clarity, we resorted to C mostly as an experiment to prove our hypothesis that the abstraction and instantiation overhead was genuinely ridiculous. I don't have any of the screenshots to hand sadly now, but the performance traces were just appalling. And this was across the board Our experiment in C showed that it was possible to implement a simple Android "view" or "control" (however it should be called), in native C, with significantly better performance than Android itself provided. It wasn't intended to be the least effort solution, rather a side project to prove something we always suspected. RecyclerView is a start, but I believe we still found it slow. The delays from malloc()/free() were very significantly lower in impact, though admittedly we weren't doing them in nested loops or anything. I would like to think using C forced us to think more efficiently and we probably did a few little optimizations (noting it was just a side project) that were a bit like the recycler view does, to create enough memory in advance for a feasible scroll buffer both up and down, and fill it as the user moved.
toast0 6y ago
The recycler view means at least you don't need to rebuild the object trees when you want to replace something, but it's still super slow to build it the first time.
- g_p 6y ago
  Must confess I had gotten as far as possible from UI development in Android by the time recycler views came around (or at least I became aware of them), but this sounds very familiar. I think we were talking about hundreds of milliseconds to setup the view, full of nested constructors calling each other, calling their inherited super class constrictor, calling a few factories too for good measure. It was liberating to reverse all that obfuscation and abstraction, and get all the logic into one single file, as a series of functions implementing the Android-expected API, without having to call out to a black box of stutters and constructors!
  - toast0 6y ago
    Yeah, I'm usually a backend person, but I have an app I want to build, because everything else that does it sucks. But the learn how to make Android UI stuff I need to do is all deathly slow, or says 'make a webview and do it there' if you want it to be fast, which is peobably true, but depressing. I just want to fetch some data, and put it in something vaguely tabular. I can prefetch the data, so I have it when the app needs to draw, but I can't make drawing fast, which is super demotivating. On the other hand, now I understand why even with 4GB of ram, Android is sluggish, and it's not worth using a 2GB phone anymore.
    - g_p 6y ago
      I'm in a similar position, although probably not with an idea for what I want to build right now. But been there in the not so distant past. For me the "logic" part is easy - I can make it in a terminal UI fine. I could probably make it in a VB6 style UI similarly easily just from ancient muscle memory. I have never actually built any personal "app" for Android, despite having been heavily into it since 2009, running an app development company (!) and doing a load of platform engineering. It just isn't enjoyable for me. Demotivating is a great way to describe it. Any time I have an idea, the UI side ends up frustrating as the model for positioning components is very prescriptive and doesn't help me build fast. Once I get that UI, I then start uncovering horrific complexities in how it's bad to run things on the UI thread, but then apparently none of the effort has gone into making it straightforward not to do so. The closest I got to something that made sense for me was Android Annotations (and a similar project whose name I forget) - http://androidannotations.org/ http://androidannotations.org/ This made it less painful for me, although sadly it wasn't quite pain-free enough for me to actually cross the line and build a personal side project app... If only it was possible to more easily chain together the APIs exposed by Android, without having to immerse oneself in the highly opinionated way of doing so "correctly", and instead focus on the logic required to get the data to the right address in memory.
      - scns 6y ago
        You can easily run stuff off the UIthread with Kotlin an Coroutines

g_p 6y ago

Just for clarity, we resorted to C mostly as an experiment to prove our hypothesis that the abstraction and instantiation overhead was genuinely ridiculous. I don't have any of the screenshots to hand sadly now, but the performance traces were just appalling. And this was across the board Our experiment in C showed that it was possible to implement a simple Android "view" or "control" (however it should be called), in native C, with significantly better performance than Android itself provided. It wasn't intended to be the least effort solution, rather a side project to prove something we always suspected. RecyclerView is a start, but I believe we still found it slow. The delays from malloc()/free() were very significantly lower in impact, though admittedly we weren't doing them in nested loops or anything. I would like to think using C forced us to think more efficiently and we probably did a few little optimizations (noting it was just a side project) that were a bit like the recycler view does, to create enough memory in advance for a feasible scroll buffer both up and down, and fill it as the user moved.

toast0 6y ago

The recycler view means at least you don't need to rebuild the object trees when you want to replace something, but it's still super slow to build it the first time.

g_p 6y ago
Must confess I had gotten as far as possible from UI development in Android by the time recycler views came around (or at least I became aware of them), but this sounds very familiar. I think we were talking about hundreds of milliseconds to setup the view, full of nested constructors calling each other, calling their inherited super class constrictor, calling a few factories too for good measure. It was liberating to reverse all that obfuscation and abstraction, and get all the logic into one single file, as a series of functions implementing the Android-expected API, without having to call out to a black box of stutters and constructors!
- toast0 6y ago
  Yeah, I'm usually a backend person, but I have an app I want to build, because everything else that does it sucks. But the learn how to make Android UI stuff I need to do is all deathly slow, or says 'make a webview and do it there' if you want it to be fast, which is peobably true, but depressing. I just want to fetch some data, and put it in something vaguely tabular. I can prefetch the data, so I have it when the app needs to draw, but I can't make drawing fast, which is super demotivating. On the other hand, now I understand why even with 4GB of ram, Android is sluggish, and it's not worth using a 2GB phone anymore.
  - g_p 6y ago
    I'm in a similar position, although probably not with an idea for what I want to build right now. But been there in the not so distant past. For me the "logic" part is easy - I can make it in a terminal UI fine. I could probably make it in a VB6 style UI similarly easily just from ancient muscle memory. I have never actually built any personal "app" for Android, despite having been heavily into it since 2009, running an app development company (!) and doing a load of platform engineering. It just isn't enjoyable for me. Demotivating is a great way to describe it. Any time I have an idea, the UI side ends up frustrating as the model for positioning components is very prescriptive and doesn't help me build fast. Once I get that UI, I then start uncovering horrific complexities in how it's bad to run things on the UI thread, but then apparently none of the effort has gone into making it straightforward not to do so. The closest I got to something that made sense for me was Android Annotations (and a similar project whose name I forget) - http://androidannotations.org/ http://androidannotations.org/ This made it less painful for me, although sadly it wasn't quite pain-free enough for me to actually cross the line and build a personal side project app... If only it was possible to more easily chain together the APIs exposed by Android, without having to immerse oneself in the highly opinionated way of doing so "correctly", and instead focus on the logic required to get the data to the right address in memory.
    - scns 6y ago
      You can easily run stuff off the UIthread with Kotlin an Coroutines