🚘 ⏏️ 👩‍⚕️ SwiftランタイムまたはNSObjectが消えた場所について少し 🛀 🚵🏼 📰

こんにちは友人！私はブラックボックスから突き出ている弦を引っ張るだけで退屈している人の1人です。フードの下でどのように機能するかを自分の目で見たいです。ランタイムについて説明します、はいランタイムです。私たちの経験では、Objective-Cの古き良き祖父と、まだ開発中の革新的なSwiftを検討してください。あなたと私は、Appleプログラマーが慎重に考え抜いた抽象化のほぼ底辺まで潜る必要があります。一般に新しい言語を開発する必要があった理由を少し見てみましょう。特に、すでに経験のあるObjective C開発者から、多くの否定的なレビューを聞いたことがありますが、新しいSwift言語をよく見ると、より成熟していて真剣です。最初に、彼はObjective Cの基礎となるCとは異なり、C ++で記述しました。ここでは、あなたが同意できる、非常に個人的な偏見のみを表現します。

私の意見では、現時点でのC ++は、あなたが好きなことを行うことができる最も深刻な開発言語ですが、Cよりもエレガントです。だからこそ、Swift言語、 LLDBなどを書くための基礎として選ばれたのは彼だったと思います。ここではSwift言語の機能を確認せずに、いくつかのポイントを強調します。他のすべては専門のドキュメントに記載されています。私の意見では、初心者プログラマーにとってははるかに機能的で簡単です。実際、これは開発の目標の1つであり、新しい開発者のエントリーしきい値を下げることです。特に簡潔なC＃またはJavaで書いた場合は特に、Objective-Cの括弧を初めて知った後、どのように髪を立てたかを覚えておいてください。もちろん、私の意見では、目立つためにプログラマーが思いついたのは洗練されていなかったわけではありません。しかし、これがすべての歌詞です。ビジネスに取り掛かりましょう。最初に、Objectice Cの祖父の基本クラスを分析し、Swiftと比較しましょう。

これをすべて知っている人のために、あなたはまだ煙のために出かけることができます。 Objective-Cで知っているように、クラスはNSObjectまたはNSProxyから間接的または直接継承する必要があります。 NSObjectクラスは、非公式プロトコルNSObjectを実装しています。 SwiftObjectを検討すると、それに戻ります。将来的には、将来的に2つの言語の友達を作るのに役立つのはこのプロトコルであると言えます。ここにそれがポリモーフィズムの力です！ NSObjectクラスのすべてのメソッドの一部を見ていきます。そしてその後、このすばらしいNSObjectの何が問題なのかを敢えて結論付けました。私は長い間あなたを苦しめません、彼らは運転しました！

@interface NSObject <NSObject> { Class isa OBJC_ISA_AVAILABILITY; } + (void)load; + (void)initialize; - (instancetype)init #if NS_ENFORCE_NSOBJECT_DESIGNATED_INITIALIZER NS_DESIGNATED_INITIALIZER #endif ; + (instancetype)new OBJC_SWIFT_UNAVAILABLE("use object initializers instead"); + (instancetype)allocWithZone:(struct _NSZone *)zone OBJC_SWIFT_UNAVAILABLE("use object initializers instead"); + (instancetype)alloc OBJC_SWIFT_UNAVAILABLE("use object initializers instead"); - (void)dealloc OBJC_SWIFT_UNAVAILABLE("use 'deinit' to define a de-initializer"); - (void)finalize; ....

最初の2つの方法は、通常のObjectice C開発者にはあまり出会わないため、ここでは詳しく説明しません。 loadメソッドは、クラスまたはカテゴリがランタイムにロードされるときに呼び出され、継承の古典的な規則に従わず、実行時にアプリケーションをブロックします。 初期化メソッドは、クラスを最初に使用する前に遅延モードで呼び出され、アプリケーションをブロックせず、継承の古典的な規則に従います。

