iOS前缀标题中单例的内存问题

时间:2011-08-02 15:47:49

标签: iphone xcode memory-management singleton prefix

我使用了很多单身人士,我设置了很多,因为我称之为“单身框架”。

另外,我喜欢在我的XCode项目的前缀头中编写单例的定义,所以我可以在每个类中只用一行代码来使用我的所有单例! 对我而言,这似乎是天堂,但我一直注意到我必须在我的所有应用程序中处理很多内存警告。所以我想知道,这与将我的单例定义放在前缀标题中有什么关系吗?对我来说,似乎因为单例只是一个实例,如果你把它放在前缀标题中,它根本不重要。 也许更多的事实是8个不同的单身人同时存在,每个人都有不同的物体?

以下是我的项目中常规前缀标题的示例:

//Imports
#import "Program.h"
#import "Category.h"
#import "GetSpecs.h"
#import "FlurryAPI.h"
#import "AdSmallView.h"
#import "SoundPlayer.h"
#import "ButtonAlert.h"
#import "NSViewHelper.h"
#import "NSDateHelper.h"
#import "NSStringHelper.h"
#import "TESTAppDelegate.h"
#import "EGORefreshTableHeaderView.h"

//Singletons
#define gSpecs [GetSpecs sharedGetSpecs]
#define bAlert [ButtonAlert sharedButtonAlert]
#define sPlayer [SoundPlayer sharedSoundPlayer]
#define adSmallV [AdSmallView sharedAdSmallView]
#define vHelper [NSViewHelper sharedNSViewHelper]
#define dateHelper [NSDateHelper sharedNSDateHelper]
#define nsprefs [NSUserDefaults standardUserDefaults]
#define strHelper [NSStringHelper sharedNSStringHelper]
#define pDel ((TESTAppDelegate *)[[UIApplication sharedApplication] delegate])

总而言之,我有两个问题: 1.将单例定义放在前缀标题中是不好的做法? 2.记忆问题是由这个前缀标题部分引起的,还是更可能是因为许多不同的单身人士一直“活着”?

2 个答案:

答案 0 :(得分:0)

因为这些是宏,所以无论何时使用它们,就像你实际输入[NSUserDefaults standardUserDefaults]或其他任何一个一样,所以不存在让更多单身人士活着的风险,因为前缀头实际上并没有创建单身人士。

我不会说这是不好的做法;我以前做过。但是,我可能会建议您将这些定义放在类标题中,例如将pDel放在TESTAppDelegate.h中,这样如果您#import TESTAppDelegate.h可以使用它。如果前缀标题中没有#import多个标题(因为将为每个文件导入这些标题),它可能会使您的程序编译更快。

答案 1 :(得分:0)

有趣的方法。在预编译的头文件中将#define作为{{1}}来实现并不是问题 - 这确实使它们在任何地方都可用,并且正如jtbandes所说,它们仅在使用时被调用,因此没有内存问题。

在风格上有点愚蠢,你实际上创造了全球性的“神奇”保留词,看起来它们可能是局部变量名。如果其他人正在阅读您的代码,那么他们并不是特别不言自明。如果这样做,我可能至少会用资本启动它们,或者让它们全部为大写,以表明它们是一个定义/宏。

将这么多应用程序标题放入预编译的标题(通常非常精简,并用于核心系统的东西)也有点不正统,但现代机器上编译时间的实际影响将完全可以忽略不计。


关于你为什么要创建单身人士和记忆警告的陈述让我觉得你可能还在学习编程。单身人士在面向对象的世界中是很好的方式来封装一个应该只存在一次的对象。如果您正在使用它们来避免“反复编写相同的代码”,那么您需要它的任何常规函数或方法也会起作用。对于“助手”,你应该查看“类别”,这可能会为你做一些提升。回复:8个不同的单身人士。在应用程序运行时,数以万计的对象同时共存,单例和其他方式。仅这一点不是问题 - 只要它们都被正确管理,它们就不会打扰彼此。