try swift 2018 tokyo day 2 参加メモ
try swift 2018 tokyo 2日目の参加メモです。
Expression Problem を解決する
- MapViewのようなものを作るときUIViewのサブクラスを作って解決する
- UIViewだとMacOS, Webで使えない
- どうするか
- Expression Problem: 拡張性の問題
- 解決策
- enumで解決できないか?
- EnumKit
- こういうenumを定義
enum View { case button case textField }
- renderメソッドを定義
extension View { func renderSomething() -> Something { } }
- iOSだとUIViewで実装
extension View { func renderSomething() -> UIView { } }
- Viewを追加したいときにどうするか
- ライブラリに追加するのはよくない
- non exhaustive enumkit はどうか
- デフォルト実装が必要になりよくない
- protocolを検討してみる
- Selfに注目
protocol View { static func button() -> Self
- SelfがREALに置き換わる
extension REAL: View { static func button() -> REAL }
- 新しいViewを追加するときはprotocolを追加
protocol WithMapView { static func map() -> Self }
- もっと知りたい方は Final Tagress Style で検索すると関連した話題が見つかる
- もっと詳しく知りたい人向けに4つの資料を紹介(詳しくは発表資料で)
⚡️🎤 Swift もくもく会 in Barcelona
- 開発者が一箇所に集まって共同作業する場を提供した
Swift によるアルゴリズムの可視化
- Bezier曲線の話
- アルゴリズムについて理解する必要がある
- Playgroundを使ってSwiftで描いてみる
- ライブコーディング
Kitura で Codable ルーティング
- JSONのエンコード、デコードについて
- jsでは簡単
- swiftは型安全に処理する必要がある
- Swift4からEncodable, Decodableが提供された
- Encodableに準拠するコードも大変
- Kitura: Build end-toend application in Swift
- クライアント、サーバを同じ言語で書ける
- Swiftはメモリのフットプリントが低くサーバサイドの実装に向いている
- Kituraとクライアントの実装について。JSONのEncode/Decodeを中心に
⚡️🎤 超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する
- 超解像: 解像度の低い動画を高くする技術
- SEMethod
- Deep Learingを使ったテクニック
- 低解像度の画像をダウンロードし、クライアントサイドでSR On Core MR
- MLModelを学習して用意した
- Modelをアプリに取り込む。とても軽量
- OpenSourceで公開
iOSでCharlesを導入する
- プログラミングを学び始めた1985年ごろデバッグは難しかった
- AdobeでFlushの開発をしていた
- ネットワークを多く使う開発だった
- 問題が発生するとネットワークが問題なのかクライアントが問題なのか判断が難しかった
- iOSでCharlesを使うのは少しめんどくさい
- wifiの設定を変更しなければいけない
- iOS用のCharlesを用意しようと思った
- CharlesはJavaで実装されていた。大変だった
- iPadでも動く
- iOSのCharlesにデータが残る
- デスクトップで確認することができる
- プロキシ設定不要
- コンピュータ不要
- wifi不要(mobile通信でもOK)
- まだAppleレビュー中
拡張現実における体験設計
Swift エンジニアのための Kotlin 入門
⚡️🎤 Swift5のOwnershipに備える
- メモリのパフォーマンスの高度な制御が可能になる
shared
キーワードを使う- コピー不可能な型の提案もされている
- 先発のRustでも学習コストが取り上げられている
- Rustは理解必須だが、Swiftはオプトイン機能
デジタル信号処理 in Swift
- DSP
- 信号を操作するテクニック
- デジタル音声はフーリエ変換なしに考えられない
- フーリエ変換とは音を聞いたときの耳の反応
- AVFoundaionはかなり強力
- Swiftで見逃しがちの事に焦点を当てたい
内容が難しく理解できなかった。
15:25 - ⚡️🎤 Codableが導く型安全な世界
- Codable: Support Encoding, Decoding
- Codableはjson以外にも使える
- protocolと組み合わせるとうまく使える
- userDefaults/keychainにも使える
- Dictionary, URLQueryのCordableを実装してみた
iOS / Swift における対話型インターフェースの作成
- 対話型インターフェースの音声のインターフェースについて
- おじいちゃん、おばあちゃん。対話型インターフェースなら使える
- 魅力:面倒なことはソフトウェアが行ってくれてユーザの負担が少ない
- 音声認識を行う方法はいくつもある
- いずれも音声認識はサーバ側で行われ、結果がクライアントに戻ってくる
- iOS Speech Recognition APIの実装の紹介
- Amazon Lexの実装の紹介
UIImageView vs Metal
画像表示とGPU
- 画像表示の基本的な処理の流れ
- processerは2種類
- CPU:スポーツカーのイメージ。はやいが多くの人は乗せられない。
- GPU:バスのイメージ。はやくないが多くの人を乗せられる。
- pixelの処理順番が変わってOK。画像処理はGPUに向いている
metalとopenGL
metalの実装
- metalを使うとコード量が多い
- Metalのwrapperクラスがあれば良いのでは
- MetalImageViewを作った
パフォーマンス比較
- TableViewに画像を表示するサンプル
- metalの方が早い
- UIImageView: 0.4 0.6
- metal: 0.02 0.05
- スクロールするとMetalが遅い
- 先程の計測だとGPUの処理が含まれていなかった
- 修正結果
- UIImageView: 0.4 0.6
- metal: 40 200
- UIImageViewは既に早い
- WWDC2017のPlatforms states of the unionでUIKitは既にmetalを使っていると発表されていた
- metalを使った自分の実装がなぜそんなの遅かったのか
実装の確認
- Instrumentsでtraceしてみた
- resize->renderingという処理
- この処理の間に時間がかかっていた
- GPUの処理完了をCPUで待っていた
- resize, renderingでCPU,GPU行き来していた
- resizeとrenderingを同じCommandBufferにまとめた
- 短縮できた
- texstureのキャッシュが必要
- GPUではどこでキャッシュするか気をつけなければいけない
- CPU側にキャッシュしてしまうと遅くなる
⚡️🎤 Swiftが動くDockerコンテナの各OSの性能比較
- Ubuntu 14.x and 16.x
- Swiftのバージョンアップにより安定した環境を用意するのは難しい
- Dockerを使う
- vaporのDocker Imageを用意した
- Ubuntuバージョン間のパフォーマンス比較をしたが、差がほとんどなかった
- imageの容量の差 16.xのほうが小さかった
⚡️🎤 型とパフォーマンスで見るType-erasureの利点
niwatakoさんのまとめ
https://github.com/tarunon/try-erasure
VisionとCoreGraphicsで顔をでかくする
- 顔の領域を取得する方法を探した
- Visionでは顔の下半分しかとれない
- Visionの下半分の情報を反対側にも描くことでやってみた
- 点の操作にCoreGraphics
- うまくいった
開発者ツールと経験への時間投資
いくつか例を見ていく
コンパイルに時間がかかる
フレームワークを分ける
- アーキテクチャが良くなる
- ビルドが早くなる
フレームワークを分けられない場合
- Code Injection
- playgrounds
データに対する依存
- アーキテクチャを整備していれば解決できる
- アーキテクチャのレイア間でprotocolを使う
- fileアクセスもサーバリクエストも同じAPIで操作できるFilewatchersを使った
- ファイルの変更が直ぐに反映される
手動データ入力(ログイン画面など)
- 開発時にいちいちデバイスに手入力するのは面倒
- 自動化すべき
- breakpointを設定して設定すると一番簡単
- 多くのステップが多い場合は向かない
#if
でデータを設定するようにする
問い合わせ対応
ボイラープレートコードを書くこと
- 毎回お決まりのコードを書く必要はない
- ライブラリを作った
- ライブラリが動くなくなったら削除し、コードを書く作業に戻すだけ。導入しやすい・
- テストのFakeオブジェクト作成にも使える
asset
- SwiftGenが使える