최근 아이폰 어플을 공부하고 개발하고 배포까지 하면서 개발시 꼭 체크하거나 염두해야할 일을 생각나는데로 정리해 보았다. 

 

1. 메모리는 항상 관리한다.

Instruments를 이용해 Memory leaks를 반드시 한다. 특히 View Controller가 전환시, 또는 데이터 통신후에 체크하도록 하는 것이 중요하다. Instruments를 이용하면 완벽하지 않지만 문제를 해결할 수 있는 발판을 마련해준다.

 

또한 Build만 해보지 말고 Build and Analyze를 통해 잠재적으로 메모리 leaks가 생길 부분을 찾도록 한다. 완벽하지 않지만 retain후 release를 안한 부분도 은근히 잘 찾아주므로 꼭 활용하길 바란다.

 

2. 디바이스 테스트는 필수

아이폰 시뮬레이터에서 동작을 잘하던 것이 디바이스에서 테스트 하면 중간에 멈추던가 이상한 동작할 하는 경우가 발생한다. 거의 대부분 이것은 메모리 문제이다. 디바이스는 제한된 메모리이기 때문에 메모리 경고가 자주 일어난다. 또한 이러한 메모리 문제는 View Controller에서 viewDidLoad 메소드를 다시 호출시켜 그에 따른 대책을 마련하지 않으면 어플이 죽거나 이상한 동작을 하게 된다.

 

디바이스에서 테스트는 개발 중간중간 자주 해야한다. 그렇지 않고 시뮬레이터에서만 개발하다가 디바이스에 올린뒤 발생하는 문제를 해결하려면 노력이 배 이상이 들 수 있다.

 

 

3. Memory Warning을 지나치지 말아라.

일단 아이폰 시뮬레이터의 메뉴를 보면 강제적으로 메모리 경고를 줄 수 있다. 그렇게 되면 AppDelegate와 View Controller에서 메모리 경고를 감지할 수 있게 된다. 경고가 발생하면 필요없는 자원을 해제 시키길 바란다. 또한 View Controller에서는 viewDidUnload 메소드가 호출될 수 있다. 이때 self.myView = nil 처리가 되어 있으면 이 객체는 메모리 반환이 되고 나중에 viewDidLoad와 viewWillAppear 호출된다. 이 때 중복된 메소드 호출이나 잘못된 메모리 반환으로 어플이 중간에 중지되거나 이상한 데이터를 View상에 보여주게 된다. 이런 처리도 말끔하게 해주어야 된다. 결국 View Controller의 라이프 사이클을 잘 이해하는 것이 중요하고 그에 따라 대처해야한다.

 

 

4. 인터페이스 빌더를 잘 활용하자.

개발자이기 때문에 인터페이스 빌더를 사용안하고 오로지 코딩으로 뷰배치를 하시는 분들이 있다. 초반에 아이폰 개발때는 이 방법이 좋을 수 있다. 무언가 코드안에서 다 해결할 수 있기 때문이겠다. 하지만 아이폰과 같은 작은 기기의 어플들은 긴 기간의 개발을 요구될 수 없다. 짧은 기간안에 빠른 승부를 내야하는게 바로 아이폰 어플이라고 본다. 뭔가 View 구성을 코드로만 하다 보면 개발자는 나중에 지쳐버린다. 한 페이지 View를 만드는데 만해도 엄청난 노력이 들어가야 한다.

 

인터페이스 빌더를 이용해 ViewController 단위로 만들고 TableView에 보일 Cell들도 만들면 여러분은 어느정도 View 구성하는 스트레스에서부터 해방될 수 있다. 완벽하지 않지만 복잡한 배치를 위해 골머리 쌓는 일에서는 거의 70~80% 해방된다. 게다가 ViewController의 코드도 많이 짧아진다. 왜냐하면 View를 구성하기 위한 코드가 많이 줄기 때문이다.

 

