最近把一个游戏内嵌到app里，选用了微信开源的Mars，结果遇到了内存峰值。解决的方法很容易，加上@autoreleasepool就可以了。但是做实验的时候又有了好多疑惑，不停地往深处挖，最终了解了autoreleasepool的实现，Tagged Pointer，和NSString内存管理的特殊性。
Mars
我们做的小游戏需要实时传输数据，数据很小，就选用了Mars。结果内存一直涨，在这里加个autoreleasepool就可以避免内存峰值。
void StnCallBack::OnPush(int32_t _cmdid, const AutoBuffer& _msgpayload) { if (_msgpayload.Length() > 0) { @autoreleasepool {
NSData *recvData = [NSData dataWithBytes:(const void *)_msgpayload.Ptr() length:_msgpayload.Length()];
[[TRSocketManager sharedInstance] OnPushWithCmd:_cmdid data:[[NSString alloc] initWithData:recvData encoding:NSUTF8StringEncoding]];
}
}
}autoreleasepool
Objective-C Autorelease Pool的实现原理
这篇博客很不错，详细介绍了autoreleasepool的实现，图文并茂，很好理解。不过他提的3个场景，答案现在已经不适用了。
__weak NSString *string_weak_ = nil;
- (void)viewDidLoad {
[super viewDidLoad]; // 场景 1
NSString *string = [NSString stringWithFormat:@"leichunfeng"];
string_weak_ = string; // 场景 2// @autoreleasepool {// NSString *string = [NSString stringWithFormat:@"leichunfeng"];// string_weak_ = string;// }
// 场景 3// NSString *string = nil;// @autoreleasepool {// string = [NSString stringWithFormat:@"leichunfeng"];// string_weak_ = string;// }
NSLog(@"string: %@", string_weak_);
}
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated]; NSLog(@"string: %@", string_weak_);
}
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated]; NSLog(@"string: %@", string_weak_);
}结果令人大跌眼镜，来看看输出吧：
//3个场景全部都是这个答案2017-04-09 22:33:47.362 ReleaseTest[3338:184169] string: leichunfeng2017-04-09 22:33:47.362 ReleaseTest[3338:184169] string: leichunfeng2017-04-09 22:33:47.396 ReleaseTest[3338:184169] string: leichunfeng
我的第一反应是这不科学，weak是不会增加引用计数的，怎么可能不释放呢？难道我所理解的都是不对的？
然后我改了改，把NSString改成NSDate
//场景一2017-04-09 22:42:12.211 ReleaseTest[3453:189869] date: 2017-04-09 14:42:12 +00002017-04-09 22:42:12.211 ReleaseTest[3453:189869] date: (null)2017-04-09 22:42:12.227 ReleaseTest[3453:189869] date: (null)//场景二2017-04-09 22:41:21.333 ReleaseTest[3428:188843] date: (null)2017-04-09 22:41:21.333 ReleaseTest[3428:188843] date: (null)2017-04-09 22:41:21.349 ReleaseTest[3428:188843] date: (null)//场景三2017-04-09 22:39:33.494 ReleaseTest[3395:187226] date: 2017-04-09 14:39:33 +00002017-04-09 22:39:33.494 ReleaseTest[3395:187226] date: (null)2017-04-09 22:39:33.511 ReleaseTest[3395:187226] date: (null)
这个答案才对嘛，不过有两个疑惑：
NSString下，引用计数为0，可是没有释放内存
stringWithFormat这个方法创建的对象，会被系统自动添加到了当前的 autoreleasepool中，赋个变量后，引用计数会为2（作者的想法，可是现在没法验证）
Tagged Pointer
第一个疑惑很好解决，这是Tagged Pointer的锅。
Tagged Pointer是一个能够提升性能、节省内存的有趣的技术。
他不是一个对象，不用在堆上分配空间，感觉和python变量的存储方式很像，简单点理解就是以变量值来寻址，只要变量相同，就指向同一个地址，读取速度非常快。
NSString *tempStrA = @"lu"; NSString *tempStrB = @"lu"; NSNumber *tempNumA = @(123); NSNumber *tempNumB = @(123); NSDate *tempDateA = [NSDate date]; NSDate *tempDateB = [NSDate date];2017-04-11 23:33:46.312 NSStringTest[30025:411902] tempStrA:0x10bd390682017-04-11 23:33:46.313 NSStringTest[30025:411902] tempStrB:0x10bd390682017-04-11 23:33:46.313 NSStringTest[30025:411902] tempNumA:0xb0000000000007b22017-04-11 23:33:46.313 NSStringTest[30025:411902] tempNumB:0xb0000000000007b22017-04-11 23:33:46.313 NSStringTest[30025:411902] tempDateA:0x600000008b002017-04-11 23:33:46.313 NSStringTest[30025:411902] tempDateB:0x600000008b70
NSNumber对象缓存以及Tagged Pointer
这篇博客提到Tagged Pointer专门用来存储小的对象，例如NSNumber和NSDate。
NSNumber的地址位很高，明显是栈上，符合Tagged Pointer。
NSString地址位很低，同样的值分配的同一个空间，应该是在常量区。
NSDate同一个值存在不同的地址，应该不是Tagged Pointer。
令人疑惑的地方
回到最开始的问题，就是autoreleasepool可以降低内存峰值，这个很好测试，这边就有个小测试。
autoreleasepool避免内存峰值
不过自己测试下来发现一个奇怪的地方：
- (void)doSomething { for (int i = 0; i < 10e6; ++i) {
第一种：
[NSString stringWithFormat:@"%d", i];
[NSString stringWithFormat:@"%d", -i];
第二种：
[NSString stringWithFormat:@"%d%d",i,-i];
}
}上面一种情况测试下来是：
第二种情况是：
即使没有autoreleasepool，第一种情况内存丝毫不涨，但是第二种情况涨的很快，而且结束后感觉内存没有回收。
MRC测试
带着一些疑问，首先想到测试下计数。换成MRC环境：
NSString *a = @"a"; NSString *b = @"aaaaaaaaaaa"; NSString *c = [NSString stringWithFormat:@"a"]; NSString *d = [NSString stringWithFormat:@"%@%@",a,b]; NSString *e = [NSString stringWithFormat:@"%@%@",a,c]; NSLog(@"%ld and %ld and %ld and %ld and %ld", (unsigned long)[a retainCount], (unsigned long)[b retainCount], (unsigned long)[c retainCount], (unsigned long)[d retainCount], (unsigned long)[e retainCount]);
2017-04-16 13:50:16.934 MRCTest[2302:110760] -1 and -1 and -1 and 1 and -1
有的引用计数为-1，有的引用计数为1。
为-1的情况介绍很多，就是说不由引用计数来管理内存释放，由系统来管理。
为1的情况肯定还是由引用计数来管理。
感觉应该和Tagged Pointer有关系。
NSString特殊的内存管理
灵机一动，想到了NSString判断字面量是否相等是不用==，而是用isEqualToString来判断的，这些和引用计数，Tagged Pointer是不是有关系呢？
继续测试，还是刚才上面的5个值：
2017-04-16 14:04:55.427 NSStringTest[2729:120949] a:0x10817d068 __NSCFConstantString2017-04-16 14:04:55.428 NSStringTest[2729:120949] b:0x10817d088 __NSCFConstantString2017-04-16 14:04:55.428 NSStringTest[2729:120949] c:0xa000000000000611 NSTaggedPointerString2017-04-16 14:04:55.428 NSStringTest[2729:120949] d:0x600000030180 __NSCFString2017-04-16 14:04:55.428 NSStringTest[2729:120949] e:0xa000000000061612 NSTaggedPointerString
因为存储地址从高位到地位为栈区，堆区，常量区。
所以很明显可以得出结论：
| 类型 | 存储区 | 引用计数 |
|---|---|---|
| __NSCFConstantString | 常量区 | -1 |
| NSTaggedPointerString | 栈区 | -1 |
| __NSCFString | 堆区 | 1 |
NSString每种初始化方式，或者字符的长度都会影响到他的类型和存储区。所以不能用==来判断。
根据上面的内存情况，NSTaggedPointerString确实是提高性能，节省内存的类型。所以，如果字符串很短，应该用stringWithFormat的方式初始化。
所以很多时候不是仅仅解决了问题就行了，还要往深处挖，知道为什么这样解决，正是这次的内存峰值，让我知道了NSString的特殊之处，在后来一眼就解决了一个很少见很奇特的bug。
很少见的bug
主要是做的游戏是cocos2dx写的，需要传string值给oc。简化后就是下面这种状况：
std::string cstr = "1"; void *c = &cstr; //第一种场景 //void *c = (void *)cstr.c_str(); //第二种场景 NSString *tempC = [NSString stringWithUTF8String:(char *)c]; NSMutableDictionary<NSString *, NSString *> *dict = [[NSMutableDictionary alloc] init]; [dict setObject:@"123" forKey:tempC]; NSLog(@"%d",[dict.allKeys containsObject:@"1"]);
大家可以写写测测看看类型，还可以在ios8（Tagged Pointer还没出来）下测测，两种场景是不一样的，挺有意思的。
http://www.cnblogs.com/stevenfukua/p/6721537.html
延伸阅读
- 每一次挑战自我就会让我离顶峰越来越近 2023-04-15 14:22:18.54
- 期待下一次的合作 2023-04-15 14:16:17.793
- 从0到0.5，坚持学习 2022-09-08 15:52:26.217
- 珍惜每一次的机会继续前进 2022-09-07 13:37:44.32
- 未来很长，就从这里，“码”上开始吧 2022-07-12 15:46:55.777
- 未来很长，就从这里，“码”上开始吧 2021-06-01 15:23:37.83
- 从今天开始改变自我 2021-05-19 10:42:42.943
- 此生难忘的一次学习 2020-06-11 15:30:55.913
- 每一次结束都是一次新的开始 2020-06-11 15:28:55.21
- 每一次结束都是一次新的开始——王*昊 2020-01-15 09:14:12.547
每一次挑战自我就会让我离顶峰越来越近