I know that in Kitkat and later versions android does a AOT (Ahead of time compilation), this happen during app install time and result in plenty of performance benefits. But any app would be referencing number of classes from operating system, which I guess they are packaged as jar file somewhere.
Take the example of TextView, so when AOT happens does it also include all the reference to system dependent classes? or AOT it just app exclusive procedure ? in that case a good amount of performance improvements will not be reachable, as we only do a part of processing through our code.
My app is too slow, I am using android system class called android.text.StaticLayout, I think if it were also precompiled whether install time or at the time OS itself was installed it would have been faster than what I am facing.
Related
After I installed MultiDex I noticed,first ever launch of the app takes extra 4-5 seconds. However after a few researches, I noticed that the app size inside the phone settings(app manager) went from 7 MB to 19 MB and if I clear data, app goes back to 7 MB. But every time that I launch the app for the first time, app size increases to more than double.
Now my question is, what happens that makes the app size increase so much?
So far I have found a few topics on slackoverflow about MultiDex but none talks about what really happen with the code, and what kind of data MultiDex saves/caches.
Multi-Dexing is enabled in your gradle and extended in your Application class.
This is used when you use over 64,000 methods.
https://developer.android.com/studio/build/multidex
I would say probably 90% of the time if you are hitting multi dex needs, you have likely not properly managed your dependencies. I'm NOT saying every time. However, typically the issue is people bring in entire Google dependencies instead of just the ones you need. For example the Google Play Services. If you include this, it will instantly force you into multi-dexing. However, this does come with a performance hit. You now have multiple dex files to load. There is some pre-dexing of course for things that will not change such as 3rd party dependencies to help your speed a bit on building and deploying. However, having multiple lookup tables comes with it's speed consequences. For example, if you included.
com.google.android.gms
has about 44,000 methods alone in it, You should specify which one you want like
com.google.android.gms:play-services-location:16.0.0
for example.
So before you go down the road of using Multi-Dex, ensure you have properly cleaned up your unused dependencies, and that you are properly managing your transitive dependency tree. Also don't forget to use ProGuard or the new D8 minification process as that may also help you, although may require you to run in Debug as well if you have that heavy of dependencies.
If you have done all that and you still need to use Multi-Dex (and I have run into this at larger companies that force tons of bloat libraries on you) then you go for it.
Now as for what is happening, well Dex stands for Dalvik Executable. It is the process of packaging the code into Dalvik bytes for execution. This is limited to 65,536 methods. They say 64k in the documentation, but everywhere I've read shows 65k+. Many of Google's libraries already contain 17k methods which puts you 1/4 of the way there right out the gate.
I believe the issue has something to do with the header allocation of 2 bytes per method signature and the lookup table. they are limited on number of unique IDs they can create. So it requires you to create multiple dex files with multiple lookup tables for the method signatures. So the short answer is, it makes multiple Dalvik Executable files to ensure unique method signatures are properly found and executed on the Dalvic Virtual Machine.
Other important things to note, is that prior to Android API 21, the Virtual Machine only supports 1 dex file. Therefore you need to do multi-dex install on your application onCreate to get the rest brought in properly. However, if you are using proguard, your additional dex files could have been removed so you may need to address a MultDexProguard file as well.
Now, it's important to realize that Android completely redid their Virtual Machine and no longer relies on Dex for their modern OS virtual machines. So then the next question is "should you still use it"?
Well if you are still needing to support pre-Lollipop, then you are better off leaving your multi-dex in place. Otherwise if you are Lollipop and up. Android uses ART (Android Runtime) and does not have this limitation. Honestly the population that has pre-Lollipop is so small that it is not worth supporting in my personal opinion, but it depends on your product and your needs.
Hope that helps shed some light on things here.
Happy Coding
A single .dex file can have 65,536 methods(references) so if the number of references exceeds 65,536, you go with multidex.
Maybe as your app is storing more than one .dex file it is allocating more space for new .dex files.
Breakdown your APK using APK Analyser to see what is causing the app size to increase
use the following link refer
https://developer.android.com/studio/build/apk-analyzer
if you want to decrease the size of the app this article is helpful
https://medium.com/exploring-code/how-you-can-decrease-application-size-by-60-in-only-5-minutes-47eff3e7874e
I am building some android application. And of course it use many library included in gradle.
I want to do performance test, which library can affect much my application performance for doing other logic , like encode and decode, or other stuff.
Any idea?
There's an entire section in the Android User Guide called Profile Your App. There's a number of tools you can use to measure the performance of your app, however an extensive performance testing will probably be time consuming. Normally you'd have to identify a problem in your app and pick appropriate profiling techniques to find out what causes it.
To add to #Egor's answer about profiling, you may also want to think about the method count limit when considering library dependencies, in particular on older devices. While not directly related to runtime performance, having to use multidex in your builds will significantly increase your build times and the initial loading time of your app (on Android older than Lollipop).
This question is related to android system.
Dalvik VM uses JIT concept, it means that when you first run application Dalvik VM compiles it and loads into RAM as long as it could stay there. I understand that concept. But new virtual machine called ART, uses AOT method. ART compiles app after you install it(or when you are installing it?). What this means ? Apps compiled by ART are the same as already compiled apps(like C apps) but run in a separate processes separated from the rest of OS ?
Can somebody explains me this concepts more thoroughly. I have to make some presentation, and this is mentioning there, but I don't understand this concept and I don't want to look dumb if somebody asks me something about that :)
Sorry for bad English, it would be nice if somebody could edit question a bit.
I am not completely familier how Dalvik JIT on Android works in practice, because JIT have several options how can work.
First option is, that JIT translate all bytecode into CPU instructions on application launch. This option spent some time before application launches and after that application can run as native. Problem is, that translated application has to kept in memory during launch, which is not good.
Second option is, that JIT works as real Just-In-Time, which means that translate block of code when is about to launch. Whole application is not translated on launch, but only main function is translated on launch and then is translated during run, when certain block of code (function etc.) is used. This option consumes less memory, but application is much slower during run.
According to informations I found, Android uses first option. Application is translated on launch and after that it runs "almost" natively. And this "almost" makes main difference between JIT and AOT.
When you are about to launch some application, JIT have only limited time to compile all bytecode to CPU instructions to make launch-lag "acceptable" long. This means, it can perform only basic optimizations. However, when you install some application, you have usually more time to waste and you are doing it only once - not on every launch. This means that AOT compiler has much more time to find tricks how to optimize that application. Resulted code should be more "efficient". Second benefit is, that compiled application is stored to cache and only part of it can be loaded to memory on launch. That means that OS hadn't keep whole code in memory and can save it. And that is main differences.
And last part of your question - ART on Android will perform compilation on installation (after saving apk to /data/app/). However, if you wipe that cache, or switch from Dalvik to ART, it will compile all installed application on first boot, which can take 10 or even more minutes.
And sorry for my bad english too, I am Czech :-)
Ahead Of Time(AOT) - Android Runtime(ART) - generates machine byte code during installation.
[JIT vs AOT]
I'm going to implement aodv protocol as a linux module for a research project, and I need to implement it on Android later.I wonder if I could compile my codes into the android kernel and have my module work as in Linux (kernel 2.6 up).
Any suggestions would be greatly appreciated.
(P.S. There are already some aodv implementations on Android, such aodv-on-android and UoB JAdhoc, however, those are implemented in Java, not involving kernels)
The tagline goes: Android is Linux, so anything (portable) you do on Linux should be simple to make happen on Android.
This is mostly true, however there are a few things you'll want to keep in mind:
Portability: If you're writing your implementation on x86 and then moving the module to ARM for Android, be careful not to use any capabilities that don't exist on both. However, for something like a network protocol, you probably won't be running into a lot of these. The only one that comes to mind is the NIC.
Dalvik: Generic Linux distributions tend to run fairly close to the OS, meaning they regularly make system calls or libc calls, and the semantics of interactions with the kernel mostly carry over to the application. Android, however, has essentially a Java environment build on top of that, and the majority of applications only interact with that framework. For you, this means you will want to be aware of the possible need to modify the Android framework in order to make changes visible to applications.
The above point depends on your use case, however. If you plan on augmenting routing for existing applications to use aodv, then you'll want to hack around with Dalvik. If you'll be writing one proof of concept application, then you can write the portions that interact with aodv in C using the NDK, and avoid having to modify the application framework.
You probably already know this, but the kernel built system is sophisticated enough that you should be able to get away with writing your module once and compiling it for two architectures or platforms just by changing your configuration.
Hope this helps.
Forenote: This is an extension of the thread started on /r/haskell
Lets start with the facts:
Android is one awesome Operating System
Haskell is the best programming language on the planet
Therefore, clearly, combining them would make Android development that much better. So essentially I would just like to know how I can write Haskell programs for the Android OS. My question is:
How can I get a Haskell program to execute/run on the Android OS?
How you do it is by first getting a Haskell compiler which can target C with the android NDK which comes with a GCC port for ARM architectures. JHC can trivially do this with a very small inf style file which describes the platform (word size, c-compiler, etc) I've done this with the Wii homebrew dev kit and it was quite easy. However jhc still has some stability issues with complex code such as using a monad transformer stack with IO but jhc has been improving a lot over the last 6 months. There is only one person working on JHC I just wished more people could help him.
The other option is to build an "unregistered" port of GHC targeting the ndk gcc, this is a lot more involved process because GHC is not a true cross-compiler at the moment and you need to understand the build system what parts you need to change. Another option is NHC which can cross-compile to C, like GHC you need to build nhc targeting a C compiler, NHC does not have many Haskell extensions like GHC.
Once you have Haskell compiler targeting NDK GCC, you will need to write bindings to either the android NDK JNI glue code framework (added since android 2.3) or you must write JNI glue code between Java-C-Haskell, the former option is the easier solution and if I remember correctly might actually be backwards compatible with previous versions of Android below 2.3.
Once you have this you must build Haskell code as shared library or static library which gets linked into the NDK java glue code (which itself is a shared library). As far as I'm aware you can not officially run native executables on android. You could probably do it with a rooted phone, thus I assume this means you can not distribute native executables on the app store even when the NDK gcc port can generate native executables just fine. This also probably kills the option for using LLVM unless you can get the NDK JNI working with LLVM.
The biggest hurdle isn't so much of getting a Haskell compiler for android (which is still a big hurdle) the biggest problem is that some one needs to write binding APIs for NDK libraries which is a huge task and the situation is worse if you need to write android UI code because there are no NDK APIs for this part of the android SDK. If you want to do android UI code in Haskell somebody will have to write Haskell bindings to Java through JNI/C. Unless there is a more automated process to writing binding libraries (I know there are some, they are just not automated enough for me) then chances of some one doing it are quite low.
L01man: Is there a tutorial about how to do this? For the
first part, I understand I have to download JHC. What do I have to
write in the inf file and how to use it?
Please note before I answer this question I haven't used jhc for quite sometime since I originally wrote this and newer versions have been released since so I do not know how stable jhc currently is when it comes to code generation of more complex Haskell programs. This is a warning to anyone before you consider making a large Haskell program with JHC, you should do some small tests before you go full on.
jhc does have a manual http://repetae.net/computer/jhc/manual.html and a section on setting-up cross-compilation and .ini file with options: http://repetae.net/computer/jhc/manual.html#crosscompilation.
L01man: The second part is an alternative to the first. I don't know how to do what you said in the
third.
Before you begin you should have some knowledge of C and be comfortable with using the Haskell foreign function interface (FFI) and tools such as hs2c. You should also be familiar with using the Android NDK and building .apk with shared libraries. You will need to know these to interface between C-Haskell, Java/C-Haskell and develop Haskell programs for Android that you can officially distribute/sell on the market store.
L01man: I understand that its goal is to create a binding for the
Android API. But... does the 4th part says we can't make .apk with
Haskell?
.apk is just an app package file format and is built with the tools that come with the Android SDK (not NDK), this has very little to do building the binaries itself. Android packages can contain native shared libraries, this what your Haskell program will be and the native shared/static libraries are generated via the Android NDK.
A language that has recently come to my attention is Eta.
Eta's compiler is a fork of GHC 7.10 which has a JVM backend. It is possible to use the generated JAR files to write Android apps and even use its Foreign Function Interface to call native Android Java libraries.
Brian McKenna has written a blog post about how to configure an Android Studio project to use an Eta library.
There is https://github.com/neurocyte/android-haskell-activity demonstrating Haskell code running.
I once came across the same Reddit thread, but it was old, and comments were closed. I sent a message to the OP, but am not sure whether it reached the recipient. My suggestion here (may work for older Androids where native activities were not possible).
I (developed in Haskell some time ago, but currently switched to Smalltalk) am currently developing a port of Squeak VM to Android. The way I am doing this is similar to what might be dealt with in a haskell-on-android project: a lump of C code which needs to be called from Java part of the application (basically all that can be done in Android is to handle various events; an application cannot poll for events itself and does not have any event loop). In my case the code is generated by the Squeak VM building tools, in the case of haskell on android this will be output from GHC of JHC or whatever front end used. This repo may be worth looking at:
http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/project
Under "src" there is the Java code which provides for user events interception and sending them to the native code (see the CogView class). The C code of the VM itself is not completely there (see squeakvm.org, the Cog branch for that), but one may get the idea. One also might look under http://gitorious.org/~golubovsky/cogvm/dmg-blessed/trees/master/platforms/android/vm which is the C frontend to the interpreter (including user events handling, some timekeeping, etc.)
Hope this helps.
Dmitry
There is https://github.com/conscell/hugs-android a port of HUGS Haskell interpreter to Android.
I think the general answer should come from source->source transformations, since loading specially compiled shared objects seems to be a bit of a kludge (involving ghc->c and a c->java step in the answers above). This question thus falls under the heading of Haskell on the JVM, which has been tried (with one step as a Java intermediate representation) and discussed at length. You could use frege if the libraries you need compile there. The only remaining steps would be the beginnings of the Android framework API translated into IO() actions and maybe a wrapper for building the manifest xml and apk.