Android 5.1 Dex配置

  1. 打开odex编译优化
  2. 预编译的包不进行优化
  3. 只进行BOOT.img 优化
  4. LOCAL_DEX_PREOPT 编译变量使用
  5. PRODUCT_DEX_PREOPT_ 编译变量使用
  • Android 7.0 之后的优化
  • 打开odex编译优化

    product BoardConfig.mk 文件中,添加编译变量: WITH_DEXPREOPT := true

    升级包小了,第一次开机时间极其慢;

    预编译的包不进行优化

    预编译的包是指那些在模块编译文件中指定为:include $(BUILD_PREBUILT) 的APK和JAR包等,这在升级包中占了一大部门;
    DONT_DEXPREOPT_PREBUILTS 变量就可以配置这部门代码是否进行预编译优化;

    DONT_DEXPREOPT_PREBUILTS := true 后,编译系统将会阻止 prebuild 包的odex优化;

    只进行BOOT.img 优化

    Android启动过程中,boot.img包含了大部分底层系统的启动和初始化,主要包含在boot.art文件中;
    使用 WITH_DEXPREOPT_BOOT_IMG_ONLY 编译变量,可以控制编译系统只进行boot.img的优化;
    使能该变量后,将会大量节省system分区的大小,但同时意味着所有的app都需要在第一次重启的时候进行odex优化;

    所以最好是通过 DONT_DEXPREOPT_PREBUILTS 进行更精确的控制;

    LOCAL_DEX_PREOPT 编译变量使用

    每个app应用,可以通过该编译变量进行控制是否进行odex优化;
    在 app’s Android.mk,进行变量赋值 LOCAL_DEX_PREOPT := false

    PRODUCT_DEX_PREOPT_ 编译变量使用

    在 post-L 发行版本之后,添加了这个系列的编译变量,进行更深入控制预编译的优化;

    PRODUCT_DEX_PREOPT_BOOT_FLAGS 传递参数给 dex2oat 命令,控制boot.img的编译
    PRODUCT_DEX_PREOPT_DEFAULT_FLAGS 传递默认参数给 dex2oat 命令,控制除了 boot.img的编译,即jar包和apk文件
    $(call add-product-dex-preopt-module-config,services,–compiler-filter=space)

    或者 直接关闭模块的预编译优化

    $(call add-product-dex-preopt-module-config,Calculator,disable)

    Android 7.0 之后的优化

    7.0后,系统可以分为A/B两个分区,OTA升级以及APK的优化不影响用户前台的正常使用,这样既减小了升级包的大小,又提升了第一次开机速度;

    预加载类文件

    预加载类会由zygote统一初始化,这样使后续使用到这些类的app开启速度加快;但是预加载类的使用在实际项目中要非常注意,需要仔细评估后确认权衡值,太多的预加载类会导致一些不常用的类消耗宝贵的内存资源,相反则会导致常用的类在不同应用中独立加载,各自有一个备份,既减慢应用开启速度,也是浪费内存;

    预加载类的定义列表,默认放置在 frameworks/base/preloaded-classes ,也可以在产品的devic.mk中添加自行定义的预加载列表:

    PRODUCT_COPY_FILES += :system/etc/preloaded-classes

    编译类列表

    结合 PRODUCT_DEX_PREOPT_BOOT_FLAGS 和 compiled-classes 可以控制编译系统是否在预编译优化中编译这些类;
    不过上述列表只能定义启动类的一个子集,适合用于那些存储空间非常有限,不能全局优化编译整个boot.img 分区的设备,所以对我们来说并不适合;


    ref:
    http://blog.csdn.net/austindev/article/details/61194249
    https://source.android.com/devices/tech/dalvik/configure

    Configuring ART

    This page discusses how to configure ART and its compilation options. Topics addressed here include configuration of pre-compilation of the system image, dex2oat compilation options, and how to trade off system partition space, data partition space, and performance.

    See ART and Dalvik, the Dalvik Executable format, and the remaining pages on source.android.com to work with ART. See Verifying App Behavior on the Android Runtime (ART) to ensure your apps work properly.

    How ART works

    ART uses ahead-of-time (AOT) compilation, and starting in Android 7.0 (Nougat or N), it uses a hybrid combination of AOT, just-in-time (JIT) compilation, and profile-guided compilation. The combination of all these compilation modes is configurable and will be discussed in this section. As an example, Pixel devices are configured with the following compilation flow:

    An application is initially installed without any AOT compilation. The first few times the application runs, it will be interpreted, and methods frequently executed will be JIT compiled.
    When the device is idle and charging, a compilation daemon runs to AOT-compile frequently used code based on a profile generated during the first runs.
    The next restart of an application will use the profile-guided code and avoid doing JIT compilation at runtime for methods already compiled. Methods that get JIT-compiled during the new runs will be added to the profile, which will then be picked up by the compilation daemon.
    ART comprises a compiler (the dex2oat tool) and a runtime (libart.so) that is loaded for starting the Zygote. The dex2oat tool takes an APK file and generates one or more compilation artifact files that the runtime loads. The number of files, their extensions, and names are subject to change across releases, but as of the Android O release, the files being generated are:

    .vdex: contains the uncompressed DEX code of the APK, with some additional metadata to speed up verification.
    .odex: contains AOT compiled code for methods in the APK.
    .art (optional): contains ART internal representations of some strings and classes listed in the APK, used to speed application startup.
    Compilation options

    Compilation options for ART are of two categories:

    System ROM configuration: what code gets AOT-compiled when building a system image.
    Runtime configuration: how ART compiles and runs applications on a device.
    One core ART option to configure these two categories is compiler filters. Compiler filters drive how ART compiles DEX code and is an option passed to the dex2oat tool. Starting in Android O, there are four officially supported filters:

    verify: only run DEX code verification.
    quicken: run DEX code verification and optimize some DEX instructions to get better interpreter performance.
    speed: run DEX code verification and AOT-compile all methods.
    speed-profile: run DEX code verification and AOT-compile methods listed in a profile file.
    System ROM configuration

    There are a number of ART build options available for configuring a system ROM. How to configure these options depends on the available storage space for /system and the number of pre-installed applications. The JARs/APKs that are compiled into a system ROM can be divided in four categories:

    Boot classpath code: compiled with the speed compiler filter by default.
    System server code: compiled with the speed compiler filter by default.
    Product-specific core applications: compiled with the speed compiler filter by default.
    All other applications: compiled with the quicken compiler filter by default.
    Makefile options

    WITH_DEXPREOPT
    Whether dex2oat is invoked on DEX code installed on the system image. Enabled by default.

    DONT_DEXPREOPT_PREBUILTS (since Android 5.0)
    Enabling DONT_DEXPREOPT_PREBUILTS prevents the prebuilts from being pre-optimized. These are apps that have include $(BUILD_PREBUILT) specified in their Android.mk, such as Gmail. Skipping pre-optimization of prebuilt apps that are likely to be updated via Google Play saves /system space but does add to first boot time.

    WITH_DEXPREOPT_BOOT_IMG_ONLY
    Enabling WITH_DEXPREOPT_BOOT_IMG_ONLY pre-optimizes only the boot classpath.

    LOCAL_DEX_PREOPT
    Pre-optimization can also be enabled or disabled on an individual app basis by specifying the LOCAL_DEX_PREOPT option in the module definition. This can be useful for disabling pre-optimization of apps that may immediately receive Google Play updates since the updates would render the pre-optimized code in the system image obsolete. This is also useful to save space on major version upgrade OTAs since users may already have newer versions of apps in the data partition.

    LOCAL_DEX_PREOPT supports the values ‘true’ or ‘false’ to enable or disable pre-optimization, respectively. In addition, ‘nostripping’ can be specified if pre-optimization should not strip the classes.dex file from the APK or JAR file. Normally this file is stripped since it’s no longer needed after pre-optimization, but this last option is necessary to allow third-party APK signatures to remain valid.

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    Passes options to dex2oat to control how the boot image is compiled. It can be used to specify customized image classes lists, compiled classes lists, and compiler filters.

    PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
    Passes options to dex2oat to control how everything besides the boot image is compiled.

    PRODUCT_DEX_PREOPT_MODULE_CONFIGS
    Provides the ability to pass dex2oat options for a particular module and product configuration. It is set in a product’s device.mk file by $(call add-product-dex-preopt-module-config,,

    PRODUCT_DEXPREOPT_SPEED_APPS (New in Android O)
    List of applications that have been identified as core to the products and which are desirable to compile with the speed compiler filter. For example, persistent apps such as SystemUI get a chance to use profile-guided compilation only at the next reboot, so it may be better for the product to have these apps always AOT-compiled.

    PRODUCT_SYSTEM_SERVER_APPS (New in Android O)
    List of applications that are loaded by the system server. These applications will be compiled by default with the speed compiler filter.

    WITH_DEXPREOPT_PIC (Removed in Android O)
    In Android 5.1.0 through Android 6.0.1, WITH_DEXPREOPT_PIC can be specified to enable position-independent code (PIC). With this, compiled code from the image doesn’t have to be relocated from /system into /data/dalvik-cache, saving space in the data partition. However, there is a slight runtime impact because it disables an optimization that takes advantage of position-dependent code. Typically, devices wanting to save space in /data should enable PIC compilation.

    In Android 7.0, PIC compilation was enabled by default.

    Boot classpath configuration

    Preloaded Classes List
    The preloaded classes list is a list of classes the zygote will initialize on startup. This saves each app from having to run these class initializers separately, allowing them to start up faster and share pages in memory. The preloaded classes list file is located at frameworks/base/preloaded-classes by default, and it contains a list that is tuned for typical phone use. This may be different for other devices, such as wearables, and should be tuned accordingly. Be careful when tuning this since adding too many classes wastes memory loading unused classes; meanwhile, adding too few forces each app to have to have its own copy, again wasting memory.

    Example usage (in product’s device.mk):

    PRODUCT_COPY_FILES += :system/etc/preloaded-classes
    Note: This line must be placed before inheriting any product configuration makefiles that get the default one from: build/target/product/base.mk

    Image Classes List
    The image classes list is a list of classes that dex2oat initializes ahead of time and stores in the boot.art file. This allows the zygote to load these results out of the boot.art file on startup instead of running the initializers for these classes itself during preloading. A key feature of this is that the pages loaded from the image and shared between processes can be clean, allowing them to be swapped out easily in low-memory situations. In L, by default the image classes list uses the same list as the preloaded classes list. Beginning post-L in AOSP, a custom image classes list can be specified using:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    Example use (in product’s device.mk):

    PRODUCT_DEX_PREOPT_BOOT_FLAGS += –image-classes=
    Compiled Classes List
    In post-L AOSP, a subset of classes from the boot classpath can be specified to be compiled during pre-optimization using the compiled classes list. This can be a useful option for devices that are very tight on space and can’t fit the entire pre-optimized boot image. However, note classes not specified by this list will not be compiled - not even on the device - and must be interpreted, potentially affecting runtime performance. By default, dex2oat will look for a compiled classes list in $OUT/system/etc/compiled-classes, so a custom one can be copied to that location by the device.mk. A particular file location can also be specified using:

    PRODUCT_DEX_PREOPT_BOOT_FLAGS
    Example usage (in product’s device.mk):

    PRODUCT_COPY_FILES += :system/etc/compiled-classes
    Note: This line must be placed before inheriting any product configuration makefiles that get the default one from: build/target/product/base.mk

    Runtime configuration

    Jit options

    The following options affect Android releases only where the ART JIT compiler is available.

    dalvik.vm.usejit: whether or not the JIT is enabled.
    dalvik.vm.jitinitialsize (default 64K): the initial capacity of the code cache. The code cache will regularly GC and increase if needed.
    dalvik.vm.jitmaxsize (default 64M): the maximum capacity of the code cache.
    dalvik.vm.jitthreshold: (default 10000) - This is the threshold that the “hotness” counter of a method needs to pass in order for the method to be JIT compiled. The “hotness” counter is a metric internal to the runtime. It includes the number of calls, backward branches, and other factors.
    dalvik.vm.usejitprofiles: whether or not JIT profiles are enabled; this may be used even if dalvik.vm.usejit is false. Note that if this is false, the compiler filter speed-profile does not AOT-compile any method and is equivalent to quicken.
    dalvik.vm.jitprithreadweight (default to dalvik.vm.jitthreshold / 20) - The weight of the JIT “samples” (see jitthreshold) for the application UI thread. Use to speed up compilation of methods that directly affect users experience when interacting with the app.
    dalvik.vm.jittransitionweight: (default to dalvik.vm.jitthreshold / 10) the weight of the method invocation that transitions between compile code and interpreter. This helps make sure the methods involved are compiled to minimize transitions (which are expensive).
    Package manager options

    Since Android 7.0, there’s a generic way to specify the level of compilation/verification that happened at various stages. The compilation levels can be configured via system properties with the defaults being:

    pm.dexopt.install=quicken
    This is the compilation filter used when installing applications through Google Play. For faster installs, try the quicken compiler filter.

    pm.dexopt.bg-dexopt=speed-profile
    This is the compilation filter used when the device is idle, charging and fully charged. Try the speed-profile compiler filter to take advantage of profile-guided compilation and save on storage.

    pm.dexopt.boot=verify
    The compilation filter used after an over-the-air update. We strongly recommend the verify compiler filter for this option to avoid very long boot times.

    pm.dexopt.first-boot=quicken
    The compilation filter for the first time the device ever boots. The filter used here will only affect the boot time after factory. We recommend the filter quicken for it to avoid long times before a user gets to use the phone for the very first time. Note that if all applications in /system are already compiled with the quicken compiler filter or are compiled with the speed or speed-profile compiler filter, the pm.dexopt.first-boot has no effect.
    Dex2oat options

    Note that these options affect dex2oat during on-device compilation as well as during pre-optimization, whereas most of the options discussed above affect only pre-optimization.

    To control dex2oat while it’s compiling the boot image:

    dalvik.vm.image-dex2oat-Xms: initial heap size
    dalvik.vm.image-dex2oat-Xmx: maximum heap size
    dalvik.vm.image-dex2oat-filter: compiler filter option
    dalvik.vm.image-dex2oat-threads: number of threads to use
    To control dex2oat while it’s compiling everything besides the boot image:

    dalvik.vm.dex2oat-Xms: initial heap size
    dalvik.vm.dex2oat-Xmx: maximum heap size
    dalvik.vm.dex2oat-filter: compiler filter option
    On releases through Android 6.0, one additional option is provided for compiling everything besides the boot image:

    dalvik.vm.dex2oat-threads: number of threads to use
    Starting with Android 6.1, this becomes two additional options for compiling everything besides the boot image:

    dalvik.vm.boot-dex2oat-threads: number of threads to use during boot time
    dalvik.vm.dex2oat-threads: number of threads to use after boot time
    Starting with Android 7.1, two options are provided for controlling how memory is used when compiling everything besides the boot image:

    dalvik.vm.dex2oat-very-large: minimum total dex file size in bytes to disable AOT compilation
    dalvik.vm.dex2oat-swap: use dex2oat swap file (for low-memory devices)
    The options that control initial and maximum heap size for dex2oat should not be reduced since they could limit what applications can be compiled.

    A/B specific configuration

    ROM configuration

    Starting in Android 7.0, devices may use two system partitions to enable A/B system updates. To save on the system partition size, the preopted files can be installed in the unused second system partition. They are then copied to the data partition on first boot.

    Example usage (in device-common.mk):

    PRODUCT_PACKAGES += \
    cppreopts.sh
    PRODUCT_PROPERTY_OVERRIDES += \
    ro.cp_system_other_odex=1
    And in device’s BoardConfig.mk:

    BOARD_USES_SYSTEM_OTHER_ODEX := true
    Note that boot classpath code, system server code, and product-specific core applications always compile to the system partition. By default, all other applications get compiled to the unused second system partition. This can be controlled with the SYSTEM_OTHER_ODEX_FILTER, which has a value by default of:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%
    Background dexopt OTA

    With A/B enabled devices, applications can be compiled in the background for updating to the new system image. See App compilation in background to optionally include the compilation script and binaries in the system image. The compilation filter used for this compilation is controlled with:

    pm.dexopt.ab-ota=speed-profile
    We recommend using speed-profile to take advantage of profile guided compilation and save on storage.


    转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 wilber_bai@hotmail.com

    文章标题:Android 5.1 Dex配置

    文章字数:3,155

    本文作者:风沉殇史

    发布时间:2017-12-12, 12:12:12

    最后更新:2018-06-21, 16:20:40

    原始链接:http://wilber.win/posts/1144f3b2/

    版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

    目录
    ×

    喜欢就点赞,疼爱就打赏