Android apps are interpreted rather than compiled. Does this make them slower than iOS apps at runtime?
Take the 2-minute tour
×
Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. It's 100% free, no registration required.
|
|
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. If really interpreted languages are slower than compiled one then Google never thought of using Java as their base on Android Development, they might have contacted Microsoft(for .Net) or Apple (Obj C) for app development. Best example is Java which is an interpreted language and you can found it everywhere in this world, from a washing machine to satellites. 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. |
|||||||||||||||||||||
|
|
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. |
|||||||||
|