또한 인터페이스 빌더를 이용하면 Command+R 만으로 시뮬레이터에서 View를 미리 볼 수 있다. 이런 것들을 활용하면 개발에 많이 도움된다.

 

 

5. SVN을 이용한 소스 관리를 꼭 하자.

개발하면서 소스관리 툴하나 쓰지 않는다는 것은 사실 말이 안된다. Eclipse와 같은 툴을 다뤄봤던 사람이라면 소스관리를 위해 SVN을 많이 사용했을 것이다. 협업을 위한 것도 있지만 개인적으로 쓰더라도 소스 관리는 반드시 필요하다. Xcode는 기본적으로 SCM 기능이 있어 이것으로 소스관리가 가능하다. Eclipse에 비해서 많이 불편한 편이지만 익숙하면 쓸만하다.

 

6. 최적화에 만전을 기하자.

아이폰은 데스크탑과 다르게 제한된 메모리, 제한된 CPU 기반이다. 그러므로 이런 제한된 환경에서도 부드럽게 동작하도록 노력해야한다. 가령 이미지를 프로세싱 하더라도 cache처리를 해야할지 말아야 할지, Thread나 Operator를 이용해 데이터를 가져오거나 말아야할지 등을 잘 결정해서 개발해야한다. 까페에 문씨님이 올린 Operator 활용법을 참고하면 좋겠다.

 

7. 다양한 장치에서 구동되도록 하자.

애플 개발 정책(?)상 xcode를 배포하면서 번들로 있는 SDK는 항상 최신을 유지한다. 그래서 구버전의 아이폰이나 아이팟 터치에 동작하도록 만들 필요가 있다. iOS 4 기반으로 개발하더라도 약간의 옵션 조정으로 3.0, 3.1 에서도 동작하도록 할 수 있다. 그것은 Groups & Files에서 어플의 이름을 선택한뒤 info에서 Build 탭을 선택한다. 거기서 iOS Deployment Target을 iOS 3.1 등으로 맞추면 가능하다. 물론 SDK 상에서 상위버전시에만 구동이 되는 부분에 대해서는 따로 조치를 취해야 하며 장치 구성상 전혀 사용할 수 없는 부분은 아에 AlertView등으로 알려줘야한다. 가령 카메라의 경우 구형 아이팟터치는 동작하지 않듯이 말이다.

 

8. [myObject release]; 후에는 반드시 myObject=nil 을 하자.

@property로 지정된 속성의 경우 self.myObject = nil 하는 것만으로도 [myObject release];myObject=nil; 이 진행된다. 하지만 속성이 @property로 지정되어 있지 않은 경우에는 self.myObject로 접근할 수 없으므로 release만 할 수 있다. 하지만 [myObject relase];만 하면 문제가 발생할 수 있다. 가령, release를 한뒤 retainCount가 0가 되면 이것은 이제 좀비가 된다. 이 좀비객체에 어떠한 메시지를 보내면 무조건 어플 죽는다. 하지만 myObject=nil 처리하면 nil에 어떤 메시지를 보내도 무시해버린다. 이러한 문제는 좀처럼 눈에 보이지 않게 어플을 죽게하는 요인이 된다. 정상적인 상황에서는 이런 문제가 안생기는데, 디바이스에 물려서 돌리면 어플 죽은 범인이 여기에도 있다. 왜냐하면 디바이스는 제한된 메모리로 waning이 빈번하게 날 수 있고 그에 따라서 viewDidLoad등이 다시 호출되면서 좀비가된 myObject를 엑세스해버리는 현상이 발생할 수 있기 때문이다. release후 다시 새로운 객체로 할당해 retain 하더라도 그냥 버릇처럼 [myObject release];myObject=nil; 이런식으로 하는게 좋다.

 

 

이외에도 많겠지만 일단 생각나는데로 정리해보았다.


글쓴이 : 지돌스타(http://blog.jidolstar.com/724)

+ Recent posts