Fresco: Share Element Gone after SharedElementReturnTransition in Android N

Erstellt am 31. Aug. 2016  ·  70Kommentare  ·  Quelle: facebook/fresco

Ich verwende den neuesten Freskocode für die Arbeit mit SharedElement Transition, er läuft gut in Android L、M, Aber auf Android N geht es schief

vor dem Übergang
screenshot0

nach dem Übergang
screenshot0

bug help wanted

Hilfreichster Kommentar

Fügen Sie einfach diesen Code in der Anrufaktivität,+1 hinzu, wenn Ihnen dies helfen kann!!! @oprisnik


setExitSharedElementCallback(new SharedElementCallback() {

            <strong i="6">@Override</strong>
            public void onSharedElementEnd(List<String> sharedElementNames,
                                           List<View> sharedElements,
                                           List<View> sharedElementSnapshots) {

                super.onSharedElementEnd(sharedElementNames, sharedElements,
                        sharedElementSnapshots);

                for (View view : sharedElements) {
                    if (view instanceof SimpleDraweeView) {
                        view.setVisibility(View.VISIBLE);
                    }
                }
            }
        });

Alle 70 Kommentare

Können Sie bitte zeigen, wie Sie den Übergangsteil mit der Demo-App von Fresco durchführen?

Activity_main.xml und Activity_detail haben dieselbe SimpleDraweeView mit demselben TransitionName
und in der onCreate-Methode von DetailActivity wie folgt:

protected void onCreate(Bundle savedInstanceState) {
getWindow().requestFeature(Window.FEATURE_CONTENT_TRANSITIONS);
getWindow().setSharedElementEnterTransition(DraweeTransition.createTransitionSet(ScalingUtils.ScaleType.CENTER_CROP, ScalingUtils.ScaleType.FIT_CENTER));
getWindow().setSharedElementReturnTransition(DraweeTransition.createTransitionSet(ScalingUtils.ScaleType.FIT_CENTER, ScalingUtils.ScaleType.CENTER_CROP));
addTransitionListener();
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_detail);
mBaselineJpegView = (SimpleDraweeView) findViewById(R.id.baseline_jpeg);
mBaselineJpegView.setImageURI(Uri.parse("https://www.gstatic.com/webp/gallery/1.sm.jpg"));
mBaselineJpegView.setOnClickListener(neue View.OnClickListener() {
@Überschreiben
public void onClick(View v) {
Toast.makeText(DetailActivity.this, "dsasa", Toast.LENGTH_LONG).show();
}
});
}

addTransitionListener() tut nichts, druckt nur das Protokoll

also verwende ich den falschen Weg, um den Übergang zu tun?

Das passiert mir auch.

Ich habe Folgendes in der Methode onCreate() vor super.onCreate()

supportRequestWindowFeature(Window.FEATURE_CONTENT_TRANSITIONS);
Transition fade = new Fade();
fade.excludeTarget(android.R.id.statusBarBackground, true);
fade.excludeTarget(android.R.id.navigationBarBackground, true);
Window window = getWindow();
window.setEnterTransition(fade);
window.setReturnTransition(fade);
window.setExitTransition(fade);
TransitionSet transitionSet = DraweeTransition
                    .createTransitionSet(ScalingUtils.ScaleType.CENTER_CROP,
ScalingUtils.ScaleType.CENTER_CROP);
window.setSharedElementEnterTransition(transitionSet);
window.setSharedElementExitTransition(transitionSet);

Ich habe das gleiche Problem. Die setSharedElementReturnTransition funktioniert nicht auf Android N. Ich habe den Transition Listenern Logs hinzugefügt und onTransitionStart und onTransitionEnd werden auf Android N nicht ausgelöst, aber auf Android M & L funktioniert es einwandfrei.
Ich verwende die neueste Version der Fresco-Bibliothek com.facebook. fresco:fresco :0.14.1 mit com.facebook. fresko:imagepipeline-okhttp3 :0.14.1
Ich habe dieses Problem nicht, wenn ich die Picasso-Bibliothek zum Laden des Bildes verwende.
Das Szenario ist ähnlich: gridView, gridItem navigiert zu einer anderen Aktivität (alles ist in diesem Teil in Ordnung), aber wenn ich zurückgehe, gibt es keinen erneuten Eintrag, das Bild blinkt und wird neu geladen (das Platzhalterbild ist nicht sichtbar, noch das Bild, das war bereits geladen). Dies geschieht nur unter Android N (7.0)

