class 변수 쓰지 말자...

 

Obj-C 2.0 이상이고, 본인 프로젝트에서 메모리 사용량이 100%에 달하는 구간이 있는 앱이라면,

데이터 처리는 class 변수 말고 @property로 가고 @synthesize는 필수로 쓰세요. 

왠만하면 DB(sqlite)로 데이터 넘기는 구조가 안전합니다.

 

끗.

 

Swift로 무사히 전향 되었다고 생각했었는데, 최근 2년간은 오브젝티브C도 병행하였습니다.

이에, deprecated된 library 는 둘째치고 정말 다양한 상황의 문제점을 만났는데요.

그 중 하나 입니다. 임베디드 분야에 있으면서 메모리 사용량은 항상 봐야하는 것이지만 Swift 4+ 올라왔을 때부터는

거의 안 보고 살았거든요. 혹, legacy code를 보실 분. 그리고 먼 훗날 해당 코드를 다시 볼 때를 대비해서 기록을 남겨 둡니다.

스위프트 마이그레이션 하고 있지만 수년 간 만들어 온 코드를 Swift 로 바꾸기 힘듭니다. xib를 SwiftUI로 바꾸어야 하니...

안드로이드 처럼 쉽게 코틀린으로 바꿀 수 없죠.

(Android Studio 에서 코틀린 변환은 정말 대단하더군요. 프로젝트 전체 변환은 문제가 생기지만 일부 모듈 file by file은

100% 입니다.) 게다가 SwiftUI 까지 적용해야 하니 iOS 마이그레이션 시장은 지금부터 5년까지 꽤 활황일 것 같아요.

 

그럼, 정리 들어갑니다.

 

1. class 변수는 최대한 자제하고 @property 와 @synthesize 를 이용합니다. 

 - 잘 되던 코드가 iOS 업글하면서 class 변수 값이 날아가는 경우가 생겼습니다. 아무런 이유가 없었습니다.

 - copy, retain은 사용하지 않고 nonatomic, assign 으로 충분했습니다. 

 - 정확한 분석은 아니나. 메모리를 거의 풀로 쓰는 모듈(파씽, 데이터 처리 모듈)의 경우 @property 의 attributes가 영향을 주는 것 같긴 합니다.

 

   NSString *mData;   클래스 멤버변수라면 지우고, 

   @property (nonatomic, strong) NSString *mData; 와 같이 프로퍼티로 만들어 씁니다.

   BOOL mIsAll; 라면 클래스에서 지우고

   @property (nonatomic, assign) BOOL mIsAll;

로 쓰는 것입니다. 

 

2. UserDefault 땜빵은 한계가 있습니다. 그리고 @property 이 후 @syncthesize는 필수

  -처음에는 발생하는 문제가 몇 개 밖에 안 되어서, UserDefault 로 땜빵했습니다. 그러나 거대한 코드 더미에서 문제가 발생하는 경우

  난감했습니다. 딱히 setter, getter가 필요 없어서 @synthesize는 안 쓰고 self 나 _ 접두어로 썼습니다. 제 코딩 스타일이 그랬죠. self -> 도 좋아하구요 ^^;;  회사 동료들이 코르도바 사용 프로젝트의 경우에도 변수값 사라지는 문제가 발생하는 것을 리포팅 해서 @syncthesize 로 바꾸었는데 문제가 사라졌습니다. 

 

1, 2 의 문제는 결국 넘기는 데이터 보존이 안되는 문제 입니다. 데이터 넘기는 것은 콜백, 싱글톤, 델리게이트, DB 등 다양한 방법이 있습니다. 그 중 DB가 가장 느리지만 결국 DB가 가장 확실하다는 결론에 이르게 됩니다. Swift의 경우 Coredata 라는 ORM이 있어 참 좋은데. 엔터프라이즈급 data CRID엡은 앱 서버가 RDB를 항상 물고 있습니다. 이에, 해당 데이터는 SQL이 아닌 펼쳐서 재구현 하는 것이 쉽지 않더군요. 

 

임베디드는 아직 메모리를 믿을 단계가 아니다.(여전히) 라는 것입니다. 안드로이드나 iOS나 동일하니 더 좋네요.

 

안드로이드의 경우 액티비티 죽었다 다시 살아날 때 관련 리소스를 모두 재설정 해주는 것이 기법이었는데, iOS 의 경우 뷰컨이 내려간다고 해도 딱히 그런 생각은 없었습니다. 그러나 메모리 풀로 쓰는 모듈이 돌 때 참조가 0이 안된 애들도 청산(주식용어) 되는 것을 보며, 더더욱 DB로 가야 겠다는 생각이 들었습니다.

 

왠만하면 View를 넘나드는 데이터의 경우 전부 DB로 처리한다... 쯤 되겠네요. 예전보다 좋아지긴 했지만... 아직도 메모리 문제는 프로그래밍 언어와 운영체제가 다 알아서 해주는게 맞는 것 같다는 꿈을 꿔 봅니다. 30년도 더 된 일이지만요. 사실 속마음은 이럴거면 ARC  왜 도입 했고, 자바 코스프레 왜 하는겨? 정도네요. 필터카메라 만들 때 강제 gc 미친듯이 호출해야만 하는 상황도 생각나구요. 오래된 프로그래머라 그런지 아직도 메모리 스스로 관리해야하는 C/C++이 맞다는 생각입니다.