I have been during the last couple of months playing and building a full app in compose. My project has grow, and now with Kodein and other libraries that work already with compose I'm starting to realize how slow sometimes the IDE build the app just to show a simple preview. It was great on a new project to change code, compile in 3-5s and see the result.
But now, it's taking between 30-60s even if the change in the code was minimal.
Is there any way presently to improve the building speed performance for the previews and compose projects?
Try to put all UI components in a structured way, for example, do not put all functions in one file by doing this all functions with preview annotation will run at the same time and will result in slow rendering.
The Bad News
Under the hood, Compose works by performing annotation processing to turn your declarative #Compose functions into imperative rendering code. This annotation processing is done at build-time, which means it adds an extra step in the build process.
With XML and the View system, the UI wrangling is done at runtime. XML layouts are inflated at runtime, with no annotation processing necessary. This means that writing UI with Compose will always increase your build time compared to writing UI imperatively (with XML and the View system).
The Good News
Once you've accepted that you'll never reach the same build performance you had with the View system, you can start optimising. There are things you can do to take advantage of the gradle build cache, so that you only need to rebuild parts of the codebase since the last build. The official Gradle performance guide is here: https://docs.gradle.org/current/userguide/performance.html
A big potential gain is making use of gradle modules:
gradle can build independent modules in parallel
gradle can rebuild only the modules that have been updated
By splitting your codebase into modules, in particular extracting your Compose code to a dedicated UI module, you could see considerable build time improvements. I think this article explains this setup pretty well: https://proandroiddev.com/modular-architecture-for-faster-build-time-d58397cb7bfe
The Future
The Android Studio team seem to be focused on making Compose Previews render more quickly.
In the Artic Fox update, they added support for Live Edit of Literals. It works well in very specific circumstances.
In the Electric Eel update, they added Immediate Updates to Previews. Note that despite the name, updates are far from immediate. There are also many cases where a manual refresh of the Preview is still necessary.
In the Flamingo update, they added experimental support for Live Edit. Again, with a long list of exceptions.
Right now this tooling is not all there. But it is certainly getting better every update, and that makes me hopeful for the future!
Related
I decided to make an application on jetpack compose but when I download the Android Studio canary version 2021.1.1.1 and I try to write some code to see the changes on the preview at the right the preview tab says the preview is not up to date (or something like this) and requires a full project re-build to let me see my code changes
As of May 2022, There is no solution. Sorry!
Perhaps someday this will change. Until then, if you use jetpack compose, you'll have to do a rebuild your entire project to see the tiniest change in layout.
Furthermore, the requirement that you essentially have to write all your composable functions twice to preview them doubles the amount of boilerplate code you have to write and nearly guarantees that there will be code differences between the preview and actual behavior. Can you say, "Extremely easy to introduce bugs"? I thought you could.
For now, I recommend sticking with the old xml layouts. At least your work flow will be a lot faster. jetpack compose is simply not ready yet.
Why does gradle sync happen after creating new Activity?
Any way to stop this unnecessary build (which takes a huge time in big projects) without any impact?
It's not unnecessary. When you create a new activity using the automatic option for it, AS will also add an entry for it in you manifest file. This is most likely why it syncs with Gradle as that will also reload the manifest file (among other things).
It should also be mentioned that a Gradle sync is not a full project build. It can take some time in larger projects sure, but if it's taking an extremely long time (I'dd say more then 5-10s) you might want to have a look at your Gradle setup and see if there are any sore spots in it. If you are using the Kotlin DSL then building your build scripts will naturally take more time and this is one of the draw backs of using them.
Also how often do you create new activities? For me this is not something I do much at all (on average maybe once a week at best). I don't think it would save any time and probably cost more even if you could disable it (which I doubt you can as, like I stated above, it is needed). If it really costs you that much time you have to optimize your Gradle setup, otherwise their will be other spots in your workflow where you can save more time with less effort.
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).
I know that new versions both support NDK for android applications.
But many plugins doesnt work with gradle-experimental.
What is gradle?
Gradle is an advanced build system as well as an advanced build toolkit allowing to create custom build logic through plugins.
What is gradle-experimental?
The new experimental plugin is based on Gradle’s new component model mechanism, which allows significant reduction in configuration time. It also includes NDK integration for building JNI applications. This user guides provides details on how to use it and highlights the difference between the new plugin and the original plugin.
WARNING: Note that this is plugin is at the experimental stage. The Gradle API for the new component model is not final, which means it’ll only work with a specific version of Gradle until the APIs are final.
Additionally, the DSL is likely change significantly, as APIs to create the DSL are finalized.
This is a very early preview of the plugin for feedback on performance and NDK integration.
Essentially, gradle-experimental is a work in progress (as stated above this plugin is at the experimental stage) of what gradle itself should become in the future.
An analogy:
A house was built some years ago and has been through alot of improvement. Everything is in place, and it appears done. Today, it is a place where you know you'll be safe if you live in it.
Another house is being built at this very moment, because the owners of the house above have plans to move. Some rooms have been constructed, some haven't. Some doors and windows are already in place, some have not even been ordered yet. Some areas they don't even know yet what they are going to do with. Some rooms might appear done, but they may very well be refurnished at any point in time. The ceiling may collapse, the floor may disappear, you'd only know about it when it has already happened. This house is not currently safe to live in.
Gradle is the first house.
Gradle-experimental is the second house.
I don't think there is much use in comparing them at this stage. If you don't absolutely need to use gradle-experimental for whatever reason, just stick with the current and stable gradle.
I'm looking into greenDAO as an option for our database mapping needs. I noticed that greenDao does not use annotation processing, but instead uses a handmade java program to generate the source code.
Having just finished a small utility which uses annotation processing for generating code at compile time (to be used with Android ContentProviders), I wonder if greenDao ever considered using annotation processing and, if yes, why it was decided not to.
I would like to hook the code generation with the compile cycle of our Android projects and it would be nice if we could skip the extra step in creating the SourceGenerator project.
First of all, I'm not a member of greendao.
I'm just using it for some time now (and extended it to my needs). So some of my information is just a guess or my opinion.
I don't think greendao will support annotation-processing in near future, since there is nothing on their projects page.
Furthermore I think there are other features which seem more important.
For example:
Joins
ContentResolvers
extended code generators
On top of that I think database-structure shouldn't change as much as code does, so it is completely ok to have the code generation in a separate project, keeping the build-process of the app faster.
This may be a reason for not using annotations.
I'm using greendao for about 6 months now and I am at DB-Version 23. I am glad the generation didn't take place every time I built the project.
Greendao now supports annotation processing!
It is a feature in the latest major release (greenDao 3.0).
Check out the migration guide!