Hi am new to flutter when i do flutter run command its takes about 7 minutes to run my project to the emulator for a two page .dart file
My question, is it that as the project gets bigger the longer it takes to build when i do flutter run command.
note: my pc is a low end one
spec: 8gb ram AMD E1-6010 HP 15
when you run your project in the emulator or real device for the first time, flutter creates a build folder and uses it in other runs to speed up the build process or even help through hot reload. As a result, usually, it takes lower than the first time for running the project. If your project gets bigger, although it does not affect the build process very much (linearly or exponentially), it may take a little longer.
Related
Regarding the above topic, it usually takes this much time to install NDK. I ran the newly created app with react-native run-android command. My virtual device and android studio is also running along with react-native start in another terminal.
Please refer to below.
Of course it'll take time. The NDKs are pretty huge like above 1 GB in size irrespective of the platform.
My Gradle build time is usually around 12 seconds, but after around 10 - 20 builds it starts to increase at once, exponentially: 30 seconds, 50 seconds, 2 minutes, 5 minutes, etc. up to out of memory.
Healthy build:
:app:compileDev21DebugJavaWithJavac 4.783s
:app:transformClassesWithRealmTransformerForDev21Debug 3.011s
:app:transformClassesWithDexForDev21Debug 2.133s
:app:compileRetrolambdaDev21Debug 1.325s
:app:packageDev21Debug 0.997s
:app:processDev21DebugResources 0.703s
After 10 - 20 of those, it starts increasing:
:app:transformClassesWithDexForDev21Debug 39.172s
:app:compileDev21DebugJavaWithJavac 34.221s
:app:packageDev21Debug 9.922s
:app:transformClassesWithRealmTransformerForDev21Debug 8.353s
:app:compileRetrolambdaDev21Debug 3.120s
:app:fabricGenerateResourcesDev21Debug 1.376s
As you can see, every task increases in time.
I use Android Studio 2.2.2, but I had the problem since the last 3 versions or so. Gradle 2.14.1. Probably it’s related to our project. I use Mac, my colleague on Windows has the same on the same project. If I stop AS, kill Java and start AS again, that solves it for a while.
I am not using the Jack compiler (yet).
To be clear: my build time is NOT generally slow: 13 seconds is fine. This is not a duplicate of all the "slow build time" questions. Only after 10 - 20 builds the build time increases exponentially with every build.
Update: Make Gradle build "offline" didn't help. Using "gradle-3.1-all.zip" (distributionUrl in grade-wrapper.properties) also did not help.
Anyone had this problem and knows a solution?
I experienced(and somehow still facing) the same issue. There are some fixes that you can try.
1- Make Gradle build Offline.
2- Install Gradle on machine and use local installation alongside Offline work checked in Android Studio instead of Using wrapper which connects to proxy and takes more time with building cache of Studio.
I followed this and this article and it helped me not substantially but enough to get me nearly 6,7 hours of continuous development on 8GB memory system then i have to Invalidate and Restart.
It is fixed since the day that I removed Fabric (CrashLytics) and replaced it with FireBase Crashes. Fabric was most probably causing it, but I'm not 100% sure.
There are two options available to run unit tests in Android Studio:
Right click on the file with your unit tests (which is Gradle-Aware Make).
testAppDebugUnitTest task is from the list of available Gradle tasks.
The first one actually consists of two tasks:
- :app:assembleAppDebug and :app:assembleAppDebugUnitTest
The second one is just testAppDebugUnitTest itself.
The first one is a recommended way by Google Tools Team, but it takes as twice as much time compared to the second one.
There is no visible difference how to run unit tests except the duration. You might think your code won't be compiled without assembleAppDebug, but this is not true - changes you introduce to either class under a test or a test itself compiled and executed as expected.
So, what's the difference and why is it the recommended way if it takes as twice as much time to prepare everything before actual unit tests run?
I don't have much work experience with Gradle, But off course it is always better to use Google Team recommended tools instead of others.
it takes as twice as much time compared to the second one.
If you use the new Gradle build system with Android (or Android Studio) you might have realized, that even the simplest Gradle call (e.g. gradle project or grade tasks) is pretty slow.
To avoid this time taking processes in android studio you need to Speed up Gradle build time. It will definitely makes a difference
Here is few steps to speed up the Gradle build time >>
In compiler settings (Android Studio -> Preferences -> Project
settings[your project] -> Compiler (Gradle-based Android Projects)),
type --offline in the "Command-line options" box.
from ~4 minutes to ~20 seconds.
In another way, You can decrease this startup time of Gradle (on my computer down to two seconds), if you tell Gradle to use a daemon to build. Just create a file named gradle.properties in the following directory:
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
Add this line to the file:
org.gradle.daemon=true
From now on Gradle will use a daemon to build, whether you are using Gradle from command line or building in Android Studio. You could also place the gradle.properties file to the root directory of your project and commit it to your SCM system. But you would have to do this, for every project (if you want to use the daemon in every project).
Note: If you don’t build anything with Gradle for some time (currently 3 hours), it will stop the daemon, so that you will experience a long start-up time at the next build.
For more details please refer this Building and running app via Gradle and Android Studio is slower than via Eclipse
Performance improvements are one of the great tasks in the Gradle roadmap for 2015 (and reaching into 2016). So hope, we’ll see the general performance increasing within these years.
n g+ there is a discussion with the developers about it.
Hope this information will helps you.
The reason your option 1 takes twice as time is because most of the time is wasted on spinning up Gradle and checking if tasks are up to date. So running an no-op assemble will make it twice as long. You can verify this by running it yourself and check the time wasted by doing an no-op.
With gradle, running with "--offline --daemon --parallel" can get you somewhere (offline is helpful when you have slow internet access to Maven/JCenter repos, daemon is helpful to keep files cached, and parallel is particularly helpful if you have MultiDex on and have split your app into small modules)
If you are just asking about "What's the fastest way to run unit tests in Android?" without considering the change you would need, I would recommend switching to Buck (https://buckbuild.com/), which is 10x faster than Gradle on dex-xing and spinning up tests but has limited AS support.
The following measures were taken to speed up gradle build from this (SO post)
org.gradle.parallel=true, org.gradle.daemon=true
build from terminal and not from android Studio
building with ./gradlew assembleDebug --offline
Problem:
Even after these measures build times can take upto 6-8 minutes for a single line of code change! and during this time computer mostly freezes and nothing else can be done except to stare at the terminal. I've noticed that "app:dexDebug" takes a lot of time in this. What are the possible causes?
Relevant files:
Terminal build dump
build.gradle(app)
build.gradle(project)
System details:
Android Studio 1.2.2
Description: Ubuntu 14.04.2 LTS
You can try disabling your lint checks by adding this code to your build.gradle
tasks.whenTaskAdded { task ->
if (task.name.toLowerCase().contains("lint")) {
task.enabled = false
}
}
Also you can use the --profile parameter to export a html report of what's taking so long in your build time
EDIT: removed the debug check
We had a similar problem: our build took about 4 minutes. After some research, we get next steps:
Try turning on offline work in your Gradle settings (Ctrl + Alt + S for the Settings, then Build Tools -> Gradle settings). Usually, we do not update libraries so often and Gradle will not check that they are up to date.
Multidex increases the time for build: Android documentation. To mitigate this, you can add additional flavors for debug and production builds, setting for debug builds minSdk = 21 (suggestion from official site).
If you have several modules in project, try to flatten them into one or at least extract "Library project" and connect it as .aar
As a result, our build time decreased to about minute - minute and a half. Hope these suggestions will help you too.
And if we will talk about small changes, starting from Android Studio 2.0, it is possible to use Instant run and Incremental build, which makes small changes in method or layout even faster.
Understand that Gradle Build has nothing to do with your CPU Speed or RAM. The reason why the Build gets slower in your PC is due to your Internet Connection. The build can take nearly ~100 MB approx. of data to complete it's process. Even if your Internet Connection is fast and your connection's PING speed is slow, it takes more time.
We have a large Xamarin.Android project with two depending projects and a bunch of third party dll's. Doing a debug deployment (without any changes) onto a Hax-x86 Emulator or a Nexus 5 device is painfully slow (> 80 seconds). For comparison the Xamarin.iOS version of the App deploys in under seven seconds onto a real device.
To test the deployment times I've also created a fresh Xamarin.Android project which deploys in about four seconds. When I add a depending project, the deploy time goes up to seven seconds. When I add a layout file to the depending project the deployment time increases to about ten seconds.
Is it possible to speed the Android build and deployment up with Xamarin Studio? A big Eclipse Android Projects is deployed rather quick in comparison.
Update:
Just running the installation build step takes about 40 seconds:
time xbuild /t:Install BigApp.csproj
...
...
...
Time Elapsed 00:00:42.8526970
about half the time is spend where the above command prints to console:
Target _CompileDex:
JavaSourceFiles:
JavaLibraries:
ExternalJavaLibraries:
Tool /usr//bin/java execution started with arguments: -Xmx512M -jar
/Users/myname/Library/Developer/Xamarin/android-sdk-mac_x86/build-tools/17.0.0//lib/dx.jar
--no-strict --dex --output=obj/Debug/android/bin/classes.dex obj/Debug/android/bin/classes
/Library/Frameworks/Xamarin.Android.framework/Versions/Current/lib/mandroid/platforms/android-15/mono.android.jar
/Users/myname/Projects/BigApp/obj/Debug/__library_projects__/TestFlightBindings.Jars.TestFlightLib_1_2.jar
/Users/myname/Projects/BigApp/obj/Debug/__library_projects__/android-support-v4.jar
/Users/myname/Projects/BigApp/obj/Debug/__library_projects__/classes.jar
/Users/myname/Library/Developer/Xamarin/android-sdk-mac_x86/extras/google/google_play_services/libproject/google-play-services_lib/libs/google-play-services.jar
When I run the solution from Xamarin Studio this step happens twice. Once for the depending project and once for the main project. I tried to reproduce this behavior on the console with
"/Applications/Xamarin Studio.app/Contents/MacOS/mdtool" -v build "--configuration:Debug -t Install" "BigApp.sln"
but that only builds the main project.
Update:
I created a small demo project with very slow deployment time:
https://github.com/perpetual-mobile/SlowAndroidDeploymentWithXamarin
I contacted the Xamarin guys about this problem and they fixed two issues in Xamarin.Android:
https://bugzilla.xamarin.com/show_bug.cgi?id=16622 (provided since Xamarin Android 4.12.0)
https://bugzilla.xamarin.com/show_bug.cgi?id=15162 (provided since Xamarin Android 4.10.0)
The build time for my huge project without any changes is now ~5 seconds. And when making a code change in the deepest depending lib a deploy cycle does not take longer than 16 seconds.