Разница между и ?

Я хочу загрузить некоторые изображения в свое приложение из файловой системы. Есть 2 простых способа сделать это:

[UIImage imageNamed:fullFileName] 

или:

 NSString *fileLocation = [[NSBundle mainBundle] pathForResource:fileName ofType:extension]; NSData *imageData = [NSData dataWithContentsOfFile:fileLocation]; [UIImage imageWithData:imageData]; 

Я предпочитаю первый, потому что это намного меньше кода, но я видел, как некоторые люди говорили, что изображение кэшировано и что этот метод использует больше памяти? Поскольку я не доверяю людям на большинстве других форумов, я думал, что задаю здесь вопрос, есть ли какая-то практическая разница, и если да, то какой из них «лучше»?

Я пробовал профилировать свое приложение, используя инструмент Object Allocation, и я не вижу никакой практической разницы, хотя я только пробовал в симуляторе, а не на самом iPhone.

Это зависит от того, что вы делаете с изображением. Метод imageNamed: изображение, но во многих случаях это поможет в использовании памяти. Например, если вы загружаете изображение 10 раз для отображения вместе с некоторым текстом в виде таблицы, UIImage будет хранить только одно представление этого изображения в памяти вместо выделения 10 отдельных объектов. С другой стороны, если у вас очень большое изображение, и вы не используете его повторно, вы можете загрузить изображение из объекта данных, чтобы убедиться, что он удален из памяти, когда вы закончите.

Если у вас нет огромных изображений, я бы не стал беспокоиться об этом. Если вы не видите проблему (и надежду на проверку распределения объектов вместо предварительной оптимизации), я бы выбрал меньше строк кода из-за незначительных улучшений памяти.

По моему опыту [UIImage imageNamed:] имеет значительно лучшую производительность, особенно когда используется в UITableViews .

Это не только память, но и декодирование image . Наличие кэширования происходит намного быстрее.

Поскольку ссылка API UIImage говорит:

+ (UIImage *) imageNamed: (NSString *) name

Этот метод просматривает системные кэши для объекта изображения с указанным именем и возвращает этот объект, если он существует. Если соответствующий объект изображения еще не находится в кеше, этот метод загружает данные изображения из указанного файла, кэширует его и затем возвращает результирующий объект.

+ (UIImage *) imageWithContentsOfFile: (NSString *) путь

Этот метод не кэширует объект изображения.

поэтому мы можем видеть, что если у вас есть много одинаковых элементов интерфейса (например, UITableViewCell), которые могут использовать одинаковое изображение (часто как значки ), и из-за производительности, конечно, мы хотим повторно использовать один и тот же образ , чтобы мы сохранит некоторую память для другого использования. В общем случае повторно используемое изображение часто используется в элементе ui, который наш пользователь может работать с ним много раз . Поэтому он позволяет нам повторно использовать его. Таким образом, вы можете использовать метод imageNamed .

С другой стороны, в приложении будет некоторый элемент пользовательского интерфейса, который будет присутствовать во время жизненного цикла приложения, например, кнопка, вид логотипа, поэтому эти изображения, используемые этими элементами ui, также могут присутствовать во время приложения жизненный цикл, вы не будете учитывать, должно ли это изображение быть кешем или нет. Таким образом, вы можете использовать метод imageNamed .


Напротив, в приложении часто возникают некоторые элементы пользовательского интерфейса, которые создаются динамически. Например, наше приложение поддерживает динамический фон , так что пользователь может выбрать фон, который им нравится. И фон может быть изображением. Таким образом, у нас может быть интерфейс, в котором перечислены многие разные фон (часто показываются с помощью UIImageView ), чтобы пользователь мог выбрать , мы можем назвать представление списка MyBackgroundListView. Так как пользователь выбирает фоновое изображение , MyBackgroundListView должен быть уничтожен, потому что он завершил свою работу. В следующий раз, когда пользователь захочет изменить свой фон, мы снова можем создать MyBackgroundListView . Таким образом, изображения, используемые MyBackgroundListView, не должны кэшироваться, или память нашего приложения закончится. Поэтому на этот раз вы должны использовать метод imageWithContentsOfFile .

Как говорится в документе Apple, поддерживающем экраны с высоким разрешением.

На устройствах с экранами с высоким разрешением методы imageNamed:, imageWithContentsOfFile: и initWithContentsOfFile: автоматически ищут версию запрошенного изображения с модификатором @ 2x в его имени. Если он найдет один, он загрузит это изображение. Если вы не предоставляете версию изображения с высоким разрешением, объект изображения по-прежнему загружает изображение стандартного разрешения (если оно существует) и масштабирует его во время рисования.

поэтому вы будете беспокоиться о пути поиска изображения для проблемы сетчатки сетчатки. IOS поможет вам справиться с этим.

Извините за моего бедного английского. Пусть это будет полезно.

Если вы не хотите, чтобы ваше изображение было кэшировано, вы также можете напрямую использовать initWithContentsOfFile:

 NSString *fileLocation = [[NSBundle mainBundle] pathForResource:fileName ofType:extension]; UIImage* yourImage = [[[UIImage alloc] initWithContentsOfFile:imagePath] autorelease]; 

Мне также сказали, что [UIImage imageNamed:] делает немного слишком много кеширования, а изображения не часто выпускаются. Мне сказали быть осторожным, чтобы использовать его.

imageWithData полезна, когда вы храните двоичный файл изображения в базе данных или постепенно загружаете большое изображение из Интернета.

Я бы не использовал imagenamed, если ваше приложение имеет множество больших изображений, которые не совпадают. Я столкнулся с проблемой сбоя приложения из-за слишком многого использования.

Я не считаю, что изображение вообще кэшируется, и я не знаю, почему вы все это говорите. UIImage является подclassом NSObject, который использует контрольные счетчики для отслеживания того, с чем он связан. Поэтому, когда вы загружаете изображение, он делает то же самое. Если вы загружаете одно и то же изображение несколько раз, он будет (или должен) иметь только одну копию изображения в памяти и просто увеличивать счетчик ссылок каждый раз, когда вам нужно что-то использовать с этим изображением. Посредством ссылочных счетчиков я имею в виду, что когда счетчик достигает 0, он удаляет себя. поэтому «alloc», «сохранить» составляют +1 к счету, а «release» – -1. Мало того, что это лучший способ управлять памятью, но этот стиль программирования также помогает очищать утечки памяти.

  • Установка UIDatePicker в таблицу UIActionSheet
  • Есть ли способ ограничить максимальный уровень масштабирования MKMapView?
  • UISegmentedControl регистрирует краны на выбранном сегменте
  • Вид сетки в iPhone SDK
  • Как получить IMEI на iPhone?
  • Можно ли программно отключить iPhone?
  • Разница iPhone SDK между isKindOfClass и isMemberOfClass
  • ios симулятор появляется с UDID в xcode 6
  • JSON и core data на iPhone
  • Получить значение RGB из пресетов UIColor
  • Какие шрифты поддерживают приложения для iPhone?
  • Давайте будем гением компьютера.