Освобождение памяти iOS UnsafePointer
Я взаимодействую с аппаратным устройством, которое выполняет код C ++ и отправляет живые данные почти 10 раз в секунду на устройство iOS.
У меня есть метод Swift, как это:
func m16b_to_mE0(_ pointer: UnsafePointer<m16bytes_t>) -> UnsafePointer<metrics_E0>? {
return UnsafeRawPointer(pointer).bindMemory(to: metrics_E0.self, capacity: MemoryLayout<metrics_E0>.size)
}
куда m16bytes_t является
typedef uint8_t m16bytes_t[16];
А также metrics_E0 является
struct metrics_E0 {
uint8_t tag;
uint8_t hr;
uint16_t c_speed;
uint16_t c_max_speed;
uint16_t c_met_power;
uint16_t c_speed_intensity;
uint16_t c_hr_exertion;
uint8_t hr_avg;
u3bytes_t c_acc_met_power; //typedef uint8_t u3bytes_t[3];
};
Выше m16b_to_mE0 метод вызывается почти 10 раз в секунду, около двух часов, более или менее.
Мой вопрос: требуется ли освобождать / деинициализировать память для каждого UnsafeRawPointer после bindMemory в metrics_E0? Если да, то как?
Что произойдет, если я не позабочусь о том, чтобы вручную освободить / деинициализировать UnsafePointer типа из памяти?
Решение
bindMemory не меняет владельца выделенной памяти, его цель состоит в том, чтобы дать вам возможность получить максимальный доступ к содержимому памяти. Если в документации к библиотеке C ++ не указано, что вам нужно вручную освобождать полученный указатель, вам не нужно беспокоиться об этом.
Вы можете сделать некоторое профилирование памяти, если хотите быть уверенным, и контролировать использование памяти вашим приложением. Или, если у вас есть доступ к коду C ++, вы можете установить точку останова на m16b_to_mE0 функционируйте и проходите через трассировку стека, пока не достигнете зоны C ++, и проверьте, что произойдет позже с указателем, который был отправлен вашему методу.
Обратите внимание, что для освобождения памяти этого буфера могут потребоваться некоторые специальные функции библиотеки для освобождения, вместо стандартных, однако это должно быть указано в документации библиотеки.
Другие решения
Других решений пока нет …