low-memory 处理思路

本文详细阐述了移动设备终端内存管理策略,包括低内存警告时的视图控制器资源释放方法,以及iOS5与iOS6版本的差异处理。通过设置IBOutlets为weak引用,实现资源的自动释放,确保应用在低内存环境下正常运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

移动设备终端的内存极为有限,应用程序必须做好low-memory处理工作,才能避免程序因内存使用过大而崩溃。

 

注意:iboutlet作为私有变量时,可以设置形如

__weak IBOutlet UILabel *twoLB;的即可实现释放效果,再次didload时,会重新链接相应控件。

low-memory 处理思路
通常一个应用程序会包含多个view controllers,当从view跳转到另一个view时,之前的view只是不可见状态,并不会立即被清理掉,而是保存在内存中,以便下一次的快速显现。但是如果应用程序接收到系统发出的low-memory warning,我们就不得不把当前不可见状态下的views清理掉,腾出更多的可使用内存;当前可见的view controller也要合理释放掉一些缓存数据,图片资源和一些不是正在使用的资源,以避免应用程序崩溃。

 

思路是这样,具体的实施根据系统版本不同而略有差异,本文将详细说明一下iOS 5与iOS 6的low-memory处理。


iOS 5 的处理
在iOS 6 之前,如果应用程序接收到了low-memory警告,当前不可见的view controllers会接收到viewDidUnload消息(也可以理解为自动调用viewDidUnload方法),所以我们需要在 viewDidUnload 方法中释放掉所有 outlets ,以及可再次创建的资源。当前可见的view controller 通过didReceiveMemoryWarning 合理释放资源,具体见代码注释。


举一个简单的例子,有这样一个view controller:
@interface MyViewController : UIViewController {  
    NSArray *dataArray;  
}  
@property (nonatomic, strong) IBOutlet UITableView *tableView;  
@end 


对应的处理则为:
#pragma mark -
#pragma mark Memory management


- (void)didReceiveMemoryWarning {
    // Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];
    
    // Relinquish ownership any cached data, images, etc that aren't in use.
}


- (void)viewDidUnload {
    // Relinquish ownership of anything that can be recreated in viewDidLoad or on demand.
    // For example: self.myOutlet = nil;
    self.tableView = nil;
    dataArray = nil;
    
    [super viewDidUnload];
}


iOS 6 的处理
iOS 6 废弃了viewDidUnload方法,这就意味着一切需要我们自己在didReceiveMemoryWarning中操作。
具体应该怎么做呢?


1.将 outlets 置为 weak
当view dealloc时,没有人握着任何一个指向subviews的强引用,那么subviews实例变量将会自动置空。

@property (nonatomic, weak) IBOutlet UITableView *tableView;

 

2.在didReceiveMemoryWarning中将缓存数据置空
#pragma mark -   
#pragma mark Memory management   
  
  
- (void)didReceiveMemoryWarning  
{  
    [super didReceiveMemoryWarning];  
    // Dispose of any resources that can be recreated.   
    dataArray = nil;  

不要忘记一点,每当tableview reload 的时候,需要判断一下 dataArray ,若为空则重新创建。


 注意:iboutlet作为私有变量时,可以设置形如

__weak IBOutlet UILabel *twoLB;的即可实现释放效果,再次didload时,会重新链接相应控件。


兼容iOS 5 与 iOS 6
好吧,重点来了,倘若希望程序兼容iOS 5 与 iOS 6怎么办呢? 这里有一个小技巧,我们需要对didReceiveMemoryWarning 做一些手脚:

#pragma mark -
#pragma mark Memory management


- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
    
    if ([self isViewLoaded] && self.view.window == nil) {
        self.view = nil;
    }
    
    dataArray = nil;
}


判断一下view是否是window的一部分,如果不是,那么可以放心的将self.view 置为空,以换取更多可用内存。


这样会是什么现象呢?假如,从view controller A 跳转到 view controller B ,然后模拟low-memory警告,此时,view controller A 将会执行self.view = nil ; 当我们从 B 退回 A 时, A 会重新调用一次 viewDidLoad ,此时数据全部重新创建,简单兼容无压力~~


Note:
如果你好奇Apple为什么废弃viewDidUnload,可以看看Apple 的解释:
Apple deprecated viewDidUnload for a good reason. The memory savings from setting a few outlets to nil just weren’t worth it and added a lot of complexity for little benefit. For iOS 6+ apps, you can simply forget about view unloading and only implement didReceiveMemoryWarning if the view controller can let go of cached data that you can recreate on demand later.

