Fresco: Partager l'élément Gone after do SharedElementReturnTransition dans Android N

Créé le 31 août 2016  ·  70Commentaires  ·  Source: facebook/fresco

J'utilise le code de fresque le plus récent pour effectuer le travail de transition SharedElement, il fonctionne bien dans Android L、M, Mais sur Android N, ça se passe mal

avant la transition
screenshot0

après le passage
screenshot0

bug help wanted

Commentaire le plus utile

Ajoutez simplement ce code dans l'activité d'appel,+1 si cela peut vous aider !!! @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);
                    }
                }
            }
        });

Tous les 70 commentaires

Pouvez-vous s'il vous plaît montrer comment vous faites la partie de transition en utilisant l'application de démonstration de Fresco ?

activity_main.xml et activity_detail ont le même SimpleDraweeView avec le même transitionName
et dans la méthode onCreate de DetailActivity comme ci-dessous :

protected void onCreate (Bundle saveInstanceState) {
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(new View.OnClickListener() {
@Passer outre
public void onClick (View v) {
Toast.makeText(DetailActivity.this, "dsasa", Toast.LENGTH_LONG).show();
}
});
}

addTransitionListener() ne fait rien juste imprimer le journal

alors est-ce que j'utilise la mauvaise façon de faire la transition?

Cela m'arrive aussi.

J'ai ce qui suit dans la méthode onCreate() avant 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);

Je rencontre le même problème. Le setSharedElementReturnTransition ne fonctionne pas sur Android N. J'ai ajouté des journaux aux écouteurs de transition et onTransitionStart et onTransitionEnd ne sont pas déclenchés sur Android N, mais sur Android M & L, cela fonctionne très bien.
J'utilise la dernière version de la bibliothèque Fresco com.facebook. fresco:fresco :0.14.1 avec com.facebook. fresque:imagepipeline-okhttp3 :0.14.1
Je n'ai pas ce problème si j'utilise la bibliothèque Picasso pour charger l'image.
Le scénario est similaire : gridView, gridItem navigue vers une autre Activity (tout va bien sur cette partie) mais quand j'y retourne, il n'y a pas de réentrée, l'image clignote et se recharge (l'image d'espace réservé n'est pas visible ni l'image qui était déjà chargé). Cela ne se produit que sur Android N (7.0)

Une mise à jour sur ce problème?

Passé de Fresco à Picasso et le problème est résolu. Dommage que cette bibliothèque ne soit pas maintenue aussi souvent que l'exigent les nouvelles versions du système d'exploitation Android qui sortent.

Il semble que ce problème soit marqué à tort comme « besoins-détails ». Ce problème existe également sur Android 7.1.1 (API niveau 25).

Merci, nous allons jeter un oeil

Je rencontre également le même problème, donc +1 de ma part pour le résoudre.

pareil ici

Fais-le. Fais-le. ;-)

Oui, s'il te plaît, fais-le.

S'il te plaît...

+1

Je me demande pourquoi ce n'est pas une priorité élevée..

+1

Lorsque je fais défiler jusqu'à la position de l'élément partagé dans onActivityReenter l'élément disparu revient cependant avec un petit scintillement blanc :

    <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);
        }
    }

Si quelqu'un connaît une meilleure solution, j'apprécierais si vous pouviez la partager.

Bonjour, je rencontre le même problème mais uniquement sur Android 7.1.1 API 25

S'il y a des mises à jour sur le problème, je l'apprécierais grandement.

même chose ici sur emu avec 7.x, mais j'utilise onWindowFocusChanged pour être immersif, une fois la finition terminée, l'image disparaîtra mais se réaffichera instantanément.

Pareil ici. L'appel de requestLayout sur la vue contenant le SimpleDraweeView semble le corriger avec un certain scintillement. s'il vous plaît donnez votre avis

Ajoutez simplement ce code dans l'activité d'appel,+1 si cela peut vous aider !!! @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);
                    }
                }
            }
        });

même problème ici ... @antxyz J'ai mis votre code dans la méthode onCreate des activités d'appel et d'appel mais sans succès. L'image de l'élément partagé est toujours invisible après le retour de la transition.

Je ne sais pas si cela peut aider à trouver une solution, mais j'ai remarqué que lorsque le clavier logiciel est ouvert, le SimpleDraweeView devient visible.

