Hong's Programing World

개발 환경: XCode (6.4), iOS (8.4)

Crash 종류!

먼저, Crash 타입에는 크게 2가지 유형이 있다.

1. SIGABRT ( EXC_CRASH로 불리기도 함)

- Signal Abort, 해당 Signal은 프로그램 스스로 error를 감지하여 abort signal을 보내는 것이다.(This signal indicates an error detected by the program itself and reported by calling abort. )

- C stdlib중에 abort()라는 함수가 있다. 이 함수는 프로그램을 비정상적으로 종료시키는 함수로, 호출한 프로세스에게 SIGABRT를 날려서 프로그램을 종료시킨다. 즉 App이 프로그램 실행 도중 의도치 않은 동작을 감지 했을때 abort()를 호출하여 App을 종료시키는 것이다. 

- 이 경우는 Crash 원인을 찾기에 비교적 쉬운 타입에 속한다. 왜냐하면 App(프로그램)이 Crash 원인을 알고 있어서 Debug Output에 Crash 원인을 출력해주기 때문이다.

2. EXC_BAD_ACCESS( SIGBUS, SIGSEGV )

- SIGSEGV : signal segmentation violation, 할당된 메모리의 범위를 벗어나는곳에서 읽거나 쓰기를 시도할 때 발생됨.(프로그램 자신의 영역이 아닌 다른 영역의 메모리를 접근했을 때) 또는 readonly 메모리에 대하여 write를 시도했을때 발생되는 error signal 이다.

- SIGBUS : signal bus, SIGSEGV와 같이 메모리에 비정상적인 접근을 할 때 발생하는데, SIGSEGV는 valid한 메모리에 비 정상적인 접근을 할 때 발생하며, SIGBUS는 invalid한 메모리에 접근할 때 발생한다.

- 이 경우는 Crash 원인을 찾기가 어렵다. App(프로그램)이 Crash원인을 감지하고 App을 중단 시킨것이 아니기 떄문에 Debug Output에 Crash원인을 출력하지 않는다.

다행인점은, XCode가 업그레이드 되면서 EXC_BAD_ACCESS Crash가 일어나야 되는 상황도 미리 감지하여 SIGABRT Crash를 발생시키는 것으로 보인다. 실제로 old 버젼 XCode에서 EXC_BAD_ACCESS Crash가 일어나던 것이 최신 버젼에서는 SIGABRT Crash를 발생시키는 사례를 종종 볼 수 있다.

Crash 대처법

- 위에서 소개한 SIGABRT, EXC_BADACCESS Crash 둘다 XCode가 업데이트 되면서 왠만한 Crash들은 해당 code line 위치에서 break point가 걸린다. 하지만 그렇지 않은경우 해당 crash를 해결하기 위한 기본적인 팁을 소개하겠다.

1. SIGABRT

- 위 Crash는 SIGABRT 타입이기 때문에  debug output에 Exeption Reason이 출력된다. 하지만 해당 Exeption이 일어난 위치를 확인하고 싶을때는 All Exception BreakPoint를 설정해 준다.

- 왼쪽 Navigator에서 BreakPoint Navigator를 활성화 시킨다. 

- 왼쪽 하단에 '+' 버튼을 눌러 모든 Exception에 Breakpoint를 지정한다.

이제 SIGABRT Crash가 발생되기 직전 exception이 발생된 코드 라인에 break point가 걸려 있을것이다. 해당 기능을 사용하면 좀 더 빠른시간안에 crash원인을 찾을 수 있다.

2. EXC_BAD_ACCESS

- EXC_BAD_ACCESS Crash의 대부분의 원인은 release retain 메커니즘 오류이다. 보통 MRC 모드에서 많이 발생되나, ARC 모드에서도 간혹 발생된다.

- 위 스샷 처럼 Crash가 난 위치에서 break point가 잡히지 않았을때는 Zombie Objects를 이용한다.

- 메뉴 Product -> Scheme -> Edit Scheme 에서 Enable Zombie Objects를 활성화 한다.

