Pergunta

Eu tenho um sistema que envia para um servidor de arquivo por arquivo e exibe uma barra de progresso de upload de arquivo progresso, em seguida, debaixo de uma segunda barra de progresso que eu quero indicar a percentagem de lote completo em todos os arquivos na fila para fazer o upload.

Informações e algoritmos eu posso trabalhar fora são:

Bytes Enviados / Total de Bytes Para Enviar = Primeira barra de progresso (por exemplo.512KB de 1024KB (50%))

Que funciona bem.No entanto supondo que eu tenho dois outros arquivos esquerda para carregar, mas ambos os tamanhos de arquivo são desconhecidas (como esta só é conhecida depois que o arquivo está prestes a começar e carregar, em que ponto ele é comprimido e o tamanho do arquivo é determinado) como eu poderia ir sobre fazer minha terceira barra de progresso?

Eu não acho que isso seria possível, pois eu precisaria de "Total de Bytes Enviados" / "Total de Bytes A Enviar", para replicar a lógica da minha primeira barra de progresso em uma escala maior, no entanto, eu consegui uma versão de trabalho:"Número do ficheiro actual estamos no" / "número total de arquivos para enviar" devolver o percentual de meio lote, no entanto, obviamente, não vai atualização incremental e é muito bruto.

Assim, no pensar mais eu pensei que se eu pudesse incorporar o arquivo atual % com este algoritmo, eu talvez pudesse obter o correto andamento percentual de meu lote ponto atual.

Eu tentei este algoritmo, mas infelizmente nenhuma tal aproveitar (desculpe a matemática cabeças, é, provavelmente, bastante evidente porque ele não vai funcionar)

("Current file number we are on" / "total number of files to send") * ("Bytes Sent" / "Total Bytes To Send")

Por exemplo, eu pensei que eu estava no caminho certo quando o teste com este exemplo:2/3 (2º de 3 de arquivo) = 66% (o que é certo até agora), mas depois, quando eu adicionei * 0.20 (para indicar que apenas 20% do 2º arquivo foi carregado), voltamos para 13%.O que eu preciso é apenas um pouco mais de 33%!Eu tentei o inverso no 0,80 e um (2/3 * (2/3 * 0.2))

Isso pode ser feito sem saber toda bytes em lote para carregar?

Por favor, ajuda!Obrigado!

Foi útil?

Solução 3

Oh meu Deus, eu não considerei a abordagem mais simples:

(double)((ProcessedFileCount + DecimalBytesTransferred) / TotalFileCount)

(onde o ProcessEdFileCount sempre indica arquivos totalmente transferidos e completos)

e prova de teste em 3 lote de arquivo:

Eg. ((2 + 1.0) / 3) (File 1+2+3: 100%) == batch 100% complete.
Eg. ((2 + 0.9) / 3) (File 1+2: 100%, File 3: 90%) == batch 96% complete.
Eg. ((1 + 0.9) / 3) (File 1: 100%, File 2: 90%) == only 63% complete.

Funciona um deleite! Obrigado pela sua opinião, embora eu considere todos os conselhos externos.

Outras dicas

Se você não sabe o quão grande é o outro fila de arquivos são, então não há nenhuma maneira para exibir com precisão um valor de porcentagem que é relevante e proporcional ao tempo necessário.

Um número de soluções alternativas vêm à mente:

  • Uma abordagem que parece que você conhece, mas são, na verdade, enganando o usuário seria assumir todos os arquivos na fila sejam do mesmo tamanho que o arquivo em andamento, ou a média dos arquivos processados até agora.Com base nisso, a barra de progresso seria mostrar a "verdade" se todos os arquivos estão, de fato, o mesmo tamanho, e seria muito fora se tamanhos diferem significativamente.

  • Outra estratégia seria a sua segunda barra de progresso para mostrar não a porcentagem de bytes transferidos, mas a porcentagem de arquivos.Assim, se você tem 4 arquivos, que o bar iria hop de 0 a 25% para 50% a 75% a 100%.Ele não refletir com precisão o tempo necessário, mas pelo menos você não estaria mentindo.

  • Você pode fazer ainda pior, com uma abordagem semelhante da Microsoft:Faça a sua barra de progresso do crescimento assintoticamente mais lento a medida que se aproxima de 100%, para que ele, na verdade, nunca chega ao fim.Tudo o que o usuário vê é constantemente mais perto valores de "quase terminado." Um visor parece legal, mas está em vigor, dando ao usuário o mínimo possível de informações.

Como @carl observou, sem saber quanto ainda há para enviar, você não pode produzir uma estimativa verdadeira da proporção já enviada. Deixando de lado a precisão e a integridade científicas por um momento, seu cálculo:

("Current file number we are on" / "total number of files to send") * 
("Bytes Sent" / "Total Bytes To Send")

deve ser estendido para incorporar a idéia de frações de arquivos. Se, digamos, você enviou 6 arquivos em 11 e 30% do 7º arquivo, desejará calcular

(6.3 / 11) * ("Bytes Sent" / "Total Bytes To Send")

Em algum lugar ao longo da linha, você multiplicou o número de arquivos enviados pela proporção do arquivo atual já enviado, ou seja, você calculou 0.66*0.2=0.13, em vez de adicionar a proporção do arquivo atual.

Pegando precisão e integridade científica novamente, por que não usar a taxa de transmissão na segunda barra de progresso? Se você integrar isso durante um período sensato, deve dar ao vigia o sentido satisfatório de que algo está acontecendo e o progresso está sendo feito.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top