<think>好的,我现在需要回答用户关于“lowmemorykiller后面接着NativeWatchCall”的问题。首先,我得确认用户提到的这两个术语分别是什么,以及它们之间的关联。 首先,lowmemorykiller。我记得在Android系统中,内存管理是一个重要的部分,特别是当系统内存不足时,需要一种机制来终止不必要的进程以释放内存LowMemoryKiller(LMK)应该就是负责这个任务的模块。它通过监控系统的内存使用情况,根据进程的优先级(oom_adj值)来决定哪些进程应该被终止。比如,前台应用的优先级高,不会被轻易杀掉,而后台进程可能更容易被终止。 接下来是NativeWatchCall。这个术语我不太熟悉,可能需要进一步确认。可能是指Android系统中的某个本地(Native)层的监控或回调机制。可能和Watchdog(看门狗)相关,用来监控系统服务是否响应,防止系统死锁或服务无响应的情况。当某个服务长时间没有响应时,Watchdog会触发相应的处理机制,比如杀死相关进程或重启系统。 现在,用户提到的是lowmemorykiller后面接着NativeWatchCall,可能是在日志或调试信息中看到的这两个事件接连发生的情况。我需要分析这种情况的可能原因和含义。 可能的情况是,当系统内存不足时,LowMemoryKiller被触发,杀死了某个进程以释放内存。而随后,NativeWatchCall可能检测到某个系统服务因为进程被终止而无法响应,从而触发相关处理。例如,某个关键服务进程被LMK杀死,导致系统服务无法正常工作,NativeWatchCall检测到超时,记录日志或采取恢复措施。 接下来,我需要验证这个思路是否正确。查阅相关资料,LowMemoryKiller确实是Android内存管理的一部分,负责在内存不足时终止进程。而Watchdog在Android系统中确实存在,用于监控系统服务的健康状态。当服务长时间没有响应时,Watchdog会记录错误或重启系统。 那么,当LMK杀死了一个重要的系统服务进程,可能导致该服务无法响应Watchdog的检查,从而触发NativeWatchCall的相关日志或处理。这种情况下,用户可能在日志中看到这两个事件连续出现,表明系统在内存压力下杀死了进程,进而导致服务异常。 不过,也有可能NativeWatchCall是另一个机制,比如与应用层面的监控相关,比如某个Native层的监控调用,用于追踪资源使用情况或其他性能指标。需要进一步确认NativeWatchCall的具体定义和上下文。 如果用户是在分析系统日志时遇到这两个条目,可能需要检查具体的日志内容、时间戳以及相关进程的信息,以确定它们之间的因果关系。例如,LMK杀死进程后,NativeWatchCall可能是在报告该进程终止后的资源释放情况,或者是在尝试恢复服务时触发的操作。 此外,还需要考虑系统版本和定制ROM的影响,不同厂商可能对Android系统进行定制,添加特定的监控或日志机制,导致NativeWatchCall的具体行为有所不同。 总结来说,可能的解释是:当系统内存不足触发LowMemoryKiller终止进程后,Native层的监控机制(如Watchdog)检测到相关服务异常,从而记录NativeWatchCall事件。这反映了系统在内存压力下的自我修复或错误处理机制。用户需要进一步检查日志的上下文和具体进程信息,以确定具体原因和影响。</think>在Android系统中,`lowmemorykiller`和`NativeWatchCall`的关联通常与内存管理及系统监控机制相关。以下是逐步分析: --- ### **1. LowMemoryKiller 的作用** - **功能**:Android系统的`lowmemorykiller`(LMK)负责在内存不足时终止低优先级的进程以释放内存- **优先级规则**: - 进程按`oom_adj`值划分优先级(值越高越容易被终止)。 - 前台应用(如用户正在操作的APP)优先级最低(`oom_adj`值小),后台进程优先级高(`oom_adj`值大)。 - **触发条件**:当系统可用内存低于特定阈值时,LMK会按优先级从高到低终止进程。 --- ### **2. NativeWatchCall 的潜在含义** - **可能场景**: 1. **Watchdog 机制**:Android的`Watchdog`(看门狗)监控系统服务的响应情况。若某个服务长时间未响应,会触发重启或记录错误。 2. **Native 层监控**:`NativeWatchCall`可能是厂商定制的本地层监控工具,用于追踪资源使用(如内存、CPU)或服务健康状态。 - **关联现象**:若LMK终止了关键服务进程,可能导致依赖该服务的组件无响应,进而触发`NativeWatchCall`记录异常。 --- ### **3. 两者连续出现的典型原因** 1. **内存压力引发连锁反应**: - **步骤1**:系统内存不足 → LMK杀死某进程释放内存- **步骤2**:被终止的进程可能是某系统服务(如`SurfaceFlinger`、`MediaServer`),其异常终止导致依赖它的组件无法工作。 - **步骤3**:`NativeWatchCall`检测到服务无响应,记录日志或尝试恢复。 2. **日志中的表现**: ```log lowmemorykiller: Kill 'com.example.app' (adj 900) NativeWatchCall: Service X timeout, restarting... ``` --- ### **4. 排查与解决方法** - **检查日志上下文**: - 确认被LMK终止的进程名称及其重要性。 - 查看`NativeWatchCall`的具体错误描述(如服务名称、超时时间)。 - **优化内存使用**: - 减少后台进程数量。 - 检查内存泄漏(如通过`Android Profiler`)。 - **调整LMK阈值**(需Root权限): ```shell # 修改/sys/module/lowmemorykiller/parameters/minfree中的阈值 echo "1536,2048,4096,5120,5632,6144" > /sys/module/lowmemorykiller/parameters/minfree ``` --- ### **5. 厂商定制的可能性** 部分设备厂商会增强监控机制,例如: - 添加更细粒度的内存事件追踪。 - 自定义Watchdog策略(如延长超时时间或增加恢复逻辑)。 若问题频繁出现,建议联系设备厂商或查看官方文档以获取针对性解决方案。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值