- Zombie Objects가 하는 일은 메모리에 할당된 객체가 release될때 dealloc 시키지 않고 모니터링 하는 것이다. 해당 객체를 모니터링 하는 도중 프로그램이 객체에 접근하면 에러 메시지를 날려 어떤 객체에 invalid한 메모리 접근이 일어났는지 알려주는 것이다.

* 요약: main 함수에서 SIGABRT Crash가 발생되면 All Exception Break Point를 지정하고 다시 실행해서 정확한 Crash 위치를 확인해라, EXC_BAD_ACCESS Crash가 발생되면 Zombie Objects를 활성화 시켜 어느 객체에서 메모리 접근 오류가 발생했는지 확인해라.

* http://stackoverflow.com/questions/3327828/xcode-lldb-how-to-get-information-about-an-exception-that-was-just-thrown (exception print)

출처 : NHN Ent 기술공유 게시판

- 카운터 관리 방식을 사용할 경우, 자식 스레드 쪽에서는 객체가 누수되는 것을 막기 위해 부모 스레드와는 다른 자동 해제 풀을 만들어 관리할 필요가 있다.

- 스레드 세이프
    -- 여러 개의 스레드가 하나의 인스턴스를 조작할 때 오작동하지 않을 경우, 그 클래스는 스레드 세이프 하다고 말한다. 일반적으로 불변 객체는 스레드 세이프하고 가변 객체는 스레드 세이프 하지 않다. 즉, 가변 객체를 공유하기 위해서는 상호 배제나 동기화를 적절히 사용해야 한다.

- 스레드 생성                                                                                                                               
    -- NSThread                                                                                                                                       + (void)detachNewThreadSelector:(SEL)aSelector toTarget:(id)aTarget withObject:(id)anArgument                                                                                                                          
    -- 객체 aTarget에 대한 메소드 호출을 새로운 스레드를 만들어 실행한다. aSelector는 id 타입의 인수를 하나만 사용해서 void를 리턴하는 액션 메소드여야만 한다. 카운터 관리 방식을 사용할 경우 실행되는 메소드 자체가 자동 해제풀을 관리할 필요가 있다. 인수 aTarget과 anArgument에 지정된 객체는 스레드를 만드는 것과 동시에 retain되어 스레드가 종료될때 release된다.

   -- NSApplication                                                                                                             
      --- + (void)detachDrawingThread:(SEL)aSelector toTarget:(id)aTarget withObject:(id)anArgument
         ---- 위에 NSTherad의 스레드 생성 메서드를 사용하는데, 카운터 관리 방식일 경우 스레드를 위한자동 해제 풀을 만든다.
      --- + (BOOL)isMultiThreaded                                                                                                
          ---- 여러 개의 스레드가 병행으로 동작하고 있거나 그 시점에서 메인 스레드 밖에 없더라도 이제까지 스레드가 생성된 적이 있다면 YES를 리턴.

- 상호 배제
    -- 여러 개의 스레드 사이에서 전역 변수와 같은 공유 자원의 상호 배제를 하기 위해 NSLock 클래스를사용.
    -- Lock은 프로그램이 멀티 스레드로 동작하기 전에 만들어져야 함.
        --- 어떤 락에 대해 lock이 실행 되면 그 후 반드시 unlock을 1회만 실행해야 한다. lock을 한 후 unlock을 사용하는 것은 같은 스레드에서 해야함.                                                                          
    -- (void)Lock
        --- P조작: 락이 사용 중이라면 스레드는 휴면상태에 들어감. 사용중이 아니라면 락을 사용 중으로 바꾸고 실행을 계속함
    -- (void)unLock
        --- V조작: 사용 중이던 락을 해제, 그 락을 획득하기 위해 휴면 상태에 있는 스레드가 있다면 그 스레드가 해제된 락을 획득                                                                                                       
    -- (BOOL)tryLock
        --- 리시버인 락 획득을 시도하고 획득을 성공한 경우 YES를 리턴함, 실패한 경우 휴면 상태에 들어가지 않고 NO를 리턴한 후, 실행을 계속함.

- Objective-C에서는 런타임 시스템의 기능을 사용해서 클래스의 일부 메소드를 런타임에 추가하거나 교체하는 것이 가능함. 