J'avais le même problème et il a été résolu après ces deux appels:

  1. Juste avant 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. Dans le onCreate de la nouvelle activité :
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 des mises à jour à ce sujet ? C'est dommage qu'il n'ait pas encore été réglé.
Je rencontre toujours cela avec l'API 24+, lorsque l'élément partagé est un élément à l'intérieur d'un RecyclerView .
Aucune des solutions de contournement répertoriées sur ce ticket n'a fonctionné pour moi (la vue n'est jamais définie sur invisible/partie en premier lieu).
J'utilise DraweeTransition.createTransitionSet() pour les transitions d'entrée et de retour.
Parfois, l'image disparaît jusqu'à ce que la vue recycleur défile, parfois elle revient avec un scintillement après un certain temps (peut-être en raison de l'appel de notifyDataSetChanged()).

Je ne sais pas si cela peut vous aider, mais c'est ce qui se passe dans Fresco selon les journaux lorsque la deuxième activité est fermée et que l'élément partagé revient à sa position :

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

Cela se produit lorsque le bitmap s'affiche à nouveau.
Lorsque le bitmap n'est pas affiché, les deux derniers événements ne se produisent pas :

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

@marcosalis Au retour à la première activité (avec recyclerView). Cela déclenche-t-il toujours un notifyDataSetChanged() ?

@erikandre merci pour la réponse ;)
Après quelques tests, je peux confirmer que notifyDataSetChanged() n'est pas appelé, même lorsque le bitmap est affiché seul.

C'est l'état du SimpleDraweeView si je mets un point d'arrêt dans SharedElementCallback.onSharedElementEnd() dans l'activité d'appel.

 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}}}

Je pense que cela pourrait avoir quelque chose à voir avec les méthodes doDetach() et doAttach() dans SimpleDraweeView , lorsque la vue elle-même est dans un RecyclerView .
Enfin, cela a fonctionné pour moi (ajouté à l'activité à partir de laquelle la transition est générée), bien que ce ne soit pas extrêmement propre :

        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 Super que vous ayez trouvé une solution de contournement ! J'ai essayé de reproduire ce problème particulier dans l'application Showcase fonctionnant sur Genymotion avec Android 7, mais sans succès.

À quoi ressemblent les vues d'éléments pour recyclerview ? Dans mon cas, il s'agissait simplement d'un FrameLayout enveloppant un SimpleDraweeView.

@marcosalis votre solution a fonctionné pour moi avec un petit changement, en supprimant le cycle for :

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();
                        }
                    }
            );

Je viens de tomber sur le même problème en jouant avec les transitions inter-activités. Aucune des solutions de contournement proposées ci-dessus ne semblait fonctionner. (API 25) Voici à quoi cela ressemble : https://vimeo.com/225497240

Je pense que nous avons trouvé une solution de contournement et j'espère qu'un correctif sera bientôt disponible.

La solution de contournement se trouve dans dc7ec2436fc9b639fe1a39398712c360b16da468.

Pour l'instant, vous devez configurer le premier DraweeView où commence la transition pour utiliser la gestion de la visibilité héritée en appelant simpleDraweeView.setLegacyVisibilityHandlingEnabled(true); (comme vous pouvez le voir dans l'exemple de transition de notre exemple d'application Showcase) .

Pouvez-vous s'il vous plaît vérifier si cela résout les problèmes pour vous? Nous allons sortir une nouvelle version de Fresco qui contiendra ce correctif très bientôt.

Oui, merci ! Confirmé que cela résout le problème. Dans l'attente d'une version mise à jour.

Nous avons publié Fresco v1.4.0 , qui inclut le correctif mentionné ci-dessus. Appelez simplement simpleDraweeView.setLegacyVisibilityHandlingEnabled(true); et cela devrait fonctionner maintenant.

Nous avons également mis à jour l' exemple de transition Showcase pour refléter ces changements.

Merci pour ce correctif, cela a fonctionné parfaitement dans mon cas. Une question, pourquoi ne pas mettre setGlobalLegacyVisibilityHandlingEnabled à true par défaut ? Il y a un problème de performances ?

La gestion de la visibilité a changé avec Android N et mon changement revient (en quelque sorte) à revenir au comportement pré-N. Changer ce comportement pour toutes les images pourrait entraîner d'autres problèmes inattendus et c'est pourquoi nous avons décidé de ne pas l'activer par défaut pour le moment. Une fois que nous aurons vérifié qu'il n'y a pas d'effets secondaires, nous envisagerons de l'activer par défaut.
N'hésitez pas à le définir sur true et à signaler tout problème que vous rencontrez.

ezgif com-resize

Ce correctif semble ne pas fonctionner au hasard. Je définis setGlobalLegacyVisibilityHandlingEnabled sur true, mais après quelques clics, l'image renvoyée est vide.

Fresque 1.5.0, Oreo

