Правильный способ выпустить UIColor PatternImage - PullRequest
2 голосов
/ 25 января 2011

У меня есть несколько полноэкранных UIColor PatternImagesscrollViews) в приложении для iPad, и у меня возникают проблемы с памятью (удивительно?)
Когда у меня начались проблемы с памятью, я включил ленивую загрузку в свои прокрутки.
Когда проблемы продолжались, я отошел от заводских методов (как [UIColor colorWithPatternImage:...]) «выделить» методы (как [[UIColor alloc]initWithPatternImage:...]), чтобы я мог отвечать на предупреждения памяти, выпуская страницы.

Однако всякий раз, когда я выпускаю свой UIColor PatternImages, я получаю ошибку “EXC_BAD_ACCESS”.

Сначала я подумал, что это может быть вызвано моими образцами [UIImage imageNamed:...], поэтому я переключился на [[UIImage alloc]initWithContentsOfFile:...] изображения, но это не помогло. Только сейчас я установил NSZombiesEnabled, и он говорит мне, что проблема:

-[UICGColor release]: message sent to deallocated instance 0x187b50

Со следом:

#0  0x35823910 in ___forwarding___ ()
#1  0x35823860 in __forwarding_prep_0___ ()
#2  0x357e53c8 in CFRelease ()
#3  0x357e48de in _CFAutoreleasePoolPop ()
#4  0x3116532c in NSPopAutoreleasePool ()
#5  0x341a7508 in _wrapRunLoopWithAutoreleasePoolHandler ()
#6  0x3580ac58 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#7  0x3580aacc in __CFRunLoopDoObservers ()
#8  0x358020ca in __CFRunLoopRun ()
#9  0x35801c86 in CFRunLoopRunSpecific ()
#10 0x35801b8e in CFRunLoopRunInMode ()
#11 0x320c84aa in GSEventRunModal ()
#12 0x320c8556 in GSEventRun ()
#13 0x341dc328 in -[UIApplication _run] ()
#14 0x341d9e92 in UIApplicationMain ()
#15 0x00002e5e in main (argc=1, argv=0x2fdff610) at...

У меня также нет никаких объектов UICGColor, поэтому я думаю, что каким-то образом мой "alloc" ed UIColors имеет базовые UICGColor объекты автоматического выпуска ...? Любые идеи / идеи?

Ответы [ 2 ]

3 голосов
/ 25 января 2011

У меня тоже была такая же проблема, и вот как я оптимизировал свой код.

После некоторого анализа в инструментах и ​​отладки я обнаружил, что шаблон colorwith будет занимать 1,12 Мбайт с ответственной библиотекой под названием ripl_create. Для каждого экрана с colorWithPattern будет занимать один и тот же 1,12, и поэтому у вас будет выделено несколько oj 1,12 МБ. Это высосало мое приложение. Так что я решил, что нет colorWithPattern.

Полагаю, вы хотите установить изображение на фоне вида. То, что я хотел бы предложить, это сохранить ImageView и поместить изображение в него ...

Теперь перейдем к оптимизации imageView

Если вы хотите, чтобы изображение использовалось во многих частях приложения, или представление, которое содержит изображение, будет часто посещаться, тогда выберите imagenamed.

imageNamed кэширует изображение и не выпускает его, даже если вы обнуляете или выпускаете его.

В другом случае, когда вы хотите, чтобы изображение было выпущено

В вашем viewWillAppear или viewDidLoad назначьте изображение для viewview

        NSString *fileLocation = [[NSBundle mainBundle] pathForResource:@"yourImage" ofType:@"png"];
        imageView.image = [UIImage imageWithData:[NSData dataWithContentsOfFile:fileLocation]]; 

inYour viewDidDisappear установить ноль, чтобы освободить изображение

       imageView.image=nil;
2 голосов
/ 26 января 2011

ОК, я кое-что разработал, отчасти благодаря (плохо помеченному и озаглавленному) ТАКОМУ вопросу / ответам здесь .Что мне нужно было сделать, так это прочесть о UIView.backgroundColor.В моих документах написано @property(nonatomic, copy) UIColor *backgroundColor.Здесь «копия» говорит мне, что когда я говорю что-то вроде:

myUIView.backgroundColor=[[UIColor alloc]initWithPatternImage:myUIImage];

myUIView.backgroundColor на самом деле отличается от [[UIColor alloc]initWithPatternImage:myUIImage].Это отдельное myUIView.backgroundColor, на самом деле, автоматически выпущено, поэтому, когда я иду [myUIView.backgroundColor release];, я на самом деле стреляю себе в ногу.Что мне нужно сделать, это:

UIColor* tmpColor=[[UIColor alloc]initWithPatternImage:myUIImage];
currentPage.backgroundColor=tmpColor;
[tmpColor release];

(и, конечно же, вокруг этого я также выделяю и освобождаю myUIImage).Теперь, чтобы освободить свой scrollView patternImage, я могу просто сделать что-то вроде currentPage.backgroundColor=nil; (например, @BuildSucceeded) или currentPage.backgroundColor=[UIColor clearColor]; (не уверен, есть ли практическая разница).Я думаю, внутренне, оба они вызывают currentPage до autorelease старого backgroundColor.После внесения этих изменений я не смог вызвать сбой моего приложения.

Мне нужно сказать следующее: я не думаю, что C ++ делает это правильно, но C # и Java прекрасно справляются безлюбой из этих сложных выпусков, авто-релиз, @property business.Конечно, если бы кто-то хотел реализовать аналогичную (для Objective-C) систему управления указателями в Java или C #, он мог бы, но, конечно, никто не хочет этого, потому что это было бы довольно бесполезно. Pleeeease Apple, мигрировать от Objective-C!

...