달력

06

« 2017/06 »

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
2012.08.20 01:41

Strong, Weak, Assign 살펴보기 개발기술/iOS2012.08.20 01:41

ARC가 나오면서 새로운 Property로 strong, weak이 추가되었다. 알다시피 strong은 강한 참조, weak은 약한 참조라는 의미이다. iOS 4.x에서 썼던 retain, assign( unsafe_unretained)의 대체 개념이라고 알고 있는데 어떤 개념으로 쓰이는 것일까? 그리고 weak과 assign은 어떻게 다른 것일까? 이런 궁금증이 발동하여 테스트 코드를 작성해보았다. 아래 코드를 보자.


@interface SMViewController ()

@property (nonatomic, strong) NSObject *strongObj;
@property (nonatomic, weak) NSObject *weakObj;
@property (nonatomic, assign) NSObject *assignObj;

@end

@implementation SMViewController

- (void)printAddress {
    NSLog(@"strong addr : 0x%x", (unsigned int)self.strongObj);
    NSLog(@"weak addr   : 0x%x", (unsigned int)self.weakObj);
    NSLog(@"assign addr : 0x%x", (unsigned int)self.assignObj);
}

- (void)viewDidLoad
{
    [super viewDidLoad];

    NSLog(@"> init values");
    self.strongObj = [[NSObject alloc] init];
    self.weakObj = self.strongObj;
    self.assignObj = self.strongObj;
    [self printAddress];
    
    NSLog(@"> set strongObj to nil");
    self.strongObj = nil;
    [self printAddress];
}

- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];
    NSLog(@"> move another stack");
    NSLog(@"> will die at assignObj");
    [self printAddress];
}


코드의 내용은 strong, weak, assign 값을 선언하고 strongObj에 Object을 할당한 다음 weakObj와 assignObj에 strongObj을 세팅하고 생명주기가 어떻게 되나 살펴보는 내용이다.


결과는 이러했다.


> init values
strong addr : 0x6a20320
weak addr   : 0x6a20320
assign addr : 0x6a20320
> set strongObj to nil
strong addr : 0x0
weak addr   : 0x6a20320
assign addr : 0x6a20320
> move another stack
> will die at assignObj
strong addr : 0x0
weak addr   : 0x0
== BAD ACCESS ==


처음 시작할 때는 strongObj의 강한 참조값이 살아 있어 weakObj, assignObj의 주소값이 모두 찍힌다. strongObj값을 날려버리고 난 후에는 strongObj의 주소는 0x0이 되고 다른 Obj들은 그대로이다. 


그런데 결과의 12라인을 보면 다른 스택으로 넘어가는 순간 weakObj의 주소값이 0x0으로 바뀐 걸 알수가 있다. 코드로 아무런 조치도 안 했는데 자동으로 값이 바뀐 것이다. weakObj의 약한 참조가 strongObj의 오브젝트가 메모리에서 사라지면서 풀려버린 것이다!! (ARC를 쓰면 오브젝트에 대한 BAD ACCESS의 위험이 대폭 줄어들 것이라는 예상을 할 수가 있다.)


그리고 그 다음 라인에서 assignObj의 주소값을 찍으려는 순간 앱은 BAD ACCESS 내뱉고 죽어버린다. assignObj가 가지고 있는 address의 오브젝트에 대한 잘못된 접근을 했다는 말인데 메모리에서 오브젝트가 사라지더라도 값은 그대로 남아있어 문제를 일으켰다는 것을 알 수 있다.


이 간단한 테스트로 weak과 assign의 차이를 알 수 있고, strong, weak의 쓰임, assign의 쓰임에 대해서도 얼핏 짐작할 수가 있다.


정리하면, strong, weak은 오브젝트을 참조할 때 쓰고, assign은 int, float, double 등과 같은 primitive type에 대해값을 할당할 때 쓰면 되겠다.


TestWeakAssign.zip


저작자 표시 변경 금지
신고

ARC, non-ARC 소스가 같이 있는 프로젝트에서 메모리 해제가 잘 될까?


궁금해서 데이터 오브젝트를 하나 만들어 해제하는 간단한 테스트 프로젝트를 만들어 보았다.



TestARC.zip



프로젝트에 대해서 대충 설명하면, ARC을 사용하는 프로젝트를 만들고 ARC, non-ARC 소스 두개를 만든다.


@interface SMData : NSObject

@property (nonatomic, strong) NSData *data;

@end


@implementation SMData

- (id)init {
    self = [super init];
    if (self) {
        self.data = [NSMutableData dataWithCapacity:1024*1024];
    }
    return self;
}

@end

<ARC소스는 strong을 써서 1메가를 할당하는 오브젝트>


@interface SMData_noARC : NSObject

@property (nonatomic, retain) NSData *data;

@end

@implementation SMData_noARC

@synthesize data = _data;

- (id)init {
    self = [super init];
    if (self) {
        self.data = [NSMutableData dataWithCapacity:2*1024*1024];
    }
    return self;
}

- (void)dealloc {
  [_data release];
  [super dealloc];
}

@end

<non-ARC소스는 기존 방식대로 retain을 쓰고 2메가를 할당하는 오브젝트>



그리고 컴파일 에러가 나지 않게 non-ARC소스에는 -fno-objc-arc 플래그를 지정한다.



이제 Alloc, Release 하는 버튼을 만들어 데이터 오브젝트를 생성하고 해제할 수 있도록 만든다.


- (IBAction)onAlloc:(id)sender {
    self.data = [[SMData alloc] init];
}

- (IBAction)onRelease:(id)sender {
    self.data = nil;
}

