Nous avons des problèmes avec une application hybride de lecteur audio, en utilisant des fichiers audio m4a assez volumineux. En bref, il faut beaucoup trop de temps pour commencer la lecture (lors de l'utilisation de ressources audio en ligne).Comportement bizarre de l'application hybride CrossWalk lors de la lecture audio web m4a
Pour illustrer le problème, nous avons créé un prototype plus petit avec la structure suivante:
Corps:
<audio src="..." controls="controls" preload="none"></audio>
<button class="change-current-time">Play and change currentTime</button>
Script:
var audioTags = document.querySelectorAll('audio');
[].forEach.call(audioTags, function (item) {
item.addEventListener('play', onPlayStateChange);
item.addEventListener('timeupdate', onPlayStateChange);
item.addEventListener('error', onPlayStateChange);
item.addEventListener('pause', onPauseReset);
});
function onPlayStateChange(e) {
var id = e.target.parentNode.id;
if (count[id]) {
return;
}
if (e.type === 'play') {
count[id + 'start'] = +new Date();
} else if (e.target.parentNode.querySelector('audio').currentTime > currentTimeOffset) {
var span = e.target.parentNode.querySelector('span');
count[id] = 1;
if (span) {
span.innerText = e.type === 'error' ? 'Audio type or codec does not supported' : new Date() - count[id + 'start'];
}
}
}
Lorsque nous construire l'application avec Cordova 6.4.0 en utilisant WebView, il commence playb Ack dans ~ 3.5s. L'activité du réseau ressemble à ceci:
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=webview HTTP/1.1 206 29522945
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=webview HTTP/1.1 206 326657
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=webview HTTP/1.1 206 29163520
Lorsque nous construisons l'application avec Cordova 6.4.0 avec le plugin Crosswalk-WebView 2.2.0, il commence la lecture en 18s au mieux, mais parfois le retard est encore plus important - jusqu'à 45s. Il semble que la raison principale est la différence de l'activité du réseau:
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 2
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 200 29522945
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 577690
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 200 29522945
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 577690
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 200 29522945
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 577690
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 200 29522945
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 577690
GET /tmp/1916firstchapterscollection_09_various_64kb.m4a?app=crosswalk HTTP/1.1 206 7384995
... quand seule la première demande est servi avec le « normal » user-agent, toutes les suivantes sont servis avec stagefright/1.2 (Linux;Android 5.0.1). Pourquoi la différence et comment pouvons-nous éviter cela?
P.S. Voici the folder avec tous les apks et les données connexes.
Créer quelque chose lika un [Github] (https://github.com/) référentiel pour votre prototype rendrait beaucoup plus facile de reproduire votre problème. – Phonolog
@Alex Je suppose que vous avez déjà soulevé un problème dans un projet de crosswalk et qu'il a été classé en tant que problème P2. Nous devons donc attendre le correctif de l'équipe de passage pour piétons. L'ai posté pour le bénéfice des autres – Gandhi
vous n'êtes pas seul .... [question similaire sur xda] (https://forum.xda-developers.com/android/help/stagefright-makes-multiple-http-t3390372) et même sur [github] (https://github.com/WhisperSystems/Signal-Android/issues/4636) – ymz