原文摘自微信公众号。
UIGraphicsEndImageContext
UIGraphicsBeginImageContext和UIGraphicsEndImageContext必须成双出现，不然会造成context泄漏。另外XCode的Analyze也能扫出这类问题。
UIWebView
无论是打开网页，还是执行一段简单的js代码，UIWebView都会占用APP大量内存。而WKWebView不仅有出色的渲染性能，而且它有自己独立进程，一些网页相关的内存消耗移到自身进程里，最适合取替UIWebView。
autoreleasepool
通常autoreleased对象是在runloop结束时才释放。如果在循环里产生大量autoreleased对象，内存峰值会猛涨，甚至出现OOM。适当的添加autoreleasepool能及时释放内存，降低峰值。
互相引用
比较容易出现互相引用的地方是block里使用了self，而self又持有这个block，只能通过代码规范来避免。另外NSTimer的target、CAAnimation的delegate，是对Obj强引用。
大图片处理
举个例子，以往图片缩放接口是这样写的：
-(UIImage *)scaleImage:(UIImage *)image newSize:(CGSize)newSize{
UIGraphicsBeginImageContextWithOptions(newSize, NO, 0);
[image drawInRect:CGRectMake(0, 0, newSize.width, newSize.height)];
UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return newImage;
}
但处理大分辨率图片时，往往容易出现OOM，原因是-[UIImage drawInRect:]在绘制时，先解码图片，再生成原始分辨率大小的bitmap，这是很耗内存的。解决方法是使用更低层的ImageIO接口，避免中间bitmap产生：
+(UIImage *)scaledImageWithData:(NSData *)data withSize:(CGSize)size scale:(CGFloat)scale orientation:(UIImageOrientation)orientation{
CGFloat makePixelSize = MAX(size.width, size.height);
CGImageSourceRef sourceRef = CGImageSourceCreateWithData((__bridge CFDataRef)data, nil);
NSDictionary *options = @{(__bridgeid)kCGImageSourceCreateThumbnailFromImageAlways__bridgeid)kCFBooleanTrue, (__bridgeid)kCGImageSourceThumbnailMaxPixelSize:[NSNumbernumberWithFloat:makePixelSize]};
CGImageRef imageFef = CGImageSourceCreateThumbnailAtIndex(sourceRef, 0, (__bridgeCGPDFDictionaryRef)options);
UIImage *resultImage = [UIImage imageWithCGImage:imageFef scale:scale orientation:orientation];
CGImageRelease(imageFef);
CFRelease(sourceRef);
return resultImage;
}
大视图
大视图是指View的size过大，自身包含要渲染的内容。超长文本是微信里常见的炸群消息，通常几千甚至几万行。如果把它绘制到同一个View里，那将会消耗大量内存，同时造成严重卡顿。最好做法是把文本划分成多个View绘制，利用TableView的复用机制，减少不必要的渲染和内存占用。