4 ms·

is that it's intermixed with native code via the NDK Idiomatic use of the NDK is that you always provide Java surrogates for NDK functionality, but of course w

by personZ 12y ago

is that it's intermixed with native code via the NDK Idiomatic use of the NDK is that you always provide Java surrogates for NDK functionality, but of course we know that isn't often the case. Instead developers can and do cross compile into a single APK. That is exactly what I do -- for my NDK components I build to x86 / ARM / MIPS (the last one I can never really justify) and it all goes into one APK. Alternately, and as a middle-grounds, I can make separate APKs for the platforms.

pcwalton 12y ago
> Instead developers can and do cross compile into a single APK. So you lose the Web's ability to be retargeted to arbitrary architectures. You can only be retargeted to architectures that you compiled for. It's the exact same situation as in native code (because it is native code), and has very little in common with the Web's model (which can be retargeted to any architecture, even ones that Web authors didn't "cross-compile to"). By way of example, Nintendo could ship a Wii Browser (PowerPC), because JavaScript is platform independent. But Nintendo couldn't ship a Wii Android app runner and have it play games, because nobody compiles games for PowerPC.
- personZ 12y ago
  It's the exact same situation as in native code Just to be clear, Android applications can be, and often are, 100% DEX (the vast majority of productivity, video, etc). Because, you hold, there are exception applications that break this model, the whole model is broken? It's saying that the web is broken because ActiveX is used somewhere. That is horribly specious. It is a dead-end argument by exception. But let's look at those uncommon apps that use some native code. a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. b) The majority of the NDK code will or should have Java equivalents. When the native code can't be used, DEX code will be used. Again, this is idiomatic. c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. In every case you benefit from the device specific compilation. So what doesn't hold again?
  - pcwalton 12y ago
    > But let's look at those uncommon apps that use some native code. Games are not exactly uncommon apps: https://play.google.com/store/apps/collection/topgrossing?hl=en https://play.google.com/store/apps/collection/topgrossing?hl... > a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. Do games really bother to ship Java equivalents? I would be really surprised if they did. > c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. Yes, you can use emulators for native code too, but that's hardly a good user experience unless the games are old.

by personZ 12y ago

pcwalton 12y ago

> Instead developers can and do cross compile into a single APK. So you lose the Web's ability to be retargeted to arbitrary architectures. You can only be retargeted to architectures that you compiled for. It's the exact same situation as in native code (because it is native code), and has very little in common with the Web's model (which can be retargeted to any architecture, even ones that Web authors didn't "cross-compile to"). By way of example, Nintendo could ship a Wii Browser (PowerPC), because JavaScript is platform independent. But Nintendo couldn't ship a Wii Android app runner and have it play games, because nobody compiles games for PowerPC.

personZ 12y ago
It's the exact same situation as in native code Just to be clear, Android applications can be, and often are, 100% DEX (the vast majority of productivity, video, etc). Because, you hold, there are exception applications that break this model, the whole model is broken? It's saying that the web is broken because ActiveX is used somewhere. That is horribly specious. It is a dead-end argument by exception. But let's look at those uncommon apps that use some native code. a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. b) The majority of the NDK code will or should have Java equivalents. When the native code can't be used, DEX code will be used. Again, this is idiomatic. c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. In every case you benefit from the device specific compilation. So what doesn't hold again?
- pcwalton 12y ago
  > But let's look at those uncommon apps that use some native code. Games are not exactly uncommon apps: https://play.google.com/store/apps/collection/topgrossing?hl=en https://play.google.com/store/apps/collection/topgrossing?hl... > a) The majority of the code in most cases will still be in DEX. It will still benefit from device specific compilation. Do games really bother to ship Java equivalents? I would be really surprised if they did. > c) And when those two aren't true, on x86 for instance if you only include ARM, it simply transcodes the ARM native code to x86 native code. It obviously isn't optimized, but it's a pretty decent exception case. Yes, you can use emulators for native code too, but that's hardly a good user experience unless the games are old.