Naruszenie liczby instancji aktywności StrictMode (2 wystąpienia, 1 oczekiwane) przy rotacji całkowicie pustej aktywności

Istotne tylko w tym, że motywuje eliminowanie fałszywych alarmów ze ścisłego trybu, ponieważ ciągła obecność jakiegokolwiek sprawia, że kara śmierci jest niepraktyczna

Przez ostatnie kilka dni ścigałem i naprawiałem wycieki pamięci w aplikacji. Po dojściu do punktu, w którym wierzyłem, że naprawiłem je wszystkie, zaimplementowałem mechanizm głośności awarii podobny do tego opisanego w Android StrictMode i wysypiska sterty (Włącz śledzenie instancji z karą śmierci, przechwytywanie komunikat o błędzie zamknięcia, sterta zrzutu, Wyślij sygnał SOS przy następnym uruchomieniu aplikacji). Wszystko to oczywiście w kompilacjach debugowania.

Do punktu

Po przekonaniu, że naprawiłem wszystkie wycieki aktywności, niektóre działania nadal powodują ostrzeżenia o naruszeniu instancji trybu podczas obracania ekranu. Co ciekawe, robią to tylko niektóre, a nie wszystkie działania aplikacji.

Przejrzałem wysypiska zrobione, gdy takie naruszenia występują, i przejrzałem Kodeks działań w pytanie w poszukiwaniu przecieku, ale nie dostać nigdzie.

Więc w tym momencie starałem się zrobić najmniejszy możliwy przypadek testowy. Tworzę całkowicie puste działanie (nawet bez layoutu), wyglądające tak:

package com.example.app;

import android.app.Activity;
import android.os.Bundle;
import android.os.StrictMode;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        StrictMode.setVmPolicy(
                new StrictMode.VmPolicy.Builder()
                        .detectAll()
                        .penaltyLog()
                        .build());
        StrictMode.setThreadPolicy(
                new StrictMode.ThreadPolicy.Builder()
                        .detectAll()
                        .penaltyDeath()
                        .penaltyLog()
                        .build());
        super.onCreate(savedInstanceState);
    }

}

A dla kompletności manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app" >

    <application
    android:allowBackup="true"
    android:icon="@drawable/ic_launcher"
    android:label="@string/app_name"
    android:theme="@style/AppTheme" >
    <activity
        android:name="com.example.app.MainActivity"
        android:label="@string/app_name" >
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
    </application>

</manifest>

Otwieram aktywność(urządzenie trzymane w portrecie). Obracam się do pejzażu, a z powrotem do portretu, w którym momencie widzę ze StrictMode to w LogCat:

01-15 17:24:23.248: E / StrictMode(13867): Klasa com.przykład.app.MainActivity; instances=2; limit=1 2011-01-15 17: 24: 23.248: E/StrictMode(13867): android.os.StrictMode$InstanceCountViolation: class com.przykład.app.MainActivity; instances=2; limit=1 / 2011-01-15 17: 24: 23os.StrictMode.setClassInstanceLimit (StrictMode.java: 1)

Zrzut sterty

W tym momencie ręcznie uzyskuję zrzut sterty za pomocą DDMS. Oto dwie instancje w MAT:

A oto ten, który był jest to pierwsza część ścieżki z niej do korzenia GC:

Zauważ, że bez względu na to, ile razy obracam między pionowym a poziomym, liczba rzeczywistych instancji nigdy nie przekracza dwóch, a liczba oczekiwanych instancji nigdy nie przekracza jednej.

Czy ktoś może zrozumieć przeciek? Czy to w ogóle prawdziwy przeciek? Jeśli tak, to prawdopodobnie musi to być błąd Androida. Jeśli nie, to jedyne, co widzę, że może to być błąd w StrictMode.

Dobrze odpowiedzi mogą zawierać

