Method Swizzlingを行うライブラリにおけるマルチモジュール設計

Method Swizzlingはメソッドの実行時の挙動を動的に変更する強力な機能ですが、アプリケーションの安定性に影響を与える可能性があります。今回はSwift Package Managerのマルチモジュール構成を採用した場合でも正しくSwizzlingが行われるよう、設計した事例について紹介します

Transcript

1. Method Swizzlingを行うライブラリ におけるマルチモジュール設計 松原良和
2. Method Swizzlingとは • Objective-Cのランタイムを用いてメソッドの実装を入れ替える機能 • 条件を満たせばSwiftでも利用可能 • viewDidLoadなどのライフサイクルなどに独自の処理を挟むことができる メソッド名 処理 methodPrintA print(“A”) methodPrintB print(“B”) メソッド名 処理 methodPrintA print(“B”) methodPrintB print(“A”) Swizzling
3. Method Swizzlingのやり方 • viewDidLoadをSwizzlingしてみる • AppDelegateにSwizzling処理を追加 @UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { UIViewController.swizzling() return true } }
4. Method Swizzlingのやり方 • viewDidLoadをSwizzlingしてみる extension UIViewController { func swizzling() { let originalSelector = #selector(viewDidLoad) let swizzledSelector = #selector(swizzled_viewDidLoad) guard let originalMethod = class_getInstanceMethod(UIViewController.self, originalSelector), let swizzledMethod = class_getInstanceMethod(UIViewController.self, swizzledSelector) else { return } method_exchangeImplementations(originalMethod, swizzledMethod) }() // 交換するMethod @objc func swizzled_viewDidLoad() { print(”swizzled_viewDidLoad") // 元のviewDidLoadを呼び出し swizzled_viewDidLoad() } }
5. Method Swizzlingのやり方 • viewDidLoadをSwizzlingしてみる LoadView print("viewDidLoad") ViewWillAppear print(”swizzled_viewDidLoad") swizzled_viewDidLoad ViewDidLoad 明示的に呼ぶ
6. Method Swizzlingのやり方 • viewDidLoadをSwizzlingしてみる extension UIViewController { func swizzling() { let originalSelector = #selector(viewDidLoad) let swizzledSelector = #selector(swizzled_viewDidLoad) guard let originalMethod = class_getInstanceMethod(UIViewController.self, originalSelector), let swizzledMethod = class_getInstanceMethod(UIViewController.self, swizzledSelector) else { return } method_exchangeImplementations(originalMethod, swizzledMethod) }() // 交換するMethod @objc func swizzled_viewDidLoad() { print(”swizzled_viewDidLoad") // 元のviewDidLoadを呼び出し swizzled_viewDidLoad() } }
7. Method Swizzlingの利用例 状態の追跡 • ユーザーのログイン状態を追跡し、特定のメソッドが呼ばれた際にログイン状態を確認する • UIApplicationのsendEvent:メソッドをSwizzlingして、ユーザーがアプリを操作するたびにログイン状態を チェック 自動可視判定 • 特定のメソッドが呼ばれた際にアナリティクスイベントを送信する • UIViewControllerのviewWillAppear:メソッドをSwizzlingして、画面表示時にアナリティクスイベントを送信 Viewの動的変更 • アプリ全体のテーマを動的に変更するために、特定のメソッドの動作を変更する • UIButtonのsetTitleColor:forState:メソッドをSwizzlingして、テーマに応じた色を動的に設定 etc…
8. Method Swizzlingの利用例 • 画面の可視判定 • 画面上にViewが表示された、されていないを判定したい場合 • ロギングや動画の自動再生 Cell1 Cell2 Cell3 Cell4 画面スクロール Cell1 Cell2 Cell3 Cell4 見えなくなった 見えるようになった 見えない 見える
9. Method Swizzlingの利用例 • iOS18+はonScrollTargetVisibilityChangeなどのAPIが利用可能 ScrollView { } .onScrollTargetVisibilityChange(idType: Int.self, threshold: 0.5) { newItems in // 画面内に表示された!! } https://developer.apple.com/documentation/swiftui/view/onscrolltargetvisibilitychange(idtype:threshold:_:) override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) // ページが表示された!! }
10. Method Swizzlingの利用例 • 可視判定処理をSwizzlingを使ってライフサイクルに差し込む • View側で実装することなくViewControllerのViewに可視判定をつけることが可能 イベント Viewのライフサイクル 画面描画が完了 viewDidAppear 現在の画面が非表示 viewDidDisappear スクロール scrollViewDidScroll アクションの送信（clickなど） sendAction scrollViewWillBeginDecelerating Cellの可視判定 scrollViewDidEndDecelerating scrollViewDidScroll スクロールのライフサイクル
11. Method Swizzlingの利用例 • 実直に実装するとすべてのViewControllerに実装が必要 • Swizzlingを使うと自動でViewの可視判定を行うことが可能 • 実装漏れが起きにくくなる • 実装コストが下がる メリット
12. Method Swizzlingの危険性 • Method Swizzlingしていることが明示的でない • 動作の不安定化 • Swizzlingを利用しない機能でもSwizzlingされてしまう 非常に便利な機能であるが以下の3つの懸念がある
13. Method Swizzlingの危険性 • Method Swizzlingしていることが明示的でない • 動作の不安定化 • Swizzlingを利用しない機能でもSwizzlingされてしまう 非常に便利な機能であるが以下の3つの懸念がある
14. Method Swizzlingの危険性 Method Swizzlingしていることが明示的でない • 別の場所に実装しているコードが呼ばれる • 勝手にSwizzlingされていると気付けない こちらが呼ばれる 本来はこちらが呼ばれる 元の処理を呼び出している // アプリ内のコード class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() } } // ---SDK内でSwizzlingする処理--- // 略 // --- // Swizzling対象 @objc func swizzling_viewDidLoad() { self.title = ”Title" self.swizzling_viewDidLoad() }
15. Method Swizzlingの危険性 • Method Swizzlingしていることが明示的でない • 動作の不安定化 • Swizzlingを利用しない機能でもSwizzlingされてしまう 非常に便利な機能であるが以下の3つの懸念がある
16. Method Swizzlingの危険性 同じメソッドを複数の箇所からSwizzlingすると競合し動作が不安定に class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() } @objc func first_swizzling_viewDidLoad() { self.title = ”Title" self.swizzling_viewDidLoad() } @objc func second_swizzling_viewDidLoad() { self.title = ”Title2" self.swizzling_viewDidLoad2() } } • もし同時にSwizzlingをしていたら… • 非同期でSwizzlingしていたら…
17. Method Swizzlingの危険性 framework Swizzling処理 可視判定 データ送信 バッファリング 暗号化 SDK内でSwizzlingをしているかは コードを読まなければわからない Other framework Swizzling処理 可視判定 データ送信 バッファリング 暗号化 他のSDKでも同じメソッドを Swizzlingしているかもしれない 同じメソッドを複数の箇所からSwizzlingすると競合し動作が不安定に
18. Method Swizzlingの危険性 • Method Swizzlingしていることが明示的でない • 動作の不安定化 • Swizzlingを利用しない機能でもSwizzlingされてしまう 非常に便利な機能であるが以下の3つの懸念がある
19. Method Swizzlingの危険性 • 大抵のSDKでは複数の機能がパッケージ化されており Swizzlingの機能を使わない場合でもSwizzlingが実行 されてしまう可能性 • 複数のSDKに分割すると管理コストが上がる framework Swizzling処理 可視判定 データ送信 バッファリング 暗号化 SDK内に複数の機能がある場合不用意にMethod Swizzlingをしてしまう その他I/F
20. Method Swizzlingの危険性 • Method Swizzlingしていることが明示的でない →細かなSDKに分割しSwizzlingをしていることを明示的にする • 動作の不安定化 →Swizzlingを行う範囲を小さくする • Swizzlingを利用しない機能でもSwizzlingされてしまう →Swizzlingするものとしないものでうまく分割する 非常に便利な機能であるが以下の3つの懸念がある Swift Package Managerのマルチモジュール構成を利用すると良さそう
21. Swift Package ManagerのModule構成を利用する 通常のSDK SPMのモジュール構成を用いたSDK Package.swift Swizzling 可視判定 ログ送信 自動可視判定モジュール 共通モジュール その他のI/Fモジュール framework Swizzling 可視判定 I/Fその1 データ処理 I/Fその2 メタデータ取得 I/Fその3 ログ送信 データ処理 メタデータ取得 Swizzlingを利用する機能としない機能でModuleを分ける
22. Swift Package ManagerのModule構成を利用する Swizzlingを利用しない機能のみを使う場合はSwizzling処理を含んだモジュールを含まなくて済む Swizzling 可視判定 自動可視判定モジュール その他のI/Fモジュール 利用者 用途に合わせて選択可能 共通処理モジュール その後の処理は共通処理モジュールを内部で依存 データ処理 メタデータ取得
23. Swift Package ManagerのModule構成を利用する Module構成を取ることによって引き起こされる問題 • Swizzling処理をするModuleが2箇所から参照される可能性 • 複数のModuleから同じメソッドに対してSwizzlingを行う可能性 Swizzlingモジュール I/Fモジュール I/Fモジュール 依存 ViewDidLoad Swizzlingモジュール Swizzlingモジュール Swizzling モジュール化によって不安定さが増してしまう可能性
24. Swift Package ManagerのModule構成を利用する Swizzlingモジュールの構成 モジュールのStart処理 Swizzling Swizzle結果を返却 • 呼び出し元のアプリでは必ず起動時に同期的に実行する • 2度Start処理が実行されないようにする Swizzlingを行い結果を返却 事象 結果 対象のメソッドが取得できない場合 .failed 対象のメソッドがoverrideされていない場合 .add 対象のメソッドがoverrideされている場合 .exchanged
25. Swift Package ManagerのModule構成を利用する • 異なるメソッドに対してSwizzlingを行う場合はモジュールを分けても問題なし • 同じメソッドに対してSwizzlingを行う場合はモジュールを同一のものにする 機能1 viewDidLoad 機能2 機能 Swizzling対象 モジュール1 モジュール 機能1 viewDidLoad 機能2 モジュール1 scrollViewDidScroll モジュール2 機能1を使う人が無駄にscrollViewDidScroll のSwizzlingをする必要がない 機能1と2でviewDidLoadのSwizzling を行う場合は同一モジュール
26. Swift Package ManagerのModule構成のメリット • Swizzling処理をモジュールで隔離することでSwizzlingによる影響を最小限に抑えられる • 影響範囲を狭めることで不具合の発見が容易 • モジュールを分けやすいため設計変更がしやすい • Swizzlingを行うことを明示的にできる • 使わない機能の不要なSwizzling処理を含めなくて済む SDK開発者側のメリット SDK利用者側のメリット
27. まとめ • SDKではSwizzlingがとても有用だが実装が見えづらいためとても危険 • 工夫してモジュール単位で分割すると責務が分かれて安全性が高まる • Swizzlingは用法・用量を守って正しく使いましょう！