android lint performance probe帮助.zip下载

This is a simple tool to help pinpoint performance bottlenecks in individual Android Lint checks. It uses Java byte code instrumentation to collect and report performance statistics per detector for a Lint analysis invoked from Gradle. It relies on YourKit Probes to do the byte code instrumentation part, although in principle alternative instrumentation agents could be used. This tool was involved in the 2x-level Lint performance improvements that landed with the Android Studio 3.3 release; there's a blog post with more details. Getting started This tool requires a valid YourKit installation. YourKit is a paid profiler, although trial versions are available. Once YourKit is installed, edit the properties in gradle.properties to point to the corresponding files in your YourKit installation. You will need to set both the yourkitJar property and the yourkitAgent property. Next, run to compile the tool and print out the JVM arguments needed to instrument Lint. Here's an example of what those JVM arguments will look like: Add the generated arguments to your Gradle JVM arguments in an Android project. (See Gradle documentation for how to set the org.gradle.jvmargs property.) Finally, invoke Lint from Gradle as you normally do. Once Lint finishes, performance statistics for each Lint detector should be printed to the console. Here's some sample output: Memory allocation instrumentation The tool also supports measuring memory allocations through the use of an allocation instrumentation agent. To enable this, generate the JVM arguments with this command instead: Here's some sample output: Troubleshooting If you get strange error messages from the Gradle JVM, double check that the JVM arguments are formatted and quoted properly. Quoting may be needed if there are spaces in the file paths, for example. Similarly, be aware that typos in the JVM arguments may cause YourKit to silently ignore the probe. If the JVM arguments have been applied properly but you still don't see performance stats output, it's worth checking to see if YourKit has reported any errors---especially if you've made code changes to the probe. To do this, run java with the JVM arguments generated by this tool. YourKit should print a line to standard error like this. Open that log file to see if there were any errors reported. For example, if you added a malformed regular expression to the @MethodPattern annotation in LintDetectorStats.java, you might see a line like this. Conversely, it's a good sign if you see a line like this. If you make code changes to the tool, be sure to run ./gradlew assemble in order to rebuild the probe. Also, be sure to start a new Gradle daemon for Lint; otherwise the old version of the tool could still be in use. This is easy to do by using the --no-daemon Gradle flag. Notes and tips The tool will print out three columns for each detector: total shows the total amount of time spent within any method in that detector self is similar to total, but it excludes any time spent in other instrumented callees calls shows the number of calls to any method in that detector In addition to individual Lint detectors, the tool also instruments LintDriver and TopDownAnalyzerFacadeForJVM. LintDriver drives the entire Lint analysis, so it will help show the total time spent in Lint. TopDownAnalyzerFacadeForJVM is essentially the entry point into the Kotlin compiler, so it is a good proxy for how much time is spent upfront analyzing a Kotlin module before Lint detectors can start. To include your own custom Lint checks in the output of the tool, you can add to the list of regular expressions in LintDetectorStats.java. Be aware that caching effects may distort the performance stats for individual detectors. For example, the first Lint check to run might get the blame for the initial cache misses when resolving calls, types, etc.