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の方がいいはず