SwiftにおけるARC: 基礎とその先

SwiftにおけるARC: 基礎とその先

SwiftにおけるオブジェクトのライフタイムとARCの基本について確認しましょう。どのような言語機能がオブジェクトのライフタイムを観測可能にするのか、観測されたオブジェクトのライフタイムに依存した結果と、それを修正する安全なテクニックについて深く掘り下げます。

リソース
- ARC - The Swift Programming Language
- - HDビデオ
  - SDビデオ
ダウンロード

♪ （SwiftにおけるARC: 基礎とその先）こんにちは私の名前はMeghanaです今日はSwiftのARCについてお話します Swiftは構造体や列挙型などの強力な値型を提供します参照型が付属していて意図しない共有の危険を回避するため可能な場合は値型を使用することをお勧めしますクラスはSwiftの参照型でありあなたがそれらを使用することにした場合 Swiftは自動参照カウントかARCを介して管理します効果的なSwiftを書くために ARCがどのように機能するかを理解することが重要ですこのセッションではまさにそれを行いますオブジェクトの存続期間とSwiftのARCのレビューから始めます次に観測可能なオブジェクトの存続期間について説明します以下について詳しく説明していきますオブジェクトの存続期間を観察可能にする言語機能は何か観察されたオブジェクトの存続期間に依存することの結果そしてそれらを修正するためのいくつかの安全なテクニックですさぁ始めましょう Swiftでのオブジェクトの存続期間は初期化から始まりますそして最後の使用で終了します存続期間が終了した後にオブジェクトの割り当てを解除することでARCは自動的にメモリを管理しますその参照カウントを追跡することによってオブジェクトの存続期間を決定します ARCは主に保持および解放操作を挿入する Swiftコンパイラによって駆動されます実行時に保持は参照カウントを１つ加算させそしてリリースはそれを１つ減算させます参照カウントがゼロに下がるとオブジェクトの割り当てが解除されます例を使ってどのように機能するかを見てみましょう旅行Appを作成したいとします旅行者を表すために名前を付けやオプションの目的地プロパティでクラスを作成しましょう test（）関数ではまずTravelerオブジェクトが作成されます次にの参照がコピーされますそして最後にその目的地が更新されます自動的に管理するために Travelerオブジェクトのメモリ Swiftコンパイラは保持操作を挿入します参照が開始されリリース操作が行われたとき参照を最後に使用した後です traveller１はTravelerオブジェクトへの最初の参照ですそしてその最後の用途はコピーです traveller１参照を最後に使用した直後ここで swiftコンパイラはリリース操作を挿入します参照が始まると保持操作は挿入されません初期化によって参照カウントが１に設定されるためです traveller２はTraveler オブジェクトへの別の参照で最後に使用するのは目的地の更新です参照が開始されリリース操作が行われたとき参照を最後に使用した直後ここでSwiftコンパイラは保持操作を挿入しますコードをステップスルーし実行時に何が起こるかを見てみましょうまずTravelerオブジェクトがヒープ上に作成され参照カウント１で初期化されます次に新しいリファレンスの準備として保持操作が実行され参照カウントを２に１つ加算されます今や traveler2もTraveler オブジェクトの参照になります traveller1リファレンスを最後に使用した後リリース操作が実行され参照カウントを１に１つ減算されます次にTravelerオブジェクトの目的地 BigSurに更新されますそれがtraveler２リファレンスの最後の使用だったのでリリース操作が実行され参照カウントをゼロに１つ減算します参照カウントがゼロに下がるとオブジェクトの割り当てを解除できます Swiftのオブジェクトの有効期間は使用ベースですオブジェクトの保証された最小の存続期間は初期化で始まり最後の使用で終わりますこれはC ++などの言語とは異なり closing braceでオブジェクトの存続期間が終了することが保証されていますこの例では最後に使用した直後オブジェクトの割り当てが解除されていることがわかりましたただ実際にはオブジェクトの存続期間は保持および解放操作によって決定され Swiftコンパイラによって挿入されますそして開始するARC最適化に応じて観測されたオブジェクトの存続期間は保証された最小値で異なる場合がありますオブジェクトの最後の使用を超えて終了しますこのような場合オブジェクトはプログラムポイントでその最後の使用を超えて割り当て解除されますほとんどの場合オブジェクトの正確な存続期間は何かそれは本当の問題ではありませんただし弱い参照や所有されていない参照や初期化解除の予想外の結果などの言語機能を使用する場合オブジェクトの存続期間を観察することが可能ですそしてあなたがプログラムを持っているなら保証されたオブジェクトの存続期間の代わりに観測されたオブジェクトの存続期間に依存し将来的に問題が発生する可能性があります観測されたオブジェクトの存続期間に依存しているため今日はうまくいくかもしれませんがそれは偶然です観測されたオブジェクトの存続期間はSwiftコンパイラの緊急のプロパティです実装の詳細が変更されたとき変更することができますこのようなバグは開発中に発見されない場合があり長い間隠されたままになる可能性がありますが ARCの最適化が改善されたコンパイラのアップデートや関連性のないソースの変更によって以前は制限されていた ARCの最適化が可能になることが明らかになりますオブジェクトの存続期間を観測可能にする言語機能を説明し観測されたオブジェクトの寿命だけに頼るとどのようなことが起こるかを説明しそれを解決するための安全なテクニックを紹介します強い参照であるデフォルトの参照とは異なり弱い参照や所有していない参照は参照カウントに参加しませんそのため一般的には参照サイクルを壊すために使用されます詳細に入る前に参照サイクルとは何かを見てみましょうこれは私たちの旅行Appの拡張ですオプションのポイント制を導入したいと思います旅行者はアカウントを持ってポイントを貯めることができますこれを表すためにポイントプロパティ付きの新しいアカウントクラスがあります AccountクラスはTraveler クラスを指しますまたTravelerクラスは Accountクラスを参照しますテスト関数はTravelerオブジェクトと Accountオブジェクトを作成し次に旅行者の参照を介して printSummary（）関数を呼び出しますコードをステップスルーして ARCで何が起こるかを見ましょうまずTravelerオブジェクトがヒープ上に作成されます参照カウントは１です次にアカウントオブジェクトが参照カウントは１でヒープ上に作成されます AccountオブジェクトはTraveler オブジェクトを参照しているため Travelerオブジェクト参照カウントが２に１つ加算されますこれでTravelerオブジェクトは Accountオブジェクトの参照を開始し Accountオブジェクトの参照カウントはまた２に１つ加算されますこれはアカウント参照の最後の使用ですこの後アカウント参照はなくなりますアカウントオブジェクトの参照カウントは１に１つ減算されます次に名前とポイントを印刷するrintSummary（）関数が呼び出されますこれはTravelerリファレンスの最後の使用法ですこの後Travelerリファレンスは消えおよびTravelerオブジェクトの参照カウントは１に１つ減算されますオブジェクトを到達可能にするすべての参照の後で消えてもオブジェクトの参照カウントは１のままでこれは基準サイクルによるものですその結果オブジェクトの割り当てが解除されることはなくメモリリークを引き起こします弱い参照または所有されていない参照で基準サイクルを壊す可能性がありますそれらは参照カウントに参加していないので弱い参照または所有されていない参照が使用されている間参照されたオブジェクトの割り当ての解除の場合がありますこれが起こるときSwiftランタイムは弱参照へのアクセスをnilとしておよびトラップとして所有されていない参照へアクセスを安全に切り替えます参照サイクルに参加している参照は参照サイクルを中断するため弱いまたは所有されていないものとしてマークすることができます Appによって異なりますこの例では旅行者の参照に Accountクラスでは弱いものとしてマークを付けましょう弱参照が参加しないため参照カウントでは Travelerオブジェクトを最後に使用した後その参照カウントはゼロになります Travelerオブジェクトの参照カウントがゼロになると割り当てを解除できます Travelerオブジェクトがなくなると Accountオブジェクトへの参照がなくなり参照カウントをゼロにしますこれでAccountオブジェクトの割り当てを解除できますこの例では弱参照を使用しました基準サイクルを壊すだけです保証されているオブジェクトの存続期間が終了しているときに弱い参照を使ってオブジェクトにアクセスした場合そのオブジェクトが利用できるかどうかを観測されたオブジェクトの存続期間に依存していると将来観測されたオブジェクトの存続期間が無関係な理由で変更されたときにバグが発生する可能性があります例を見てみましょうここでprintSummary（）関数は TravelerクラスからAccountクラスに移動されますそしてtest（）関数は printSummary（）関数をアカウント参照を介して呼び出すようになりました printSummary（）関数が呼び出されたとき正確に何が起こるでしょう？今日は旅行者の名前とポイントが印刷される場合がありますがしかしこれは単なる偶然ですこれはTravelerオブジェクトが最後に使用されたためで printSummary（）関数を呼び出す前ですこの後Travelerオブジェクトの参照カウントがコンパイラがリリースを挿入した場合最後に使用した直後ゼロに低下する可能性があります参照カウントがゼロに低下した場合弱参照を介したTraveler オブジェクトへのアクセスがゼロになりまた Travelerオブジェクトの割り当てが解除される場合がありますしたがってprintSummary（）関数が呼び出されると弱いTraveler参照の強制アンラップはトラップしクラッシュを引き起こしますあなたは疑問に思うかもしれませんフォースアンラップがここでのクラッシュの理由である場合オプションのバインディングがそれを妨げている可能性がありますオプションのバインディングは実際に問題を悪化させます明らかなクラッシュがなければサイレントバグが発生します無関係な理由で観測されたオブジェクトの存続期間が変わると気付かない可能性があります弱くて所有権のない参照を安全に処理するためにはさまざまな技術がありますそれぞれの技術には導入時のコストと継続的なメンテナンスのコストがあります私たちの例でそれらを一つずつ調べてみましょう SwiftはwithExtendedLifetime （）ユーティリティの提供でオブジェクトの寿命を明示的に延長できます withExtendedLifetime （）を使用すると Travelerオブジェクトの存続期間を安全に延長するには printSummary（）関数が呼び出されている間潜在的なバグを防ぎます空の呼び出しをかけることでも同じ効果が得られます既存のスコープの最後に withExtendedLifetime（）を追加しますより複雑なケースについてはオブジェクトの存続期間を延ばし deferを使用して現在のスコープの最後までコンパイラに問い合わせることができます withExtendedLifetime()はオブジェクトの存続期間のバグを回避する簡単な方法のように見えますただしこの手法は壊れやすく正しさの責任があなたに移りますこのアプローチでは弱い参照がバグを引き起こす可能性があるたびに withExtendedLifetime（）の使用を確認する必要があります制御されていない場合 withExtendedLifetime（）はコードベース至る所に忍び寄りメンテナンスコストの増加させますより優れたAPIを使用したクラスの再設計はるかに理にかなったアプローチです強い参照のみにオブジェクトへのアクセスを制限できる場合オブジェクトの存続期間の不意打ちを防ぐことができますここではトラベラークラスへ printSummary（）関数が元に戻され Accountクラスの弱参照は非表示になっていますテストは強力な参照を介して printSummary（）関数を呼び出すように強制されるようになり潜在的なバグを排除しますパフォーマンスコストを負担することに加えてクラスの設計に注意しない場合弱くて所有されていない参照はバグを公開する可能性があります一時停止して考えることが重要ですなぜ弱くて所有されていない参照が必要なのか？それらは参照サイクルを中断するためにのみ使用されますか？そもそも参照サイクルの作成を回避した場合はどうなりますか？参照サイクルはアルゴリズムを再考やツリーの構造への循環クラス関係の変換で回避できることがよくありますこの例ではトラベラークラスはアカウントクラスを参照する必要があります Accountクラスには実際には必要ありません Travelerクラスを参照しますアカウントクラスは旅行者の個人情報にアクセスのみが必要です PersonalInfoと呼ばれる新しいクラスに旅行者の個人情報を移動できますトラベラークラスとアカウントクラスの両方が参照できますサイクルを回避して PersonalInfoクラスに追加します弱い参照や所有されていない参照の必要性を回避することは追加の実装コストがかかる場合がありますがしかしこれは明確な方法ですすべての潜在的なオブジェクトの存続期間のバグを排除しますオブジェクトの存続期間が観察可能になる別の言語機能 deinitializerの副作用です deinitializerは割り当て解除の前に実行され外部プログラムの効果によりその副作用を観察することができます deinitializerの副作用と外部プログラムの効果を連続させるようにコードを書くと隠れたバグが発生する可能性があり観測されたオブジェクトの存続期間が無関係な理由で変化したときに初めて発見されることになりますこのようなバグがどのように発生するかを説明する前に deinitializer とは何かを見てみましょうこれは deinitializerを使用した最初の例の繰り返しです deinitializerにはグローバルな副作用がありコンソールにメッセージを印字します今日「Donetraveling」が印字された後に deinitializerが実行される可能性があります Travelerオブジェクトを最後に使用してからとは目的地の更新であり開始する ARC最適化によって異なりますが「Donetraveling」が印字される前に deinitializer を実行できますこの例では deinitializer の副作用は観察可能でしたが信頼されていませんでしたより複雑な例を見てみましょう deinitializer の副作用が外部プログラムの効果により依存している場合ですここでTravelerクラスに旅行メトリックを導入します行き先が更新されるたびに TravelMetricsクラスに記録されます最終的にTravelerオブジェクトを非初期化するとメトリックはグローバルレコードに公開されます公開されているメトリックは旅行者の匿名IDと調べた行き先の数そして計算された旅行の関心カテゴリです test（）関数ではまずTravelerオブジェクトが作成されます次にtravelMetricsを参照し Travelerオブジェクトからコピーされます旅行者の目的地がBig Surに更新されこれはTravelMetricsに Big Surを記録します旅行者の目的地がカタリナに更新されカタリナをTravelMetricsに記録します次に記録された目的地を見ることで旅行の関心カテゴリが計算されます今日旅行の関心を計算した後 deinitializerが実行される可能性があります関心のあるカテゴリを Natureとして公開しますしかしTravelerオブジェクトの最後の使用はカタリナへの宛先アップデートで直後にデイニシャライザーを実行できます deinitializer が実行されるため旅行の関心を計算する前にnilが公開されますバグを引き起こします弱くて所有されていない参照のように deinitializer の副作用を安全に処理するさまざまなテクニックがありますそれぞれの先行実装コストの程度対継続的なメンテナンスコストの程度はさまざまですそれらを一つずつ見ていきましょう Travelerオブジェクトの有効期間を旅行の関心カテゴリが計算されるまで明示的に延長するため withExtendedLifetime（）を使用でき潜在的なバグを防ぎます前に説明したようにこのアプローチではあなたに正しさの責任を移し deinitializerの副作用とおよび外部プログラムの影響間の誤った相互作用でメンテナンスコストが増加する可能性があるたびに使用される withExtendedLifetimeを確認する必要があります効果がすべて局所的である場合 deinitializerの副作用は観察できません内部クラスの詳細把握で可視性を制限するクラスAPIの再設計はオブジェクトの存続期間のバグを防ぐことができますここでTravelMetricsは外部アクセスから隠されたプライベートとしてマークされています deinitializerが最も関心のある旅行カテゴリを計算するようになりメトリックを公開しますこれは機能しますがより理にかなったアプローチは deinitializerの副作用のすべてを取り除くことですここではdeinitializerの代わりにメトリックを公開するには deferが使用されて deinitializerは検証のみを実行しますデイニシャライザーの副作用を取り除くことによりオブジェクトの存続期間に関する潜在的なバグをすべて排除できます教育的な旅行Appの例で ARCと弱い参照と所有されていない参照およびdeinitializerの副作用について学びましたオブジェクトの存続期間を観察可能にする言語機能を完全に理解することが重要です潜在的に誤った観測されたオブジェクトの存続期間についての依存を排除し意外な時にバグを発見しないようにします xcode 13では「オブジェクトの寿命の最適化」と呼ばれる新しい実験的なビルド設定が Swiftコンパイラで利用できますこれにより強力な存続期間短縮ARC最適化が可能になりますこのビルド設定をオンにするとオブジェクトの割り当ての解除が見える場合があります最後の使用直後ははるかに一貫して観測されたオブジェクトの保証された最小値に近い存続期間をもたらしますこれで隠しオブジェクト存続期間のバグが明らかになる可能性があり説明した例と同様ですあなたは安全なテクニックに従うことができますこのセッションではこれらのバグをすべて排除するために説明しましたこのセッションを楽しんでいただけたでしょうか見てくれてありがとう ♪