Edit: Après avoir développé quelques jours de plus et déplacé certaines vues, j'ai découvert que le problème ne se produisait plus du tout sur mon appareil Oreo pixel. Sur mon Nexus 5x API 24 émulé, l'image est toujours vide après l'animation de sortie.

J'ai le même problème avec setLegacyVisibilityHandlingEnabled . Le régler sur true fonctionne la plupart du temps mais parfois, juste au hasard, l'image disparaît après la transition de retour.

@marcosalis ça n'arrive que sur Oreo ou aussi sur Nougat ?

Salut @oprisnik J'ai réussi à le reproduire de manière aléatoire sur un Samsung S7 (Nougat) et sur un émulateur sur API 26. Faites-moi savoir si je peux être utile pour le déboguer.

Merci, j'essaierai de repro quand j'aurai un peu plus de temps

@oprisnik
Peut confirmer qu'il ne semble pas du tout faire son travail la plupart du temps (API24 + API25)

Cependant, j'ai réussi à le faire fonctionner un peu en utilisant le hack suivant:

        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();
                        });
                    }
                }
            }
        });

J'ai pu repro. Pour moi, cela ne se produit que rarement cependant. Je vais vérifier si je peux trouver une autre solution de contournement pour résoudre ce problème.

Bonjour @oprisnik ,
Avez-vous trouvé une autre solution de contournement ?

Pas encore, c'est difficile à résoudre car Google a modifié le comportement de visibilité de View, ce qui casse la gestion de la visibilité de Fresco (dont nous avons besoin pour la gestion de la mémoire) et je n'aurai pas non plus beaucoup de temps pour examiner cela dans un proche avenir . Cependant, il existe plusieurs alternatives mentionnées dans ce fil qui résolvent le problème (comme la solution de contournement de @MartB qui définit manuellement la visibilité).

Si quelqu'un souhaite examiner cela, les demandes de tirage sont toujours les bienvenues ! :)

@oprisnik , le react-native-maps est également affecté par ce problème.
J'ai marqué ces lignes comme commentaire dans le fichier RootDrawable.java comme solution de contournement.
Vous souvenez-vous/connaissez-vous un problème important lié au marquage de ces lignes en tant que lignes de commentaires ?

Le même problème que @efkan semble affecter un grand nombre d'appareils Android (Android Nougat 7.1 API 25 et

Leur solution a résolu tous les problèmes que j'avais.

@efkan je ne sais pas exactement. Je me souviens que j'ai également examiné cela lorsque je cherchais des solutions alternatives, mais que je l'ai rejeté. Je pense qu'un problème avec la suppression de ces contrôles est que le bitmap sous-jacent a été publié (puisque la vue n'est plus visible) et essayer de le dessiner lancerait un java.lang.RuntimeException: Canvas: trying to use a recycled bitmap ... puisque BitmapDrawable ne le fait pas effectuer tous les contrôles de santé mentale.

ImageView lui-même a le même bogue où il ne restaure pas correctement la visibilité Drawable de tout dessin, mais cela fonctionne toujours car la plupart des Drawables ne font pas la vérification de la visibilité et il n'y a pas de gestion manuelle de la mémoire - et le Bitmap sous-jacent serait toujours valable.

@oprisnik merci pour toutes ces explications.

Afin de tester si cela fonctionne, il est assez facile d'ajouter ceci en tant que paramètre à GenericDraweeHierarchyBuilder et en fonction de cela ignorer le contrôle de visibilité dans RootDrawable (qui est créé dans GenericDraweeHierarchy , voir https://github.com/facebook/fresco/blob/master/drawee/src/main/java/com/facebook/drawee/generic/GenericDraweeHierarchy.java#L155).

N'hésitez pas à soumettre un PR qui ajoute ce paramètre afin que vous puissiez l'activer pour vos applications et voir s'il y a des effets secondaires.

Le même problème n'apparaît que sur les appareils avec Android 7.1 (ou supérieur).
Aucune des solutions ci-dessus ne fonctionne.
Le problème apparaît toujours lorsque le réseau est limité à 10kb/s.

@babyblue1314 - Le changement RootDrawable mentionné ci-dessus ne le résout pas non plus pour vous ?

@oprisnik Merci pour votre réponse rapide !
Em… Je suppose que oui, le changement RootDrawable mentionné ci-dessus ne le résout pas non plus pour moi.
Je ne sais pas si je l'ai mal utilisé. Voici à quoi cela ressemble:

Avant d'utiliser le changement RootDrawable :

Après avoir utilisé le changement RootDrawable :

_ Je précise que le réseau est limité à 10kb/s. _
Et en plus, cela apparaît non seulement dans ListView mais aussi RecyclerView et GridView, comme indiqué ci-dessous :