後続のすべてのメソッドは、オブジェクトの作成と初期化を担当します。また、それらについても少し説明します。 allocWithZoneメソッドは、オブジェクトにメモリを割り当てる役割を果たします。内部では、彼は私たちの最愛のmallocを呼び出します。それは、メモリがゾーンに分割されたときのbeの時代からです。すべてのオブジェクトが1つのゾーンで作成されるようになったため、内部でallocWithZoneを呼び出してデフォルトのゾーンNSDefaultMallocZoneを渡すallocメソッドが登場しました 。

オブジェクトが削除されると、 deallocメソッドとfinalizeメソッドが呼び出されます。これらのメソッドでは、関連するすべてのリソースがクリアされ、その結果、空きメモリが空きメモリプールに入ります。通常、 ファイナライズは使用されず、最後のリリースが発生したスレッドでdeallocが呼び出されます 。

次の一連のメソッドに移動します

 - (id)copy; - (id)mutableCopy; + (id)copyWithZone:(struct _NSZone *)zone OBJC_ARC_UNAVAILABLE; + (id)mutableCopyWithZone:(struct _NSZone *)zone OBJC_ARC_UNAVAILABLE;

まあ、おそらくスポットライトで書いたことのない人にとっても、彼らがコピーのためだと推測するのは簡単です。ゾーンでは、すべてが明確であり、これらはもはや関係のない古代の方法です。実際、私たちから何かをコピーするには、 NSCopyingプロトコルを実装する必要があります。これらのメソッドを単純に呼び出すと、すべてが失敗します。ただし、これについては引き続き説明します。それまでの間、次のパックに進みます。

 + (BOOL)instancesRespondToSelector:(SEL)aSelector; + (BOOL)conformsToProtocol:(Protocol *)protocol; - (IMP)methodForSelector:(SEL)aSelector; + (IMP)instanceMethodForSelector:(SEL)aSelector; - (void)doesNotRecognizeSelector:(SEL)aSelector; + (NSMethodSignature *)instanceMethodSignatureForSelector:(SEL)aSelector OBJC_SWIFT_UNAVAILABLE(""); - (BOOL)allowsWeakReference UNAVAILABLE_ATTRIBUTE; - (BOOL)retainWeakReference UNAVAILABLE_ATTRIBUTE; + (BOOL)isSubclassOfClass:(Class)aClass; + (BOOL)resolveClassMethod:(SEL)sel OBJC_AVAILABLE(10.5, 2.0, 9.0, 1.0); + (BOOL)resolveInstanceMethod:(SEL)sel OBJC_AVAILABLE(10.5, 2.0, 9.0, 1.0); + (Class)superclass; + (Class)class OBJC_SWIFT_UNAVAILABLE("use 'aClass.self' instead");

