It's a well known fact in technical circles (certainly nothing new); yet a topic that most will simply dismiss as too technical or too complicated. Yet in this case I'll give you the benefit of the doubt i.e. that you truly are interested to understand the technical differences.
Ok a good starting point is probably
this research article which reaches the following conclusion:
We believe these results will be helpful both to practitioners and researchers. For practitioners, these results can guide their choice of using explicitly-managed languages like C and C++, or garbage- collected languages like Java or C#. As long as their applications will be running on systems equipped with more than three times as much RAM as required, then garbage collection is a reasonable choice. However, if these systems will have less RAM or if the app- lication will be competing with other processes for physical mem- ory, then practitioners should expect garbage collection to exact a substantial performance cost. This cost will be more pronounced for systems whose performance depends on maximizing the use of memory, such as in-memory databases and search engines.
This article although focusing on web apps, deals with the underlying architecture differences; differences that come in play irrespectively.
Here's another hopefully easier to understand write up on the GC complexities by a Microsoft GC engineer.
Or maybe you need some
document from Google on the challenges presented by GC model of automated memory management.
Here's a few more:
As I said it a well known issue / challenge with both GC and Android, and I could easily carrying on posting article after article to substantiate this; but hopefully this is enough to get it.
As I've implied before, too often the Android vs iOS debates sink to "my phone is better than your phone because" :
- Bigger CPU
- Faster GPU
- More RAM
The particpants in these senseless debates have no understanding the reasons for differences i.e. Android requires more RAM and faster processors because of constraints like GC, etc. They end up for example: dismissing this on the basis that Android's manufacturers are somehow more innovative than Apple, or Apple likes to charge a fortune for less adequate hardware.
Samsung like others started down it's Android path with far less powerful CPUs and substantially less RAM; but after round after round of poor performance, and the subsequent hammering in the media re the experience being largely unusable they chose to find a quick remedy to the problem i.e. kill it with bigger and faster CPUs and more RAM -- an approach they were quite familiar with in the Windows world, and extra plus points re it could easily be exploited as being an advantage over Apple.
What you should know is that Samsung would (if they could) prefer to ship it's devices with less RAM and smaller CPUs; for reasons like: financial, heat generation, battery, etc... Basically Android phones became larger not because of a latent user need, but primarily because of engineering challenges (more RAM & bigger CPUs require for example a larger battery); fortunately for them it was something the Android community was happy to receive.
Ps. This is a topic I find very interesting and as such I'm well versed, so feel free to PM if you want to discuss it in more detail.