- (IBAction)onAllocNoARC:(id)sender {
    self.data_noARC = [[SMData_noARC alloc] init];
}

- (IBAction)onReleaseNoARC:(id)sender {
    self.data_noARC = nil;
}


<실행화면>



이제 메모리를 생성하고 해제하는 동작이 잘 되는지 Instrument 을 통해서 확인한다.


Xcode 메뉴의 Open Developer Tool에서 Instrument을 실행한다.




Allocations을 선택한다.



Choose Target > Attach to Process 에서 TestARC을 선택한후 Record을 누르면 Allocations 모니터링을 할 수가 있다.




버튼을 누를때마다 그래프가 오르락 내리락 하는 걸 통해 정상적으로 메모리가 할당되고 삭제되는걸 확인할 수가 있고, 통계 수치를 통해서도 알 수가 있다. (Malloc 1.25MB는 ARC로 만든 데이터, Malloc 2.50MB는 non-ARC로 만든 데이터)





이로써 ARC, non-ARC 둘다 섞인 소스도 메모리 관리가 정상적으로 된다는 것을 알게 되었네요...

의심이 많다보니 오늘은 뻘짓을 좀 해봤습니다. ㅋㅋ



TestARC.zip



저작자 표시 변경 금지
신고

iOS5의 ARC(Automatic Reference Counting)은 Objective-C 객체의 메모리 관리를 자동으로 관리하는 "Compiler" 속성이다. 이 속성을 사용하면 예전에 쓰던 retain, release, autorelease, dealloc 코드는 사용할 수 없게되며 이들이 하던 역할을 컴파일 시점에 알아서 처리해준다. ARC가 허용하지 않는 코드를 사용하면 아래와 같은 에러를 뿜어낸다.


그럼, ARC을 사용하게 되면 기존 오픈소스를 사용하는데 문제가 되지 않을까 걱정을 할 수 있는데 다음과 같이 해결하면 된다.
  • 이미 컴파일된 오픈소스 라이브러리 사용
  • ARC옵션을 끈 다른 라이브러리 프로젝트를 생성해서 사용
  • 오픈소스 파일별로 ARC옵션을 끄고 사용
ARC옵션을 끄는 방법은 프로젝트 생성할 때 옵션을 끄거나 


프로젝트 Build Settings에서 Objective-C Automatic Reference Counting을 NO로 바꾸거나


프로젝트 Build Phases에서 옵션을 끌 파일들을 선택한 후 엔터를 치고 "-fno-objc-arc" 옵션을 적용해주면 된다.


그런데, ARC을 사용하는데 있어서 제약사항이 전혀 없는건 아니다.
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.
Xcode 4.2 for Snow Leopard does support ARC for iOS though, and Xcode 4.2 for Lion supports both Mac OS X and iOS. This means you need a Lion system to build an ARC application that runs on Snow Leopard.

Xcode 4.2 for Snow Leopard는 지원 안되고, OSX 10.6과 iOS4에서는 Weak 참조를 사용할 수가 없다. 결국 ARC을 제대로 사용하려면 Lion 시스템을 사용하고 iOS5 이상 되어야 Weak 참조를 포함해서 제대로 된 ARC을 사용할 수 있다.


사용해보기 이전에 제약사항에 대해서 먼저 알아본 것은 실컷 공부했는데 나중에 알고보니 어떤 제약이 있어서 쓸 수 없는 상황을 미연에 막기 위해서이다.

그럼 ARC란 무엇인가? retain/release하던 걸 빼고 app_code만 작성하게 해주는 컴파일 속성이다. 사람이 짜는 코드이다 보니 retain/release 쌍이 안 맞아 다양한 버그를 만들곤 하는데 이 걱정을 안하게 해주는 고마운 놈이다.


과거엔 이렇게 했다면, 
MyObj *o = [[MyObj alloc] init];
...
[o release];

ARC에서는 [o release]; 하지 않는다. release를 안 해도 컴파일러시에 자동으로 추가된다고 알면 된다.

@interface Person : NSObject
@property (nonatomic, strong) NSString *firstName;
@property (nonatomic, strong) NSString *lastName;
@property (nonatomic, strong) NSNumber *yearOfBirth;
@property (nonatomic, strong) Person *spouse;
@end
@implementation Person
@synthesize firstName, lastName, yearOfBirth, spouse;
@end
- (void)contrived {
    Person *aPerson = [[Person alloc] init];
    [aPerson setFirstName:@"William"];
    [aPerson setLastName:@"Dudney"];
    [aPerson:setYearOfBirth:[[NSNumber alloc] initWithInteger:2011]];
    NSLog(@"aPerson: %@", aPerson);
}
예전의 경험대로라면 aPerson 과 NSNumber 할당한 놈에 대해 메모리가 새는 걸 막을려는 충동을 느낄테지만 ARC에서는 위 코드가 정상이다. ARC에서는 release 짝 맞추려는 노력을 하지 않아도 된다는 것이다!

그런데, 혹자는 ARC를 사용할 경우 메모리해제가 정상적으로 되지 않는다고도 한다. aPerson = nil; 처럼 nil을 넣어줬더니 정상적으로 해제가 되더라는 사람도 있고, ... 아직 익숙하지 않아서 그렇게 느끼는 건 아닐지....

아무튼 ARC를 사용할 때 얻는 장점이 많기 때문에 앞으로 시작하는 프로젝트에 대해서는 ARC만 사용해서 쓰는 걸 추천한다. 더 자세한 내용은 아래 참고자료를 참고하고, ARC 기본설명은 여기에서 마무리한다.

* 참고자료
Transitioning to ARC Release Notes


저작자 표시 변경 금지
신고


티스토리 툴바