ここでは、内省です。安全なコードの鍵は検索エンジンsiにあります。これらのメソッドにより、オブジェクトまたはクラス、実装するプロトコル、応答可能なセレクターなどを評価できます。進む

 - (id)forwardingTargetForSelector:(SEL)aSelector OBJC_AVAILABLE(10.5, 2.0, 9.0, 1.0); - (void)forwardInvocation:(NSInvocation *)anInvocation OBJC_SWIFT_UNAVAILABLE(""); - (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector OBJC_SWIFT_UNAVAILABLE("");

最初の2つのメソッドは、何も実装しないとすべてがクラッシュするまで呼び出されます。これは、オブジェクトがあなたがそれから何を望んでいるかを理解せず、それが持たないメソッドを呼び出すときに起こります。これを有意義に行う場合は、これらのメソッドの1つを決定し、セレクターへの呼び出し、送信先、いわば処理を決定するのに十分親切にしてください。これは、実際にはメッセージリダイレクトメカニズムと呼ばれます。これも読むことができ、たくさんの記事があり、3つの方法があります。これにこだわるつもりはありません。さもないと、この記事の本質を失います。

最新の方法を見てみましょう

 + (NSUInteger)hash; + (NSString *)description; + (NSString *)debugDescription;

私は誰もがハッシュメソッドを知っていると思う、それはオブジェクトの比較、コレクション内のネストによるオブジェクトの配布などに使用されるオブジェクトのあるアドレスだけでなく、何らかの意味のある情報をログで表示する場合は、 descriptionメソッドとdebugDescriptionメソッドを再定義する必要があります。

ふう、私はすでにこれらの方法を説明するのにうんざりしていました。このクラスを詳しく見てみましょう。ここでは、基本的に検索エンジンのすべてのクラスの先頭にあります。彼の何が問題なのですか？なぜ彼がそんなに好きじゃないの？はい、彼のすべてが間違っています！

私たちのOOP原則がそこに言うように：継承、カプセル化、ポリモーフィズム！しかし、何らかの理由で、1つのクラスからすべてを継承するとは言われていません。JavaとC＃の開発者を許してください。アーキテクチャを構築した経験のあるプログラマーは、当初は非常に考え抜かれていたアーキテクチャー決定のさまざまな落とし穴に遭遇したと思います。継承は時限爆弾のようなもので、最終的には思慮深いアーキテクチャをすべてゼロにするか、開発のために手を縛ります。建築に関する多くの本は、継承ではなく構成を選択すると述べています。これはより柔軟なアプローチですが、継承も処理するのに非常に強力です。つまり、抽象化を分離し、さらに拡張することは正しいことです。今後、Swiftはプログラマが利用できるこの基本クラスを失ったと言います。

実際、それはSwiftObjectと呼ばれ、Objective-Cと対話する必要があるすべてのクラス（Swiftで記述された）が継承されます。彼についてもっと話しましょう。多くの人がおそらく言うでしょう：この男は何ですか！継承はクールなことで、コードを再利用しますが、それは悪いことです。このトピックを別の記事に入れて、他のことについて話します。たとえば、何もコピーしたくないのに、なぜcopyメソッドが必要なのですか？それにもかかわらず、私はそれを呼び出すことができ、NSCopyingパンクを実装しない場合、それ自体ですべてが落ちます。継承について話しましょう。オブジェクトを初期化する場合に呼び出す必要があるinitメソッドがありますが、それ自体で呼び出されるdeallocメソッドがあります！オブジェクトのライフサイクルのメソッドであり、決して手動で呼び出す必要はありません。しかし、誰も私にこれをやめさせません、本当に素晴らしいですか？はい、それはまったく素晴らしいことではありません。 NSObjectクラス自体により、必要のないことを実行したり、必要のないことを知ることができます。このトピックをさらに発展させることはできますが、NSObjectがすべきではないことはすでに明らかであるため、プログラマーにとってはSwift言語に姿を消しました。正式にはもちろん、基本クラスはIOSプラットフォームのみに留まりましたが、お互いに仲良くするために、これら2つの言語：老人Objective-Cと野心的なSwiftです。彼を片目で見てみましょう。

 @implementation SwiftObject + (void)initialize {} + (instancetype)allocWithZone:(struct _NSZone *)zone { assert(zone == nullptr); return _allocHelper(self); } + (instancetype)alloc { // we do not support "placement new" or zones, // so there is no need to call allocWithZone return _allocHelper(self); } + (Class)class { return self; } - (Class)class { return (Class) _swift_getClassOfAllocated(self); } + (Class)superclass { return (Class) _swift_getSuperclass((const ClassMetadata*) self); } - (Class)superclass { return (Class) _swift_getSuperclass(_swift_getClassOfAllocated(self)); } + (BOOL)isMemberOfClass:(Class)cls { return cls == (Class) _swift_getClassOfAllocated(self); } - (BOOL)isMemberOfClass:(Class)cls { return cls == (Class) _swift_getClassOfAllocated(self); } - (instancetype)self { return self; } - (BOOL)isProxy { return NO; } - (struct _NSZone *)zone { auto zone = malloc_zone_from_ptr(self); return (struct _NSZone *)(zone ? zone : malloc_default_zone()); } - (void)doesNotRecognizeSelector: (SEL) sel { Class cls = (Class) _swift_getClassOfAllocated(self); fatalError(/* flags = */ 0, "Unrecognized selector %c[%s %s]\n", class_isMetaClass(cls) ? '+' : '-', class_getName(cls), sel_getName(sel)); } - (id)retain { auto SELF = reinterpret_cast<HeapObject *>(self); swift_retain(SELF); return self; } - (void)release { auto SELF = reinterpret_cast<HeapObject *>(self); swift_release(SELF); } - (id)autorelease { return _objc_rootAutorelease(self); } - (NSUInteger)retainCount { return swift::swift_retainCount(reinterpret_cast<HeapObject *>(self)); } - (BOOL)_isDeallocating { return swift_isDeallocating(reinterpret_cast<HeapObject *>(self)); } - (BOOL)_tryRetain { return swift_tryRetain(reinterpret_cast<HeapObject*>(self)) != nullptr; } - (BOOL)allowsWeakReference { return !swift_isDeallocating(reinterpret_cast<HeapObject *>(self)); } - (BOOL)retainWeakReference { return swift_tryRetain(reinterpret_cast<HeapObject*>(self)) != nullptr; } // Retaining the class object itself is a no-op. + (id)retain { return self; } + (void)release { /* empty */ } + (id)autorelease { return self; } + (NSUInteger)retainCount { return ULONG_MAX; } + (BOOL)_isDeallocating { return NO; } + (BOOL)_tryRetain { return YES; } + (BOOL)allowsWeakReference { return YES; } + (BOOL)retainWeakReference { return YES; } - (void)dealloc { swift_rootObjCDealloc(reinterpret_cast<HeapObject *>(self)); } - (BOOL)isKindOfClass:(Class)someClass { for (auto isa = _swift_getClassOfAllocated(self); isa != nullptr; isa = _swift_getSuperclass(isa)) if (isa == (const ClassMetadata*) someClass) return YES; return NO; } + (BOOL)isSubclassOfClass:(Class)someClass { for (auto isa = (const ClassMetadata*) self; isa != nullptr; isa = _swift_getSuperclass(isa)) if (isa == (const ClassMetadata*) someClass) return YES; return NO; } + (BOOL)respondsToSelector:(SEL)sel { if (!sel) return NO; return class_respondsToSelector((Class) _swift_getClassOfAllocated(self), sel); } - (BOOL)respondsToSelector:(SEL)sel { if (!sel) return NO; return class_respondsToSelector((Class) _swift_getClassOfAllocated(self), sel); } + (BOOL)instancesRespondToSelector:(SEL)sel { if (!sel) return NO; return class_respondsToSelector(self, sel); } - (BOOL)conformsToProtocol:(Protocol*)proto { if (!proto) return NO; auto selfClass = (Class) _swift_getClassOfAllocated(self); // Walk the superclass chain. while (selfClass) { if (class_conformsToProtocol(selfClass, proto)) return YES; selfClass = class_getSuperclass(selfClass); } return NO; } + (BOOL)conformsToProtocol:(Protocol*)proto { if (!proto) return NO; // Walk the superclass chain. Class selfClass = self; while (selfClass) { if (class_conformsToProtocol(selfClass, proto)) return YES; selfClass = class_getSuperclass(selfClass); } return NO; } - (NSUInteger)hash { return (NSUInteger)self; } - (BOOL)isEqual:(id)object { return self == object; } - (id)performSelector:(SEL)aSelector { return ((id(*)(id, SEL))objc_msgSend)(self, aSelector); } - (id)performSelector:(SEL)aSelector withObject:(id)object { return ((id(*)(id, SEL, id))objc_msgSend)(self, aSelector, object); } - (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2 { return ((id(*)(id, SEL, id, id))objc_msgSend)(self, aSelector, object1, object2); } - (NSString *)description { return _getDescription(self); } - (NSString *)debugDescription { return _getDescription(self); } + (NSString *)description { return _getClassDescription(self); } + (NSString *)debugDescription { return _getClassDescription(self); } - (NSString *)_copyDescription { // The NSObject version of this pushes an autoreleasepool in case -description // autoreleases, but we're OK with leaking things if we're at the top level // of the main thread with no autorelease pool. return [[self description] retain]; } - (CFTypeID)_cfTypeID { // Adopt the same CFTypeID as NSObject. static CFTypeID result; static dispatch_once_t predicate; dispatch_once_f(&predicate, &result, [](void *resultAddr) { id obj = [[NSObject alloc] init]; *(CFTypeID*)resultAddr = [obj _cfTypeID]; [obj release]; }); return result; } // Foundation collections expect these to be implemented. - (BOOL)isNSArray__ { return NO; } - (BOOL)isNSDictionary__ { return NO; } - (BOOL)isNSSet__ { return NO; } - (BOOL)isNSOrderedSet__ { return NO; } - (BOOL)isNSNumber__ { return NO; } - (BOOL)isNSData__ { return NO; } - (BOOL)isNSDate__ { return NO; } - (BOOL)isNSString__ { return NO; } - (BOOL)isNSValue__ { return NO; } @end

あれ！ご覧の内容ですが、SwiftObjectクラスは非公式プロトコルNSObjectを実装していますが、メソッドの実装はすでに完全に異なっています。 NSObjectから明示的に継承されていないすべてのSwiftクラスは、SwiftObjectクラスから暗黙的に継承されるようになりました。これは、Objectice Cとの対話を必要とするプラットフォームでのみ発生することをすぐに修正します。ObjectiveC以外のプラットフォーム（Linuxなど）では、これは必要ありません。

私たちが学んだように、これは別の話です。少し教えてもいいと思います。ご存知のように、SwiftはAppleリポジトリのパブリックドメインにあります。誰もそれをダウンロードしてソース自体からコンパイルすることを気にしません。これはまさに私たちがやったことです。しかし、私たちはもう少し進みました。バージョン8以降の有名なXcodeを使用すると、ツールチェーンを手に入れることができます。はい、それはどういう意味ですか？これは、デバッグ情報を使用してSwiftをアセンブルし、Xcodeに配置できることを意味します。

私の同僚はそれをやったので、SwiftソースをXcodeから直接デバッグできました。

私たちは少し気を散らされています、私たちは推論を続けます。 Objective-Cで生成されたメタデータとSwiftで生成されたメタデータの性質が異なることはすでに明らかです。 Objectice Cで長い間書いており、少なくとも少しランタイムを選択したプログラマーなら誰でもこの構造を知っている

 struct objc_class { Class isa OBJC_ISA_AVAILABILITY; #if !__OBJC2__ Class super_class OBJC2_UNAVAILABLE; const char *name OBJC2_UNAVAILABLE; long version OBJC2_UNAVAILABLE; long info OBJC2_UNAVAILABLE; long instance_size OBJC2_UNAVAILABLE; struct objc_ivar_list *ivars OBJC2_UNAVAILABLE; struct objc_method_list **methodLists OBJC2_UNAVAILABLE; struct objc_cache *cache OBJC2_UNAVAILABLE; struct objc_protocol_list *protocols OBJC2_UNAVAILABLE; #endif } OBJC2_UNAVAILABLE;

私たちは皆、すべてのオブジェクトが最終的に、ある程度この構造の形で見えることを知っています。私たちのお気に入りのNSObjectは、この構造と直接対話することからプログラマを保護する抽象化です。あなたはそれについてもっと読むことができます、ロシア語でさえ、言語の存在の間に書かれたたくさんの記事があります。 Swiftに戻りましょう。現在、メタデータを保存するための特別なクラスのメタデータが登場しました。これは非常に膨大で、Swiftのすべてのメタデータの基礎を構成します。別の記事でその構造の詳細を説明します。もう1つのポイントは、すべてのSwiftオブジェクトが独自のメタデータ構造を持っているにもかかわらず、互換性のためにさらに多くのObjective-Cメタデータを生成します。つまり、各Swiftオブジェクトには2セットのメタデータがあります。

少し要約しましょう。 NSObjectは見苦しいため、新しい言語で使用する場所がないことがわかりました。したがって、Swiftでは、何からも継承せずにクラスを作成できますが、実際には、互換性のために、SwiftObjectから継承します。 SwiftObjectクラスはフレンドになり、NSObjectクラスは非公式プロトコルNSObjectによって許可されました。これにより、Swiftオブジェクトをidにキャストし、Objective Cに渡すことができますが、そこで動作するのがいいので、各Swiftオブジェクトは、そのメタデータに加えて、Objective C.メタデータを生成します。みんなありがとう！健康と良い気分！

SwiftランタイムまたはNSObjectが消えた場所について少し

More articles: