Je lisons des octets à travers TCP avec BufferDreader. Le problème est readline () lit jusqu'à ce que les octets 10 ou 10 et 13. Cela ne renvoie pas à ces NL et CR. J'ai besoin de tous les octets (car ils sont tous des données). Avec juste nl c'est bon, je peux ajouter '\ n' après chaque lecture lecture (), mais le problème est que je ne sais pas s'il y a un retour de transport après NL, qui serait également supprimé par readline (), donc je ne saurais donc pas savoir si Ajoutez-le aussi. Lire () résout ce problème, mais c'est très très lent. Inutilisable. Y a-t-il un moyen d'utiliser quelque chose d'autre? Parce que le seul moyen de faire, c'est modifier les données provenant du serveur pour adapter cet algorithme de lecture () stupide ...
4 Réponses :
sur Java moderne C'est un problème résolu mais Android a des bibliothèques anciennes ... mais je pense que Guava est utilisable (et éventuellement, inclus par défaut déjà?) - Essayez ceci: L'astuce consiste à ne pas appeler Si le code ci-dessus entraîne toujours un taux de transfert de 70 kb / s, bien, c'est ce que c'est. La connexion du téléphone est lente ou le serveur est lent ou quelque chose entre vous. Étant donné que vous 'RE* Utilisez actuellement NB: i T est possible que vous ne voulez pas une chaîne du tout ici, mais des octets à la place. Même principe: lecture () , mais à appeler lecture (char []) - mais il s'agit d'une méthode un peu délicate à utiliser (il garantit que Il ne reviendra pas que la fin du flux est atteint ou au moins 1 caractère est lu; il ne remplit pas nécessairement le tableau de caractères. La méthode chartstreams.tostring sera la plus rapide possible et la lisez. tout. bufferedreader , je suis sûr que c'est bien sûr le cas (tout le point de bufferedreader est que son lue () méthode est décemment rapide, vs. ruisseaux bruts où cela a tendance à être très lent).
On dirait que vous essayez de lire des données binaires plutôt que des données textuelles, donc Si cela ne le résout pas, examinez s'il pourrait s'agir de la vitesse du serveur ou si la vitesse est limitée, pas par l'appel à Cela pourrait aider à voir une partie du code et d'en apprendre davantage sur la source des images et de ce qui leur arrive après leur lecture. readline () n'est pas approprié. Comme le souligne Henry dans leur commentaire, readline () utilise l'une des méthodes de lecture, donc ne peut pas éventuellement être plus rapide que toutes. Essayez l'une des opérations de lecture qui prend un tampon ( octet [] ) comme argument.
Lecture () mais par ce qui se passe une fois les données ont été lus. Si vous ne lisez qu'à la vitesse à laquelle votre code peut traiter, les étapes ultérieures de votre pipeline de traitement peuvent être le problème.
Si votre tarif de lecture est ~ 70 Ko par minute, le problème est dans votre système d'exploitation ou votre connexion réseau ou le serveur que vous lisez.
La réécriture du code côté client ne résoudra pas ce problème.
jamais jamais Utiliser une concaténation à chaîne avec jamais Utilisez le + pour construire la réponse lors de la lecture d'un fichier. Puisque la chaîne est immuable, en utilisant + doit créer une nouvelle chaîne à chaque fois, juste pour ajouter un seul caractère. INT () méthode ou toute autre méthode qui lit ou écrit des caractères simples à la fois. Les frais généraux supplémentaires par caractère ne disparaissent pas complètement, pas même lorsque vous utilisez un flux qui intègre un tampon comme bufferedreader . stringbuilder . Comme ceci:
Quel
Lire la méthode Avez-vous essayé d'utiliser, il y en a 4? Pouvez-vous ajouter votre code à la question? En outre, pouvez-vous mettre "très très très lent" en chiffres, parlons-nous de mégaoctets ou de kilo-octets par secondembufferin = nouvelle bufferedReader (nouvelle INPUTREAMReader (socket.getInputStream (), "ISO-8859-1")); mservermessage + = (char) mbufferin.read ();
lent - 70kb à environ minutes. Je transfère des images, donc c'est très lent
Depuis que la lecture est plus basique que la lecture en lecture, celle-ci ne peut pas être plus rapide.
Il peut parce qu'il utilise un autre algorithme Stackoverflow.com/Questtions/41324192/...
Vous ne devriez pas utiliser un lecteur pour lire des données binaires ... comme une image. Utilisez un
bufferedInputStream . Ce sera plus rapide et plus correct.Est-ce que vous lisez des octets ("je lis des octets") ou des caractères (vous utilisez un
* lecteur )? Si vous souhaitez lire des octets, lisez à partir duintrouvable , peut-être utiliser unbufferedInputStream.