My project's turn-around had been OK (not exactly fast, but bearable) until I added a bunch of external jars. Since then, build times are in minutes for a program that has some 30000-40000 lines of Java, roughly 10 megs of assets and barely any resources. I googled it and it appears that dexing is the part that takes inordinate amounts of time because 1) it's slow by itself and 2) it's not incremental. The latter point means a single line change triggers re-dexing everything including external jars that couldn't have possibly changed (the project doesn't even contain their sources).
I came across posts that suggested some effort was being invested into making dexing incremental but they were about 6-9 months old IIRC and as far as I can tell, nothing's changed in released SDK versions. If dexing is fixed I believe build times would still not become fast - but workable at least. How long the "uploading to device" part takes seems to depend on the device rather strongly - at least the transfer rates seem to vary a lot (I've seen 0.5-2 megs/sec). Some noticeable time is spent once the APK arrives on the device but I've no idea what it's used for. On Fri, Oct 12, 2012 at 5:25 PM, Tilekab <tile...@gmail.com> wrote: > Hi. > I'm sure people have ranted about this in other threads, but here goes. > I work for a company that builds a suite of big (=lots of layouts, lots of > graphical resources, lots of everything) apps for iPhone, Android and > Windows phone. The apps are 'identical' (obviously they are nativized for > the platforms) on each os. > I have been working on ios and Android. > Turnaround when changing a line of code and running it on device (Android, > since the emulator is way too slow) and simulator for iPhone differs in the > order of minutes. Note that this does not include any changes to layouts or > other resources that would cause a regeneration of R.java and rebuilding of > the whole shebang. > It has come to the point where it is almost unworkable. > For some new features, I set up a whole nother project with just the > Activity I'm working on, but that takes time and is not always doable since > it is not easy to lift code into a separate project without having to add > everything it depends on. > Even though I am a far more experienced Java developer (since 1997 or so) > than Objective C, I am way more productive on ios. Change, run, test, > change, run, test. That's how developers do their job. And the current tool > chain does not support it on Android when the app becomes non-trivial and > grows in size. > This is a call for action! The frustration of working much more slowly on > Android than I am capable of is killing my soul > Is there work being done on this? > When we estimate the time for new projects on ios and android, we have up > until now estimated about the same. But this is going to change. I would add > a 30%-40% extra to an android project since we have to charge for the poor > devs sitting there waiting for 'generating R.java', 'Discombobulating > classes.dex', 'Gift wrapping resources', 'Spinning hamster wheel', > 'Uploading to device' (which in itself takes about a minute!!!!) > > Happy coding! > /Tile > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
