31

Android apps are interpreted rather than compiled. Does this make them slower than iOS apps at runtime?

Improve this question
4
  • 14
    It's not a good question because Android apps aren't interpreted, just as the correct answer actually points out.
    – Aaronaught
    Commented Sep 21, 2014 at 18:34
  • Note that some major corporations -- IBM included -- are writing major applications in Java these days. Given a Just-In-Time (JIT) compiler, which is a standard part of a modern Java VM, performance really is comparable with any other high-level language. Java has not been only "an interpreted language" for many years.
    – keshlam
    Commented Sep 22, 2014 at 12:34
  • JIT compilers aren't tied to the concept of a JVM at all. There are JVMs that don't use JIT compilers, even commercial ones. Some variations of IBM's JVM don't enable JIT by default, instead defaulting to AOT compilation. Also, small note, "major applications in Java these days" was probably a bit more apt a decade and a half ago (IBM was adding to Java before 1997)
    – Selali Adobor
    Commented Sep 22, 2014 at 17:29
  • The question is somewhat misleading. A "native" iOS app is written in Objective-C (or Swift) and compiled, whereas a "standard" Android app is written in Java and compiled to bytecode. See @DanHulme's answer. But it's possible to write apps for either platform in HTML & JavaScript using e.g. PhoneGap/Cordova. An HTML app is usually perceived to run more slowly than a native app on the same platform. So if a similar app for the "other" platform seems slower perhaps it's because it was created using different technology.
    – David
    Commented Sep 23, 2014 at 13:47

4 Answers 4

Reset to default
86

Java isn't interpreted on Android. Android apps are compiled to bytecode by the developer. Bytecode is a compact representation of the program: smaller than the source code written by the programmer, but still not directly executable by the CPU. Some optimizations, such as dead code removal, can be made at this stage.

When you load the app on a device, the Dalvik JVM compiles the bytecode to native executable code, just as it's about to run. This is just-in-time compilation. It causes a brief slow-down while the program waits to be compiled, but after that there's no performance overhead, because the code has been compiled to native executable code.

There are some performance advantages to doing it this way instead of compiling up-front on the developer's computer. The app can be compiled for the particular CPU on the phone, taking advantage of its hardware features and using its performance characteristics. For example, it can use hardware floating-point operations if the CPU supports it. In addition, a clever JIT compiler (admittedly, Dalvik is not quite this clever) can monitor the way the program runs, and perform optimizations based on the way the program is used in real use. It might recompile the code with better branch hinting once it has seen which options are turned on and off in your environment, on your phone. An up-front compiler doesn't have this information to use.

Dalvik uses the Dalvik cache and other techniques to mitigate the drawbacks of JIT compilation. The new JVM for Android L and later, ART, replaces the JIT entirely with an ahead-of-time compiler. This compiles the bytecode to native executable code when the app is installed, to get most of the advantages of JIT without the delay loading the app.

Don't forget that Android apps don't entirely consist of Java. Developers have the NDK to write all or part of their apps in C or C++, for performance-critical parts of the app, especially for games. Special-purpose interfaces like OpenGL and Renderscript let programmers take advantage of special hardware like the GPU and SIMD coprocessor for some kinds of computation.

So really, there's no simple answer to your question. Using JIT instead of up-front compilation makes some things faster, some things slower. It's just one part of the overall performance of the OS.

Improve this answer
10
  • 5
    Not much different from the tired old ".NET/Java vs. C++ performance" debate on PC, really. It's apples and oranges.
    – Aaronaught
    Commented Sep 21, 2014 at 18:33
  • Just a small note: The Dalvik JVM does not compiles the bytecode to native executable as it's about to run. Davlik start by interpreting the bytecode. It then compiles it if it see the same piece of code being run many times(That is typical code in a loop, or part of a method called many times).
    – MTilsted
    Commented Sep 21, 2014 at 21:25
  • 1
    @ArmonSafai Quite so.
    – Dan Hulme
    Commented Sep 21, 2014 at 22:27
  • 2
    @MTilsted: That's kind of true, but it caches almost everything, so what you're talking about would likely only happen the very first time you run an app.
    – Aaronaught
    Commented Sep 21, 2014 at 23:32
  • 1
    The main problem here is Dalvik is being though of as a "normal" JVM. Between being register-based, as opposed to stack based like HotSpot (because of the nature of ARM processors vs those HotSpot was targeting [such as IA32]), it's use of Zygote, and the concept of odex files (i.e. the whole idea of not [more or less] going straight from class file to class loader), treating Dalvik as a normal JVM is bound to lead to some misconceptions. Especially since many of the details of the HotSpot implementation have are often mistakenly associated with JVMs in general (like it's JIT compiler).
    – Selali Adobor
    Commented Sep 22, 2014 at 17:00
