2014-10-27 5 views
1

Примечание: Приносим извинения, если есть похожие вопросы, но они более специфичны, например, «Проблемы с утечкой памяти UIMapView Kit», меня больше беспокоит и действительно хочу знать в General Swift и ARC и управлении памятью Проблемы с ним.Swift UIKit Управление памятью неэффективность

Я сделал пару приложений сейчас в Xcode, однако все это было сделано в Objective-C.

Управление памятью объектов UIKit (включая UIViews и UIViewControllers) и любой другой объект в этом отношении прост в обращении в Objective-C, и я просто хочу привыкнуть к нему после битвы с ним в какой-то момент в Кривая обучения.

Теперь я работаю с Swift, пытаясь не отставать от технологии «Cutting-Edge». однако я заметил небольшую проблему с тем, что я смог зафиксировать и контролировать в Objective-C, Memory Management.

Свифт говорит, что нам будет легче сосредоточиться на разработке кода, а не на управлении памятью, как его предшественник или будущий предшественник. Однако я еще не нашел этого преимущества. У меня было ужасное время с управлением памятью моего нового приложения. Просто создание простого UIViewController с несколькими представлениями может складывать память, которая мне больше не нужна, за несколько Мб одновременно.

Имейте в виду, что я использовал деконструктор (Deinit in Swift), назначая nil значениям, которые мне больше не нужно использовать, удаляя SubViews из Super Views вручную, думая, что это проблема, даже используя сегмент кода AutoReleasePool.

autoreleasepool{ 
//Code looping through Swift Native Objects that potentially might lead to leaking 
//But AutoReleasePool helps with this, supposedly. 
} 

Теперь вопрос: кто-нибудь здесь точно знает, в чем проблема? Это я делаю что-то ужасное с моим кодом? или действительно ли ошибка в Xcode и быстрое управление памятью? У кого-нибудь еще была эта проблема, вы ее решили?

Вот ссылка, объясняющая немного эту ситуацию. Problems of ARC in Swift? ARC in Swift Apple Docs


Обновление:

Вы правы, я должен разместить больше о моей ситуации: вот он идет.

У меня есть память, начинающаяся с ~ 5 мб, как только приложение запускается.

Как только я начну навигацию вокруг приложения. Я замечаю, как постепенно начинает складываться память. , но самый большой всплеск памяти начинает накапливаться, когда я использую UIMapView около 25+ Mbs.

При использовании только обычного UITableViewController он просто накапливает ~ 2 МБ каждый раз, когда я нажимаю (на NavController) тот же UITableViewController. Когда я вставляю этот TableViewCell, он открывает еще один ViewController с UIMapView, вот где память начинает накапливаться очень хорошо.

Rememeber Я просто иду туда и обратно, просматривая приложение. Всего всего 4 UIViewControllers, включая «Мое меню».

Но вот что ... Все эти снимки SnapShots, которые вы видите, после того, как я прекратил навигацию и вернусь в главное меню, Root ViewController моего контроллера навигации.

Starting App Opening UiTableViewController Opening ViewController with UIMapView Stacking that Memory Up

ответ

2

Swift использует ARC точно так же, как ObjC делает. Если вы видите утечку, вы, вероятно, создаете цикл сохранения где-то, и вы избегаете таких почти так же, как в ObjC (с дополнительной опцией использования unowned, но они очень похожи на unsafe_unretained, поэтому даже это не является серьезным изменением). Если вы знакомы с управлением памятью в Cocoa, то вы понимаете управление памятью в Swift. Но мы не можем помочь на основе информации, которую вы указали здесь (что в основном кажется просто комментарием о Cocoa).

autoreleasepool{ 
//Code looping through Swift Native Objects that potentially might lead to leaking 
//But AutoReleasePool helps with this, supposedly. 
} 

Все, что сказал, этот комментарий намекает на вашу ошибку. Пул автореферата должен пройти внутри цикл, в котором вы создаете и уничтожаете объекты, а не вокруг него. Автореализованные объекты не выводятся до конца блока пула или конца цикла события. Последнее, как правило, достаточно, но если вы генерируете и выпускаете много объектов, вам иногда приходится сбрасывать пул раньше. Пулы Autorelease объясняются в Advanced Memory Management Programming Guide. Тем не менее, они обычно не нужны для объектов UIKit.

В качестве побочного примечания, «Проблемы ARC в Swift?» ссылка, которую вы даете, кажется, не знает об истории сбора мусора в какао. GC был опробован Apple на Mac и отклонен разработчиками Cocoa. Apple отвергла GC и впоследствии удалила ее (я был на WWDC, когда они объявили, что она устарела, мы аплодировали). Это еще менее применимо к iOS. Отличное обсуждение этого вопроса находится в Why mobile web apps are slow. Я не говорю, что GC - это плохо. Я говорю, что Apple хорошо это понимает и активно предпочитает не включать ее. Они не просто упустили возможность.


EDIT: Ваша обновленная информация выглядит как довольно стандартный цикл удержания. Я бы начал с heap shot analysis, чтобы выяснить, какие объекты задействованы. Убедитесь, что вы following the rules. И идите оттуда, в основном с инструментами (особенно с инструментами «Распределения и утечки»). Один из ключей заключается в том, что контроллеры представлений вообще не должны сохранять другие контроллеры представлений. Они должны разговаривать друг с другом через модель. Вы должны быть осторожны, используя self в блоках. Обычные правила. Они одинаковы в ObjC и Swift. Но куча выстрела, безусловно, место для начала. Узнайте, что протекает; затем выясните, почему.

+0

Впечатляющий отклик, Как вы уже сказали, я добавил больше Контекст к моей конкретной ситуации. И спасибо за это про GC. Я действительно не знал этого о WWDC и о том, как они решили не держать его из-за мнения Дэвса. –

+0

Итак, я продолжал тестировать и отлаживать и использовать инструменты, как вы предлагали. Мне удалось уменьшить объем памяти в куче примерно до ~ 1 мб за действия и вернуться в начальное состояние приложения. Но мне интересно, нормально ли это, хотя в нескольких статьях говорится, что он должен вернуться к 0mb Growth после того, как каждое действие, предполагающее, что ничего не сохраняется, что имеет смысл для меня. Но я до сих пор этого не понимаю, я думал, что Swift будет немного проще для разработчиков и управления памятью, но похоже, что он похож на Obj-C. –

+0

Вы должны увидеть почти нулевой рост за каждое действие. Во время запуска, конечно, вы увидите рост по мере того, как вы выделяете память, но это должно успокоиться довольно быстро, и просто навигация не должна приводить к росту памяти в правильной программе. Исторически были небольшие утечки внутри UIKit, которые вы не можете устранить, но, конечно, ничего подобного 1MB за действие. Если вы можете многократно расти так много, у вас все еще есть ошибки. Управление быстрой памятью идентично современному управлению памятью ObjC (ARC). –

Смежные вопросы