class Traveler {
    var name: String
    var destination: String?
}

func test() {
    let traveler1 = Traveler(name: "Lily")
    let traveler2 = traveler1
    traveler2.destination = "Big Sur"
    print("Done traveling")
}

6:37 - Reference Cycle Example

class Traveler {
    var name: String
    var account: Account?
    func printSummary() {
        if let account = account {
            print("\(name) has \(account.points) points")
        }
    }
}

class Account {
    var traveler: Traveler
    var points: Int
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    traveler.printSummary()
}

9:05 - Weak Reference Example

class Traveler {
    var name: String
    var account: Account?
    func printSummary() {
        if let account = account {
            print("\(name) has \(account.points) points")
        }
    }
}

class Account {
    weak var traveler: Traveler?
    var points: Int
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    traveler.printSummary()
}

10:05 - Accessing an object via weak reference

class Traveler {
    var name: String
    var account: Account?
}

class Account {
    weak var traveler: Traveler?
    var points: Int
    func printSummary() {
        print("\(traveler!.name) has \(points) points")
    }
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    account.printSummary()
}

11:14 - Accessing an object via optional binding of weak reference

class Traveler {
    var name: String
    var account: Account?
}

class Account {
    weak var traveler: Traveler?
    var points: Int
    func printSummary() {
         if let traveler = traveler {
            print("\(traveler.name) has \(points) points") 
         }
    }
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    account.printSummary()
}

