iOSDC 2018 day1 参加メモ
iOSDC 2018の1日目参加メモです。
Markdownをリアルタイムに解析する
Swift 4.2 はどのような進化をしているのか
- DeNA SWET所属
Swiftの歴史
- 2014年、Swift発表 - Swift3で破壊的な変更がどっさり
Swift4.2
APIの変更、追加が7つ
- ランダム生成
- ランダム取得
- 配列シャッフル
- Bool値の反転
- 配列の最後から２つ目の取得
- 配列の全ての要素が一致するか allSatisfy
- removeAll(where:)
言語仕様が8つ
- hashを自前で実装しなくてよい
- CaseIterableでenumで列挙可能に
- Dynamic Member Lookup
- IUO型 -> IUO属性、!の型がなくなる
- Conditional conformancesの改善
- モジュール間のインライン化
Swift Package Manager、マイナーな変更が3つ
安定したチャットを実現するためのアプリとAPI設計
- 以前はCoreDataを使い、今はRealm
- Realmの方がパフォーマンスチューニングしやすい
要件
- 送信失敗したらローカルプッシュ通知
- オフラインで閲覧可能
- メッセージの管理
- メインスレッドとバックグラウンドスレッド用のrealmを用意する
API
- レコードがどんどん追加されているのでOffsetPaginationではなくTimelinePaginationを使う
- slack,twitterAPIがTimelinePagination
- ローカルでメッセージにIDを振って制御
UserInterface
- UICollectionViewを使う（UITableViewを使わなかった）
- scrollToBottomの動きが安定しない
- スクロール位置を維持したままアイテムを追加する
- このような課題があった
- Inverted UICollectionViewというアプローチもある
- こちらもいくつか問題がある
- GrowingTextViewの実装も大変
- ライブラリ を用意した
海外展開を目指すアプリでセキュアで速い画像と動画の閲覧を実現した話
- 日本では問題なかったが海外で写真の表示が遅かった
- サーバはEC2, CloudFront(CDN), S3を使っていた
- CDN以外は日本、CDNは一番近いところ
- EC2, S3へのアクセスが遅いと仮設を立てた
- 次の改善を実施
- 署名付きURLを事前に取得するようにした
- 署名付きURLをRealmにキャッシュ
- 有効なURLを取得できるようにRepositoryを実装
- 画像のキャッシュはSDWebImageを使う
とある端末の触覚技術 -フィードバック-
- Taptic EngineはHaptic Feedbackの実現のために搭載
- 皮膚感覚のフィードバックを得るもの
API
- UIFeedbackGenerator: ベースクラス
- UINotificationFeedbackGenerator: 成功、失敗、警告
- UIImpactFeedbackGenerator: 大、中、小
- UISelectionFeedbackGenerator: 選択肢の変化を伝える感触。UIPickerViewなど
- UIImpactFeedbackGeneratorを同時に実行すると強くなった
- 最大20個まで
Human Interface Guideline(どういう時に使うべきか）
- アクションの結果をユーザに伝える
- success：入金、解錠が成功した時に使う
- 多用するのは避ける
- ユーザのアクションに合わせてフィードバックを発生
- フィードバックは意図通りに使う
- 視覚と触覚のフィードバックを同時に発生させる
- すべての端末で発生するわけではないのでHaptic Feedbackだけでなにかを伝えるのはやめましょう
- 特定の場所や値に到達した時に通知すること。twitterの画像拡縮で端まで達した時に light を発火させていた
- ユーザに対して操作イメージをもたせやすくすることができる
- heavyは結構強いので使わないほうがいいかも、mediumとlightを使い分けると良いとのこと。
フロントエンドエンジニアからみたiOS開発
- mybestのエンジニアの
- ライフサイクルが似ている
- async/awaitが似ている
- SwiftのRedux実装のReSwiftがある
- TypeScriptとSwiftが似ている
動画アプリをなめらかに動かす技術
- 動画再生
- HLSについて
iOS実装ポイント
- AVPlayerが一般的
- AVAsset, AVplayerItem, AVPlayerを生成する
- 複数再生の場合、生成と破棄が大切
- AVAsset, AVPlayerItemのサブスレッドで生成
- AVPlayerもサブスレッドで生成可能だが、メインスレッドで生成した方が良かった
- 破棄はサブスレッド
- スレッドの細かい調整が重要
- 端末の大きさ、解像度に合わせて最適なbitrateを指定する
- playerの監視
- Notification
- AVPlayerStatus
- playback buffer
- TimeControlStatus
- AVPlayerItemAccessLog：すべて取れる
- AVPlayerItemErrorLog：nonfatalなエラーログも含まれる
- 動画再生の状態を分析するにはメトリクスをサーバに送る必要がある
- いくつかサービスがあるので使用を検討すると良い
差分計算アルゴリズムを用いた高速なUITableView描画
- UITableViewを速くしたい
- 描画する行が少なければ速い。差分更新
- 差分計算には多くのアルゴリズムがあるので使うと良い
- 各アルゴリズム毎に計算量が異なる
- Dwifft：Myer法
- EditDistance：Wu法
- RxDataSources:Heckel法+α
- DifferenceKit:Heckel法+α
- パフォーマンスを比較
- Heckel法のものが速い
- UIのレイアウトも含めてパフォーマンスを比較
- 1000行の変更。Cellのレイアウトが単純だったためか、reladDataが早かった
- より現実的な100行の変更。DifferenceKitのみreloadDataより少し早かった
- 日経電子版ではRxASDataSourcesを採用した
- 差分更新は計算コストがかかるので損益分岐点を見極めて差分更新を行うか、reloadDataを使うか選ぶ必要がある
