try! Swift Tokyo 2017 Aftershow にてObjective-Cコミュニティの話をしてきたので記事に起しました。
Agenda
- Swiftコミュニティではあまり話題にならないObjective-Cライブラリの紹介
- なぜObjective-Cなのか
- 今後どうなるのか
Pinterest's Implementation
- PINCache : non-deadlocking parallel object cache
- PINOperation (NSOperationQueue)
- PINRemoteImage : feature rich image fetcher
Pinterestによる自社ライブラリがいくつか公開されています。
PINCacheはTumblr製のTMCacheのフォークです。ヘビーユーズした場合に問題が起きたので自分たちの実装に置き換えたと説明されています
And Spotify
- SPTDataLoader (HTTP Client)
- SPTPersistentCache
またSpotifyもアプリの基礎となっているHTTPやCachingのライブラリを最近公開しています。
View Framework
- Instagram/IGListKit : UICollectionView framework
- spotify/HubFramework : component-driven UIs
ViewレイヤーのUI開発をもっとうまくやろうというコンセプトのライブラリも活発です。
IGListKit は AFNetworking と同じぐらいの規模のライブラリです。ブログで解説が投稿されています： Open Sourcing IGListKit
アイテム間の差分を検知するアルゴリズの実装にC++標準テンプレートライブラリのvector, stack, hash table のようなコンテナを利用しています。
CocoaのFoundationで同等のデータ構造で処理を実現できるのですが、チューニングの末にC++を直接使うようになったようです。
HubFramework はコンポーネント指向でUIを構成するフレームワークです。サンプルを見て「ウッ」という気持ちになったので深追いしていません。
Objective-Cのライブラリは枯れた実装
- Cache Management
- Asynchronous I/O
- Image Downloader
- GUI Architecture for UIKit
ここから学べることとしては、キャッシュ管理やHTTPクライアントのレイヤーは標準SDKクラスを素直に使った実装では不足で、ある程度の規模のアプリデベロッパーであれば自作するのが通過儀礼になっているということです
PINRemoteImageは同種のライブラリのSDWebImageより高速で省メモリだということがいくらかの利用者が報告しています。
また最近TwitterによるImage Pipelineという実装もリリースされています： Introducing Twitter Image Pipeline iOS framework for open source | Twitter Blogs
React Friends in Facebook
- AsyncDisplayKit (Paper)
- ComponentKit (News Feed)
- React Native
Facebook Developerの人たちはUIKit版VirtualDOMを3通りぐらいリリースしています。それぞれが独立したプロジェクトです
AsyncDisplayKit は最近2.oにアップデートされ PINRemoteImage, IGListKit, Yoga のインテグレーションコードも入りました。リポジトリのExamplesを見るとだいたいどのような構成で使われる想定をしてるのかわかります。
Asyncdisplaykit はとても巨大なライブラリであることには注意が必要です。objcランタイム関数や各種C++の標準ライブラリをフル活用したObjective-C++のお手本のようなプロジェクトです。
ComponentKit は最近活発ではないです。Swiftプロジェクトから使うことができません。
React Nativeによるハイブリッド実装のパターンと、もしくはAsyncDisplayKit+αによるObjective-C++路線が最近のFacebook製iOSライブラリの主流な気がします。
InstagramアプリはReact Native化のニュースの文脈でよく取り上げられますがまだ実験的導入の段階のように見受けられます。
Facebookの人たちはSwiftにはあまり興味がなさそうですが、Parseの人達が作っていたBolts はSwift化されています。
Cross Platform
- NativeScript/NativeScript : native mobile apps with JavaScript
- Microsoft/WinObjC
クロスプラットフォームツールはアプリケーションが複数のプラットフォームで動作するよう開発できる仕組みです。ランタイムとしてObjective-Cの実装があります
WinObjCはCocoaアプリ資産をユニバーサルなWindowアプリとして動かす意欲的なプロジェクトで、Foundationを再実装しています。が実際のプロジェクトの中身を見てみると完成には程遠かったです
React Nativeがブリッジクラスを逐一実装してマッピングしているのに比べ、NativescriptはFFIという仕組みで動的に関数を呼び出しています。性能的な比較はしていませんが原理的にはNativescriptのが柔軟ですが呼び出しにオーバーヘッドが生じそうです。
Transpiler
- dropbox/djinni : generating cross-language interface bindings
- google/j2objc
トランスパイラーは既存のソースコードをObjective-Cに変換するツールです。
DropboxのdjinniはC++コードとIDLからJNI/JavaとObjective-C++のインターフェイスを自動生成。
地味なツールですが生成されたコードをSwiftから呼び出せるのがお得なポイントです。
j2objcはそのJava版といった位置付けです
まとめ: Objective-C Toolchain in 2017
- Glue Together Swift and C++
- Cross Platform Frameworkの基盤
現実のアプリケーション問題を解決してきたコード
- 大量データのハンドリング
- 複雑な画面設計への対応
- 高速化、省メモリ
Next ?
- Porting to Swift with just algorithm
- Swift 4, Swift 5 vs C++
- iOS/macOS with swift-corelibs-*
いくらかのライブラリは有用であるもののSwiftで置き換え可能だと思います。Swiftネイティブなプロジェクト増加によって影を潜めてゆくことが予想されます
また時期Swift言語の仕様策定によってはC++資産を直接扱えるようになることも考えられます
OSS版のFoundationやコアライブラリの開発も着々と進んでいるので、それらがCocoaのSDKにバックポートされ統合されてる未来も予見されます
その時にObjective-Cがどのような未来を迎えているのか? はまだ想像できていません。今後の動向に注目しましょう。
Links
- 実際に使ったスライド： Objective-C Toolchain in 2017 // Speaker Deck
- スライド管理に使ってる便利ツール： k0kubun/md2key: Convert markdown to keynote