Lors du lancement d'une activité qui utilise Fresco, qui a été générée via Android App Bundle , il ne parvient pas à trouver "libimagepipeline.so" et plante l'application.
Au départ, je pensais que cela pouvait être un problème avec minify, R8 ou Proguard, mais je les ai tous désactivés et j'ai toujours observé le même résultat lors de la création via App Bundle.
J'ai testé d'autres composants de mon application qui utilisent également des bibliothèques natives, mais ils fonctionnent tous comme prévu, uniquement avec Fresco qui a du mal à charger le binaire respectif.
Une solution temporaire, mais pas idéale, que j'ai trouvée consiste à désactiver le fractionnement des APK par abi
à l'aide de la configuration suivante, mais l'inclusion de tous les fichiers binaires entraîne une taille d'APK considérablement plus grande.
android {
// Rest of your configuration here
bundle {
abi {
enableSplit false
}
}
}
Votre message d'erreur ressemble-t-il à celui-ci ? #2049
Oui, en gros. Cependant, cette question, bien que liée, je pense qu'elle se concentre davantage sur la
manque de prise en charge d'Android App Bundle dans Fresco ou SoLoader et
diviser les binaires de cette façon.
Je peux me tromper, mais ce problème est reproductible sur tous les appareils que j'ai
testé, pas seulement des marques sélectionnées.
Et selon les guides d'expédition Fresco, il n'y a pas de note sur le cas d'utilisation de
expédition via Android App Bundles, et nous ne pouvons pas utiliser la clé splits
comme quand
vous utilisez bundle
la clé splits
est ignorée.
Le mardi 11 décembre 2018, 06:40 KimiChiu, [email protected] a écrit :
Votre message d'erreur ressemble-t-il à celui-ci ? #2049
https://github.com/facebook/fresco/issues/2049-
Vous recevez ceci parce que vous avez créé le fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/fresco/issues/2253#issuecomment-446089907 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABUQnQ4cZ-sWkG5b72Ea81wiQjS02yjlks5u31NxgaJpZM4ZIsuf
.
Salut @icerfish ,
Merci d'avoir déposé ce problème avec tous les détails requis (peut-être ajouter une pâte de l'erreur si vous avez le temps). Je peux imaginer que Fresco pourrait ne pas prendre entièrement en charge les bundles d'applications et je ne pense pas que nous ayons déjà testé l'interaction.
Je vais marquer cela comme un "bug" et "aide recherchée" en espérant que c'est quelque chose avec lequel la communauté open source peut nous aider.
Salut @lambdapioneer ,
Voici la trace de la pile :
FATAL EXCEPTION: FrescoIoBoundExecutor-8
Process: com.gobuzzvault.android, PID: 17499
java.lang.NoClassDefFoundError: com.facebook.imagepipeline.memory.NativeMemoryChunk
at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:25)
at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:13)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:267)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream.<init>(MemoryPooledByteBufferOutputStream.java:51)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:73)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:24)
at com.facebook.imagepipeline.producers.LocalFetchProducer.getByteBufferBackedEncodedImage(LocalFetchProducer.java:87)
at com.facebook.imagepipeline.producers.LocalFetchProducer.getEncodedImage(LocalFetchProducer.java:99)
at com.facebook.imagepipeline.producers.LocalContentUriFetchProducer.getCameraImage(LocalContentUriFetchProducer.java:100)
at com.facebook.imagepipeline.producers.LocalContentUriFetchProducer.getEncodedImage(LocalContentUriFetchProducer.java:76)
at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:52)
at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:48)
at com.facebook.common.executors.StatefulRunnable.run(StatefulRunnable.java:43)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:51)
at java.lang.Thread.run(Thread.java:764)
Caused by: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libimagepipeline.so
at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:703)
at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:564)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:500)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:455)
at com.facebook.imagepipeline.nativecode.ImagePipelineNativeLoader.load(ImagePipelineNativeLoader.java:40)
at com.facebook.imagepipeline.memory.NativeMemoryChunk.<clinit>(NativeMemoryChunk.java:31)
at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:25)
at com.facebook.imagepipeline.memory.NativeMemoryChunkPool.alloc(NativeMemoryChunkPool.java:13)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:267)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferOutputStream.<init>(MemoryPooledByteBufferOutputStream.java:51)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:73)
at com.facebook.imagepipeline.memory.MemoryPooledByteBufferFactory.newByteBuffer(MemoryPooledByteBufferFactory.java:24)
at com.facebook.imagepipeline.producers.LocalFetchProducer.getByteBufferBackedEncodedImage(LocalFetchProducer.java:87)
at com.facebook.imagepipeline.producers.LocalFetchProducer.getEncodedImage(LocalFetchProducer.java:99)
at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getThumbnail(LocalContentUriThumbnailFetchProducer.java:135)
at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getCameraImage(LocalContentUriThumbnailFetchProducer.java:100)
at com.facebook.imagepipeline.producers.LocalContentUriThumbnailFetchProducer.getEncodedImage(LocalContentUriThumbnailFetchProducer.java:75)
at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:52)
at com.facebook.imagepipeline.producers.LocalFetchProducer$1.getResult(LocalFetchProducer.java:48)
at com.facebook.common.executors.StatefulRunnable.run(StatefulRunnable.java:43)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:51)
at java.lang.Thread.run(Thread.java:764)
Cela ressemble à des problèmes que d'autres ont.
En regardant autour de la base de code, il semble que ce ne soit pas un problème avec Fresco lui-même, mais plutôt avec la bibliothèque SoLoader. Je vais poster le problème sur ce référentiel, et la charge de travail permettant de consacrer du temps à essayer de déterminer quel est le problème exactement.
Salut, j'ai eu le même problème lors de l'utilisation des bundles d'applications, comme décrit dans https://github.com/facebook/fresco/issues/2049#issuecomment -441088387
En utilisant Fresco 1.11 et en définissant .experiment().setNativeCodeDisabled(true)
dans ImagePipelineConfig de Fresco, les images statiques fonctionnaient pour moi, mais les GIF se sont écrasés avec une trace de pile différente, qui ressemblait au même problème SoLoader avec une bibliothèque différente. @icerfish , cela peut vous aider si vous n'utilisez pas de GIF.
J'ai découvert un problème dans la bibliothèque SoLoader utilisée par Fresco. J'ai préparé les relations publiques avec un correctif : facebook/soloader#26
Ce correctif permet à la fresque de fonctionner correctement avec l'app bundle.
J'ai publié la version corrigée de SoLoader lib. Vous pouvez l'utiliser dans votre projet si vous ne pouvez pas attendre que PR soit fusionné.
repositories {
maven {
url "https://dl.bintray.com/nnesterov/maven"
}
}
compile('com.facebook.fresco:fresco:1.10.0') {
exclude group: 'com.facebook.soloader', module: 'soloader'
}
compile("com.avito.android:patched-soloader:0.1.0")
La version précédente de patched-soloader ne fonctionnait pas sur les appareils pré-lollipop. Je l'ai corrigé. Utilisation
compile("com.avito.android:patched-soloader:0.1.1")
@nesterov-n merci pour le bon correctif, des progrès pour l'intégrer dans la fresque ?
@nesterov-n je suis également confronté au même problème. s'il vous plaît laissez-moi savoir quand sera-t-il intégré dans la fresque?
Salut @theromis et @sailesh2
Je ne travaille pas sur Facebook (c'est tellement triste). Je ne suis qu'un utilisateur de Fresco mais je ne pouvais pas attendre un correctif. J'ai donc dû le déboguer et le réparer.
Actuellement, j'utilise la version corrigée de soloder lib pour mon projet comme je l'ai décrit dans le commentaire ci-dessus. La version la plus récente est com.avito.android:patched-soloader:0.1.2
Mon PR à soloader lib est en cours de révision, mais le mainteneur de soloader dit qu'il n'y a pas d'estimation de la nouvelle version de soloader lib. Il est donc impossible d'estimer quand Fresco utilisera cette nouvelle version.
Si c'est urgent, vous pouvez utiliser ma version corrigée. Nous avons publié un bundle avec fresque à la production. Fonctionne bien.
Impossible de comprendre pourquoi cette solution de contournement n'est pas encore intégrée à Fresco.
Nous avons débarqué le correctif SoLoader. Nous publierons bientôt une nouvelle version de Fresco une fois la version SoLoader publiée.
@oprisnik quel est l'ETA pour les sorties ? Je comprends que cela nécessite la coordination de 2 équipes, mais au moins un nombre approximatif aiderait de nombreux développeurs à décider s'ils doivent appliquer la solution de contournement ci-dessus ou attendre la sortie.
SoLoader v0.6.0 vient de sortir et j'ai mis à jour la dépendance Fresco (6fc071d1892166d11d1f237f10e2d9bcdf858087). Nous voulons attendre la sortie de Bolts sous licence MIT (#2257). Si cette version prend plus de temps que prévu, nous allons l'ignorer pour le moment et publier sans cela. Dans tous les cas, la nouvelle version devrait sortir dans quelques jours.
Je ne veux pas être ennuyeux, mais la fresque ne devrait-elle pas être libérée ? Il semble que ce problème que vous avez signalé n'a reçu aucune activité depuis un certain temps.
Nous venons de publier la version 1.12.0 qui inclut la version fixe de SoLoader.
essayez d'ajouter proguard
-garder la classe @com.facebook.common.internal.DoNotStrip *
-keepclassmembers class * {
@com.facebook.common.internal.DoNotStrip *;
}
-gardez la classe @com.facebook.soloader.DoNotOptimize *
-keepclassmembers class * {
@com.facebook.soloader.DoNotOptimize *;
}
-keepclassmembers class * {
originaire de
}
-ne préviens pas okio. *-ne pas avertir com.squareup.okhttp. *
-ne pas avertir okhttp3. *-ne pas avertir javax.annotation. *
-ne pas avertir com.android.volley.toolbox. *-ne pas avertir com.facebook.infer. *
@ProHzen Cela a-t-il corrigé le plantage du soloader ?
Oui, je l'ai résolu.
il est toujours dans Fresco 2.0.0, :-( , veuillez suggérer une solution de contournement, je n'ai qu'un problème avec les périphériques Nexus
@ProHzen Bonjour, pouvez-vous m'envoyer votre liste de confusion? J'ai essayé comme vous l'avez fait, mais cela n'a pas fonctionné.
Info:
fresque:1.13.0
chemin de classe 'com.android.tools. build:grade :3.5.1'
Commentaire le plus utile
J'ai découvert un problème dans la bibliothèque SoLoader utilisée par Fresco. J'ai préparé les relations publiques avec un correctif : facebook/soloader#26
Ce correctif permet à la fresque de fonctionner correctement avec l'app bundle.
J'ai publié la version corrigée de SoLoader lib. Vous pouvez l'utiliser dans votre projet si vous ne pouvez pas attendre que PR soit fusionné.