I. INTRODUCTION
AAR is a file format similar to a jar. But there is a difference between them.
Jar: Contains only class and manifest files, no resource files.
AAR: Contains class files and resource files. This is the exclusive "jar" of Android.
Packaging the code into an AAR file can speed up Androidstudio to some extent.
In particular, packaging Module into AAR file, the effect of Ascension is significant.
Two. How to get AAR
1. module's AAR document
Packaging a Module from a Androidstudio project into an AAR is actually very simple.
There is a folder below each Module's directory: Build\outputs\aar.
Below this folder is a corresponding AAR file for this Module.
In general, there will be two AAR files, a debug version, and a release version.
We choose to release the OK.
AAR file diagram
Attention:
The new module is not in this folder. At this point, you can use two methods to build this folder
Run the whole project again, this folder will automatically generate
Executes the command./gradlew Assemblerelease can also generate this folder
2. AAR in remote warehouses
The remote repository's dependent libraries are often referenced in the project.
At this point, we can also introduce it in the form of AAR into the project.
This dependent AAR is really easy to find.
When you configure a dependent library, click Sync Now.
Androidstudio will automatically download this library to the C disk (Windows). You can find this file.
Here I am using Everything to search, it is convenient to find this library download folder. Other operating systems on their own search it, in short, to find the download folder on this project OK.
This download folder contains everything you need for this project: AAR, jar, and so on.
This process will be explained in detail in a later example.
Note:
Everything is a search software that can instantly search the whole.
is a very useful software. But unfortunately only the Windows version.
Website address: https://www.voidtools.com/
Three. How to use AAR
To use the AAR file, you need to go through the following steps:
1. Add the following configuration to the app Build.gradle
Repositories {
Flatdir {
dirs ' libs '//AAR directory
}
}}
2. Copy AAR files to the App/libs directory
3. Add AAR reference to dependencies
Compile (name: ' Zbar-release ', ext: ' AAR ')
Four. Leakcanary Project sample
Because the module example is relatively simple, select a remote code base as an example.
Here is an example of using a frequently used memory detection project, Leakcanary.
We usually use dependencies to use this library:
Debugcompile ' com.squareup.leakcanary:leakcanary-android:1.3 '
Releasecompile ' com.squareup.leakcanary:leakcanary-android-no-op:1.3 '
When Sync now is complete, we can find this project folder in C-Disk (Windows).
The screenshot of the project folder is as follows:
Leakcanary Project Sample Diagram
This folder has the following two libraries we need: Leakcanary-android and Leakcanary-android-no-op
Click the Leakcanary-android folder, the directory structure is as follows (1.3 is the corresponding version number):
Leakcanary-android folder
Open the innermost folder and you will find that there are three main types of files:
- Jar file: Some items are provided as a jar file
- AAR files: Some projects are provided in AAR documents
- Pom file: (Project Object Model), which is actually an XML, is a description of some of the necessary information. Here we only care about one node information: <DEPENDENCIES>: Declaring a dependency list
We use a text editor to open the Pom file under the Leakcanary-android folder:
...
<dependencies>
<dependency>
<!--package group ID, which is usually the reverse of the domain name that the publisher owns, to avoid duplication with others-->
<groupId> Com.squareup.leakcanary</groupid>
<!--package Artifactid is actually the group below should have a smaller collation-->
<artifactId> Leakcanary-analyzer</artifactid>
<!--version number-->
<version>1.3</version>
< scope>compile</scope>
</dependency>
</dependencies>
...
To learn more about the Pom file, click here
When we open the leakcanary-android pom file,
We find that leakcanary-android relies on the 1.3 version of Leakcanary-analyzer.
Again, we open Leakcanary-analyzer's pom file,
Found Leakcanary-analyzer dependent on leakcanary-watcher and haha.
Leakcanary-watcher and haha are not dependent on anything.
So the whole leakcanary-android import local stuff is four:
- Leakcanary-android
- Leakcanary-analyzer
- Leakcanary-watcher
- haha
In the same way go to layer by layer parsing leakcanary-android-no-op, all the required files are imported into the Androidstudio. So the whole leakcanary is actually localized by us.
The comparison of the two results is as follows:
Debugcompile ' com.squareup.leakcanary:leakcanary-android:1.3 '
Releasecompile ' com.squareup.leakcanary:leakcanary-android-no-op:1.3 '
Debugcompile (name: ' leakcanary-android-1.3 ', ext: ' AAR ')
Compile files (' Libs/leakcanary-analyzer-1.3.jar ')
Compile files (' Libs/leakcanary-watcher-1.3.jar ')
Compile files (' Libs/haha-1.1.jar ')
Releasecompile (name: ' leakcanary-android-no-op-1.3 ', ext: ' AAR ')
This translates the entire leakcanary project completely into a local dependency.
http://www.jianshu.com/p/59efa895589e