iPhone vs Android

[Paulo Pinto via Digitalmars-d]

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu 
wrote:
> An interesting article written for laypeople: 
> http://www.theverge.com/2016/9/12/12886058/iphone-7-specs-competition
>
> One quote that may be of relevance to us: "As to the iPhone’s 
> memory, this is more of a philosophical distinction between 
> Apple and Google. The former is neurotic about killing 
> background processes and dumping background apps from memory in 
> iOS, whereas the latter is more liberal with app management in 
> Android (though Google is gradually moving toward the Apple way 
> of doing things). The upshot is that an iPhone can feel super 
> smooth and responsive with half the RAM of an Android device. 
> RAM consumes power, so having less of it is another factor 
> contributing to the iPhone’s efficiency lead."
>
> This may be interpreted as follows: the iPhone uses native apps 
> with reference counting whereas the Android uses a virtual 
> machine with tracing garbage collection. It follows that the 
> latter needs more memory for the same performance, and is more 
> jerky in behavior than the former. Wondering to what extent 
> this is true. If it is, that provides more impetus for 
> reference counting for D by the following logic: (a) it is 
> likely that in the future more code will run on portable, 
> battery-powered systems; (b) battery power does not follow a 
> Moore trajectory, so at this point in history demand for 
> battery lifetime is elastic.
>
>
> Andrei

Just some update on your information, the Android story is much 
more complicated than having  VM.

They had a VM up to version 5.0, afterwards Java bytecode 
(actually Dex) is compiled to native code at installation time, 
then there is just the language runtime, just like D.

Now with Android 7, due to the big compilation times, specially 
when large applications need to be updated, they have an hybrid 
design. An interpreter written in Assembly that makes use of a 
JIT for hot code, then the JIT makes use of PGO and when the 
device is plugged and charging, the hot code will be AOT compiled 
to native code and never JITed or interpreted again until a new 
update takes place.

Likewise the GC algorithm in Dalvik is pretty lame, even some 
J2ME JVMs do better than it.

However that was changed in ART, updated in Android 6.0 and 
changed again in Android 7.0.

So it is not easy just to say Android works like X, because X 
depends on the Android version and OEM build, as some of them do 
also change the AOSP runtime and compilers behaviors.

Also for additional comparison, the Windows Phone also has a mix 
of RC (WinRT now renamed as UWP) and GC (.NET Native / Chackra 
JavaScript VM), yet the devices perform much better than similar 
Android devices.

Also Microsoft does a full AOT build to native code on the WP 
Store, instead of using the consumer devices for AOT compilation 
like Google does.

So it is not that easy to generalize the OS behaviors like the 
article does.