com.facebook.buck.android.dalvik

Interface ZipSplitterFactory

All Known Implementing Classes:

DalvikAwareZipSplitterFactory

public interface ZipSplitterFactory

Method Summary

Modifier and Type

Method and Description

ZipSplitter

newInstance(ProjectFilesystem filesystem, Set<Path> inFiles, Path outPrimary, Path outSecondaryDir, String secondaryPattern, Path outDexStoresDir, java.util.function.Predicate<String> requiredInPrimaryZip, com.google.common.collect.ImmutableSet<String> secondaryHeadSet, com.google.common.collect.ImmutableSet<String> secondaryTailSet, com.google.common.collect.ImmutableMultimap<APKModule,String> additionalDexStores, APKModule rootAPKModule, ZipSplitter.DexSplitStrategy dexSplitStrategy, Path reportDir) Both combines and splits a set of input files into zip files such that no one output zip file has entries that in total exceed zipSizeHardLimit.

Method Detail

newInstance

ZipSplitter newInstance(ProjectFilesystem filesystem,
                        Set<Path> inFiles,
                        Path outPrimary,
                        Path outSecondaryDir,
                        String secondaryPattern,
                        Path outDexStoresDir,
                        java.util.function.Predicate<String> requiredInPrimaryZip,
                        com.google.common.collect.ImmutableSet<String> secondaryHeadSet,
                        com.google.common.collect.ImmutableSet<String> secondaryTailSet,
                        com.google.common.collect.ImmutableMultimap<APKModule,String> additionalDexStores,
                        APKModule rootAPKModule,
                        ZipSplitter.DexSplitStrategy dexSplitStrategy,
                        Path reportDir)

Both combines and splits a set of input files into zip files such that no one output zip file has entries that in total exceed zipSizeHardLimit. Input files can be themselves zip files, individual class/resource files, or a directory of such of files. The inputs are "opened", and the files contained within them are individually processed.

For example, given a set of inFiles of A.zip and B.zip where A.zip contains { A, B, C }, and B.zip contains { X, Y, Z }, a possible outcome of this method could yield outPrimary.zip containing { A, B }, outSecondary1.zip containing { C, X }, and outSecondary2.zip containing { Y, Z }.

This method exists as a critical utility to divide source code so large that dx/dexopt fail due to design constraints.

Parameters:

inFiles - Set of input files (directories or zip files) whose contents should be placed in the output zip files.

outPrimary - Primary output zip file.

outSecondaryDir - Directory to place secondary output zip files (if any are generated).

secondaryPattern - Pattern containing a single integer (%d) that forms the filename of output zip files placed in outSecondaryDir.

requiredInPrimaryZip - Determine which input entries are necessary in the primary output zip file. Note that this is referring to the entries contained within inFiles, not the input files themselves.

secondaryHeadSet - list of classes to include in the primary dex until it is full

secondaryTailSet - list of classes to include last in the secondary dex

additionalDexStores - mapping of APKModules to module names for creating additional dex stores beyond the primary and secondary dex

rootAPKModule -

reportDir - Directory where to publish a report of which classes were written to which zip files with a corresponding size estimate.