Jakie optymalizacje aplikacji wykonują nowsze wersje Androida podczas pierwszego restartu?

Otrzymałem od mojego operatora telefonicznego, Vodafone IT, oficjalną aktualizację OTA Google do Androida Ice Cream Sandwich 4.0.4 na moim Nexus S. Podczas automatycznego ponownego uruchamiania po raz pierwszy po aktualizacji system wyświetlił powiadomienie, że optymalizuje zainstalowane aplikacje. Jakiego rodzaju optymalizację wykonuje system Android 4.0+ przy pierwszym uruchomieniu?

Kopanie w klasie PackageManagerService na grepCode (Uwaga: Ten plik klasy jest ogromny, przeglądarka może dyszeć uczciwej trochę przy renderowaniu go), wyświetlany jest komunikat o optymalizacji w następującym kontekście:

public void performBootDexOpt() {
    ArrayList<PackageParser.Package> pkgs = null;
    synchronized (mPackages) {
        if (mDeferredDexOpt.size() > 0) {
            pkgs = new ArrayList<PackageParser.Package>(mDeferredDexOpt);
            mDeferredDexOpt.clear();
        }
    }
    if (pkgs != null) {
        for (int i=0; i<pkgs.size(); i++) {
            if (!isFirstBoot()) {
                try {
                    ActivityManagerNative.getDefault().showBootMessage(
                            mContext.getResources().getString(
                                    com.android.internal.R.string.android_upgrading_apk,
                                    i+1, pkgs.size()), true);
                } catch (RemoteException e) {
                }
            }
            PackageParser.Package p = pkgs.get(i);
            synchronized (mInstallLock) {
                if (!p.mDidDexOpt) {
                    performDexOptLI(p, false, false);
                }
            }
        }
    }
}

Tutaj wartością com.android.internal.R.string.android_upgrading_apkjest ciąg „Optymalizacja aplikacji”. Mówiąc laik, pętla przechodzi przez każdą aplikację w urządzeniu, aktualizuje komunikat na ekranie, dzwoniąc, showBootMessage()a następnie wywołuje performDexOptLI()aplikację. performDexOptLI()Oczywiście następne pytanie brzmi: „Co robi ?” Oto jak to wygląda:

private int performDexOptLI(PackageParser.Package pkg, boolean forceDex, boolean defer) {
    boolean performed = false;
    if ((pkg.applicationInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0) {
        String path = pkg.mScanPath;
        int ret = 0;
        try {
            if (forceDex || dalvik.system.DexFile.isDexOptNeeded(path)) {
                if (!forceDex && defer) {
                    mDeferredDexOpt.add(pkg);
                    return DEX_OPT_DEFERRED;
                } else {
                    Log.i(TAG, "Running dexopt on: " + pkg.applicationInfo.packageName);
                    ret = mInstaller.dexopt(path, pkg.applicationInfo.uid,
                            !isForwardLocked(pkg));
                    pkg.mDidDexOpt = true;
                    performed = true;
                }
            }
        } catch (...) {
           //I've trimmed out a bunch of exception handling here, it basically just writes to
           //the log and sets the return value
        }
    }

    return performed ? DEX_OPT_PERFORMED : DEX_OPT_SKIPPED;
}

To wywołuje dexoptnarzędzie we wszystkich aplikacjach, które go potrzebują. Trudno jest znaleźć jakąkolwiek prostą dokumentację dexopt, ale tutaj jest ogólny przegląd . Wystarczy powiedzieć, że jest używany przez kompilator Just In Time (JIT) do tworzenia zoptymalizowanych plików .dex, które pomagają poprawić wydajność aplikacji na urządzeniu i wysyła je do pamięci podręcznej VM. Powodem, dla którego przechowuje pliki .dex w pamięci podręcznej, jest to, że w przeciwnym razie musiałby je ponownie rozpakować za każdym razem, gdy chcesz uruchomić aplikację (.apk to tylko archiwum, nie jest to plik wykonywalny!). Dlatego sensowne jest po prostu trzymanie ich w /data/dalvik-cachekatalogu w celu ich ponownego użycia i dexoptprzeprowadzanie pewnych optymalizacji podczas początkowego rozpakowywania, gdy jest w tym katalogu .

TL; DR (lub, jak sądzę, podsumowanie nieprogramowe): Odbudowuje pamięć podręczną Dalvik.