3 ms·

Android apps are meant to be platform independent. A pure Java Android app will run fine on both ARM (various flavours) and x86. I vaguely remember a MIPS imple

by hrjet 12y ago

Android apps are meant to be platform independent. A pure Java Android app will run fine on both ARM (various flavours) and x86. I vaguely remember a MIPS implementation too. Without the intermediate step (bytecode), you are pushing the awkwardness to every individual developer.

Zigurd 12y ago
I just finished editing in step 6 and saw your comment after I hit update. Currently, ART uses Dalvik bytecode as a platform independent intermediate representation. I wonder if Dalvik bytecode is ideal for that purpose.
- hrjet 12y ago
  Either I am not understanding something, or perhaps you are not clear about the system side of Android. AFAIK, ART doesn't "use" Dalvik. It is an ahead-of-time-compiling run-time for Dalvik. IOW, ART wouldn't exist without Dalvik.
  - personZ 12y ago
    It is an ahead-of-time-compiling run-time for Dalvik. ART and Dalvik fill the same role, and are redundant with each other. They both take DEX (which I suppose you could call Dalvik bytecode, but now that it's runtime independent it should just be DEX bytecode) and ART ahead-of-time compiles it into native code, while Dalvik JIT compiles it into native code where possible. That makes the difference sound greater than it really is. In reality ART is simply "rebuilding Dalvik from the ground up based upon everything that had been learned". It isn't 100% reliable right now because it's an incomplete runtime with some issues.
    - hrjet 12y ago
      Thanks for clearing up the terminology! I guess we muddled up the discussion by referring to DEX bytecode as Dalvik bytecode, and sometimes just Dalvik.
  - Zigurd 12y ago
    ART replaces Dalvik as the runtime environment in Android. Both use the same application packaging format, which contains Dalvik bytecode. ART pre-compiles it. Dalvik bytecode (DEX) was designed to efficiently interpreted. Eventually, Dalvik added a JIT compiler suitable for battery powered platforms. What ART stops short of is replacing Dalvik bytecode, perhaps with a more efficient intermediate representation for the purposes of pre-compiling.
grey-area 12y ago
Platform independence isn't really a big deal. Apple managed this just fine with fat binaries, and you could have an analogous system on Android without problems and a build chain that automatically cross-compiled (easy in golang). Developers wouldn't even have to notice. The size of binaries is often a small part of the total size of the app - resources tend to take up much more room. The real problem would be porting all the current APIs. If Google actually decided to do this though it would be a good opportunity to clean up the current APIs and provide a new version free from legacy cruft. So it is doable, but a fair amount of work to provide UI bindings etc. The obstacles are more political and monetary than technical.
- hrjet 12y ago
  Apple controls and chooses the hardware targets by itself. Android is open and the potential number of hardware targets is limitless. It's not just about the size of the binaries; the app and the programmer should ideally be agnostic of the hardware. On an open-platform with closed-source applications, the least awkward way to do this is to push the native translation to the run-time.
  - grey-area 12y ago
    In practice, is the number of hardware targets larger than two or three? I doubt it would be a problem for google to certify hardware targets.
    - tormeh 12y ago
      But here's the kicker: The number of targets is a variable. Google would have to force developers to recompile for each new ISA. New ISAs keep getting added, many of them ARM ISAs that are not mutually compatible.

by hrjet 12y ago

Zigurd 12y ago

I just finished editing in step 6 and saw your comment after I hit update. Currently, ART uses Dalvik bytecode as a platform independent intermediate representation. I wonder if Dalvik bytecode is ideal for that purpose.

hrjet 12y ago
Either I am not understanding something, or perhaps you are not clear about the system side of Android. AFAIK, ART doesn't "use" Dalvik. It is an ahead-of-time-compiling run-time for Dalvik. IOW, ART wouldn't exist without Dalvik.
- personZ 12y ago
  It is an ahead-of-time-compiling run-time for Dalvik. ART and Dalvik fill the same role, and are redundant with each other. They both take DEX (which I suppose you could call Dalvik bytecode, but now that it's runtime independent it should just be DEX bytecode) and ART ahead-of-time compiles it into native code, while Dalvik JIT compiles it into native code where possible. That makes the difference sound greater than it really is. In reality ART is simply "rebuilding Dalvik from the ground up based upon everything that had been learned". It isn't 100% reliable right now because it's an incomplete runtime with some issues.
  - hrjet 12y ago
    Thanks for clearing up the terminology! I guess we muddled up the discussion by referring to DEX bytecode as Dalvik bytecode, and sometimes just Dalvik.
- Zigurd 12y ago
  ART replaces Dalvik as the runtime environment in Android. Both use the same application packaging format, which contains Dalvik bytecode. ART pre-compiles it. Dalvik bytecode (DEX) was designed to efficiently interpreted. Eventually, Dalvik added a JIT compiler suitable for battery powered platforms. What ART stops short of is replacing Dalvik bytecode, perhaps with a more efficient intermediate representation for the purposes of pre-compiling.

grey-area 12y ago

Platform independence isn't really a big deal. Apple managed this just fine with fat binaries, and you could have an analogous system on Android without problems and a build chain that automatically cross-compiled (easy in golang). Developers wouldn't even have to notice. The size of binaries is often a small part of the total size of the app - resources tend to take up much more room. The real problem would be porting all the current APIs. If Google actually decided to do this though it would be a good opportunity to clean up the current APIs and provide a new version free from legacy cruft. So it is doable, but a fair amount of work to provide UI bindings etc. The obstacles are more political and monetary than technical.

hrjet 12y ago
Apple controls and chooses the hardware targets by itself. Android is open and the potential number of hardware targets is limitless. It's not just about the size of the binaries; the app and the programmer should ideally be agnostic of the hardware. On an open-platform with closed-source applications, the least awkward way to do this is to push the native translation to the run-time.
- grey-area 12y ago
  In practice, is the number of hardware targets larger than two or three? I doubt it would be a problem for google to certify hardware targets.
  - tormeh 12y ago
    But here's the kicker: The number of targets is a variable. Google would have to force developers to recompile for each new ISA. New ISAs keep getting added, many of them ARM ISAs that are not mutually compatible.