Утечка памяти при использовании UITableView dequeueReusableCell
Я проверил свое приложение на предмет утечек памяти в инструменте "Утечки". и обнаружил около 16 из них на контроллере, отвечающем за содержимое UITableView.
это код -
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "clause", for: indexPath) as! CodeOfConductTableViewCell
cell.index.text = String(indexPath.row + 1)
cell.cocTxt.text = lines["line\(indexPath.row + 1)"]
return cell
}
когда я изменил код на это:
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = CodeOfConductTableViewCell()
cell.index = UILabel()
cell.cocTxt = UITextView()
cell.index?.text = String(indexPath.row + 1)
cell.cocTxt?.text = lines["line\(indexPath.row + 1)"]
return cell
}
утечек не обнаружено.
что вызывает утечки? я неправильно использую?
Я хочу использовать эту функцию, так как она лучше для производительности, и я хочу понять, что здесь не так
Спасибо!
Обновлено:
добавление кода класса ячейки (здесь ничего особенного):
class CodeOfConductTableViewCell: UITableViewCell {
@IBOutlet weak var index: UILabel!
@IBOutlet weak var cocTxt: UITextView!
override func awakeFromNib() {
super.awakeFromNib()
}
override func setSelected(_ selected: Bool, animated: Bool) {
super.setSelected(selected, animated: animated)
}
}
Как вы создаете метку и текстовое представление в своей ячейке в первом примере? Переменные объявлены слабыми?
@skladek да, они объявлены слабыми точками. нет специальной инициализации ..
@ChipCoons вместо создания новых ячеек эта функция повторно использует ячейки, которые находятся за кадром. если у меня очень большая таблица, приложению не хватит памяти, если я буду продолжать создавать новые ячейки.
что содержат строки?
@nikBhosale lines - это словарь, извлеченный из файла json. который содержит пару строк текста ...
Ответы 1
Проблема заключается в строковом литерале («предложении») в вызове метода totableView.dequeueReusableCell.
Из документов яблока на строках:
You can create new strings using string literals or string interpolations. A string literal is a series of characters enclosed in quotes.
А также
Although strings in Swift have value semantics, strings use a copy-on-write strategy to store their data in a buffer. This buffer can then be shared by different copies of a string. A string’s data is only copied lazily, upon mutation, when more than one string instance is using the same buffer.
Я считаю, что вы выделяете 48 байтов каждый раз, когда вызывается метод с созданием строкового литерала. Я бы подумал, что компилятор должен оптимизировать это, но я не уверен.
Если ваш инициализатор CodeOfConductTableViewCell () загружает ресурс из Xcode, у него будут накладные расходы на чтение xib, что может объяснить наблюдаемые вами различия в производительности.
Вы должны сделать свой идентификатор константой в модуле и посмотреть, исчезнет ли утечка, поскольку тогда компилятор выделит его только один раз.
Я сделал "предложение" статической строкой. все еще течет ... :(
Я создал простой тестовый проект с UITableView и близким приближением вашего кода (очевидно, у него нет объекта CodeOfConductTableViewCell) и не смог создать условия утечки. Я подозреваю, что в вашем классе ячейки просмотра есть что-то, что является источником утечки.
Я протестирую его позже, но не должны ли я получить утечки и с моим измененным примером кода? (где я явно создаю CodeOfConductTableViewCell)
Я урезал его, чтобы вернуть только удаленную ячейку без назначения каких-либо данных. все еще просачивается :( Я добавил код класса ячейки к вопросу выше. Только два выхода. Я теряю его ...
У вас есть набор тестовых данных для линий? Повторное создание кода без этой одной строки также выполняется без утечек. (т.е. закомментировал строку cell.cocTxt.text = lines ["line (indexPath.row + 1)"])
я закомментировал эту строку. все еще протекает .. только при замене dequeueReusableCell на создание собственных ячеек - утечек нет.
Что вы имеете в виду под «лучше для производительности»?