- 단 지나치게 남용하면 유지보수하기 어려움. 

- 최후의 수단으로 사용할 것을 권함.

- @dymamic을 지정한 프로퍼티는 이에 대응하는 접근자 메소드를 클래스에서 정의할수도 있지만, 정의하지 않아도 런타임에 함수를 동적으로 결합하는 것이 가능함.

- Objective-C의 메소드는 IMP 타입으로 표현되는 C함수이다. 첫번째 인수가 self(id타입), 두번째 인수가 SEL이 되어야 함.

- BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types);

    - cls는 바인딩시키코 싶은 클래스이고, name은 메소드의 셀렉터, imp는 함수의 포인터, types는 함수의 타입 정보를 나열한 것이다. 바인딩에 성공한 경우 YES를 리턴.

- 실제 바인딩 하기

    - -(void)setList:(NSArray *)obj ----> void set_list(id, SEL, NSArray *)(프로토 타입) 

    - class_addMethod(self, @selector(setList:). (IMP)set_list, "v@:@"); 로 함수 바인딩(클래스 메소드 안에서 호출할 경우 첫번쨰 인수에 self를 집어넣으면 됨)

* @encode() 

 - Objective-C는 객체를 동적으로 다루는 일이 많아 데이터를 보존하거나 통신을 할 때, 그 데이터가 실제로 어떤 데이터 타입이라는 정보를 알려줘야 하는 경우가 있다.  

 - Objective-C는 데이터 타입을 표현하기 위해 C문자열(const char*)의 타입 코드를 사용하지만, 타입에서 문자열을 쉽게 얻을 수 있도록 @encode()라는 컴파일러 지시자가 제공됨.

 - @encode()는 인수로 타입명을 받아 컴파일할 떄 대응하는 타입으로 교체를 한다. 예를 들어 @encode(int)는 'i'가 되고, @encode(NSSize)는 '{_NSSize=ff}'가 된다.

 - 주요타입의 표

Cocoa 환경에서 여러 정보를 표현하고, 보존하기 위해 사용하는 표준적인 데이터 형식.

- ASCII, XML, 바이너리 형식의 세 종류 형식을 사용할 수 있음.

   - ASCII : NSString, NSData, NSArray, NSDictionary 표현 가능.

   - XML : 위의 네가지 + NSNumber, NSDate

   - 바이너리 : 위와 같은 형식을 텍스트가 아닌 바이너리 파일로 보존함.

- ASCII 형식의 Property List에서는 NSArray, NSDitionary의 인스턴스에 대해 description 메서드를 사용해서 문자열 형식으로 값을 얻을 수 있고, 이를 다시 객체의 구조로 복원하기 위해서 propertyList메서드를 사용해서 복원할 수 있다.

- XML 형식의 Property List에서는 NSArray, NSDictionary에 대해 writeToFile:atomically:를 사용해서 XML 형식의 프로퍼티 리스트를 파일에 쓸 수 있다. 파일에서 다시 객체로 복원하려면 initWithContentsOfFile을 사용해서 복원.

- 클래스 타입과 프로퍼티 리스트의 문자열 표현

- 프로퍼티 리스트의 변환과 검증

세 종류의 프로퍼티 리스트를 서로 변환하거나 형식을 검증하기 위한 클래스 NSPropertyListSerialization이 제공됨. 프로퍼티 리스트를 복원해서 얻는 객체의 구조를 가변 객체로 구성하는 것도 가능.

