Open6
iOSアプリ開発におけるメモリリーク対策
kamimiまず注意すべき点
- ただし必ずしもこれらを使っているからと言って、メモリリークが起きるわけではない
- Delegateパターン
weak var XXDelegate?
- クロージャ
- キャプチャリストをつけて、弱参照にする
[weak self]
- メモリリークで気をつけるべきところのより詳細
- ライブラリを使用して、開発中に検知することも可能
- tableViewのセル数が多く、画像を読み込む必要がある場合
- 全てのセル分の画像を読み込むと、メモリを一気に枯渇させてしまう恐れがある
- SwiftUIの場合は、
LazyVStackまたはLazyHStackを使用することで、Lazyロードを実現することができる
kamimiSwiftUIで注意すべきメモリ対策
- クロージャ
-
AnyViewの使用を避ける
kamimiメモリリークが発生しているかどうかの確認方法
-
deinitを使用して、メモリが解放されていることを確認する
- それによって、循環参照が起きているかどうかを確認することができる
- Xcodeの下にあるメモリデバッグのマークを押して確認できる
- 紫の⚠️が出ているとメモリリークしている
- ただし必ずしもXcodeのツールで見て紫でなかったからといって、メモリリークしていないとは限らない!!
- コードのどの行でメモリリークが発生しているかは、Malloc Stack loggingをEdit Schemeからオンにすると確認できる
- Xcodeに付属しているInstrumentsを使用することでも、メモリリークを検知できる
動画
kamimiSwiftUIアプリを作っていて、早速メモリリークが発生
- 紫のマークが出ており、malloc loggingのbacktrackを見たが、なぜか初回起動の@mainで発生している（自分で書いたのは1行だけなのだが）
コード
import SwiftUI
@main
struct XXApp: App {
var body: some Scene {
WindowGroup {
SampleView()
}
}
}
-
Xcodeで確認した結果
-
$main()の横にカーソルをフォーカスすると、矢印が出てくるので、そこを押すと該当コードにジャンプできる
修正プロセス
- クロージャを使用している場所で、
[weak self]を忘れている箇所がないか確認- 全てにキャプチャリストをつけたが、まだメモリリークする
- セグメンテッドコントロールを使用している箇所のViewの呼び出しコードをコメントアウトしたところ、発生しなくなった
- Viewの呼び出し方か、ViewModelの渡し方が問題か？
- セグメンテッドコントロールを使用してミニアプリをもう一度作り直してみたところ、ViewModelを渡していなくてもメモリリークは発生していた
- 選択したセグメントによって切り替えるViewの部分を、セグメンテッドコントールを定義しているViewと同じViewのstructではなく、別のstructとして定義すると、メモリリークしなくなる！
- 理由が不明
- SwiftUI Segmented Control Tutorial | iOS 14 | Xcode 12.4を真似てみたところ、そうだとわかった
- ただし、元のアプリでは同様に行ってもメモリリークは解決しなかった・・・
private var content: some View {
Group {
switch selectedIndex {
case .A:
SampleAView(viewModel: SampleAViewModel())
case .B:
SampleBView(viewModel: SampleBViewModel())
}
}
}
メモリリークが発生しうるケース
-
NavigationViewを使用しているとき
-
Buttonを使用しているとき