11:45 - Safe techniques for handling weak references - withExtendedLifetime()

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    withExtendedLifetime(traveler) {
        account.printSummary()
    }
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    account.printSummary()
    withExtendedLifetime(traveler) {}
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    defer {withExtendedLifetime(traveler) {}}
    traveler.account = account
    account.printSummary()
}

12:55 - Safe techniques for handling weak references - Redesign to access via strong reference

class Traveler {
    var name: String
    var account: Account?
    func printSummary() {
        if let account = account {
            print("\(name) has \(account.points) points")
        }
    }
}

class Account {
    private weak var traveler: Traveler?
    var points: Int
}

func test() {
    let traveler = Traveler(name: "Lily")
    let account = Account(traveler: traveler, points: 1000)
    traveler.account = account
    traveler.printSummary()
}

14:20 - Safe techniques for handling weak references - Redesign to avoid weak/unowned reference

class PersonalInfo {
    var name: String
}

class Traveler {
    var info: PersonalInfo
    var account: Account?
}

class Account {
    var info: PersonalInfo
    var points: Int
}

15:23 - Deinitializer Example

class Traveler {
  var name: String
  var destination: String?
  deinit {
    print("\(name) is deinitializing")
  }
}

func test() {
    let traveler1 = Traveler(name: "Lily")
    let traveler2 = traveler1
    traveler2.destination = "Big Sur"
    print("Done traveling")
}

