4 ms·

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Androi

by Aaargh20318 10y ago

Not only didn't they give a lot of thought on how apps are to be developed, they made a bunch of really shortsighted design choices that continue to harm Android as a platform today. First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either. Second, the decision to go with Java as a language. After they make us jump through ridiculous hoops to fit our applications into their stupid activity model just to save RAM, they go waste it by chosing a GC'd language, combined with the performance hit you take for the VM this this has really hurt Android app performance. In return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. But, I hear you say, you can supply JNI binaries for multiple architectures. Sure you can, if you can fit them in your APK, which you can't because your APK is limited to 50MB because it has to be downloaded to a temp partition before installing. This brings us to the thirds major fuckup: the file system on Android, or specifically the fact that there are several filesystems instead of just the one. But hey, at least now we get to support removable storage, which is both a PITA for developers, extremely confusing for end-users (why can't I install this app when I have gigabytes of free space on my SD card ?) and after all that trouble hardly any phone has removable storage anymore. This seems to be the big problem with Android's development: a complete lack of vision by Google. They never designed for tomorrows hardware, instead they designed for last years hardware. Android is an OS built around hardware limitations that no longer existed by the time it gained momentum. It's like they were completely surprised by the speed at which mobile hardware evolved.

izacus 10y ago
> n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binaries available. There's also significantly more than 0.1% of non-ARM devices, not to mention the fact that Android currently runs targeting three different ARM architectures. Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!
- Aaargh20318 10y ago
  > Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?! First of all, 50MB is the hard limit, in reality you should keep it under ~30-35MB or so. Your app will fail to install on MANY devices if you don't because while the play store may accept up to 100MB, the cache partition used by the Play Store app usually doesn't have that much space, especially on low-end devices. You start running into problems way before you hit 50MB. As for OBB's, they are a PITA to use and you can't load things like layouts from OBB neither can you load other resources from them without rolling your own system for picking out the correct (mdpi/hdpi/xhdpi/etc) version. The only thing you should use expansion files for is content, not anything needed for the application itself. And it's really easy to hit that limit then.
konschubert 10y ago
> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either. Shouldn't fragments solve this?[0] [0] https://developer.android.com/guide/components/fragments.html https://developer.android.com/guide/components/fragments.htm...
- izacus 10y ago
  Sadly fragment API is pretty terrible - it adds a heapload of complexity due to it's async nature (see https://i.stack.imgur.com/fRxIQ.png https://i.stack.imgur.com/fRxIQ.png which is NOT an exagerration), it's very buggy and filled with hard to debug device-specific issues. Most developers have opted for one of the more popular MVVM / MVP patters that help manage UIs without use of Fragments, but pain when designing tablet interfaces is still there.
- thecupisblue 10y ago
  Uh, fragments introduced just more of the same problems. A fragment in an activity has an insane, confusing lifecycle, then if you nest them, you basically summon Cthulhu. The more experienced part of the Android dev community is slowly transitioning into using views instead of fragments.
- HillaryBriss 10y ago
  <rant> IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much. Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally. To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing. Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments. If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO. But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive. And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb. </rant>
blub 10y ago
Android is usually pointed to as a success story for Java performance. I thought that it was just us that had performance issues because we were developing a big app with a completely custom UI... Interesting to see that others feel this way. The conclusion is that it almost doesn't matter what language you choose for a platform if you have enough man-power and resources and you can force developers to use it. :)
- Aaargh20318 10y ago
  Java performance on Android is crap. The real succes story for Java performance is on the server side.
  - ehosca 10y ago
    where no one can actually see the horrible performance which would be immediately noticeable in any environment with UI interaction... think falling trees in a forest...
