Android Studio Gradle Syncing/Building Performance - android

These are a series of questions for Android Studio programmers who have worked on large projects before. So, before I list the questions let me explain why I'm asking.
I couldn't help but notice it taking 36+ seconds for Gradle to sync and build for me to start programming every time I launch AS. It's not so much a problem now, but how about when the project starts to get over 26,000+ lines of code? So, now my real questions are:
1) Do large projects take significantly longer for Gradle to sync and build than a small one?
2) If it does, are there any levels of refactoring/error catching that I could bypass in the sync/build to make the process faster in the long run?
3) My computer can run any game on full ultra quality. Is a system spec that makes compiling and programming language processing faster than a gaming spec?
Thanks to all who contribute, and you will be acknowledged (with at least a vote) regardless of whether you can answer all the questions or not!

Lucky you. Gradle speeds have increased considerably over the last two years. As of today, even though still a bit slow, I'm pretty satisfied with the speed. Anyhow. Regarding your questions, here's my two cents:
Yes. But it's not a linear "function". I haven't come across any project that takes more than 3 or 4 mins tops when configured correctly, one especially was pretty big.
The only way to "speed up" the process is to allocate more memory. There are two ways here, inside the inner (module) gradle file, you can do this:
dexOptions {
javaMaxHeapSize "5g"
}
Or you can define a field inside the gradle.properties file:
org.gradle.jvmargs=-Xmx5632M
There is no system spec that I know of that will increase performance, but sounds like you got a pretty good system and you will not run into any troubles. A lot of progress has been made in the field.
Enjoy developing.

Yes, larger projects will take longer to sync and build. Lines of code is a contributing factor, as well as dependencies, number of assets, etc. Gradle is also somewhat infamous for being a bit slow.
This is dependent on your individual Gradle configuration. Removing unneeded steps (if you have configured some), such as signing the APK, may also help. 'Instant Run' is very quick for small changes but is somewhat untrustworthy. There's no way to 'skip' steps of compilation - if a recompile is needed, a recompile is needed. Trust that the compiler and IDE will optimise out any unnecessary steps and ensure that you are not asking for any unnecessary extra steps.
Gaming computers generally have fairly beefy processors, which are the main component used to sync and build a project. The disk read speed of your hard drive will also be a factor - SSDs will be much faster than platter drives - but it's comparatively much less important than your processor. Your video card, the other big component in a gaming PC, will not be used at all to build. A solid gaming PC will be more than adequate for development.
There are a few ways to shave time off your Gradle build times (for example) but build times will always be a reality.

Related

Clarification on What happens after installing MultiDex

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

How to test android library affect application's performance?

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

Multiple versions of Android App

Seeing as how there are no preprocessor directives (without jumping through some hurdles), I was wondering if there was an accepted way of doing the following:
Have an android app in the regular ol' android market that uses things like the camera, mic, etc.
Conditionally "swap out" certain features based on some build parameter.
Produce two APKs, one for each store
Ideally, I would want to keep the ANT gymnastics to a minimum ... and also ideally would not have to maintain two sets of files (ie. google_activity_layout.xml and amazon_activity_layout.xml).
edit: this answer looks interesting: https://stackoverflow.com/a/1813873/5416
I have been able to use XMLTask antlib to modify the AndroidManifest.xml as part of the -pre-build hook. I haven't used the mechanism you linked, but I would think that a combination of modifying the permissions and using the linked mechanism would achieve your goal. Since the permissions are checked at runtime vs. at compile time.
You can find the library here: http://www.oopsconsultancy.com/software/xmltask/
One thing to note, it will take some tinkering. My "ant monkey business" did take several hours of tinkering because of the way the apk is compiled together. If you are willing to run the full build a few times it should be less arduous and could probably just ad a completely new task to the beginning of the build.xml that is generated. Let me know if you have questions as I've been tinkering with this stuff a lot.

Speeding up the dex process with jar files, is it possible?