객체 직렬화와 아카이브의 차이
: 코코아 프레임워크에서 직렬화(serialization)는 아카이브와 마찬가지로 객체 그래프를 따라 객체의 데이터 내용을 저장하는 방식이다. 다만, 아카이브와 달리 직렬화는 주로 문자열, 배열이나 사전 컬렉션에 담겨 있는 계층 구조와 참조하는 객체 데이터만 직접적으로 저장하며, 참조 관계에는 관심이 없고 데이터에만 관심이 있다. 예를 들어, 여러 곳에서 하나의 객체를 다중 참조하고 있으면 참조마다 동일한 내용을 각기 저장한다. 그러므로 deserialization 할 때에도, 동일한 객체를 다중 참조하는 것이 아니라 각기 다른 객체가 만들어진다는 것이다. 그리고 데이터에만 관심이 있기 때문에 해당 객체가 가변 객체였는지 불변 객체였는지 판단해서 복원할 수 없다.
객체 직렬화와 직접적으로 관련이 있는 클래스는 NSPropertyListSerialization이 있다. 이 클래스는 Foundation 객체 중에서 NSDictionary, NSArray, NSString, NSDate, NSData, NSNumber 타입으로 저장되어 있는 데이터 구조만 XML 기반 plist 파일로 직렬화 해서 저장한다. 
NSUserDefaults 클래스도 내부적으로 NSPropertyListSerialization을 사용해서 직렬화를 지원한다.

직렬화(Serialization)는 다중 참조 관계나 가변객체 여부등을 복원하지 못하고 저장할 수 있는 클래스 종류도 한정적이다. 이러한 제약 사항을 지원해야 하는 경우라면 <NSCopying> 프로토콜을 사용해야 한다. 

<NSCoding> 프로토콜

- 객체를 Archive, UnArchive하기 위해서는 NSKeyArchiver, NSKeyUnarchiver가 필요.
- Archive 대상이 되는 객체는 NSCoding 프로토콜을 따르고 있어야 함.
- NSCoding 프로토콜 : encodeWithCoder, initWithCoder:

- (void)encodeWithCoder:(NSCoder *)aCoder
{
    [super encodeWithCoder:aCoder];
    // 슈퍼 클래스가 NSCoder프로토콜을 따르지 않으면 불필요.
    [coder encodeObject:객체 forKey:키];
    [coder encodeDouble:실수 forKey:키];
    ....
}

먼저 슈퍼클래스가 NSCoding 프로토콜을 따르고 있으면 super의 encoderWithCoder를 호출해서 인코딩 후 자신을 인코딩함. 클래스가 독자적으로 가지고 있는 인스턴스 변수가 없고, 슈퍼클래스 에 encodeWithCoder:의 정의가 있는 경우라면 이 메소드 정의 자체가 필요 없음.
인코딩할때의 Key는 인스턴스 변수 각각에 다른 키를 지정해야 한다. 슈퍼 클래스에서 지정한 키를
서브 클래스에서 사용하면 안된다. 키는 같은 내부에서만 구별할 수 있으면 되기 때문에 다른 클래스
에서 같은키 사용 가능.
객체의 아카이브 메서드는 encodeObject:forKey:를 사용하는데, 이 함수는 첫 번째 인수인 객체에
대해 encodeWithCoder:를 호출해서 인코딩하므로, 이런 메소드는 재귀 호출한다. 객체 그래프에 순환 참조가 있는 경우, 같은 객체의 인코딩 요구가 여러 번 발생할 수 있지만 일단 아카이브한 객체를 중복해서 아키이브 하지 않음.

*encodeConditionalObject: (다른 곳에서 아카이브되어 있지 않으면 인코딩하지 않는 메서드)
- 아카이브 할때 인스턴스 변수 일부만 아카이브할 수가 있는데, 아카이브 하지 않은 인스턴스 변수를 객체 그래프의 순환참조가 있을경우 다른 곳에서 아카이브를 해버리면 복원하는 시점에 문제가 발생할 수 있다. 이때 사용하는 메서드.

- (id)initWithCoder:(NSCoder *)aCoder
{
    self = [super initWithCoder:aCoder];
    //슈퍼 클래스가 NSCoding 프로토콜을 따르지 않으면 [super init]만 하면 됨.
    
    변수 = [[coder decodeObjectForKey:키] retain];
    .....
    return self;
    
    // 인코딩도 디코딩과 같은 키를 지정하기만 하면, 디코딩하는 순서는 상관없고 복원하지 않는 변수가 있어도 상관 없음.
}

copy, mutableCopy

NSObject에는  리시버를 복사하는 copy라는 메서드가 있다. 단, 실제 복사 처리를 하는것은 copy가 아니라 copyWithZone:이라는 인스턴스 메서드이다. 인스턴스 객체에 copy메세지를 보내면 인수로 NULL을 지정해서 자기 자신의 copyWithZone을 호출해서 Default Zone에 새로운 인스턴스를 만들 수 있다.

