Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issue in findbugs #12

Open
gengjiawen opened this issue Mar 29, 2017 · 4 comments
Open

Performance issue in findbugs #12

gengjiawen opened this issue Mar 29, 2017 · 4 comments

Comments

@gengjiawen
Copy link
Contributor

From the code we can see findbugs depends on assemble, but assemble execute both debug and release build.And if we have multi product flavors, this will go even worse. Especially in china, we have such a thing called "multi channel package".
So for now, I change the depend to "assembleDebug", but it still need a lots of time, since I have lots of product flavors.
Any suggestion I can make findbugs faster?

@Piasy
Copy link
Owner

Piasy commented Mar 29, 2017

Can we make it just depend on a single flavor's assemble task?

@gengjiawen
Copy link
Contributor Author

gengjiawen commented Mar 29, 2017

yes, I find a way (commonLibrary is a library project, so it has no product flavor).Sample code :

task findbugs(type: FindBugs, group: 'verification') {
    println("findbugs for ${project.getName()}")
    if (project.getName().equals("commonLibrary")){
        dependsOn("assembleDebug")
    } else {
        dependsOn("assembleDevArmeabiDebug")
    }
}

@gengjiawen
Copy link
Contributor Author

But in android project, I think default dependsOn "assembleDebug" is a better idea.Because assemble execute both debug and release (proguard will consume a lots of time from my experience) task and other product flavor if there has, this will be very slow.

@Piasy
Copy link
Owner

Piasy commented Mar 29, 2017

Yeah, that make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants