iOS理解内存警告

本文深入探讨iOS应用中的内存警告机制,包括不同级别的警告定义及其触发条件,并通过实例演示内存泄漏如何导致警告升级,最终引发应用崩溃。

我们都知道在移动设备上很多资源都是比较紧缺的,尤其时内存,通常都比较小,iPhone4也才只有512MB。而且IOS4.0以后还支持了多任务,这个问题就更加突出了。因此我们在平时设计程序的时候要注意管理好内存,减少不必要的开销,谨防泄露。

  由于写的一个小项目存在严重的内存泄漏,程序经常运行时间不长就退出了,调试时候发现运行过程中接受到系统的Memry warning level 1几次以后,紧接着收到一个Memory warning level 2,然后程序退出。通常使用xcode4自带的工具,跟踪发现由于一个图像资源忘记release导致。问题解决了,但我没有打算就此带过。接着上网查找了有关Memory warning Level的资料,后来在stackoverflow上面找到一些有用的数据,这是KennyTM写的,跟大家分享一下:

    系统有四种内存警告,定义如下:

    typedef enum {

        OSMemoryNotificationLevelAny      = -1,

        OSMemoryNotificationLevelNormal   =  0,

        OSMemoryNotificationLevelWarning  =  1,

        OSMemoryNotificationLevelUrgent   =  2,

        OSMemoryNotificationLevelCritical =  3

    } OSMemoryNotificationLevel;

  但是这几种警告之间是怎么变化的,到达什么阈值时会从一个level跳到另外一个level,文章中没有提及。

  通常我们在程序中接收到最多的就是Memory warning level 1,这个时候就证明系统内存紧张了,我们的程序必须做出相应,释放不必要的内存。通常如果我们处理得当的话,内存警告就会到此停止,恢复正常状态。如果我们在接收到memory warning level 1以后坐视不理的话,系统可能还会再尝试通知几次level 1,如果还是不去处理的话,系统将会发出更高一级的内存警告 level 2,通常的结果就是我们的App被强制退出,系统收回内存。当然系统在发出level 2的警告时,也会取尝试做一些清理内存的事,例如关闭不必要的后台程序等。很显然我们不该寄希望于系统自己清理,这就好比你的胳膊被划破了,身体肯定会有自修复功能,但是如果伤口比较大的话,肯定还是需要人工处理一下的。

  到目前位置我还没有见过level 3的警告,根据stack over flow上面讲的“当发生level 3警告时,系统内核将会接管,很有可能关掉iOS的主界面进程(SpringBorad),甚至会重启”,照这个意思来说我们程序里面接收不到,也实属正常,系统自己的东西都被干掉了,我们肯定早被kill了。

  KennyTM写的原文地址: http://stackoverflow.com/questions/2915247/iphone-os-memory-warnings-what-do-the-different-levels-mean

  如果打开上面的连接,可以看到定义OSMemoryNotificationLevel的源文件,你可能会注意到里面有一个函数OSMemoryNotificationCurrentLevel()可以用来获取当前内存告警level,不过需要加头文件#import <libkern/OSMemoryNotification.h>,网上有个查看当前内存数据的开源代码MemWatcher,大家可以看看,说实话我没有看懂。

  说了这么多,希望能帮大家弄清楚内存警告是怎么回事儿,通常我们程序是不会碰到内存警告,平时写代码注意在所有alloc,retain,copy的地方,对应的写上release,或者直接创建autorelease对象(个人不推荐这么做),发布前养成检查内存泄露的好习惯。

  顺便提一下如果运行过程中遇到内存警告的话,程序通常情况下都先调用AppDelegate中的applicationDidReceiveMemoryWarning, 然后程序会通知各ViewController,调用其didRecieveMemoryWarning方法,这个时候我们一定要种,释放不必要的资源。

  ~~~~~~~~~~~~~~~~~~~~~~3月9号更新~~~~~~~~~~~~~~~~~~~~~~

  今天回家写了个小例子测试内存泄漏,思路如下:在UIViewController的viewDidload中,向self.view添加一个自定义的专门泄漏的UIView(在初始化函数中开启一个线程不停的加载图片)。在我的iPhone4下运行程序后大概不到一分钟以后出现level 1 警告,然后过10秒左右报出level 2警告,再过5秒左右程序被退出。截图如下:

  这也证明前面说过的level 3的警告通常我们是接收不到的这个推断。

 

SvMemoryWarningViewController.m
复制代码
//
// SvMemoryWarningViewController.m
// SvMemoryWarning
//
// Created by maple on 3/9/12.
// Copyright (c) 2012 SmileEvday. All rights reserved.
//

#import "SvMemoryWarningViewController.h"
#import <libkern/OSMemoryNotification.h>
#import "SvLeakMemoryView.h"

@interface SvMemoryWarningViewController ()

@end

@implementation SvMemoryWarningViewController

- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.

SvLeakMemoryView *view = [[SvLeakMemoryView alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];
[self.view addSubview:view];
[view release];
}

- (void)viewDidUnload
{
[super viewDidUnload];
// Release any retained subviews of the main view.
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
return interfaceOrientation == UIInterfaceOrientationPortrait;
}

- (void)didReceiveMemoryWarning
{

NSLog(@"Recieve memory warning");
NSLog(@"~~~~~~~~~~~~~~level~~~~~~~~~~~~~~~ %d", (int)OSMemoryNotificationCurrentLevel());
}

@end
复制代码

 

SvLeakMemoryView.m
复制代码
#import "SvLeakMemoryView.h"
#import <QuartzCore/QuartzCore.h>

@implementation SvLeakMemoryView

- (id)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
// Initialization code

UIImageView *imageView = [[UIImageView alloc] initWithFrame:frame];

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"Car" ofType:@"jpg"];
imageView.image = [[UIImage alloc] initWithContentsOfFile:filePath];

imageView.layer.contentsGravity = kCAGravityResizeAspect;
[self addSubview:imageView];

NSString *filePath2 = [[NSBundle mainBundle] pathForResource:@"treeHighResolution" ofType:@"jpg"];
dispatch_queue_t loadImageQueue = dispatch_queue_create("load image", NULL);

__block UIImageView *testIV = [[UIImageView alloc] initWithFrame:CGRectMake(0, 0, 320, 480)];
dispatch_async(loadImageQueue, ^{
while (TRUE) {
UIImage *image = [[UIImage alloc] initWithContentsOfFile:filePath2];
testIV.image = image;
}
});
}
return self;
}
 
  
转自:http://blog.youkuaiyun.com/weiwangchao_/article/details/8110247
内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值