이러한 원리로, 인스턴스가 복사되도록 하기 위해서는 copy 메소드가 아닌 copyWithZone: 메소드를 정의해야 한다. 만약 복사가 실패했을 경우 copy, copyWithZone 둘 다 nil을 리턴한다.

copyWithZone:은 NSCopying 프로토콜 내에서 선언되어 있으므로 이 프로토콜을 적용해서 구현한다.

*인스턴스 객체를 바이트 배열로 간주하고 통째로 복사해서 다른 객체를 리턴하는 함수가 제공 됨.

 - id NSCopyObject(id anObject, NSUInteger extraBytes, NSZone *zone)

   - 인수의 anObject가 원본 객체이고 extraBytes는 보통 0을 지정함, 인수 zone에 NULL을 지정하면 default zone이 사용됨.

   -  문제점 : 원본 객체의 인스턴스 객체들까지 copy가 되지 않는다.(객체 내용의 바이트 배열을 복사하기만 하므로..) 즉, 원본객체와 복사객체 모두 해당 인스턴스 객체를 강한 참조하게 된다, 또한 MRC를 사용할 경우 해당 인스턴스 객체에 retain count가 자동 증가되지 않기 때문에 copy 후 retain을 해줘야 함. -> 즉, 단순히 값을 복사하기만 하면 되는 인스턴스가 많을 경우 유용.

- 불변객체에서 가변객체 복사를 생성하려면 mutableCopy메서드가 위에 copy메서드와 대응되고,    mutablecopyWithZone:이 copyWithZone:과 대응된다. 동작 메커니즘은 똑같다.

얕은복사 vs 깊은복사
: 얕은복사는 메모리 주소를 복사한다는 것이다. 즉, 똑같은 인스턴스를 두개의 포인터가 가리키고 있게 된다.
깊은 복사는 새로운 메모리 공간을 할당해서 인스턴스의 값을 복사한다는 것이다. 서로 다른 공간의 메모리가 생기고 두개의 포인터는 각각의 메모리 공간을 가리키게 된다.

: NSArray와 같은 파운데이션 프레임워크에 있는 모든 클래스는 얕은 복사를 지원한다. 즉, NSArray에 copy메세지를 보내도 array가 포함하고 있는 각 객체들에게 copy 메세지를 보내서 복사하는게 아니라 메모리 주소만 복사한다.
깊은 복사를 하기 위해서는 array계열 클래스는 'initWithArray:copyItems:' 메서드가 있고, 다른 컬렉션 클래스에도 비슷하게 'copyItems:' 으로 끝나는 메서드가 존재한다. 해당 메서드를 호출할 때 copyItems 인자에 'YES'를 넘기면 각 컬렉션들이 포함하고 있는 객체에 copy메세지를 보내 복사하게 된다. 단 각 객체가 <NSCopying> 프로토콜을 conform 하지 않으면 런타임 에러가 발생한다. 

Cocoa에서는 동적으로 확보되는 메모리를 관리하기 위해 zone이라는 영역을 사용한다.

동적으로 메모리를 할당하고 해제하는 작업을 반복할 경우 서로 관계가 있는 내용의 데이터가 메모리 상에서는 멀리 떨어진 곳에 흩어질 가능성이 있다. 그래서 메모리 공간에 여러 개의 힙을 만들어 서로 밀접한 관계에 있는 데이터나 객체는 특정 힙 내에서 메모리가 할당되도록 한다. 

이렇게 메모리 상에 만들 수 있는 힙 영역을 Zone이라 부른다.

Zone은 각각 메모리 관리 기능이 있고, 필요에 따라 그 크기가 증가한다. 프로그램이 실행된 직후부터 존재하는 Zone을 Default Zone이라 한다. 그리고 따로 지정하지 않을 경우 인스턴스 객체는 Default Zone에 만들어 진다.

*가비지 컬렉션을 사용하는 경우 Zone 사용 불가.

