Hi Xav, Thanks for reply. I have investigated our script and found that the bottleneck is from proguard setup, If use -optimizationpasses 5, it takes quite a long time (> 6 mins) for each flavor build, once I as disable optimization (like the default proguard file does from sdk installation folder), the average speed is acceptable (40 seconds ~ 1 min).
I agree with you, I think parallel execution and overall build strategy balancing could be two good direction for improvement. Thanks, York On Tuesday, July 15, 2014 8:47:31 AM UTC+8, Xavier Ducrohet wrote: > > It's not really possible at the moment. It is something I've talked about > with the Gradle team. It would be nice for Gradle to detect that tasks of > similar types are using exactly the same inputs and therefore could share > their output. > > There are indeed plenty of cases where flavors are very lightweight where > it would be a big win. > > We are working on more core features right now but later down the line I'd > like to improve this. > > > On Wed, Jul 9, 2014 at 9:59 PM, Ye Wang <[email protected] <javascript:> > > wrote: > >> Hi, >> >> In the project I am currently working on, we use a single source base (1 >> main project + 5 library projects) and build bunch of apks (10 ~ 20) for >> every release, which only differ by several meta-data values in >> AndroidManifest.xml, for statistics and marketing purpose. >> >> I have been following the new build system for a while and have a play >> with it, I am able to get the Product Flavor running as expected. >> >> Here comes the question, each Product Flavor run the complete build life >> cycle, from compile source to merge libs to package apk. As you can see in >> our case, we don't need manipulate complex stuff like image resource or >> java source, only the contents of AndroidManifest.xml, the build script >> hence repeatedly doing same tasks in most of time with a different >> flavor prefix dexXXXRelease, packageYYYRelease and etc. As the result, >> dramatically increase the build time. >> >> Profile in Maven has the same dilemma, the current approach we used base >> on our own python script with apktool manipulate the apk to generate batch. >> Not sure if Gradle has the built-in feature to optimize this. As most of >> assembles (class, res and etc) are generate by the first flavor, I am >> thinking if it is possible to customize gradle to run only some specific >> task like packageRelease and dexRelease multiple time for each build type >> instead of once for every flavor. to boost performance in this case. >> >> Thanks for reading. >> York >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "adt-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
