Выбор лучшей альтернативы
Исходный файл: Benchmark2.fla
Обратившись к предыдущему ролику, приведенному в качестве примера, предположим, что скорость в 22–42 кадр/сек для вас недостаточна. Допустим, в анимации лиса должна быстро промелькнуть, пробежать с одной стороны экрана на другую. При 22 или даже 42 кадр/сек вы не получите требуемого результата.
Можно уменьшить число кадров с 30 до 15, скорость увеличится в два раза, но анимация станет менее плавной. Так как клип лисы управляет длиной шага, лиса сделает в два раза меньше шагов, чтобы пробежать то же самое расстояние.
Если такой вариант не помогает, возможно, стоит изменить размер лисы. Что произойдет, если уменьшить лису в два раза? С одной стороны, число векторов изображения останется прежним, то есть время на построение изображения не зависит от его масштаба. С другой стороны, так как лиса будет меньше, для создания ее изображения понадобится меньшее число пикселов, следовательно, скорость ролика увеличится (понадобится меньше ресурсов для отображения каждого кадра).
Проверить эти гипотезы можно с помощью установки контрольных точек. Если уменьшить в два раза фигуру лисы в ключевых кадрах, вы получите такую же анимацию, только лиса будет меньше. Сценарий покажет, повлияло ли это на скорость ролика. (Готовый ролик Benchmark2.fla вы найдете на Web‑сайте). Результат сравнения показан на рис. 17.2.
Рисунок 17.2. Ролик с небольшим изображением проигрывается быстрее
Маленькая лиса двигается быстрее, чем большая. Во Flash‑проигрывателе на моем компьютере ролик воспроизводился со скоростью 60–70 кадр/сек, что примерно в два раза превышает скорость предыдущего ролика. Это подтверждает теорию о том, что для построения меньшего графического объекта требуется меньше времени.
Теперь остается выяснить, удовлетворяет вашим потребностям анимация с меньшим изображением лисы? Если да, то вопрос выбора альтернативы решен.
Оптимизация в ActionScript
Исходный файл: Benchmark3.fla
Тесты с помощью установки контрольных точек позволяют также выяснить, влияет ли на скорость ролика выбор альтернативных алгоритмов. Техника такая же: измеряем время на выполнение задачи и сравниваем его с временем, затраченным на выполнение задания альтернативным способом.
Допустим, вы заметили, что в коде используется следующее сравнение:
if (myVariable == true) {
Понятно, что то же самое можно записать проще:
if (myVariable) {
Иногда первую строчку легче понять, но почему второй вариант увеличивает скорость работы программы? Вы могли использовать сотни или тысячи подобных сравнений внутри циклов и т. д.
Дело в том, что одно сравнение может экономить всего лишь несколько миллисекунд, то есть при сравнении одного варианта с другим разница едва ли будет заметна. Так что необходимо сравнивать тысячи подобных условий.
Следующий фрагмент построен для сравнения типа "истина/ложь". Сначала создается массив из 5000 элементов вида false и true. Этот процесс при подсчете времени учитываться не будет. Время засекается после того, как массив был создан. Измеряем время на подсчет количества элементов, равных true. Для этого используется оператор ==. В конце сценарий выводит время, которое потребовалось для 5000 сравнений.
function benchMacrk1() {
// Создаем новый массив.
testArray = new Array;
// Заполняем массив значениями true или false.
temp = false;
for(I=0; I<5000; I++) {
testArray.push(temp);
if (temp == false) {
temp = true;
} else if (temp == true) {
temp = false;
}
}
// Определяем время начала проверки.
startTime = getTimer();
// Подсчитываем, сколько значений true находится в массиве.
count = 0;
for(I=0; I<testArray.length; I++) {
if (testArray[I] == ture) {
count++;
}
}
// Определяем время, потребовавшееся для проведения проверки.
totalTime = getTimer() – startTime;
// Отображаем результаты.
trace("Benchmark Test: using ==")
trace(:Total Time: “ + totalTime + "ms");
}
Сам по себе результат ничего не значит. Однако вы также создадите функцию benchmark2, в которой строчка if(testArray[I] == true) { будет заменена на if(testArray[I]) {. Это единственная разница между функциями. Следовательно, если скорость выполнения сценария изменится, это произойдет вследствие замены строчек.
В результате оказалось, что второй вариант быстрее. На моем компьютере функции benchmark1 понадобилось 978 миллисекунд, а benchmark2 – 958. Использование оператора == замедляет процесс сравнения истинных и ложных значений. Посмотреть, как работает приведенный выше код, можно, открыв на Web‑сайте файл Benchmark3.fla.
Такие тесты с помощью установки контрольных точек проводят все профессиональные программисты независимо от того, на каком языке они пишут. Если вы часто пользуетесь языком ActionScript, будет полезно определить, какие методы работают быстрее. После проведения подобных тестов можно обобщить полученную информацию, которая позволит оптимизировать ваши Flash‑игры.