今日も前夜の記事に続きiOSDC2020のセッションを聞けた範囲でおもしろかったもののまとめをしておこうと思います。
※ よかったら毎日ブログ書いてるので、暇な時に見てください🙃
4年間運用されて表示速度が低下した詳細画面を改善する過程で得た知見(Track B)
画面の初回表示のスピードを改善するというセッションの内容で、結論から言うと View の生成を遅延させる
ことで初回表示の速度を向上させるという内容のものだった気がします。
具体的には AbemaTV のアプリを例に改善方法が解説されていました。 また、初回表示のスピードを早くするための方法としては、下記の2つが挙げられていました。
- xib を利用せずにコードレイアウトに置き換える
- View の生成を遅延させる
xib については細かく言及はされていませんでしたが、主な要因として、カスタムフォントが適用されている場合や、xib の初回読み込み時には View の生成に時間がかかるようです。(UINib の初期化は2回目以降からキャッシュが使用されるため)
また、File's Owner
や View Class
などの指定方法では速度に影響はなく、あくまで xib
のロードが初回表示のスピードに影響を与えると言うものでした👀
今回のセッションの最終的な初回表示スピードの改善点は、下記のようになっていました。
- View の生成を、
viewDidAppear
後に遅延初期化viewDidAppear
で実行すれば、viewDidLoad
・viewWillAppear
などの表示系のメインスレッドをブロックせず初回スピードを向上させられるのか🤔
- 上記に View 遅延に伴った、データの取得も合わせて遅延させる
AbemaTV の詳細画面の階層や改善などのプロセスが見れて面白かった🙃
speakerdeck
そろそろ Combine(Track D)
ちょっとこのセッションは途中から聞いたのでまとめられる範囲で書きます。。
Combine とは?
2019年の WWDC で SwiftUI と共に発表されたもので、Swift でのリアクティブプログラミングを Appleが公式としてサポートしている Framework です。また、基本的には iOS13以降で動作するので注意が必要です。
セッションでは、公式ドキュメントの抜粋ですが下記のように説明されていました。
"" 連続した多種類の非同期処理などを単一の方法で扱う宣言的なAPI ""
iOSでは、非同期処理などを扱う方法がセッションのスライドで取り上げられていたように複数あり、処理の方法が場合によって異なることと処理の流れが途切れてしまうということが難しさとして挙げられていました。
Combine を構成する要素
また、Combine に関する要素もセッションで取り上げられていました。下記で簡単にまとめてみました。
Publisher
特定の方の値を時間とともに連続的流すためのプロトコルで、主に下記の3つの値を流します。(RxSwift で言うところの Observable でしょうか)
- Output
- Failure
- finished
Publisher<Output, Failure: Error> Output: 正常時に流す値の型 Failure: Error時に流す Error型
Subscriber
Publisher から欲しい分だけ値を受け取るためのプロトコルで、CustomCombineIdentifierConvertible
に準拠しています。
Subscriber<Input, Failure: Error> Input: 正常時に受け取る値の型 Failure: Error時に Publisher が流す Error型
また、購読には sink
と assign
が使用でき、違いを簡略的にまとめると、エラーが出る場合 sink
を使い、エラーが出ない場合 assign
で購読する感じかと思われます。
Operator
流れてくる値などをマッピングメソッドを使用してデータの合成や加工を行うもので、Swift の Collection のシンタックスと同じように使えるものが多いようです。
Subscription
Publisher と Subscriber のコネクションをするプロトコルで Cancellable
、CustomCombineIdentifierConvertible
などに準拠しています。Cancellable
に準拠しているので、購読をキャンセルした場合は、cancel()
メソッドで購読を解除することができます。
また、今回のセッションで初回されていた通り、AnyCancellable
は保持先のクラスのメモリが解放されるタイミングで自動的に購読が解除されるようです。(RxSwift の DisposeBag みたいな立ち位置かな🤔)
Foundation、SwiftUI、CoreData など、あらゆる処理を Publisher
に変換することで、Combine の世界でコールバックに悩まずに開発をできるようになるようです。個人的には、NotificationCenter の取り回しがすごく面倒に感じることが多いので、積極的に Combine で楽をしていきたいと思いました🙃
speakerdeck
shiz さんの GitRepo
ファッション業界を技術で変える、ZOZOの挑戦〜CTOが語る理想の組織像とは〜(Track B)
ご飯食べながら見ていたのでメモ全く取れなかったです😇
ただ、ZOZOテクノロジーズのエンジニアへの投資 + 働き方への投資がなかなかすごくて驚きました。セッションで聞いた拙い記憶が下記になります。
ZOZO と ZOZO Technologies
- ZOZO
- 事業部
- マーケティング部 など
- ZOZO TEchnologies
- 開発部
- ZOZO
開発スタンス
働き方
- 楽しくをモットーに
- 楽しく == 自ら学ぶ == 成長
- 楽しくをモットーに
支援(iOS)
Fortee
iOSリジェクト戦記 ~リジェクトされないための課金ページ~(Track A)
このセッションでは、App の課金まわりでリジェクトされないための必要知識や少しグレーな回避方法などについて発表されておりました👀
また、リジェクトされた例で〇〇の乱
のような形で下記のようなことを取り上げられていました😨
サブスクリプションページに注意文言(ガイドラインに沿った必要な課金の説明文言など)がない
- メッセージを送信しても時にリジェクトの理由は明かされずに規約違反とだけ返ってきたそうです。笑
- 問題点:
- 課金 UI 上に課金ボタンが複数設置されている場合などで、注意文言が最下部のボタンの下にのみ置かれていたことが原因のようでした?
- 解決:
- 最下部に注意文言の記載があっても審査では認知されないことが多々あるそうだったので、それぞれのボタンしたに注意文言を追加することで無事審査に通ったそうです。
金額の表記が最も目立っていない
- 問題的:
- デザイン上金額があまり目立たないため
- 解決策:
- シンプルに金額が目立つようなリデザインをすることで解決したそうです。(詳細はスライドを確認してください)
- 問題的:
無料という文言が目立ちすぎ
- 問題点:
- 体験プランなどのキーワードを 無料 にしていたこと
- 解決策:
- 無料 を お試し などのキーワードに変更すると無事審査に通ったようです。
- 問題点:
また、ガイドラインには ユーザを騙そうとするアプリ
などの言及があり、無料 というキーワードには納得しましが、Apple が出しているアプリの課金画面では、思いっきり 無料 というキーワードが使われているところがめちゃ面白かったですね😇 結果、Apple は神!
また、少しグレーなリジェクトの回避方法などはこの記事ではまとめませんが、気になる方は下記にのせた発表者のスライドをご覧ください。
speakerdeck
「iOSエンジニアだし、Androidアプリも作れるでしょ?」(Track D)
このセッションでは Androidアプリ開発の基礎的なことを iOS Developer が分かりやすいような比較を用いて発表されていました。個人的に Android 開発は最近始めたばかりだったので、とても勉強になりました🙇♂️
違うところ
セッションで共有されていた iOS、Android 開発における違いは下記のようなことだったかと思います
iOS | Android | |
---|---|---|
画面遷移 | プッシュによる遷移が軸で、状況に合わせてモーダルを表示する | ページを重ねていくイメージの遷移方法 |
BackButton | プッシュにはほぼついている | 端末自体に戻るボタンがついている場合が多いので、ついていないこともある |
画面タイトルの位置 | おおよそ中央 | 左端 |
要素選択 | リスト、ドラムロール、アクションシート | チェックボックス、ラジオボタン、ドロップダウンリスト、ボトムシート |
リスト矢印(Cellなど) | Disclosure Indicator をつけたり | つけないが一般的 |
日付選択 | ドラムロール、iOS14からカレンダー型 | カレンダー型 |
Navigation Drawer | 純正ではない(と思う) | 純正でスライドして表示するメニューがある |
デザインの参考になるサイトなど
Kotlin と Swift比較
ここに関しては、以前の記事で少し触れた気がするので割愛します。詳しい内容が知りたい方はスライドを参照してください。
Activity と Fragment
Activity
iOS でいうところの UIViewController に近いもので、通常は1つの Activity で1画面を実装するようです。
また、Activity のライフサイクルは共有していただいたスライドで下記のように分かりやすくまとまっていました。また、Ask the speaker で聞いた気がしますが、基本的には画面の回転に合わせて Activity は破棄される仕様のようです🤔
Fragment
Fragment は、Activity に組み込んで使うもので、1つの Activty に複数の Fragment を組み合わせて使うことができるようです。また、Activity 間で Fragment を再利用して使うことも可能です。
Fragment のライフサイクルは下記のようにまとめてありました✨
よく使うコンポーネント
ListView
シンプルな一覧を表示するためのコンポーネントのようで、iOS でいうところの UITableView とか UICollectionView のような立ち位置かと思われます。
具体的には、下記のようなものを使用して ListView をセットアップするそうです。
- DataSource
- Cursor
- ArrayList
- Adapter
- ListView
ex:
var arrayList = arrayListOf("Swift", "Kotlin", "Java") var adapter = ArrayAdapter(this, android.R.layout.simple_list_item, arrayList) listview.adapter = adapter
RecyclerView
ListView を拡張して柔軟性を持たせたコンポーネントで、スワイプやドラックアンドドロップなどをする際もこれを使用するようです。また、ヘッダーやフッターなどの仕組みは存在せず区切り線なども自分で実装する必要があるようです。
セットアップに必要なものは下記です。
- DataSource
- Adapter
- ViewHolder(iOSで言うところの UITableViewCell など)
- RecyclerView
- LayoutManager
個人的には、Android でよく使うコンポーネントや iOS との対応関係などが具体的にわかってとてもいいセッションでした🙃 また、レイアウトのデバックやコードのデバック方法などはスライドに記載されている通り、非常にiOSの開発と似ていることが多いので iOS Developer が Android 開発に参入する障壁はかなり低いように感じました。
speakerdeck
最後に
他にも多くのセッションがありましたが、今回は聞いた中で特に気になったセッションを簡単にまとめました。自分が参加したセッションは他にもあるので、また時間がある時にでも改めて記事を書こうかと思います🙃
楽しかった!明日は少しだけしか参加できないけど、また来年を参加しようと思います🎣