16:10 - Sequencing deinitializer side-effects with external program effects

class Traveler {
    var name: String
    var id: UInt
    var destination: String?
    var travelMetrics: TravelMetrics
    // Update destination and record travelMetrics
    func updateDestination(_ destination: String) {
        self.destination = destination
        travelMetrics.destinations.append(self.destination)
    }
    // Publish computed metrics
    deinit {
        travelMetrics.publish()
    }
}

class TravelMetrics {
    let id: UInt
    var destinations = [String]()
    var category: String?
    // Finds the most interested travel category based on recorded destinations
    func computeTravelInterest()
    // Publishes id, destinations.count and travel interest category
    func publish()
}

func test() {
    let traveler = Traveler(name: "Lily", id: 1)
    let metrics = traveler.travelMetrics
    ...
    traveler.updateDestination("Big Sur")
    ...
    traveler.updateDestination("Catalina")
    metrics.computeTravelInterest()
}

verifyGlobalTravelMetrics()

17:56 - Safe techniques for handing deinitalizer side effects - withExtendedLifetime()

func test() {
    let traveler = Traveler(name: "Lily", id: 1)
    let metrics = traveler.travelMetrics
    ...
    traveler.updateDestination("Big Sur")
    ...
    traveler.updateDestination("Catalina")
    withExtendedLifetime(traveler) {
        metrics.computeTravelInterest()
    }
}

18:31 - Safe techniques for handing deinitalizer side effects - Redesign to limit visibility of internal class details

class Traveler {
    ...
    private var travelMetrics: TravelMetrics
    deinit {
        travelMetrics.computeTravelInterest()
        travelMetrics.publish()
    }
}

func test() {
    let traveler = Traveler(name: "Lily", id: 1)
    ...
    traveler.updateDestination("Big Sur")
    ...
    traveler.updateDestination("Catalina")
}

19:08 - Safe techniques for handling deinitalizer side effects - Redesign to avoid deinitializer side-effects

class Traveler {
    ...
    private var travelMetrics: TravelMetrics
     
    func publishAllMetrics() {
        travelMetrics.computeTravelInterest()
        travelMetrics.publish()
    }

    deinit {
				assert(travelMetrics.published)
    }
}

class TravelMetrics {
    ...
    var published: Bool
    ...
}

func test() {
    let traveler = Traveler(name: "Lily", id: 1)
    defer { traveler.publishAllMetrics() }
    ...
    traveler.updateDestination("Big Sur")
    ...
    traveler.updateDestination("Catalina")
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース