Embedded Frameworkのススメ

9bf153d8c0ce36ba6d9d20c2914b70f4?s=47 Go Takagi
October 16, 2018

Embedded Frameworkのススメ

9bf153d8c0ce36ba6d9d20c2914b70f4?s=128

Go Takagi

October 16, 2018
Tweet

Transcript

  1. 2.

    ‣ Status • 東京⼯業⼤学 M2 ‣ SNS • @shimastripe /

    @shimastriper / @root ‣ Intern Task (iOS) • 電⼦版の3d touch • Modulesをフレームワーク化 ←Now!! ‣ Fav Language • Go (は?) ✴ ⼿持ちのMBPはiOSのBuildが⻑くて⾟い Go Takagi 2
  2. 7.

    ‣ Info • AppとExtension間でコード共有する埋め込みFramework ‣ Build時間改善 • App, Extensionをまたぐ重複コンパイルの削減 ✴

    Target Membershipの場合各々にコピーしてコンパイル • 差分Buildの促進 ✴ 「1⾏しかいじってないのに全体に…」が減らせる ‣ Appのサイズを⼩さくできる(起動時) • Dynamic Framework ‣ 名前空間 • 依存関係・レイヤーを嫌でも意識、例えばAPI Clientで切る Embedded Framework (iOS8) 7
  3. 12.
  4. 14.

    ‣ FrameworkはBridging-Headerが使えない • Clang Modulesを利⽤してモジュール化 • Headerをバイナリ化するためコンパイル時間の短縮にも C LibraryをModule Mapでモジュール化

    14 ※ CommonCryptoはXcode10から標準Moduleに #import <CommonCrypto/CommonCrypto.h> #import <CommonCrypto/CommonRandom.h> shim.h module CommonCrypto [system] { header "shim.h" export * } module.modulemap CommonCrypto Module import CommonCrypto Swift 1. ModuleMapに読み込むHeaderを記述 2. Header Search Pathを指定 3. Swiftファイル上でImport可能になる
  5. 15.

    ‣ Emb FrameworkはApp専⽤APIを持てない • Extensionが使えないAPIはダメ(リジェクト) ✴ Ex.) UIApplication.shared • Require

    Only App-Extension-Safe API: YES ↑でBuildしたFrameworkしか利⽤できない ✴ してないものをLinkするとwarning ๏ linking against dylib not safe for use in application extensions ✴ 後述しますが、もちろん⾃前のコードに対しても対象 Dynamic Framework Link時の注意点 15
  6. 16.

    ‣ EmbeddedFrameworkで使えるよう改善 • Bridging-Headerで読んでいたものをModuleMapに • OSSにSafe APIフラグのPR • Carthage化(Membershipの重複改善) •

    どうしようもなかったらUnsafeなAPIをforkして削除 PR投げたりCarthage化したりコード消したり… 16
  7. 17.

    ‣ 設計構造の⾒直し • 移⾏する前に設計が悪い箇所は直しておく ✴ Ex. UIViewControllerの型を⾒て分岐する箇所を取り除く ✴ Ex. App限定のAPIをApp側に持たせる(先述)

    ‣ Framework化 1. Modulesの移⾏、Framework単体でBuild Succeed 2. 外部(AppやExtension)から参照したいモジュールに
 アクセス修飾⼦を付加(public / open class) 3. AppやExtensionから参照する箇所にimportを付加 • statement毎にError出るのでものすごいエラー数になります Module群を移⾏ 17
  8. 18.

    ‣ 直感的じゃないError • 何かが抜けて明⽰的に指定する必要性が⽣じるError ✴ ambiguous use of ✴ frameworkのimportし忘れ

    ✴ frameworkのextensionがPublicになってないとか • Repositoryを複製して何が参照できなくなったか
 確認できるようにしておくといい ‣ 他ブランチとのpbxprojの衝突がとても多い • (オススメMergeツールあったら教えてください) 躓きやすいところ 1/2 18
  9. 19.

    ‣ Emb Frameworkで利⽤できないFramework • CrashlyticsはInstanceをAppにしか持つことができない • 【対策】 ✴ Emb Framework上ではprotocolとして抽象的に定義


    ApplicationからEmb Frameworkに逆Injection ‣ protocol extensionの衝突が解決できない • StringをextensionしてisEmptyフィールドを定義、
 Framework同⼠で衝突すると区別することができない • 【対策】 ✴ 冗⻑な名前を避ける/extensionを⼯夫して名前空間(疑似)作る ๏ Ex. RxSwift 躓きやすいところ 2/2 19
  10. 20.

    ‣ Build回数がとにかく多い • Error潰してBuildしてのサイクル • 作業はスペックいいPCでやるべき ‣ スペック低いとXcodeが死ぬ • 適当に移⾏するとエラー700件とか平気で出る

    • Indexing Prebuilding って常にクルクルする • 静的解析が終わらない ✴ ジャンプ先が意味不明なファイルに⾶ぶ • 儚げに落ちる 感覚的に⾟いところ 20
  11. 22.

    ‣ 実機iPhone7plusで3回測って平均 ‣ 重複コンパイルしてた箇所が効いてる • Full Buildチェック 22 iMacPro2017 MBP2013

    (Xcode10) Base Embed Base Embed Debug (second) 35.87 30.03 57.93 51.03 Release (second) 125.83 98.87 213.23 172.47 (あくまでゆるふわな実測値です)
  12. 23.

    ‣ 差分Buildが効率的に起きててサクサク!! 差分Buildチェック 23 iMacPro2017 MBP2013 (Xcode10) FullBuild 差分Build FullBuild

    差分Build Debug (second) 35.87 (30.03) 19.0 57.93 (51.03) 39.3 (あくまでゆるふわな実測値です)
  13. 25.
  14. 26.

    ‣ Build時間改善に役⽴つ • 差分Buildの促進 • 重複コンパイルの除去 • TargetMembership貼らなくていい • Appのサイズを⼩さくできる

    ✴ Dynamic Link過多に対するAppの⽴ち上がりの遅延は要確認 • レイヤーを意識した設計にも役⽴てる ‣ 移⾏するぞ!! 1. 作業時はスペックが⾼いPCでやるべき ‣ Build回数が通常より明らかに増えるため 2. 依存するLibrary / Frameworkの精査 ‣ 個⼈的にはここで苦労する⼿戻りが多かった 3. レイヤーの切り分け・設計構造の⾒直し 4. 移⾏ -> ひたすらErrorをつぶす Embedded Frameworkのススメ 26