Mon code est :

  1. ListViewAdapter (ou RecyclerViewAdapter ou 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);

Fresque 1.5.0

Appareil : Lenovo, Android 7.1.1

_S'il vous plaît laissez-moi savoir si vous avez besoin de plus d'informations.

@ babyblue1314 Je ne vois aucune transition dans vos vidéos ou dans le code lié à la transition. Êtes-vous sûr de parler du même problème ?

@oprisnik Désolé, je viens de réaliser que ce problème de transition est différent de mon problème.
J'ai vu que le phénomène est similaire au mien, alors……
Dois-je commencer un nouveau problème ?

@ babyblue1314 oui s'il vous plaît, cela semble sans rapport.

@oprisnik J'ai enfin trouvé la cause de mon problème.
En cas d'incompréhension des autres, je suis là pour donner quelques explications.
Mon problème a quelque chose à voir avec le format de l'image.
Si j'utilise la méthode imageRequestBuilder.setProgressiveRenderingEnabled(true) avec le format PNG, mon problème peut toujours se reproduire.
Si je change la méthode en imageRequestBuilder.setProgressiveRenderingEnabled(false) avec le format PNG, tout fonctionne bien.
@oprisnik Merci encore pour votre patience !

Merci de régler ce problème...

Fresco 1.9.0 ne résout pas le problème correctement.
Un mélange des propositions de ce fil le corrige en fonction de l'appareil :

J'utilise donc les deux solutions de contournement dans mon code pour être en sécurité dans mon code et j'espère que cela couvre tout. @oprisnik Je vais passer un peu de temps pour essayer de mieux comprendre le problème, si je trouve une solution, je soumettrai un PR.

Oui, malheureusement, nous n'avons toujours pas de bonne solution à ce problème, car toutes les solutions mentionnées dans ce fil échouent d'une manière ou d'une autre. Si quelqu'un a une idée sur la façon de résoudre ce problème, merci de nous le faire savoir ou, mieux encore, de soumettre un PR :)

Pourtant, ce problème sur le composant react-native-maps. J'imagine que c'est un problème concurrent ?
Avez-vous une idée d'où est le problème?

Des progrès pour identifier le problème? On dirait que nous n'avons rien entendu depuis avril.

Nous n'avons toujours pas eu le temps d'enquêter davantage sur ce qui se passe ici. N'hésitez pas à vous pencher sur le problème et à soumettre une pull request !

Comme mentionné précédemment, le problème sous-jacent semble être un bogue du framework Android où ImageView ne restaure pas correctement la visibilité du Drawable sous-jacent lors du retour de la transition.

J'ai déposé un rapport de bogue Android ici : https://issuetracker.google.com/issues/111293868

J'ai également créé un exemple d'application (non Fresco) qui décrit le problème : https://github.com/oprisnik/VisibilityPlayground

Nous étudierons s'il existe une solution à ce problème. Cependant, Fresco nécessite une gestion manuelle de la mémoire et nous comptons sur la visibilité Drawable pour demander à nouveau l'image, donc je ne sais pas s'il existe une meilleure solution que les solutions de contournement décrites ci-dessus.

Je suis passé à la fresque sans être au courant de ce problème. Je rends une tonne de gifs et cela fait un excellent travail, mais je suis également dépendant de ces animations pour la navigation. J'ai pu utiliser les hacks mentionnés ci-dessus, mais lors d'une animation de retour, l'image disparaîtra.

En fait, invalider ou View.setVisibility ne peut pas afficher drawable, vous devez appeler directement Drawable.setVisible(true, true).
J'ajoute ces codes dans A Activity#OnCreate, ça marche bien :

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 Dans votre exemple d'application sans fresque, vous définissez la transition sur ChangeBounds . Le bug se produit-il si vous supprimez cette ligne ? Je suppose que la visibilité est restaurée correctement lorsque le ChangeImageTransform est en jeu. Est-il possible de faire fonctionner les images de fresques avec le ChangeImageTransform ?

@RainFool a raison. simpleDraweeView.getVisibility() vaut VISIBLE , mais simpleDraweeView.getDrawable().isVisible() vaut false .

Oui, il s'agit d'un bogue dans le framework Android où la visibilité de la vue (ImageView pour être précis) n'est pas propagée au Drawable, vous devez donc mettre à jour manuellement la visibilité. Veuillez noter le rapport de bogue Android ici afin que cela ait plus de visibilité : https://issuetracker.google.com/issues/111293868

Cette page vous a été utile?
0 / 5 - 0 notes