31

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

  • 14
    It's not a good question because Android apps aren't interpreted, just as the correct answer actually points out. – Aaronaught Sep 21 '14 at 18:34
  • 2
    Normally the accepted answer not being the best answer isn't too much of a problem, since the goal is to help whoever asked the question (see this meta post). But this is a pretty extreme case @ArmonSafai The answer you selected as correct is full of misinformation, and is past the point of being salvageable with edits. Please consider selecting another answer. – Selali Adobor Sep 21 '14 at 22:09
  • 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 Sep 22 '14 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 Sep 22 '14 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 Sep 23 '14 at 13:47
85

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.

  • 1
    +1 for great explanation. I was actually waiting for an answer like this. – MANI Sep 21 '14 at 13:16
  • 5
    Not much different from the tired old ".NET/Java vs. C++ performance" debate on PC, really. It's apples and oranges. – Aaronaught Sep 21 '14 at 18:33
  • 1
    @ArmonSafai Quite so. – Dan Hulme Sep 21 '14 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 Sep 21 '14 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 Sep 22 '14 at 17:00
2

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.)

-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.

  • 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 Sep 21 '14 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 Sep 21 '14 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 Sep 21 '14 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. – Aza Sep 21 '14 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 Sep 21 '14 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.