I have an "older" machine which is more than adequate for developing my first Android marketplace application BUT only with Java!
I recently tried Kawa and Scala (I switch to functional programming about six years ago with LISP/Scheme and I've absorbed Erlang and Haskell since then) and I must say that I really love Scalas conciseness and Kawa is still fantastic (used it a long time ago for a project).
However... the build time when "dexing" on my machine is into the minutes(!) when the 'dx' program works on the kawa.jar file.
Does anybody know if it is possible to "cache" or "pre-build" a Jar file so that the desxing process only does what has changed. It is just a little irritating and sad to see it dexing the jar files I've used even though they are the same as last time.
I could buy a faster new machine but I don't have the spare dosh right now so I want to know what optimisations I could make...
:(
Thanks.
This article might help - Custom Class Loading in Dalvik. You would have to use multiple pre-compiled dex files and perform some of the class loading yourself as required.
Maybe you could preinstall kawa.jar on your (rooted) android device, see here: http://zegoggl.es/2011/07/how-to-preinstall-scala-on-your-android-phone.html

Is using Scala on Android worth it? Is there a lot of overhead? Problems? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I was thinking of building an app on Android with Scala instead of the regular Java (or the equivalent I guess). Is it worth it?
Any problems and unnecessary headaches?
Working with Scala should be mostly painless, as the dex compiler just works with bytecode - which is exactly what Scala produces.
Your biggest problem then is the dependency on scala-library, as dex expects everything to be in a single Jar. This is best handled with Proguard (which will also remove unused code and give you a smaller executable, ideal for mobile)
Current best practice is to use SBT with the Android plugin; It'll take care of everything for you: http://github.com/jberkel/android-plugin
If you must use Eclipse and the plugin supplied by Google, then you're going to have a non-standard directory structure. I also wrote an article on how to deal with this: http://www.assembla.com/wiki/show/scala-ide/Developing_for_Android
But be warned... it takes a lot more effort that way!
There is a talk by guys from bu.mp on Scala Days 2011.
Disclaimer: While they talk a lot about issues they've faced, the overall experience was definitely positive. Moreover, this were the problems of one particular team and they are minor ones.
Summary:
Memory usage. Closures eat memory. Scala has closures all over the place. While it is not a relative big problem (memory overheads) on your table PC, it should be considered when you develop for mobile phone. You may ask: how they solved it? They had a hunt for a tight loops and then optimized them (rewritten in closureless scala/java). (26th minute) I think Java 8 with native closures support will ease this problem Next scala release will target java 8 platform with a new backend and aim for much better performance. Discussion on roadmap is here.
Slower compiler (as Michal Galpin said they have 15 seconds for Java code compilation, about a minute for Scala and about an order a magnitude more for Proguard, but note that it depends on your code base and machines, but I suspect that ratio will be the same). It especially annoying when you making UI, like moving pixels, buttons and so on, and want to quickly see the result. (7th minute)
There were some issues with inner classes which are quite common for Android (look at 23:00 for details).
There were rare bugs in scalac (scala compiler) in scala-java-collections interop. The problems were solved by writing this things explicitly (I suspect that is not a lot of boilerplate at all).
While he talks about IDEs too, I don't think that it is a problem (look this post, about Scala environment). Guys that do Scala IDE and IntelliJ do their work well and IDE support is getting better and better.
For unit testing one could use RoboSpecs (allows you to run unit tests inside JVM, not inside emulator), which is faster.
One of the biggest problems I've stumbled upon is the limitations of the dex format (no more than 65536 method references per dex file). Scala library simply doesn't fit into limits, so you have to workaround that by:
using Proguard that will trim the fat from scala lib. But it is really slow on my laptop, and is just wasting time in the development stage (but is much much helpfull when you are releasing your app to the Google Play)
using predexed library. The bad thing is that this project is a little abandoned and contains only 2.9.0-1 version.
preinstalling scala on your phone
Some guys claiming that there are problems with IDEs, but things getting changed fast: the current version of the IntelliJ IDEA 12 not only has a good support of Scala as a plugin, but also contains UI Designer for Android. Moreover, you can use Eclipse which has a support from both Android (by Google) and Scala (by Typesafe) sides. Android Studio (the new IDE based on IDEA which was announced on Google IO '13 and is developed by Google) support IDEA plugins thus Scala.
We discussed this at Scala Lift Off London last Friday and the consensus seemed to be that it generally works fine as long as you avoid Actors. Also, the sbt-android-plugin was highly recommended. Nathan Hamblen's blog has many posts on Android and the ones also tagged Scala have a lot of gotchas worth looking out for.

Categories

Resources