Irgendein Update zu diesem Thema?

Von Fresco zu Picasso gewechselt und das Problem ist behoben. Schade, dass diese Bibliothek nicht so oft gepflegt wird, wie es von den neuen Android-Betriebssystemversionen erforderlich ist.

Es scheint, dass dieses Problem fälschlicherweise als "Benötigt-Details" gekennzeichnet ist. Dieses Problem besteht auch unter Android 7.1.1 (API-Level 25).

Danke, wir schauen mal nach

Ich habe auch das gleiche Problem, daher +1 von mir für die Behebung.

hier gilt das gleiche

Tu es. Tu es. ;-)

Ja, bitte tun Sie es.

Bitte...

+1

Ich frage mich, warum dies keine hohe Priorität hat..

+1

Wenn ich zur Position des freigegebenen Elements in onActivityReenter scrolle, kommt das verschwundene Element jedoch mit einem kleinen weißen Flackern zurück:

    <strong i="7">@Override</strong>
    public void onActivityReenter(int resultCode, Intent data) {
        super.onActivityReenter(resultCode, data);

        final int position = data.getIntExtra(EXTRA_GIF_POSITION, -1);
        if (resultCode == RESULT_OK && position != -1) {
            gifRecyclerView.getLayoutManager().scrollToPosition(position);
        }
    }

Wenn jemand eine bessere Lösung kennt, würde ich mich freuen, wenn Sie sie teilen könnten.

Hallo, ich habe das gleiche Problem, aber nur auf Android 7.1.1 API 25

Wenn es Updates zu dem Problem gibt, wäre ich sehr dankbar.

Das gleiche hier auf emu mit 7.x, aber ich verwende onWindowFocusChanged, um immersiv zu sein, wenn das Bild fertig ist, verschwindet das Bild, wird aber sofort wieder angezeigt.

Ebenfalls. Das Aufrufen von requestLayout in der Ansicht, die das SimpleDraweeView enthält, scheint das Problem mit einem Flimmern zu beheben. Bitte beraten

Fügen Sie einfach diesen Code in der Anrufaktivität,+1 hinzu, wenn Ihnen dies helfen kann!!! @oprisnik


setExitSharedElementCallback(new SharedElementCallback() {

            <strong i="6">@Override</strong>
            public void onSharedElementEnd(List<String> sharedElementNames,
                                           List<View> sharedElements,
                                           List<View> sharedElementSnapshots) {

                super.onSharedElementEnd(sharedElementNames, sharedElements,
                        sharedElementSnapshots);

                for (View view : sharedElements) {
                    if (view instanceof SimpleDraweeView) {
                        view.setVisibility(View.VISIBLE);
                    }
                }
            }
        });

gleiches Problem hier ... @antxyz Ich habe Ihren Code sowohl in die aufrufenden als auch in die aufgerufenen Aktivitäten der Methode onCreate eingefügt, jedoch ohne Erfolg. Das geteilte Elementbild ist nach der Rückkehr des Übergangs immer noch unsichtbar.

Ich weiß nicht, ob es helfen kann, eine Lösung zu finden, aber ich habe festgestellt, dass beim Öffnen des Softkeyboards die SimpleDraweeView sichtbar wird.

Ich hatte das gleiche Problem und es wurde nach diesen beiden Anrufen behoben:

  1. Kurz vor startActivity(... :
    setExitSharedElementCallback(new SharedElementCallback() {
                <strong i="9">@Override</strong>
                public void onSharedElementEnd(List<String> names,
                                               List<View> elements,
                                               List<View> snapshots) {
                    super.onSharedElementEnd(names, elements, snapshots);
                    for (final View view : elements) {
                        if (view instanceof SimpleDraweeView) {
                            view.post(() -> view.setVisibility(View.VISIBLE));
                        }
                    }
                }
            });
  1. Innerhalb der onCreate der neuen Aktivität:
setEnterSharedElementCallback(new SharedElementCallback() {
                <strong i="15">@Override</strong>
                public void onSharedElementEnd(List<String> names,
                                               List<View> elements,
                                               List<View> snapshots) {
                    super.onSharedElementEnd(names, elements, snapshots);
                    for (final View view : elements) {
                        if (view instanceof SimpleDraweeView) {
                            view.post(() -> view.setVisibility(View.VISIBLE));
                        }
                    }
                }
            });

@oprisnik irgendwelche Updates dazu? Schade, dass es noch nicht behoben wurde.
Ich habe dies immer noch mit API 24+, wenn das freigegebene Element ein Element in einem RecyclerView .
Keine der in diesem Ticket aufgeführten Problemumgehungen hat bei mir funktioniert (die Ansicht wird nie auf unsichtbar / weg gesetzt).
Ich verwende DraweeTransition.createTransitionSet() sowohl für den Ein- als auch für den Rückübergang.
Manchmal verschwindet das Bild, bis die Recyclerview gescrollt wird, manchmal kommt es nach einer Weile mit einem Flimmern zurück (möglicherweise daran, dass eine notificationDataSetChanged() aufgerufen wurde).

Ich bin mir nicht sicher, ob dies hilfreich ist, aber das passiert in Fresco laut den Protokollen, wenn die zweite Aktivität geschlossen wird und das freigegebene Element an seine Position zurückkehrt:

V/unknown:AbstractDraweeController: controller c6a03e3 9: onDetach
V/unknown:AbstractDraweeController: controller c6a03e3 9: release: image: CloseableReferenceWithFinalizer f25d513
V/unknown:AbstractDraweeController: controller f84c24e 4: onAttach: request needs submit
V/unknown:AbstractDraweeController: controller f84c24e 4: set_final_result @ onNewResult: image: CloseableReferenceWithFinalizer f25d513

Dies geschieht, wenn die Bitmap wieder angezeigt wird.
Wenn die Bitmap nicht angezeigt wird, treten die letzten beiden Ereignisse nicht auf:

V/unknown:AbstractDraweeController: controller f84c24e 4: onAttach: request needs submit
V/unknown:AbstractDraweeController: controller f84c24e 4: set_final_result @ onNewResult: image: CloseableReferenceWithFinalizer f25d513

@marcosalis Beim Zurückkehren zur ersten Aktivität (mit dem recyclerView). Löst das immer eine notificationDataSetChanged() aus?

@erikandre danke für die Antwort ;)
Nach einigen Tests kann ich bestätigen, dass notificationDataSetChanged() nicht aufgerufen wird, selbst wenn die Bitmap allein angezeigt wird.

Dies ist der Zustand von SimpleDraweeView wenn ich in der aufrufenden Aktivität einen Haltepunkt in SharedElementCallback.onSharedElementEnd() setze.

 DraweeHolder{controllerAttached=false, holderAttached=true, drawableVisible=false}

PipelineDraweeController{super=PipelineDraweeController{isAttached=false, isRequestSubmitted=false, hasFetchFailed=false, fetchedImage=0, events=[...]}, dataSourceSupplier={request=ImageRequest{uri=https://OMITTED, cacheChoice=DEFAULT, decodeOptions=100-false-false-false-false-ARGB_8888-null, postprocessor=null, priority=HIGH, resizeOptions=null, rotationOptions=-1 defer:true, mediaVariations=null}}}

Ich denke, es könnte etwas mit den Methoden doDetach() und doAttach() in SimpleDraweeView zu tun haben, wenn sich die Ansicht selbst in einer RecyclerView .
Schließlich hat dies für mich funktioniert (zur Aktivität hinzugefügt, aus der der Übergang generiert wird), obwohl es nicht sehr sauber ist:

        setExitSharedElementCallback(new SharedElementCallback() {
            <strong i="11">@Override</strong>
            public void onSharedElementEnd(List<String> names, List<View> elements, List<View> snapshots) {
                for (View view : elements) {
                    if (view instanceof SimpleDraweeView) {
                        view.post(() -> {
                                myAdapter.notifyDataSetChanged();
                        });
                    }
                }
            }
        });

@marcosalis Toll, dass du einen Workaround gefunden hast! Ich habe versucht, dieses spezielle Problem in der Showcase-App zu reproduzieren, die auf Genymotion mit Android 7 ausgeführt wird, aber kein Glück.

Wie sehen die Artikelansichten für die Recycleransicht aus? In meinem Fall war es nur ein FrameLayout, das ein SimpleDraweeView umhüllt.

@marcosalis Ihre Lösung hat mit einer kleinen Änderung für mich funktioniert und den for-Zyklus entfernt:

setExitSharedElementCallback(
                    new SharedElementCallback() {
                        <strong i="7">@Override</strong>
                        public void onSharedElementEnd(List<String> names, List<View> elements, List<View> snapshots) {
                            super.onSharedElementEnd(names, elements, snapshots);
                            notifyDataSetChanged();
                        }
                    }
            );

Ich bin gerade über das gleiche Problem gestolpert, als ich mit Interaktivitätsübergängen herumgespielt habe. Keine der oben vorgeschlagenen Problemumgehungen schien zu funktionieren. (API 25) So sieht es aus: https://vimeo.com/225497240

Ich denke, wir haben eine Problemumgehung gefunden und hoffentlich wird es bald eine Lösung geben.

Die Problemumgehung finden Sie in dc7ec2436fc9b639fe1a39398712c360b16da468.

Im Moment müssen Sie die ersten DraweeView denen aus der Übergang beginnt, einrichten, um die Handhabung der alten Sichtbarkeit zu verwenden, indem Sie simpleDraweeView.setLegacyVisibilityHandlingEnabled(true); aufrufen (wie Sie im Übergangsbeispiel in unserer Showcase-Beispiel-App sehen können). .

Können Sie bitte überprüfen, ob dies die Probleme für Sie löst? Wir werden sehr bald eine neue Fresco-Version veröffentlichen, die diesen Fix enthält.

Ja, danke! Bestätigt, dass dies das Problem löst. Freue mich auf eine aktualisierte Version.

Wir haben Fresco v1.4.0 veröffentlicht , das den oben genannten Fix enthält. Rufen Sie einfach simpleDraweeView.setLegacyVisibilityHandlingEnabled(true); und es sollte jetzt funktionieren.

Wir haben auch das Beispiel für den

Danke für diesen Fix, in meinem Fall hat es perfekt funktioniert. Eine Frage, warum wird setGlobalLegacyVisibilityHandlingEnabled standardmäßig auf true gesetzt? Gibt es ein Leistungsproblem?

Die Handhabung der Sichtbarkeit hat sich mit Android N geändert und meine Änderung besteht darin, das Verhalten (irgendwie) auf Pre-N zurückzusetzen. Das Ändern dieses Verhaltens für alle Bilder kann zu anderen unerwarteten Problemen führen. Aus diesem Grund haben wir uns entschieden, es noch nicht standardmäßig zu aktivieren. Sobald wir überprüft haben, dass es keine Nebenwirkungen gibt, ziehen wir es in Betracht, es standardmäßig zu aktivieren.
Sie können es gerne auf true und alle auftretenden Probleme melden.

ezgif com-resize

Dieser Fix scheint nicht zufällig zu funktionieren. Ich setze setGlobalLegacyVisibilityHandlingEnabled auf true, aber nach ein paar Klicks ist das zurückgegebene Bild leer.

Fresko 1.5.0, Oreo

Bearbeiten: Nachdem ich ein paar Tage mehr entwickelt und einige Ansichten verschoben hatte, habe ich festgestellt, dass das Problem auf meinem Oreo-Pixelgerät überhaupt nicht mehr auftritt. Auf meinem emulierten Nexus 5x API 24 ist das Bild nach der Exit-Animation immer leer.

Ich habe das gleiche Problem mit setLegacyVisibilityHandlingEnabled . Das Setzen auf true funktioniert meistens, aber manchmal verschwindet das Bild zufällig nach dem Rückkehrübergang.

@marcosalis passiert das nur bei Oreo oder auch bei Nougat?

Hallo @oprisnik Ich habe es geschafft, es zufällig auf einem Samsung S7 (Nougat) und auf einem Emulator auf API 26 zu reproduzieren. Lassen Sie mich wissen, ob ich beim Debuggen helfen kann.

Danke, ich werde versuchen zu reproduzieren, wenn ich etwas mehr Zeit habe

@oprisnik
Kann bestätigen, dass es die meiste Zeit nicht funktioniert (API24 + API25)

Mit dem folgenden Hack habe ich es jedoch einigermaßen zum Laufen gebracht:

        setExitSharedElementCallback(new SharedElementCallback() {
            <strong i="8">@Override</strong>
            public void onSharedElementEnd(List<String> names,
                                           List<View> elements,
                                           List<View> snapshots) {
                super.onSharedElementEnd(names, elements, snapshots);
                for (final View view : elements) {
                    if (view instanceof SimpleDraweeView) {
                        view.post(() -> {
                            view.setVisibility(View.VISIBLE);
                            view.requestLayout();
                        });
                    }
                }
            }
        });

Ich konnte reproduzieren. Bei mir kommt es aber nur selten vor. Ich werde prüfen, ob ich eine andere Problemumgehung finden kann, um dies zu beheben.

Hallo @oprisnik ,
Hast du einen anderen Workaround gefunden?

Noch nicht, dies ist schwierig zu beheben, da Google das Sichtbarkeitsverhalten von View geändert hat, was die Sichtbarkeitsbehandlung von Fresco (die wir für die Speicherverwaltung benötigen) unterbricht, und ich werde auch nicht viel Zeit haben, um in naher Zukunft darauf zu achten . In diesem Thread werden jedoch mehrere Alternativen erwähnt, die das Problem beheben (wie die Problemumgehung von

Wenn sich jemand damit befassen möchte, sind Pull-Anfragen immer willkommen! :)

@oprisnik , react-native-maps Modul ebenfalls von diesem Problem betroffen.
Als Workaround habe ich diese Zeilen in der RootDrawable.java-Datei als Kommentar markiert.
Erinnern Sie sich/kennen Sie ein großes Problem, das damit zusammenhängt, diese Zeilen als Kommentarzeilen zu markieren?

Das gleiche Problem wie bei @efkan scheint eine große Anzahl von Android-Geräten (Android Nougat 7.1 API 25 und

Ihre Lösung hat alle Probleme behoben, die ich hatte.

@efkan Ich weiß es nicht genau. Ich erinnere mich, dass ich mich auch damit befasst habe, als ich nach alternativen Fixes suchte, es aber verwarf. Ich denke, ein Problem beim Entfernen dieser Überprüfungen besteht darin, dass die zugrunde liegende Bitmap freigegeben wurde (da die Ansicht nicht mehr sichtbar ist) und der Versuch, sie zu zeichnen, würde ein java.lang.RuntimeException: Canvas: trying to use a recycled bitmap ... da BitmapDrawable dies nicht tut führen Sie alle Sanitätsprüfungen durch.

ImageView selbst hat den gleichen Fehler, bei dem es die Drawable-Sichtbarkeit eines Drawables nicht richtig wiederherstellt, aber es funktioniert immer noch, da die meisten Drawables keine Sichtbarkeitsprüfung durchführen und es keine manuelle Speicherverwaltung gibt - und die zugrunde liegende Bitmap wäre noch gültig.

@oprisnik danke für all diese Erklärungen.

Um zu testen, ob dies funktioniert, ist es ziemlich einfach, dies als Einstellung zu GenericDraweeHierarchyBuilder hinzuzufügen und abhängig davon die Sichtbarkeitsprüfung in RootDrawable ignorieren (die in GenericDraweeHierarchy , siehe https://github.com/facebook/fresco/blob/master/drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchy.java#L155).

Sie können gerne eine PR einreichen, die diese Einstellung hinzufügt, damit Sie sie für Ihre Anwendungen aktivieren und sehen können, ob es Nebenwirkungen gibt.

Das gleiche Problem tritt nur auf Geräten mit Android 7.1 (oder höher) auf.
Keine der oben genannten Lösungen funktioniert.
Das Problem tritt immer auf, wenn das Netzwerk auf 10kb/s beschränkt ist.

@babyblue1314 - Die oben erwähnte Änderung von RootDrawable behebt es auch nicht für Sie?

@oprisnik Danke für deine schnelle Antwort!
Em...ich nehme an, die oben erwähnte RootDrawable-Änderung behebt es auch nicht für mich.
Ich weiß nicht, ob ich es falsch verwendet habe. So sieht es aus:

Vor der Verwendung der RootDrawable-Änderung:

Nach der Verwendung der RootDrawable-Änderung:

_ Ich sollte erwähnen, dass das Netzwerk auf 10kb/s begrenzt ist. _
Darüber hinaus erscheint dies nicht nur in ListView, sondern auch in RecyclerView und GridView, wie unten gezeigt:

Mein Code ist:

  1. ListViewAdapter (oder RecyclerViewAdapter oder GridViewAdapter):
SimpleDraweeView thumbnail = cholder.getView(R.id.thumbnail);

GenericDraweeHierarchyBuilder hierarchyBuilder = new GenericDraweeHierarchyBuilder(thumbnail.getContext().getResources());
GenericDraweeHierarchy hierarchy = hierarchyBuilder.build();
hierarchy.getTopLevelDrawable().setVisible(true, false);
thumbnail.setHierarchy(hierarchy);

ImageLoaderUtil.loadImage(thumbnail, item.getLogourl(), 696, 288);
  1. ImageLoaderUtil:
Uri uri = Uri.parse(url);
ImageRequestBuilder imageRequestBuilder = ImageRequestBuilder.newBuilderWithSource(uri);
imageRequestBuilder.setRotationOptions(RotationOptions.autoRotate()); 
imageRequestBuilder.setImageDecodeOptions(new ImageDecodeOptions(ImageDecodeOptions.newBuilder()
.setBitmapConfig(Bitmap.Config.RGB_565)));
imageRequestBuilder.setResizeOptions(new ResizeOptions(reqWidth, reqHeight));
ImageRequest imageRequest = imageRequestBuilder.build();

PipelineDraweeControllerBuilder draweeControllerBuilder = Fresco.newDraweeControllerBuilder();
draweeControllerBuilder.setOldController(simpleDraweeView.getController());
draweeControllerBuilder.setImageRequest(imageRequest);
draweeControllerBuilder.setTapToRetryEnabled(false); 

DraweeController draweeController = draweeControllerBuilder.build();
simpleDraweeView.setController(draweeController);

Fresko 1.5.0

Gerät: Lenovo, Android 7.1.1

_Bitte lassen Sie es mich wissen, wenn Sie weitere Informationen benötigen.

@babyblue1314 Ich sehe keine Übergänge in deinen Videos oder im übergangsbezogenen Code. Sind Sie sicher, dass Sie vom gleichen Thema sprechen?

@oprisnik Entschuldigung, ich habe gerade festgestellt, dass sich dieses Übergangsproblem von meinem Problem unterscheidet.
Ich habe gesehen, dass das Phänomen meinem ähnlich ist, also……
Soll ich eine neue Ausgabe starten?

@babyblue1314 ja bitte, das scheint ziemlich unabhängig zu sein.

@oprisnik Ich habe endlich die Ursache für mein Problem gefunden.
Falls andere Leute missverstehen, bin ich hier, um einige Erklärungen zu geben.
Mein Problem hat mit dem Bildformat zu tun.
Wenn ich die Methode imageRequestBuilder.setProgressiveRenderingEnabled(true) mit PNG-Format verwende, kann sich mein Problem immer reproduzieren.
Wenn ich die Methode im PNG-Format in imageRequestBuilder.setProgressiveRenderingEnabled(false) ändere, funktioniert alles einwandfrei.
@oprisnik Nochmals vielen Dank für Ihre Geduld!

Bitte beheben Sie dieses Problem...

Fresco 1.9.0 behebt das Problem nicht richtig.
Eine Mischung aus den Vorschlägen in diesem Thread behebt es je nach Gerät:

Also verwende ich beide Problemumgehungen in meinem Code, um in meinem Code sicher zu sein, und hoffentlich deckt das alles ab. @oprisnik Ich werde einige Zeit damit verbringen, das Problem besser zu verstehen. Wenn ich eine Lösung finde, werde ich eine PR einreichen.

Ja, leider haben wir immer noch keine gute Lösung für dieses Problem, da alle in diesem Thread erwähnten Lösungen auf die eine oder andere Weise fehlschlagen. Wenn jemand eine Idee hat, wie man das richtig beheben kann, lassen Sie es uns bitte wissen oder noch besser, reichen Sie eine PR ein :)

Dennoch tritt dieses Problem bei der Komponente Reactive-Native-Maps auf. Ich kann mir vorstellen, dass es ein gleichzeitiges Problem ist?
Hast du eine Idee wo das Problem liegt?

Gibt es Fortschritte bei der Eingrenzung des Problems? Anscheinend haben wir seit April nichts mehr gehört.

Wir hatten immer noch keine Zeit, weiter zu untersuchen, was hier vor sich geht. Schauen Sie sich das Problem gerne an und senden Sie einen Pull-Request!

Wie bereits erwähnt, scheint das zugrunde liegende Problem ein Android-Framework-Fehler zu sein, bei dem ImageView die Sichtbarkeit des zugrunde liegenden Drawable bei der Rückkehr aus dem Übergang nicht richtig wiederherstellt.

Ich habe hier einen Android-Fehlerbericht eingereicht: https://issuetracker.google.com/issues/111293868

Ich habe auch eine (Nicht-Fresco-)Beispiel-App erstellt, die das Problem beschreibt: https://github.com/oprisnik/VisibilityPlayground

Wir werden untersuchen, ob es eine Problemumgehung für dieses Problem gibt. Fresco erfordert jedoch eine manuelle Speicherverwaltung und wir verlassen uns auf die Drawable-Sichtbarkeit, um das Bild erneut anzufordern, daher bin ich mir nicht sicher, ob es eine bessere Lösung als die oben beschriebenen Problemumgehungen gibt.

Ich wechselte zu Fresko, ohne mir dieses Problems bewusst zu sein. Ich rendere eine Menge Gifs und es macht einen tollen Job, aber ich bin auch auf diese Animationen für die Navigation angewiesen. Ich konnte die oben genannten Hacks verwenden, aber bei einer Rückkehranimation verschwindet das Bild.

Wirklich invalidate oder View.setVisibility kann Drawable nicht anzeigen, Sie müssen Drawable.setVisible(true, true) direkt aufrufen.
Ich füge diese Codes in A Activity#OnCreate hinzu, es funktioniert gut:

ActivityCompat.setExitSharedElementCallback(this, new SharedElementCallback() {
            <strong i="7">@Override</strong>
            public void onSharedElementEnd(List<String> sharedElementNames, List<View> sharedElements, List<View> sharedElementSnapshots) {
                super.onSharedElementEnd(sharedElementNames, sharedElements, sharedElementSnapshots);
                if (FP.empty(sharedElements)) {
                    return;
                }
                for (View view : sharedElements) {
                    if (view instanceof SimpleDraweeView) {
                        ((SimpleDraweeView) view).getDrawable().setVisible(true, true);
                    }
                }
            }
        });

@oprisnik In Ihrer Nicht-Fresco-Beispiel-App stellen Sie den Übergang auf ChangeBounds ein . Tritt der Fehler auf, wenn Sie diese Zeile entfernen? Ich denke, die Sichtbarkeit wird korrekt wiederhergestellt, wenn ChangeImageTransform im Spiel ist. Ist es möglich, Freskenbilder mit dem ChangeImageTransform Laufen zu bringen?

@RainFool hat recht. simpleDraweeView.getVisibility() ist VISIBLE , aber simpleDraweeView.getDrawable().isVisible() ist false .

Ja, dies ist ein Fehler im Android-Framework, bei dem die Sichtbarkeit der Ansicht (genauer ImageView) nicht an das Drawable weitergegeben wird, sodass Sie die Sichtbarkeit manuell aktualisieren müssen. Bitte markieren Sie den Android-Fehlerbericht hier, damit dieser mehr Sichtbarkeit erhält: https://issuetracker.google.com/issues/111293868

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen