Recentemente, no estudo da "programação avançada de JavaScript", há uma descrição das características das cordas. O texto original é aproximadamente o seguinte: Strings no ECMAScript são imutáveis, ou seja, uma vez que as strings são criadas, seus valores não podem ser alterados. Para alterar a sequência salva de uma variável, primeiro destrua a string original e depois preencha a variável com outra string contendo o novo valor, por exemplo:
A cópia do código é a seguinte:
var lang = "java";
lang = lang + "script";
O processo de implementação desta operação é o seguinte: primeiro crie uma nova string que possa conter 10 caracteres e depois preencha -a com "Java" e "Script" nesta sequência. O último passo é destruir as cordas originais "Java" e "Script", porque essas duas cordas são inúteis. No entanto, em versões mais baixas dos navegadores (como o IE6), a velocidade de splicing de cordas é um processo de consumo de desempenho.
A partir disso, penso em Java. O mecanismo da string em Java é semelhante ao JS (ou seja, não pode ser alterado após a criação e, para alterar, pode destruir apenas o valor original), mas Java possui um StringBuffer que resolve o problema da imutabilidade da string, e JS não possui um método semelhante. Mas podemos simular esse mecanismo de buffer. O princípio é usar matrizes para splicing, o código -fonte é o seguinte:
A cópia do código é a seguinte:
function stringbuffer () {
este .__ strings__ = novo array ();
}
Stringbuffer.prototype.append = function (str) {
isso .__ Strings __. Push (str);
devolver isso; // operação de cadeia conveniente
}
Stringbuffer.prototype.toString = function () {
Retornar esta .__ Strings __. Junte -se ("");
}
/*teste*/
var buffer = new StringBuffer ();
buffer.append ("hello"). Append ("javascript");
var resultado = buffer.toString ();
alerta (resultado);
PS: O endereço da GIST é o seguinte: https://gist.github.com/hehongwei44/fe71f10e4d2d9295AEAB
Simulamos o mecanismo, mas há uma diferença no desempenho entre esse método e o splicing de cordas. Podemos testá -lo, e o código de teste é o seguinte:
A cópia do código é a seguinte:
var d1 = new Date ();
var str = "";
for (var i = 0; i <10000; i ++) {
str += "texto";
}
var d2 = new Date ();
document.write ("teste um custo:" + (d2.gettime () - d1.gettime ())/1000 + "segundos" + "<br/>");
var obuffer = new StringBuffer ();
d3 = new Date ();
for (var i = 0; i <10000; i ++) {
obuffer.append ("text");
}
var sresult = obuffer.toString ();
d4 = new Date ();
document.write ("Teste dois custos:" + (d4.gettime () - d3.gettime ())/1000 + "segundos");
Os resultados dos testes são os seguintes: (os resultados do teste podem ser diferentes em diferentes ambientes):
1. Ao comparar 1000 vezes como base, a execução de ambos é muito rápida (milissegundos básicos) e leva o mesmo tempo. A última diferença entre o primeiro não excederá 10 milissegundos.
2. Com 10.000 vezes como base, o resultado da execução é semelhante ao acima, mas o primeiro possui mais contas telefônicas no IE6.
3. Com 100.000 vezes como base, a emenda de cordas no IE6 obviamente leva mais tempo, e outros navegadores não são muito diferentes, e alguns são mais curtos que o StringBuffer.
para concluir
1. Quando o número de palavras de emenda é inferior a 1.000 vezes, use ousadamente o primeiro, e raramente encontramos milhares de tempos de emenda.
2. Outros navegadores não têm problemas de desempenho com a emenda, principalmente IE6. Se os tempos de emenda custam dezenas de milhares ou centenas de milhares, é recomendável usar o StringBuffer para simular o IE6 sozinho.