3

Since this is a broad question, here's a broad answer.

"Are iOS apps faster than android apps since android apps are interpreted?"

First off iOS apps are not "faster than" android apps.

Secondly, regarding the issue "Android apps are Interpreted." This is something you'd say about computing, like "15 years ago": as you can see from the discussion above, the situation is much more complicated today; entirely new technologies have come to the fore. The concept "compiled is faster than interpreted!" was relevant comparing, you know, perl to machine code 20 years ago; things have moved on so much that issue can not be really clearly applied to "iOS V Android" today.

Thirdly, there are other issues in mobile programming that totally swamp such considerations. Just one example on the ground, mobile programmers knock themselves out over handling large scrolling lists of images, lazy loading, and similar issues. How the two OSs, and the various popular libraries, handles these critical issues often swamps other issues.

Fourthly, just one more overwhelming issue on mobiles is the issues of the graphics chipset and the various complicated relationships of that to software, OpenGL, and so on. For example, Apple is coming out with a system they calL "Metal" in relation to these problems, and Android is coming out with their own "thingy" in this field. These issues around the graphics pipeline are tremendously important to how apps "feel" in your hand.

The very short answer to your question is "compiled V. interpreted" is basically an out-of-date discussion point you know?

(Also, I don't particularly find a Note3 "slower" than an iPhone. Also, some of this is pure artefact - there does exist inexpensive Android phones: there simply aren't low performance iPhones made, so some people may have incorrect ideas from this.)

Improve this answer
2

Short answer:

Android only executes native machine codes and not VM bytecodes.

  • Codes are compiled to byte-code by software developer (apk files)

  • During app installation, the phone byte-codes are converted to native machine codes for a specific CPU. This leads to longer installation and larger execution files but faster runs.

Improve this answer
-3

Because interpreted apps does not means that they are always slow. Sometimes they are more powerful and dynamic as compared to compiled one. As all codes in compiled app are compiled once & output is kept in form of libraries or executables, while in interprated language, once can randomly change the sequence of execution. So i can say, it depends of developer to developer and there way of programming.

However, Java (Android's programming language) is not interpreted but is JIT compiled. That means that Android programs compile just before you run them, giving reasonably similar performance to iOS' Objective C.

More recently, Android's ART framework pre-compiles the apps, so they are run in the same way as iOS apps. In other words, the next version of Android will presumably be just as fast as iOS.

Update

Programming languages generally fall into one of two categories: Compiled or Interpreted. With a compiled language, code you enter is reduced to a set of machine-specific instructions before being saved as an executable file. With interpreted languages, the code is saved in the same format that you entered. Compiled programs generally run faster than interpreted ones because interpreted programs must be reduced to machine instructions at runtime. However, with an interpreted language you can do things that cannot be done in a compiled language. For example, interpreted programs can modify themselves by adding or changing functions at runtime. It is also usually easier to develop applications in an interpreted environment because you don't have to recompile your application each time you want to test a small section.

Improve this answer
8
  • 1
    what do you mean "once can randomly change the sequence of execution? And how are they more powerful and dynamic? Also im not saying that theyre slow, just that they are slower, even slightly.
    – Armon Safai
    Commented Sep 21, 2014 at 8:26
  • 3
    This isn't entirely true. It's misleading to say that not having to recompile is an advantage, since you still need to build an APK file and deploy it to the test device. Google didn't decide to use Java: Android was already Java-based before Google bought it. APK files don't contain the code "in the same format that [the programmer] entered."
    – Dan Hulme
    Commented Sep 21, 2014 at 11:00
  • 1
    Microsoft .NET is compiled down to IL code which is also interpreted just like java is compiled down to bytecode.
    – Esben Skov Pedersen
    Commented Sep 21, 2014 at 12:39
  • 12
    A lot of information in this answer really isn't relevant or technically correct. I'd honestly suggest this answer be totally revised for technical accuracy.
    – user73777
    Commented Sep 21, 2014 at 17:07
  • 2
    Java is generally not an interpreted language, unless you're dealing with an unusual JVM implementation. JIT compilation is not the same thing as an interpreter, so most of this answer is honestly pretty irrelevant in the context of Android's performance since it uses JIT.
    – eldarerathis
    Commented Sep 21, 2014 at 17:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .