Hi titanium team / Experts,
I'm using Titanium and I look for a way to make my app build faster so it won't take so long to test it every time. Even when I run it twice without adding anything, it takes about 2 minutes to build and 15 more seconds to install on my device.
I think the key is in "Forcing rebuild: JavaScript files need to be re-encrypted". Is there a way to avoid this rebuilding?
The development is being done under mac machine
Rebuilding application can, depending on your mac specs, take 2 minutes indeed. A much faster way of developing is using LiveView or TiShadow (if you're using open source tools). Both methods don't need re-compiling but will only recompile files that need recompiling.
Be aware both methods do not fully clean the app when restarted/rebuilding, things like event listeners, collections and models can cause issues. So every now and then an actual restart is required, and sometimes bugs can appear that only appear during liveview development. But mostly, especially for UI improvements these methods greatly increase development speed.
There are a few ways to speed up your builds. Some of which is described here: https://wiki.appcelerator.org/pages/viewpage.action?pageId=29002843
However I also discuss some other methods.
TiShadow
Consider using TiShadow. It can simultaneously live deploy and test across multiple real devices using any OS for development. I've used it for some time, and it's AMAZING! Don't understand how anyone uses Titanium without it
Use ccache
The Android NDK r7, required by V8 and Titanium Mobile 1.8+, can use ccache, a tool for reusing cached C/C++ compilations. We get huge improvements in build time with it.
Install HomeBrew if you don't have it installed already
Install ccache with the following command: brew install ccache
Set an environment variable NDK_CCACHE to point to it. Installed with HomeBrew, the command would be: export NDK_CCACHE=/usr/local/bin/ccache
Parallelize Compiling
The NDK can also parallelize while compiling, which can speed up the process.
Determine how many cores your machine has. You can use this command on Mac OSX: system_profiler | grep -i "Number Of Cores"
Multiply the above number by 2. So if the above command returned Number of Cores: 2, then your value should be 4.
Set an environment variable NUM_CPUS equal to the above value. In this case: export NUM_CPUS=4
Don't Build the Docs on Every Compile
Skip building the JSCA files (the files used by Titanium Studio's code assist feature). You don't need them if you're just making a build for yourself for testing. To skip, run scons like this:
scons build_jsca=0
Live View
Live view reduces the need to recompile as is decribed here: https://wiki.appcelerator.org/display/guides2/LiveView
Speed Up Emulator
Although this doesn't really speed up your build time, speeding up your emulator helps speed up run-time a lot. Some methods are described here: https://gist.github.com/adam-lynch/7247983
GenyMotion is also a much faster emulator I have been told. Haven't tried it myself.
Related
I recently switched from Eclipse+ADT to Android Studio. My app is a full native C++ application. I use Android Studio 2.0 Beta 5 and Gradle Experimental 0.6.0-beta4.
The build process of Android Studio is very slow for the native code. I read all questions on Stackoverflow and Internet. I applied all suggested methods (--offline, --daemon, --parallel, -XmxSize, etc..). They mostly addresses to speed up the build of Java code. The compiling process of native C++ files (ndk-build) is still very slow. Even if I write one line C++ code, I wait 5-7 minutes each time I click Run button, where the compiling time of Eclipse was around 15-20 seconds for the same job.
Do you have any suggestion to speed up the compiling process of the native code (C/C++) on Android Studio?
If you're building on linux I've got a hack for you to speed up the NDK build:
cd <ndk-bundle-path>
mv ndk-build ndk-build2
Now create a shell script called "ndk-build" containing the following:
#!/bin/sh
$(dirname $0)/ndk-build2 -j 8 $#
Now set the execute permissions for the new script:
chmod 775 ndk-build
Now, anyone who launch ndk-build (including gradle/android studio) will be force to bang out object files on 8 cores simultaneously. 8 cores is just an example. You must set this to what ever number of cores you have available. If you set it too high compared to the number of available cores you'll usually lose performance. If the CPU have hyper threading you can double the the number of cores.
I am sure there is a equivalent way of doing it on windows with a batch script or something but I don't have a windows machine available atm.
I will give an answer to my old question to close it.
In the end of the story, we integrated cmake into the project. It works as fast as old Eclipse build performance.
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
When we first started developing for android, we had 2 projects:
One for the 'core' functionality, other for the 'business' functionality.
So far so good, we went through bad times waiting so much time for compilation of XML changes, but life was still quite bearable.
After some time, we evolved (or not) to come with 9 projects. For some projects, we have a 'test' project.
We also have some library projects, for instance, we have two different projects for different versions of android, and we have a 'shared' project for shared configs or controllers.
The reason for that is because our application is quite big.
When we make some changes on the core project, we usually have to recompile, and 'clean' the workspace with eclipse. Also, we usually have to use the 'Build Project' option a few times for the projects to update their references, the first build hardly compiles everything, we call this in our team 'COMBO', which is the combination of 'F5' and 'CTRL+B' to compile the projects.
All this setup is killing a lot of time and making developers sad, like, a team of 6 developers :(
I know that by this time we should pretty much know all the issues and the best options, but I can't believe the way it is. And after so many time searching and trying to improve, we can't seem to find other solutions to improve development time with android.
Our set of tools is:
Eclipse 4.2.1
ADT 21.1.0
Eclipse Colour Themes (for a cute code)
SDK always updated
Hardware:
Windows 7 Professional 64 bits
8 GB RAM
Intel Core i5-3470 3.20GHz
I would love answers about:
Compilation time improvement: Did you found any IDE that for YOU it was faster than eclipse? Why? How was the setup? What are the drawbacks of using ADT and how can I improve performance with it, while using multiple projects?
Project references management, is there any suggestion on how
to speed up build? Should I put the whole source code in a single project?
Any way to speed up development when you have the device and need to deploy it while testing the application?
Try Intellij.
In the latest version, 12, they made project build improvements that make it much faster than 11 and Eclipse.
Parallelization
Note also the third column, called Parallelized. This
is a new compiler option which allows you to use more than one core
for building a project. In this case the compiler runs for multiple
independent project modules in parallel. Since each compiler thread
uses file system, the benefit of parallelizing highly depends on how
fast you hard drive is. Still the average gain in performance is
spread between 10 and 20 percent for large projects.
Automatic Make
One more exciting compiler option added in IntelliJ
IDEA 12 is automatic make. This is another time-saver, which triggers
project make automatically on every change. Since the compiler runs in
a separate process, it is able to compile modified files in the
background, while you are doing something else. This means your
project is in compiled state all the time, so you don’t need to wait
any time you want to run it.
http://blogs.jetbrains.com/idea/tag/brand-new-compiler/
Also if you are using git for version control I have noticed Intellij is much better at updating after I switch branches. It integrates well with git and notices that you switched branches and refreshes and cleans out the project in the background automatically, while on Eclipse you might have to refresh and clean manually.
I'm currently working on a large Android app using a massive amount of C++ code.
It compiles and runs, so far so good.
Unfortunately, every time I modify something in the structure of my native source (add/delete/rename/move a file), which happens pretty often, ndk-build rebuilds the whole source, even the untouched files.
Does anyone know how I can set up the Android NDK to build incrementally somehow?
Thanks in advance
I got fed up with the NDK build system, studied it for a bit, and wrote my own makefiles. This was not hard.
However, it was then pointed out to me that by doing this, I would have to take responsibility for tracking future changes to the platform, for example if it becomes necessary to ship binaries for additional processor types, I'd have to modify my homegrown build solution to do that too.
In other contexts, I've sometimes had projects with two build systems - one for quick experiments, another for deployable builds. The time spent updating both now and then was saved many times in the speed gain for daily work. Provided I had to do a real build at least every week or two, things never got very far out of consistency (and both build scripts were in the revision control system, so there was history to examine). Something like this could be done with a custom makefile for debug builds and still using the NDK build system for deployable packages.
(In one case of doing a lot of experiments at the edge of what the platform permits, I actually had my makefile pushing the updated .so onto the device and gave my application one of the discouraged hard-quit buttons, so I could restart it using an updated native library without even having to rebuild and reinstall the apk)