Вы, вероятно, установили _imgUrl
с помощью ref.getDownloadURL()
напрямую без ключевого слова await
.
Если вы установите переменную с помощью var url = ref.getDownloadURL()
, вы получите Future<Url>
, но если вы установите переменную с помощью var url = await ref.getDownloadURL()
, вы получите Url
На поверхности это кажется, что что-то еще приведено в действие здесь. Любая дополнительная обработка изображения должна только добавить время, пока она не отобразилась на экране...
Было бы вообще возможно получить сервер к gzip изображения путем отправки соответствующего HTTP-заголовка? (Если это даже помогает размеру файла очень, который является.)
Временно использование pngcrush источника могло бы быть хорошим тестом также, только для получения некоторых измерений.
Та ссылка, которую Вы отправили в значительной степени, отвечает на Ваш вопрос.
Во время процесса сборки XCode предварительно обрабатывает Ваш png, таким образом, это находится в формате, это является более дружественным по отношению к графическому процессору в iPhone.
Png, которые не были обработаны как это, будет, вероятно, использовать более медленный путь рендеринга, тот, который имеет дело с несобственным форматом и тем, что альфа должна быть вычислена отдельно для каждого цвета.
Таким образом, у Вас есть две опции;
Выполните ту же работу, что pngcrush делает и подкачивает ordering/pre-multiply альфу. Скорость может произойти из-за одной или обоих из них.
После загрузки изображения можно "создать" новое изображение из него. Это новое изображение должно быть в собственном формате iPhone и, работают быстрее - также. Оборотная сторона - это, мог потенциально поднять немного больше памяти.
Например.
CGRect area = CGRectMake(0, 0, width, height);
CGSize size = area.size;
UIGraphicsBeginImageContext(size);
[oldImage drawInRect:area];
UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
То, что Вы говорите, что это "кажется" 100x медленнее, указывает, что Вы не выполнили экспериментирования, но высказали предположение (это должна быть оптимизация PNG), и теперь спускаются по пути на основе догадки.
Необходимо провести время для подтверждения то, чем состоит в том проблема, прежде чем Вы попытаетесь решить ее. Мой пищеварительный тракт говорит, что оптимизация PNG не должна быть проблемой: это главным образом влияет на загрузку изображений, но после того как они находятся в памяти, не имеет значения, в каком формате файла они были первоначально.
Так или иначе необходимо попробовать сравнение A-B, или заставить код загружать оптимизированный PNG из где-то в другом месте и видеть, как он выдерживает сравнение, или сделайте тестовое приложение, которое просто делает некоторых привлекающих два типа PNG. После того как Вы подтвердили, какова проблема, затем можно выяснить, необходимо ли скомпилировать pngcrush в приложение.
Вы храните png в исходном загруженном размере? Если это будет большое изображение, то это возьмет значительно дольше для рендеринга.
Хорошо кажется, что хороший способ сделать это (так как Вы не можете выполнить pngcrush на iPhone и ожидать, что для ускорения его) состоял бы в том, чтобы выполнить запросы через прокси, который выполняет pngcrush. Прокси имел бы хороший л.с. на самом деле дать Вам некоторое усиление по 100x боль, которую Вы чувствуете.
Вы говорите, что тянете сверху изображения путем переопределения UIView's drawRect:
метод. Вы пытаетесь сделать некоторую анимацию путем повторного рисования целого изображения с пользовательским материалом сверху его?
Вы могли бы получить лучшие результаты, если Вы помещаете свой пользовательский материал в отдельное представление или слой, и позволяете ОС иметь дело с составлением композита результата по фону. ОС только обновит части экрана, который Вы на самом деле изменяете и не будете перекрашивать все изображение как часто.