こんにちは！ LIFULL HOME'S事業本部 技術開発部の小賀野と申します。 普段フロントエンドやBFFなどの開発を行っているエンジニアです。
さて、今年もiOSエンジニアにとっての一大イベントの1つであるiOSDC Japan 2018が開催されました。 LIFULLは、昨年のドリンクスポンサーに引き続き、 今年はゴールドスポンサー＋前夜祭＆LT大会ビアスポンサーとして協力させていただきました。また、今年はなんとLIFULLから2人が登壇いたしました！
8/30(木)〜9/2(日)に開催されたiOSDC Japan 2018に参加してきましたので、 一部ではありますがその様子をお届けしたいと思います！
iOSDC Japanとは
iOSDC Japanは、2年前より開催されているiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。今年で3回目の開催になるそうですね！ 参加者はiOSエンジニアがほとんどではありますが、「iOSエンジニアに聞いて欲しいトーク」という枠が設けられるなど、iOSエンジニア以外の方々も登壇されています。 内容としては、アーキテクチャの話題や最新のiOS技術の話題など多種多様で、 今年は昨年よりも1日長い開催期間となり、とても多くのトークが行われておりました。 その中でも私が特に注目したトークを少しご紹介したいと思います！
iOSとgRPC
Googleの開発したRPC(Remote Procedure Call)フレームワークであるgRPCですが、今年のiOSDCではこのgRPCに関するトークが多くありました。
iOSエンジニアの為のgrpc-swift入門 @tikidunpon
このトークでは、gRPCやProtocol Buffersを使用するメリット、実際にSwiftのコードを生成するための方法について紹介されていました。 特に、iOSエンジニアとしてはOptionalの扱いについてが気になるところですね。
- gRPCを使用することで、クライアントのコードを自動生成することができるので、APIの仕様と実装の乖離を減らすことができる
- grpc-swiftでは、ブロッキングなものとノンブロッキングなものの両方のSwiftのコードを生成できる
- Protocol Buffersにより、JSONに比べてペイロードサイズを削減できる
oneofを使用することでSwiftのOptionalを表現することは可能であるが、他の言語で使用できない可能性を考えるとあまり得策ではない
grpc-swiftを使ってiOSアプリでも快適なgRPC通信を行う @KyoheiG3
このトークでは、gPRCによるクライアント実装だけでなく、サーバ実装の話までがされていました。また、実際にgrpc-swiftを使用した上でのクライアント側でのつらみを紹介し、そのつらみを解消するために自分たちで作成したライブラリの紹介もされていました。Unaryについてだけではなく、Bi-Directional Streamingなどの他の通信方式についてもサンプルを交えながらわかりやすく説明されています。
- grpc-swiftでは、timeoutをリクエスト個別に設定することはできないが、登壇者の作成したgrpc-swift-clientを使用することで、リクエスト単位にtimeoutを設定することができるようになる
- HTTP/1.1しか使用できない環境ではgRPCを使用することはできないが、Protocol Buffersのみの使用でも通信容量の削減などメリットはある
- とはいえバイナリベースなので、Charlesなどでエラー時のデバッグを行いにくいのが少しネック
まだiOSアプリでgRPCを本番環境で運用している企業はそれほどいないようでした。ただ、gRPC関連のトーク数や会場でのトークの観覧者数を見る限りでは、今後検討してみたい・使用してみたいという企業が多いのではないでしょうか。
差分更新
今年はTableViewの差分更新関連の話が多くありました。差分更新ライブラリの内部的なアルゴリズムの話やチューニング方法の話などがありました。
差分アルゴリズムの原理について @horita_yuya
このトークでは、TableViewやCollectionViewの差分更新用ライブラリに採用されているアルゴリズムの中でも特に優位性の高い「Myers Algorithm」・「Paul Heckel Algorithm」について紹介されていました。それぞれの差分更新アルゴリズムの詳細な方法から計算量がどれほどになるかまで触れられていました。
- Myers Algorithmの計算量はO(ND)
- Paul Heckel Algorithmは、DifferenceKitやRxDataSourcesに使用されている差分更新アルゴリズム、計算量はO(N)
- 計算量がO(N2)であるアルゴリズムを採用するライブラリも存在するが、パフォーマンスをとるか機能面をとるかしっかりと考えて検討すべき
- 現在、差分更新系のライブラリでは、機能面・パフォーマンス面をとってもDifferenceKit一択なのではないか
5000行のUITableViewを差分更新する @banjun
このトークでは、差分更新の方法だけでなくXcodeのInstrumentsを利用したパフォーマンスチューニングの方法まで紹介されていました。私もInstrumentsを利用したチューニングを行ったことがありますが、各メソッドの実行時間が細かく見れるため、ボトルネックとなっている箇所を特定しやすいので非常に便利ですね。
- XcodeのInstrumentsのTime Profilerを使うことで実行アプリのCPU負荷のグラフやスタックトレースの各段ごとの実行時間が確認でき、ボトルネックになっている部分を特定しやすい
- RandomAccessControllを使おう
- Genericsを除去しよう
普段何気なく使用するライブラリには様々なアルゴリズムが使われており、もちろんすべてのアルゴリズムには計算量がつきものです。実装上の使い勝手や機能面だけではなく、より良いパフォーマンスを出すためにも使用するライブラリがどんなアルゴリズムで実装されているのかを把握することも選定の基準の一つであるということですね。今回の差分更新の話のような内部実装を理解できるトークは非常に貴重でした。
iOSエンジニアに聞いて欲しいトーク
iOSエンジニア以外の方から見たiOS技術についての話をするトークがいくつかありました。普段主にWebの開発を行っている私が特に注目していた内容です。登壇されている方はほとんどがWebフロントエンジニアの方のようでした。
フロントエンドエンジニアからみたiOS開発 @ohayou_kenchan
このトークでは、iOS技術とWebフロントエンド技術の似ているところについての比較を交えつつ、iOSエンジニアもWebの開発ができるのではないかという話をされていました。私は、iOSの開発もフロントエンドの開発もしたことがあるため、改めて聞いてみると確かに似ているところもあるなと共感するところがありました。個人的には、Swiftでいうprotocolのデフォルト実装がTypeScriptではやりづらいこともあり、Swiftのほうが書きやすい印象がありますね。
- viewが表示される直前の処理や直後の処理など、iOSにおけるUIViewControllerのライフサイクルとReactやVueにおけるライフサイクルは似ているものが多く、メソッドをフックしたときの処理がイメージしやすい(Swiftでいう
viewDidAppearとVueでいうmountedなど) - SwiftとTypeScriptが似ている
- Swiftにおける
letとvarは、TypeScriptにおけるconstとletに対応している - 他にもTypeScriptには、Type(TypeAnnotation)やinterface、any型などSwiftと似ている部分が多い
iOSエンジニアが知るべきProgressive Web Apps開発のエッセンス @laiso
このトークでは、PWAとiOSとの関係性についての話からiOSエンジニアがWebアプリに注目しておいたほうがいい理由について紹介されていました。SafariがService WorkerをサポートしたということでPWAが再び話題になりましたが、その実態についての話もされていました。
- Appleが公式にPWAに対応したという話はなく、あくまでService WorkerにSafariが対応したいうだけの話であって、PWAすべてに対応したと内容が拡大解釈されてしまっていた
- PWAによりiOSで初めてWebアプリをホーム画面に追加できるとの記事もたまにあるが、ホーム画面への追加だけならiOS2のころのSafariの機能で昔からできた
- SafariにはiOS/macOSに密結合した機能が多いため、PWAをiOSで使用するには他のベンダーブラウザをデフォルトにできない
- SwiftやOSSライブラリのエコシステムに参加することで、iOSもより早い速度で進化していくことができるのではないか
- 特にServer-side swiftはまだまだコントリビュートする余地がある
昨年はKotlinをAndroid開発言語に選定したというGoogleからの発表もあり、SwiftとKotlinというようなiOSとAndroidの関係性の話が多くされていましたが、今年はWebとネイティブアプリの関係性についての話が多く、参加者の興味・関心もよりあったような印象でした。
かざして検索
LIFULL HOME'S「かざして検索」リリースの裏側 @HanawaTakuro
LIFULLからも塙が「LIFULL HOME'S「かざして検索」リリースの裏側 」というタイトルで登壇いたしました。「かざして検索」は、建物をかざすだけでその建物の物件情報を閲覧できる今年の5月にリリースされたLIFULL HOME'Sアプリの新機能となります。こちらのプロジェクトにおいて、実際に物体検出をするためにCoreMLやVisionフレームワークをどのように使用したか・工夫したかなどについて紹介されています。かなり濃い内容となっていますのでぜひスライドをご覧ください！
www.slideshare.net
また、「かざして検索」も非常におもしろいアプリ体験となっていますので、こちらもぜひ使ってみてください！
その他トーク
その他、ここでは紹介しきれなかったおもしろいトークがありましたので記載いたします。
Swiftにコルーチンをもたらすための話
iOS周りの技術の総まとめ
イベントの様子
毎年iOSDCでは多くの企業ブースが設けられたり、ランチやドリンクが提供されたりと、トーク以外でも参加者が楽しめる内容となっておりますので、その一部の様子をご紹介いたします。
ブース
iOSDCでは毎年多くの企業がブースを出しています。 ブースではiOSにまつわるアンケートやちょっとしたゲームのようなものが行われており、立ち寄るとノベルティがもらえたりなんかします。
いくつかのブースでは昨年に引き続き、iOSの開発手法にまつわるアンケートが行われていました。CyberAgentさんでは、アーキテクチャはMVCやMVVM・Clean Architectureのどれなのか、UIはSyoryboardで管理するのかコードで管理するのかなどの内容がありました。
DeNAさんは少し細かな内容で、Optionalのアンラップ時は変数を同じにするかしないかなど個々人で記述にズレがでそうなものと、とても興味のある内容となっていました。
ちなみに私は、アーキテクチャはMVVM、UIはコードベース、Optionalのアンラップ時に変数名は変えない派です。
ルーキーズLT
毎年恒例の夕方より行われるLT大会では、ビールや酎ハイなどが振る舞われ、お酒を飲みながら参加することができます。同じく前夜祭でもお酒を飲みながら参加することができたのですが、前夜祭・LT大会ともにLIFULLがスポンサーとしてビールを提供させていただきました。お酒があるとまた雰囲気が変わっていいですね。
また、こちらのLT大会は今年からはルーキーズLTという位置付けで、登壇経験があまりない方々が気軽に登壇できるように配慮されたものでした。
LIFULLからは又来が「ARKit2.0でAppleが伝えたいアプリ体験を考える」というタイトルで登壇いたしました。今年の秋にリリースされるiOS12から使用できるARKitの新機能でどんなアプリ体験を提供すべきかについて紹介しています。最新のiOS12についてやARKitについて興味のある方はぜひスライドをご覧ください！
ARKit2.0でAppleが伝えたいアプリ体験を考える - Speaker Deck
ランチ
参加者が無料でいただけるランチです。3種類の中から選ぶことができ、今年は昨年に比べ、より満足のいく内容となっていました。今年はどうやら会場で作っていたようですね。
懇親会
懇親会は毎年多くの方が参加され、チケットも争奪戦となっています。 お酒はクラフトビールから日本酒まで、料理もオードブルだけでなく、ハンバーガーやケバブなどたくさんの種類が提供されていました。 運営の方々が工夫されていることもあり、初めての方でも気軽に会話に参加することができます。iOS関連の話などで非常に賑わっておりました。
まとめ
開催が3回目ということもあり、iOSを始めたばかりの方からベテランの方までの多くの人が参加され、トーク内容も多種多様でした。特に今年から開催されたルーキーズLTでは、昨年iOSDCに参加された方の中で「来年こそは自分も登壇したい！」と思っている方々が多く登壇されているとのことでした。なかなかカンファレンスという場にいきなり立つのは。。という方も多いと思うので、このように敷居を下げてくださるのは非常にありがたいですね！より一層のiOSコミュニティの盛り上がりが感じられる、非常に有意義なカンファレンスでした！
最後になりますが、LIFULLではネイティブアプリ好きなエンジニアやWeb好きなエンジニア、カンファレンス好きなエンジニアの方を募集しています。 ご応募お待ちしています！