1. jeśli jest to prawdziwy przeciek, wyjaśnienie, jak to się dzieje, i co, jeśli można podjąć jakiekolwiek działania w celu naprawienia go lub powstrzymania StrictMode od rozpoczęcia kary śmierci w takich przypadkach (przypomnijmy, że fałszywe alarmy/neutralne sprawiają, że kara śmierci jest niepraktyczna).
2. jeśli to nie jest prawdziwy przeciek, wyjaśnienie, dlaczego StrictMode myśli inaczej, i co jeśli można podjąć jakiekolwiek działania, aby go naprawić lub powstrzymać StrictMode od zainicjowania kary śmierci za takie przypadki (przypomnijmy, że fałszywe alarmy / neutralne sprawiają, że kara śmierci jest niepraktyczna).
3. w obu przypadkach hipotezy, dlaczego nie występuje to przy wszystkich działaniach (większość działań w aplikacji, nad którą pracuję, nie powoduje takich naruszeń na rotacji).

Mam tak daleko, jak patrząc na źródło StrictMode i nie widzę tam nic oczywiście złego - zgodnie z oczekiwaniami, wymusza to GC przed rozważeniem dodatkowej instancji jako naruszenia.

Dobry wpis punkty za odczyt Źródła StrictMode disclosure

Zrobiłem te testy tylko na jednym urządzeniu, Galaxy S4 z CyanogenMod 11 migawka m2 (http://download.cyanogenmod.org/get/jenkins/53833/cm-11-20140104-SNAPSHOT-M2-jfltexx.zip)ale nie wyobrażam sobie, żeby CyanogenMod odbiegał od KitKat pod względem zarządzania aktywnością.

Dodatkowe źródła StrictMode:

1. instancetracker activity jest tylko polem ostatniej instancji: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4_r1/android/app/Activity.java#Activity.0mInstanceTracker
2. gdzie oczekiwane wystąpienie aktywności jest zwiększane: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4_r1/android/app/ActivityThread.java#2095
3. gdzie liczba oczekiwanych instancji aktywności jest zmniejszana: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4_r1/android/app/ActivityThread.java#3485

    // Note: adding 1 here to give some breathing room during
    // orientation changes.  (shouldn't be necessary, though?)
    limit = newExpected + 1;

    ...

    // Quick check.
    int actual = InstanceTracker.getInstanceCount(klass);
    if (actual <= limit) {
        return;
    }

    // Do a GC and explicit count to double-check.
    // This is the work that we are trying to avoid by tracking the object instances
    // explicity.  Running an explicit GC can be expensive (80ms) and so can walking
    // the heap to count instance (30ms).  This extra work can make the system feel
    // noticeably less responsive during orientation changes when activities are
    // being restarted.  Granted, it is only a problem when StrictMode is enabled
    // but it is annoying.
    Runtime.getRuntime().gc();

    long instances = VMDebug.countInstancesOfClass(klass, false);
    if (instances > limit) {
        Throwable tr = new InstanceCountViolation(klass, instances, limit);
        onVmPolicyViolation(tr.getMessage(), tr);
    }

Method m = StrictMode.class.getMethod("incrementExpectedActivityCount", Class.class);
m.invoke(null, MainActivity.class);

// Note: adding 1 here to give some breathing room during
// orientation changes.  (shouldn't be necessary, though?)
limit = newExpected + 1;

...

// Quick check.
int actual = InstanceTracker.getInstanceCount(klass);
if (actual <= limit) {
    return;
}

// Do a GC and explicit count to double-check.
// This is the work that we are trying to avoid by tracking the object instances
// explicity.  Running an explicit GC can be expensive (80ms) and so can walking
// the heap to count instance (30ms).  This extra work can make the system feel
// noticeably less responsive during orientation changes when activities are
// being restarted.  Granted, it is only a problem when StrictMode is enabled
// but it is annoying.
Runtime.getRuntime().gc();

long instances = VMDebug.countInstancesOfClass(klass, false);
if (instances > limit) {
    Throwable tr = new InstanceCountViolation(klass, instances, limit);
    onVmPolicyViolation(tr.getMessage(), tr);
}

 if (BuildConfig.DEBUG)
 {         
     System.gc();
 }
 Intent intent = new Intent(context, SomeActivity.class);
 this.startActivity(intent);

while(!ready.compareAndSet(false, true)) {
    //sleep a bit
}