QNetworkAccessManager – d'abord GET très lent

J'ai un problème avec l'utilisation de QNetworkAccessManager dans Qt 5.5 sur Android. Le téléchargement d'un fichier graphique simple et petit via http GET entraîne beaucoup d'appels de collecte de déchets et un verrouillage de l'interface utilisateur pendant cette période. Les GET subséquents fonctionnent parfaitement et sans ces appels GC. Le code est le suivant:

void DownloadManager::downloadFile(QUrl fromUrl, QString toFilePath) { _currentFilePath = toFilePath; QNetworkRequest request; request.setUrl(fromUrl); qDebug() << "before"; _currentReply = _mgr.get(request); qDebug() << "after"; connect(_currentReply, SIGNAL(error(QNetworkReply::NetworkError)), this, SLOT(downloadError(QNetworkReply::NetworkError))); connect(_currentReply, SIGNAL(downloadProgress(qint64, qint64)), this, SLOT(downloadProgress(qint64,qint64))); connect(_currentReply, SIGNAL(finished()), this, SLOT(downloadFinished())); } 

DownloadManager est une classe dérivée QObject personnalisée sans aucune caractéristique particulière pertinente pour la demande get. _mgr est un objet QNetworkAccessManager qui est attribué lors de DownloadManagers cTor.

  • Comment ajouter des tuiles à Google Maps et les animer, c'est-à-dire les remplacer par de nouvelles carreaux en continu
  • RecyclerView est absent
  • Les fichiers copiés copiés dans APK incluent les bibliothèques JOO et Common IO dans le projet Android
  • Couper la partie du bitmap
  • Impossible d'ouvrir une extension de fichier personnalisée
  • Comment ajouter des informations de profil dans le tiroir de navigation Android?
  • Comme vous pouvez le voir, ce n'est qu'un exemple de manuel d'une demande de demande, rien de trop intéressant à ce sujet. Et comme je l'ai dit: cela fonctionne, pour la plupart. Seule la première requête est terminée comme ceci:

     D/ .../downloadmanager.cpp:61 (void DownloadManager::downloadFile(QUrl, QString)): before D/dalvikvm(13298): GC_CONCURRENT freed 2290K, 25% free 10911K/14407K, paused 2ms+3ms, total 29ms D/dalvikvm(13298): GC_CONCURRENT freed 501K, 25% free 10884K/14407K, paused 13ms+2ms, total 35ms D/dalvikvm(13298): GC_CONCURRENT freed 524K, 25% free 10892K/14407K, paused 12ms+3ms, total 36ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 6ms D/dalvikvm(13298): GC_CONCURRENT freed 537K, 25% free 10887K/14407K, paused 2ms+9ms, total 32ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 14ms D/dalvikvm(13298): GC_CONCURRENT freed 840K, 25% free 10899K/14407K, paused 12ms+3ms, total 38ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 11ms D/dalvikvm(13298): GC_CONCURRENT freed 1294K, 25% free 10901K/14407K, paused 2ms+2ms, total 27ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 11ms D/dalvikvm(13298): GC_CONCURRENT freed 1187K, 22% free 11330K/14407K, paused 2ms+2ms, total 30ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 15ms D/dalvikvm(13298): GC_CONCURRENT freed 1459K, 19% free 11919K/14535K, paused 13ms+4ms, total 64ms D/dalvikvm(13298): WAIT_FOR_CONCURRENT_GC blocked 18ms D/ .../downloadmanager.cpp:65 (void DownloadManager::downloadFile(QUrl, QString)): after 

    Je ne comprends tout simplement pas ce qui provoque le fait que GC se produise: il faut environ une demi-seconde pour que tout fonctionne (pour un téléchargement qui devrait prendre une fraction de seconde et, en outre, être asynchronique et ne pas verrouiller La UI).

    Information additionnelle:

    • C'est toujours le premier téléchargement qui déclenche ceci. Les téléchargements subséquents, même pour le même fichier, fonctionnent parfaitement

    • Peu importe s'il y a un fichier à l'emplacement exact avec le nom exact ou non. En téléchargeant le fichier, en le supprimant, en revenant à l'application et en redéployant, vous obtenez les mêmes résultats: le premier get est lent et le GC, le second fonctionne parfaitement.

    • J'appelle tout cela à partir d'un fichier QML, qui provoque un objet c ++ de singleton pour appeler DownloadManager :: downloadFile.

    • À l'exception de l'interface utilisateur QML, rien d'autre ne se produit dans l'application. Pas de gros échanges de données, aucun chargement d'arrière-plan sur d'autres threads, rien.

    Je serais reconnaissant de toutes les indications pour résoudre ce problème.

  • Comment imprimer la requête exécutée par la méthode query () de l'Android
  • Utilisation des API Android de reconnaissance vocale de Google Glass
  • Comment lancer une caméra avant avec intention?
  • Comment utiliser People.getFraction ()?
  • Icônes AccountAuthenticator
  • Inflatable ImageView pour mettre en GalleryView n'est pas la bonne taille
  • One Solution collect form web for “QNetworkAccessManager – d'abord GET très lent”

    Je n'ai pas essayé sur Android, mais j'ai eu le même problème sur Windows. Parce que ce sont les mêmes symptômes, je dirais que c'est probablement la même raison, c'est-à-dire que la mise en œuvre consiste à charger une bibliothèque partagée pendant un premier appel. Ceci est particulièrement vrai lors de l'utilisation de la connexion cryptée; Dans mon cas, je peux voir dans Visual Studio que 19 DLL sont chargées lors du premier appel get ().

    Une façon de contourner cela est de préconnexion au serveur en utilisant connectToHost ou connectToHostEncrypted, selon que vous utilisez une connexion cryptée (p. Ex. HTTPS) ou non. Je l'appelle au démarrage de l'application, mais chaque fois que l'IU est inactif devrait être bien. Ensuite, les appels get () seront tous les mêmes, y compris le premier, car les bibliothèques ont été chargées et la connexion est déjà établie. Je suppose que la connexion à n'importe quel serveur va charger les bibliothèques.

    Voir https://forum.qt.io/topic/65201/qnetworkaccessmanager-first-get-very-slow/14 pour plus de détails sur l'erreur générique (pas spécifique à Android).

    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.