将应用程序静态链接到我自己的自定义 obj-c 运行时有多简单？
我一直在研究运行时，并提出了 objc_allocateClassPair / objc_registerClassPair 的替代方案，可以生成匿名类。
匿名类对于我正在处理的事情来说非常方便，但我担心，因为它们依赖于运行时的不透明数据类型的实现方式（据我所知，运行时是一个共享库，可能会改变这些类型在操作系统版本之间的布局）这会带来麻烦。
更一般地说，运行时是开源的这一事实似乎为该语言开辟了一定的创造力潜力……
静态链接到我修改过的运行时而不是共享的运行时有多简单？我是否必须扰乱编译器，或者它更像是链接到任何其他库。
还对这可能如何影响 App Store 批准感兴趣。
I've been playing with the runtime and came up with an alternative to objc_allocateClassPair / objc_registerClassPair that produces anonymous classes.
Anonymous classes would be extremely handy for something I'm working on, but I'm worried that since they depend on the way that the runtime's opaque data types are implemented (and to my knowledge, the runtime is a shared library that may change the layout of these types between OS versions) it'd be asking for trouble.
More generally, the fact that the runtime is open source seems to open up a certain potential for creativity with the language...
How straightforward would it be to statically link to my modified runtime instead of the shared one? Would I have to mess with the compiler, or would it be more like linking to any other library.
Also interested in how this might affect App Store approval.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
很可能，这最终带来的麻烦超过了它的价值。当然，您不想替换系统框架正在使用的运行时。这不仅可能是不可能的（或者肯定非常困难），而且很可能会使您的应用程序速度慢得难以忍受，因为有许多优化只能在系统级别完成。
这样做可能需要大量的编译器和链接器恶作剧。你还会遇到边界问题；是一个调用站点，对您的代码的调用或对系统的调用（如果您尝试并行运行两个运行时——这可能是不可能的）。
您的评估绝对正确，依赖当前运行时中元数据的布局是不行的。在 Obj-C 2.0 过渡中，所有元数据都放在 API 后面，专门是为了允许元数据发生显着变化，而不会破坏[正确编写的]应用程序。
如果您确实想要为类中的某些功能子集使用新的/不同的运行时模型，那么最好尽可能地将其与系统运行时隔离。新的根类可能很有趣，但与框架类的任何混合都可能充满脆弱性。
Likely, it is ultimately more trouble than it is worth. Certainly, you don't want to replace the runtime being used by the system frameworks. Not only is it likely impossible (or certainly extremely hard), it is also quite likely going to make your app unbearably slow as there are numerous optimizations that can only be done at the system level.
Doing so would likely require significant compiler and linker shenanigans. You are also going to run into issues of boundaries; is a call site a call into your code or a call into the system (if you were to try to run two runtimes in parallel -- which is likely impossible).
You are definitely correct in the assessment that relying upon the layout of the metadata in the current runtime is a no-go. All of the metadata was put behind APIs in the Obj-C 2.0 transition specifically to allow for the metadata to change significantly without breaking [properly written] applications.
If you really want a new/different runtime model for some subset of functionality in your class, it is best to isolate that from the system runtime as much as possible. A new root class might be interesting, but any intermingling with framework classes is likely to be rife with fragility.