在 Objective C 中使用类方法的缺点
我想知道使用类方法是否有任何内存/性能缺点，或者只是一般的缺点：
+ (void)myClassMethod:(NSString *)param {
// much to be done...
}
或者
+ (NSArray*)myClassMethod:(NSString *)param {
// much to be done...
return [NSArray autorelease];
}
在类方法中放置很多功能很方便，特别是在我必须处理内存管理的环境中（ iPhone），但是当有什么方便的时候通常会有一个问题？
一个示例可以是一个构思的 Web 服务，它由许多功能非常简单的类组成。即，
TomorrowsXMLResults;
TodaysXMLResults;
YesterdaysXMLResults;
MondaysXMLResults;
TuesdaysXMLResults;
.
.
.
n
我在 Web 服务类中收集了大量此类内容，然后实例化 Web 服务类，并让该类上的方法调用“结果”类上的类方法。课程 很简单，但它们处理大量的 Xml、实例化大量对象等。
我想我是在问类方法是否存在于堆栈和内存中，或者在堆栈和内存中的处理方式是否与实例化对象的消息不同？
或者它们只是在幕后实例化并再次下拉，因此只是节省几行代码的一种方法？
I was wondering if there are any memory/performance drawbacks, or just drawbacks in general, with using Class Methods like:
+ (void)myClassMethod:(NSString *)param {
// much to be done...
}
or
+ (NSArray*)myClassMethod:(NSString *)param {
// much to be done...
return [NSArray autorelease];
}
It is convenient placing a lot of functionality in Class Methods, especially in an environment where I have to deal with memory management(iPhone), but there is usually a catch when something is convenient?
An example could be a thought up Web Service that consisted of a lot of classes with very simple functionality. i.e.
TomorrowsXMLResults;
TodaysXMLResults;
YesterdaysXMLResults;
MondaysXMLResults;
TuesdaysXMLResults;
.
.
.
n
I collect a ton of these in my Web Service Class and just instantiate the web service class and let methods on this class call Class Methods on the 'Results' Classes. The classes
are simple but they handle large amount of Xml, instantiate lots of objects etc.
I guess I am asking if Class Methods lives or are treated different on the stack and in memory than messages to instantiated objects?
Or are they just instantiated and pulled down again behind the scenes and thus, just a way of saving a few lines of code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短的回答：没有缺点 - 按预期使用
长的回答：objective-c 中的类实际上是对象，您可以像其他任何东西一样使用它（检查 -[NSObject class] 的返回类型 - 指向 obj-c 对象的指针） 。当你调用 [yourclass alloc] 时，你实际上是在向 yourclass 发送一条消息，它是一个向运行时描述类的对象。 （该方法本身是 malloc() 的一堆包装器，因此并不涉及任何魔法。）就如何处理这些对象而言，objc 中的所有对象（包括类）都分配在堆，所以堆栈不起作用。编辑：需要明确的是，使用类方法与实例方法没有区别，只是使用类方法不需要拥有该类的实例。
要进一步了解这些类对象的实现方式，我建议 http: //www.sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html
Short answer: no downside - use as expected
Long answer: Classes in objective-c are actually objects, that you can use like anything else (check the return type of -[NSObject class] -- a pointer to an obj-c object). When you call [yourclass alloc], you're actually sending a message to yourclass, which is an object describing the class to the runtime. (the method itself is a bunch of wrappers around malloc(), so there's not exactly any magic involved.) As far as how these objects are handled, ALL objects in objc, including classes, are allocated in the heap, so the stack plays no part. EDIT: Just to be clear, there is no difference in using a class method as opposed to an instance method, except that with a class method you do not need to have an instance of the class.
for further reading on how these class objects are implemented, I recommend http://www.sealiesoftware.com/blog/archive/2009/04/14/objc_explain_Classes_and_metaclasses.html
根据我的经验，类方法或我定义的静态函数都有特定的用途。其中之一可以是性能，但前提是它们很小并且不处理大量数据。 （即 NSString stringWithString）。如果您正在处理大量数据，您可能知道，您的性能影响在于处理数据，而不是对象的实例化。坚持专注于处理耗时的任务，而不是创建对象来处理任务的开销。
具体答案：类方法在加载时加载，并且始终可供您的应用程序使用，与您描述的大量工作相比，通过类实例化加载它们的代码开销是最小的。 （无论如何它们很可能会被缓存）
In my experience, class methods, or in my definition static functions, serve specific purposes. One of them CAN be performance, but only if they are small and not dealing with a lot of data. (i.e. NSString stringWithString). If you are dealing with a lot of data, your performance hit, as you are probably aware, is in dealing with the data, not the instantiation of an object. Stick with focusing on the dealing with the time consuming task as opposed to the overhead of creating objects to handle the task.
SPECIFIC ANSWER: Class Methods are loaded at load time, and are always available to your application, the code overhead for loading them via a class instantiation is minimal compared to the large amount of work you describe. (They will most likely be cached anyway)