読者です 読者をやめる 読者になる 読者になる

絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

iOSDC Japan 2016 参加メモ: A-7 メモリー管理の嬉しいバイキング料理

  • Ray Fix さん
    • めっちゃ日本語うまい

モリー管理

  • ほぼ自動的にメモリ管理をしてくれる
  • 仕組みがわかれば、バグの少ないアプリがかける

スタックとヒープ領域

スタック

  • スタックはとにかく速い
  • ロックする必要は全く無い
  • スタックから出るときには必ず開放が必要になる

  • もっと広く使いたい場合はヒープを使う

ヒープ領域

  • 共通メモリ

    • ヒープ領域に情報を確保し、スタックの領域の参照とカウントを持つ
  • 参照型を使うときには、定数型をつかうと上書きのデメリットが消せる

  • 循環参照問題

    • 複数のクラス間でそれぞれが持ち合うと、参照のサイクルが出来上がってしまう
    • Xcode 8で参照がグラフィカルに見える
    • 解決するには
      • weak型の参照を使う
      • 弱い参照が勝手にnilになる

Swiftの弱い参照

  • Objective-Cの時は強い参照が0になると開放されていたが、Swiftではそうではない。

  • 強い参照がなくなるとdeinitalizeが走って、weak countが0でない場合はゾンビができる

  • weak countが0になった時に、初めてメモリから開放される

    • つまりweak 用のカウントは別にある
  • weak

    • 参照先がゾンビの場合はnilを返すようになる
  • unowned

    • 参照先がゾンビの場合はエラーになる
  • 呼び出す場合の例

    • Closureのなかで値を使う場合、selfをつけろと言われる
    • 循環参照しているかもしれない!というヒントをXcodeがくれる
    • キャプチャーリスト [unowned self] みたいにする
  • 非同期の問題

    • 非同期の場合、[unowned self] してしまうと、selfが消えてしまうことがある
    • なので、書かないのが正解になる
  • また、そのような状況で循環参照を防ぐには[weak self] を使えばよい

  • weak selfの場合、selfがOptionalになるので、実行されないところが出てくる

  • それを防ぎたいなら storngSelfに代入するような strong weak danceのパターンでguardする

まとめ

しっかりメモリを理解してバグを少なく!

QAより

  • Apple的には、あんまりキャプチャするのは良いと思ってない様子
  • back tick selfを使ってる人もいるが、MLでバグだ、っていう話になってたので、strong weak selfの方がいいはず