2017-02-01 19 views
1

В настоящее время я работаю над приложением tvOS. Это мое первое родное приложение (Swift). Приложение будет представлять собой приложение для цифровых вывесок, которое используется во время событий или в офисах компаний. Одна большая разница по сравнению с обычным приложением в iOS/tvOS заключается в том, что он должен работать почти 24/7, поэтому память является большой темой для этого приложения. Самая маленькая утечка в конечном итоге приведет к сбою приложения.Инструменты: утечки и распределения (tvOS)

Приложение постоянно перебирает набор полноэкранных слайдов. В нижней части экрана есть тикер с 10 статьями (обновляется каждые 10 секунд - теперь во время разработки). Ниже приведен снимок экрана о погоде, чтобы получить представление.

Screenshot

В настоящее время приложения происходит сбой после определенного периода времени, и я уверен, что я сузил к компоненту тикера (при отключении его, приложение живет в течение нескольких дней). Если я использую предустановку «Утечки» в Инструментах, я получаю следующий результат: Leaks  Похоже, что это утечка экземпляров. Я обновляю экземпляры статей каждые 10 секунд и предоставляю их компоненту тикера. Я думаю, поэтому новые экземпляры протекают каждые 10 секунд.

Прежде, чем я начал использовать предварительный набор «Утечки» в «Инструменты», я использовал предустановку «Аллюкации», в то время как использование этого все казалось мне прекрасным. Но я, наверное, неправильно понимают результаты ...

Использование распределений: Allocations  Как я прочитал это в том, что в настоящее время 10 статьи экземпляры существуют в памяти, и 31 существуют, но убирали сейчас - так что я безопасно.

Но приложение все еще падает.

Я много читал о циклах удержания, реализовал слабые/незаслуженные, где я считаю, что должен.

Так что мой вопрос не столько о коде, но больше о том, как читать эти данные, что делает Leak означает в этом контексте, и почему я вижу эту «утечку» не как постоянные объекты в распределения окно?

(тесты проводились на нескольких устройствах + имитатор)

ответ

0

Я возвращаюсь после нескольких недель, пытаясь выяснить, что случилось. Хорошие новости, я нашел утечку и решил!

Проблема была решена путем удаления крышки внутри другого закрывающего устройства, содержащего ссылку на переменную в первом закрытии. Это вызвало удержание цикла.

Я действительно не понимаю, почему я не нашел его раньше, я задал новый вопрос для этого здесь: getting-different-data-in-instruments-based-on-method-of-profiling.

1

Если вы видите устойчивый (т.е. примерно п GB/мин или час) увеличение использования памяти в инструменты, что является хорошим признаком того, что объекты в настоящее время созданный, но не освобожденный. Ваш намек на слабые и незаслуженные vars заставляет меня думать, что вы это знаете, но вы, возможно, не нашли всех источников утечки. Я бы предложил взять несколько резюме поколений в «Инструменты» и посмотреть на определенные классы/объекты в распределении кучи. Ваши проблемные классы будут неуклонно увеличиваться и, вероятно, никогда не уменьшатся. Попробуйте отладить проблему оттуда.

Что касается «утечки», то в этом контексте это всегда означает: ваш компьютер не освобождает ресурсы памяти. Это может показаться другим, потому что мы привыкли думать о утечке как нечто, что ест через память гораздо быстрее (например, бесконечный цикл, работающий на четырех ядрах или что-то в этом роде), но такая утечка, и это на самом деле то же самое вещь; ваш просто медленнее.

+0

Но не факт, что количество постоянных объектов (в скриншоте Allocations) остается устойчивым с течением времени, означает, что мой объект не протекает? Почему эта информация отличается от той, что я вижу на экране «Утечки»? –

+0

Не обязательно. У меня только тесты распределения полной кучи, чтобы искать утечки в трех разных приложениях, и каждый из них рассказал мне подобную историю в резюме. Я не знаю, как Инструменты определяют, что такое «Постоянный» объект, и извините, что я не могу быть более полезным в этом счете. Общее количество просмотров, контроллеров просмотров и некоторых других объектов в каждом случае продолжало расти в течение жизненного цикла приложения, в более подробных отчетах о генерации. Конечно, я бы предложил запустить хотя бы пару. – dylanthelion