Методы для профилирования памяти в настольных Safari и iOS? - PullRequest
30 голосов
/ 19 октября 2010

Обновлено 10/21: Изменены заголовок и вопрос для возможного получения ответа (кроме «нет»).

У нас возникают утечки в Safari (подтверждено в Windowsи Mac, подозреваемый в iOS). Существуют ли какие-либо расширения Safari, позволяющие одному профилю использовать память JavaScript / DOM для обнаружения потенциальных утечек?А еще лучше, есть ли какой-нибудь инструмент, который можно использовать на iOS или в эмуляторе Apple iOS? Какие предлагаются методы обнаружения утечек памяти в JavaScript / DOM в Safari?А кто-нибудь знает ЛЮБОЙ способ доступа к информации о памяти для iOS?

Фон

Мы разрабатываем веб-приложение iOS Safari, в котором используется парадигма одностраничного приложения., загрузка 100-х полноэкранных изображений.Мы обошли нормальный лимит изображений iOS Safari в 6,5 МБ, сбросив источник для тегов изображений, но теперь мы столкнулись с тем, что, как мне кажется, утечка памяти в iOS Safari.После загрузки ~ 250-300 изображений iOS Safari просто перестает загружать изображения, из-за чего, как мы подозреваем, происходит утечка памяти.Не удивительно, учитывая, что одна и та же утечка возникает как в Safari для Windows, так и в Safari для Mac - в Windows это особенно плохо;для каждого нового полноэкранного изображения с высоким разрешением потребляется еще 10-15 МБ памяти, если мы переключаемся на изображения с более низким разрешением, они по-прежнему сжигают ~ 5 МБ на изображение.

В Windows мы изолировалиутечка к простому акту рендеринга изображения в окне просмотра браузера - у нас есть карусель изображений, и даже при нулевой манипуляции с DOM, просто переводя (3d) изображение через окно просмотра, память выделяется и никогда не освобождается.В Windows потребление памяти может быстро возрасти до ~ 1,5 ГБ, после чего Safari просто падает.На Mac это не так плохо, но объем памяти легко увеличивается с 100 МБ на старте до 500 МБ и выше.Для сравнения: вкладка / процесс Chrome, на которой размещается та же страница, увеличивается с 33 МБ до ~ 120 МБ, а затем стабилизируется.

Попытки обойти

Мы попытались удалить отдельное изображениетеги и заменяя их изображением-заполнителем, а не сбрасывая их, но это, похоже, не облегчает проблему, а также вызывает проблемы с производительностью, предположительно из-за оттока DOM.Интересно, что удаление / отсоединение ВСЕХ изображений работает - как только команда выполняется, память освобождается.Однако это вызывает свои проблемы, управление состоянием пользовательского интерфейса и создание резервной копии карусели также занимает заметное количество времени.Обновление страницы - это еще один обходной путь, но он приводит к еще большему нарушению работы UX.

Обновление 04/10: Просто обновление того, что мы в итоге сделали: iOS 4.2 ввела ограничение, которое отсекает3D-трансформированный Div на 122,900 пикселей.Не уверен, почему, но это заставило нас реструктурировать и использовать динамическую карусель вместо нашей предыдущей статической киноленты.

Во-вторых, мы обнаружили, что использование div с фоновыми изображениями работает лучше, чем сами изображения.Это похоже на очередную ошибку в Safari или, в лучшем случае, на противоречивую реализацию ограничений.

end update

Мысли? Если вы столкнулисьесть подозрения, что в Safari есть утечки, как вы обходили их?

1 Ответ

37 голосов
/ 22 октября 2010

При установке iOS SDK также устанавливается утилита под названием Instruments.Он может отслеживать все виды статистики использования, включая память (есть даже шаблон «Утечки»).Самое замечательное то, что он может отслеживать как симулятор iPhone / iPad, так и любое подключенное устройство для разработки iOS.Конечно, его также можно использовать для мониторинга использования памяти в Mac OS, поэтому он может помочь и с Safari.Вы можете найти инструменты в /Developer/Applications.

Еще одна полезная вещь: когда вы синхронизируете свой iPad / iPhone с iTunes, он также синхронизирует любые отчеты о сбоях с устройства на ваш компьютер.Их можно найти в ~ / Library / Logs / CrashReporter / MobileDevice / [Device Name] /.

Одна вещь, которую мы обнаружили при разработке для iPad, в частности, это то, что он был очень склонен к сбоям из-за проблем с памятьюособенно в таких тяжелых приложениях, как наше.Одна вещь, которую мы узнали, заключалась в том, что простое удаление элемента DOM не означает, что этот элемент будет собирать мусор браузером.Мы обнаружили, что установка изображения src (или background-image, если это был div) в пустую строку перед удалением его из DOM очень помогла.

Не уверен, поможет ли что-нибудь из этого, но, надеюсь, получить инструментыи даст вам лучшее представление о том, куда идет вся эта память.

...