sievebrain 10y ago
That seems very unfair. Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their entire app ecosystem, something many Android apps avoided. Phones are still memory constrained. Yes they have "shitloads" of RAM compared to previous devices but they still don't have a swap file of any kind. The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Simply increasing the amount of RAM doesn't solve the problems the activity model was designed to solve, and it's worth noting that when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities. The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. That's why they're reintroducing JIT compilation in Android N - having moved to fully AOT when ART was introduced they are now going back again to reduce memory pressure. The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.
- Aaargh20318 10y ago
  > Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. Layout managers are complex technology now ? The layout managers Android uses are pretty much identical to what Java used in AWT and Swing and is trivial to implement. I know because I implemented just such a thing for a UI toolkit I made for J2ME back in the day. Desktop apps have been doing it for decades. iOS by contrast uses a much more complicated system (not saying it's better, just more complex). Also, I vastly prefer iOS's sytem with just a handful of resolutions so you can fine-tune your designs to the exact screen dimensions. In practice I've found it very hard to explain Android's layout mechanisms to designers and to get good designs from them that scale well. Most designers I know prefer being able to make a pixel-perfect design like you can on iOS. Sure it works fine for business-style apps but if you want to make something spiffy, you're fucked on Android. > when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities. iOS has nothing even remotely resembling activities. Background apps can be suspended and possibly killed, but that's as far as the parallelels go. Don't even get me started on the insane idea of Intents (sounds like a great concept but horrible in practice and badly implemented too). > The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Then why is this not an issue at all on iOS. In fact, my 6S pretty much never kills background apps and even when it does that does not affect foreground performance. And if they were so concerned about the UI stalling, they should have stayed away from Java. It has improved a little bit but especially in the early days the GC would regularly freeze the entire JVM for 100+ ms. Try hitting 60fps like that. > The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. Wut ? Loaded code is a completely negligible part of an apps memory usage. And again, not an issue on iOS. In fact memory is far more constrained on Android than on iOS even when Android devices have more physical RAM. Android severely limits the amount of RAM an application can use (the heap size limit). I've never run into problems with RAM usage on iOS and regularly on Android. On a 1GB iPhone you can easily use 700-800MB RAM for your app if you wanted, while you're lucky if you can get 192MB on a 3GB Android phone. Furthermore, garbage collected languages use about 3 times as much RAM as a non-GC language for similar performance (tradeoff between how often the GC runs vs performance) negating any and all gains of a smaller code size. There is also this thing called the ARM Thumb instruction set which results in smaller binaries if that really is an issue. > The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited. And this goes to the heart of my criticism: yes internal storage was a lot more limited back then. Both Google and Apple knew this. They both also knew (or should have) that internal storage was going to improve a LOT and very quickly at that. This is the point I'm trying to make: Google develops for yesterdays and todays constraints while they should be developing for tomorrows. In fact, Google should look farther into the future than Apple does because it takes so long for their software to reach consumers, it's taking 2-3 years for any new Android release to gain any significant market share. Android N should be built with 2019's phone hardware in mind, instead it's being built for 2015 hardware.

izacus 10y ago

> n return we get an OS that can run in multiple CPU architectures, unfortunately no one runs it onanything other than ARM. The 0.01% of non-ARM devices can't run half the software anyway because they included ARM JNI components to work around the slowness of the VM. These sentences are utter lies that have no basis in reality. Most applications do not use native code and even those that can mostly do have x86 binaries available. There's also significantly more than 0.1% of non-ARM devices, not to mention the fact that Android currently runs targeting three different ARM architectures. Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?!

Aaargh20318 10y ago
> Also having worked on a rather huge NDK project that barely hits 15MB of native code I seriously have to wonder how is 100MB limit (not 50MB as you say, since that was lifted) a problem code-wise. Resource-wise yes (and OBB system is kinda crap), but 50MB of compressed binary?! First of all, 50MB is the hard limit, in reality you should keep it under ~30-35MB or so. Your app will fail to install on MANY devices if you don't because while the play store may accept up to 100MB, the cache partition used by the Play Store app usually doesn't have that much space, especially on low-end devices. You start running into problems way before you hit 50MB. As for OBB's, they are a PITA to use and you can't load things like layouts from OBB neither can you load other resources from them without rolling your own system for picking out the correct (mdpi/hdpi/xhdpi/etc) version. The only thing you should use expansion files for is content, not anything needed for the application itself. And it's really easy to hit that limit then.

konschubert 10y ago

> First is the stupidity of Activities. The basic idea was that 1 screen = 1 activity and we can remove all non-active activities from memory and restart them as needed. This was clearly designed with an eye on memory constrained systems. Nowadays even the cheapest phones have shitloads of RAM but we're still stuck with this retarded model. Worse, now we have support for tablets and phones with big screens the 1 activity per screen no longer makes any sense anymore either. Shouldn't fragments solve this?[0] [0] https://developer.android.com/guide/components/fragments.html https://developer.android.com/guide/components/fragments.htm...

izacus 10y ago
Sadly fragment API is pretty terrible - it adds a heapload of complexity due to it's async nature (see https://i.stack.imgur.com/fRxIQ.png https://i.stack.imgur.com/fRxIQ.png which is NOT an exagerration), it's very buggy and filled with hard to debug device-specific issues. Most developers have opted for one of the more popular MVVM / MVP patters that help manage UIs without use of Fragments, but pain when designing tablet interfaces is still there.
thecupisblue 10y ago
Uh, fragments introduced just more of the same problems. A fragment in an activity has an insane, confusing lifecycle, then if you nest them, you basically summon Cthulhu. The more experienced part of the Android dev community is slowly transitioning into using views instead of fragments.
HillaryBriss 10y ago
<rant> IMHO, Fragments didn't simplify my work or make it more manageable. Fragments mostly added new weird things to remember, and, for all that complication, I don't seem to reuse them all that much. Fragments have their own lifecycle events which are like those of an Activity, but not exactly. They also interact with the Activity lifecycle in ways that I found a bit confusing, personally. To get access to your Fragment instances, you're supposed to rely on the FragmentManager (and/or FragmentManagerCompat, depending on what minimum version of Android you support), which puts you at arm's length from them, making life a bit awkward. Fragments also exist in another flavor, from the compat library, so that sometimes results in mismatched types which can be confusing. Then you have to get used to the idea that you're only supposed to create trivial constructors for your Fragments. If a Fragment needs to know something interesting, you're supposed to pass parameters to it, not through a constructor, but, with setArguments. That way the system can resupply those arguments if it has to destroy and recreate your Fragment on your behalf in certain circumstances. This could be better documented, IMHO. But wait, there's also a lifecycle callback named "onViewStateRestored" which supplies a savedInstanceState Bundle to your Fragment which it can use to bring itself back to the desired state. This is more like what Activities do, kind of. But it doesn't seem to interact usefully with Activity state restoration, which I found counterintuitive. And when I think about how smart these Android SDK programmers are (and I have no doubt that they are super bright people), I wonder why this is what they came up with. It makes me feel dumb. And if your goal is to create a product your customers will love, maybe you should avoid making them feel dumb. </rant>

blub 10y ago

Android is usually pointed to as a success story for Java performance. I thought that it was just us that had performance issues because we were developing a big app with a completely custom UI... Interesting to see that others feel this way. The conclusion is that it almost doesn't matter what language you choose for a platform if you have enough man-power and resources and you can force developers to use it. :)

Aaargh20318 10y ago
Java performance on Android is crap. The real succes story for Java performance is on the server side.
- ehosca 10y ago
  where no one can actually see the horrible performance which would be immediately noticeable in any environment with UI interaction... think falling trees in a forest...

sievebrain 10y ago

That seems very unfair. Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. That meant Android was able to adapt to a range of screen sizes way earlier than Apple could. Every time Apple tried to introduce a new screen size or resolution it resulted in major pain across their entire app ecosystem, something many Android apps avoided. Phones are still memory constrained. Yes they have "shitloads" of RAM compared to previous devices but they still don't have a swap file of any kind. The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Simply increasing the amount of RAM doesn't solve the problems the activity model was designed to solve, and it's worth noting that when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities. The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. That's why they're reintroducing JIT compilation in Android N - having moved to fully AOT when ART was introduced they are now going back again to reduce memory pressure. The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited.

Aaargh20318 10y ago
> Android invested up front in more complex technology that would allow adaptation to future hardware devices. Most obviously, by using layout managers instead of pixel positioning like iOS did. Layout managers are complex technology now ? The layout managers Android uses are pretty much identical to what Java used in AWT and Swing and is trivial to implement. I know because I implemented just such a thing for a UI toolkit I made for J2ME back in the day. Desktop apps have been doing it for decades. iOS by contrast uses a much more complicated system (not saying it's better, just more complex). Also, I vastly prefer iOS's sytem with just a handful of resolutions so you can fine-tune your designs to the exact screen dimensions. In practice I've found it very hard to explain Android's layout mechanisms to designers and to get good designs from them that scale well. Most designers I know prefer being able to make a pixel-perfect design like you can on iOS. Sure it works fine for business-style apps but if you want to make something spiffy, you're fucked on Android. > when Apple introduced multi-tasking into iOS, they ended up with something quite similar to activities. iOS has nothing even remotely resembling activities. Background apps can be suspended and possibly killed, but that's as far as the parallelels go. Don't even get me started on the insane idea of Intents (sounds like a great concept but horrible in practice and badly implemented too). > The activity model allows phones to have an apparently infinite number of apps open, without the UI ever stalling due to hitting a paging storm like desktop apps can. Then why is this not an issue at all on iOS. In fact, my 6S pretty much never kills background apps and even when it does that does not affect foreground performance. And if they were so concerned about the UI stalling, they should have stayed away from Java. It has improved a little bit but especially in the early days the GC would regularly freeze the entire JVM for 100+ ms. Try hitting 60fps like that. > The choice of Java had complex effects on memory usage. Whilst Java heaps can be kind of piggy, a lot of memory usage comes from loaded code, and bytecode is a lot more compact than native code is. Wut ? Loaded code is a completely negligible part of an apps memory usage. And again, not an issue on iOS. In fact memory is far more constrained on Android than on iOS even when Android devices have more physical RAM. Android severely limits the amount of RAM an application can use (the heap size limit). I've never run into problems with RAM usage on iOS and regularly on Android. On a 1GB iPhone you can easily use 700-800MB RAM for your app if you wanted, while you're lucky if you can get 192MB on a 3GB Android phone. Furthermore, garbage collected languages use about 3 times as much RAM as a non-GC language for similar performance (tradeoff between how often the GC runs vs performance) negating any and all gains of a smaller code size. There is also this thing called the ARM Thumb instruction set which results in smaller binaries if that really is an issue. > The decision to support SD cards made a lot of sense back in the days when internal storage was a lot more limited. And this goes to the heart of my criticism: yes internal storage was a lot more limited back then. Both Google and Apple knew this. They both also knew (or should have) that internal storage was going to improve a LOT and very quickly at that. This is the point I'm trying to make: Google develops for yesterdays and todays constraints while they should be developing for tomorrows. In fact, Google should look farther into the future than Apple does because it takes so long for their software to reach consumers, it's taking 2-3 years for any new Android release to gain any significant market share. Android N should be built with 2019's phone hardware in mind, instead it's being built for 2015 hardware.