- Objective-C 에서는 클래스 클러스터를 만들기 위한 언어 자체의 매커니즘은 없다. 하지만 일반적으로, 공개클래스는 추상 클래스로, 구체적인 클래스는 공개 클래스의 비공개 서브 클래스로 구현되어 있음.

- Cocoa에서 많은 클래스가 실제로는 클래스 클러스터로 구현되어 있다. 대표적으로 NSData, NSDate, NSArray, NSDictionary, NSSet, NSString, NSNumber, NSValue 등이 있다. 이들 클래스는 일반적인 방법으로 서브 클래싱을 할 수가 없다.

- 클래스 클러스터 인스턴스의 소속을 확인할 경우.

   - 클래스 클러스터에서 각 인스턴스는 비공개 서브 클래스의 인스턴스이다. 따라서 공개 클래스를 인수로 한 메소드 isMemberOfClass:를 사용해도 어떤 결과가 나올지 알 수 없다. 인스턴스가 속하는 클래스를 확인하기 위해서는 isKindOfClass:나 respondsToSelector:로 확인하는것이 바람직하다.

- 서브 클래스를 만드는 경우 밑에 두가지 방법이 있다. 

1) True Subclass

1. 비공개 데이터 구조를 결정한다.

- 인스턴스 변수로 가질 데이터 구조를 결정한다. 슈퍼 클래스인 클래스 클러스터가 가지는 데이터 구조는 절대 사용하면 안됨.

2. 이니셜라이저를 정의한다.

- init 이외의 슈퍼클래스의 이니셜라이저를 상속받아 사용하면 안됨. 비공개 데이터 구조가 없다면 init을 사용하면 되므로 이니셜라이저의 정의는 필요 없음.

3. 컨비니언스 컨스트럭터를 정의한다. 

- 필요할 경우, 데이터 타입명으로 시작하는 임시 객체를 생성하는 클래스 메소드를 정의합니다. 슈퍼 클래스의 같은 메소드를 상속받아 사용하면 안됩니다.

4. 원시(primitive) 메소드를 정의한다.
- 원시 메소드는 각 클래스 클러스터의 레퍼런스 문서에 나와있다.

5. 그외의 메소드를 정의한다.

- 원시 메소드를 정의하면 공개 클래스에서 선언된 메소드가 일단 동작은 한다. 다만 그 데이터 구조의 특징을 살리기 위해 메소드를 오버라이드 해서 사용할 수 있다.

2) Composite Object

Composite Object의 경우 역시 abstract superclass를 상속 받은 후 데이터 모델을 직접 설계하지 않고 기존의 private cluster object를 맴버로 가지고 그것을 그대로 사용하는 방식입니다.

문제는 실제 데이터가 모두 맴버 변수에 저장되어있기 때문에 primitive methods들을 모두 구현하되 내부에 가지고 있는 private cluster object와 연결 해주어야 합니다.

뭐, 자주 쓰일 일은 없을 것 같지만 일단 두가지 방법으로 서브클래싱이 가능하기 때문에 특정 동작을 위한 컬랙션 같은 것을 구성할 때 편하게 사용할 수 있을듯 합니다.

그럼 어떤 때 이런 Class Cluster에 대한 subclassing이 필요할까요?

먼저 생각이 떠오른 것은,

True subclass의 경우 NSValue가 지원하지 않는형태의 value를 사용해야 한다던지.. (물론 valueWithBytes:objCType: 같은 것으로 해결 할 수도 있을것 같습니다.) file 같은 것에 매핑된 거대한 array같은 것을 사용한다던지, 심지어 서버와 통신하면서 동작하는 NSArray를 구현한다던지(아.. 너무 오버인것 같기도 합니다. 큰 데이터에 sorting 같은 걸 하면 안드로메다 가겠습니다.) 등등 응용분야는 많을듯 합니다.

Composite object의 경우 기존의 collection에 validation처리를 한다던지, logging을 한다던지, 데이터 처리 자체를 변경하지 않는 범위에서 무엇인가 추가작업을 간결하게 하고자 하면 유용할듯 합니다.

  *출처 -  http://maccrazy.tistory.com/102