iOSDC 2018 day3 参加メモ

iOSDC 2018の3日目参加メモです。

AutoLayoutエラー診断所 ~発狂しないためのデバッグ手法~

発表資料-完全版
発表資料-省略版

  • コンソールログを見て、水平方向なんだなくらいを把握する
  • Encapsulatedを探す。これは勝手に生成した制約
  • WTF Auto Layout。ワーニングを貼ると視覚化してくれる
  • 括弧内をコピペしてgoするだけ
  • constraintsAffectingLauout(for:)
  • 暗黙的な制約も含んだ制約を取得できる
  • lldbコマンドでアドレス指定でbackGroundColorを変更してどのViewが対象なのか確認できる
  • 便利なツール:pviews, border

    コツ

  • 固定長でないところを確認する
  • 複数端末で確認する
  • 多くのワーニングが出ていても恐れずに方向を見極めよう

教育・企業におけるデバイス管理手法について

  • 本当にデバイス管理は必要か?おそらくいらないw
  • 目的を明確に!

バイス管理を支える技術

  • Mobile Device Management:構成プロファイル
  • Enterprice Mability Management Service
  • Apple Configurator 2:デバイス構成の管理
  • Apple Busines Manager
  • Apple School Manager

UIViewPropertyAnimatorで実現するリッチなアニメーション表現

コード

  • 画面遷移のアニメーションの実装

圏論

発表資料

資料のスライド:62以降の図にあるU(D)はG(D)のtypoなので注意

iOSDC 2018 day2 参加メモ

iOSDC 2018の2日目参加メモです。

iPhone が数秒おきにクラッシュするんだけど!

  • iPhoneが再起動する
  • 12月2日から突然発症
  • 一部アプリの通知をオフにすると解消
  • Zaimサーバ側、Xcodeにエラーなし
  • 原因判明
  • LocalNotificationをコメントアウトしたら発生しなくなった
  • LocalNotificationなしバージョンを作る
  • ユーザを救いたい。が、アプリ削除、通知オフは避けたい
  • 13月は対象外のエラーメッセージが出ていることがわかる
  • AppleからiOS11.2がリリースされて解消する
  • iOS11.2へのアップデートにはアンインストールor通知オフにしなければならず残念
  • 解消後、Blog, Twitter等で一般ユーザ、技術者向けに情報発信
  • 対象iOS: 11.0.x 11.1.x
  • なぜZaimが対象になったか?
  • 日本がJSTで12月2日になるのが速い
  • 多くのユーザが使っている

まとめ

  • Blog, Twitter等の調査
  • デモコードを可能な限り作って、テストする
  • 英語で騒ぐ
  • 修正版を申請して、広報する

詳解Fastfile

Fastlane活用事例

  • コードレビュー
  • リリースフロー管理
  • サブミット
  • リリースビルド(CIのみ)。slack bot と 定期実行。
  • 社内向けビルド自動化。Enterpriseライセンス
  • メトリクスの監視。ビルド時間、CIのコードカバレッジ

Fastfileの基本

  • ありがちなこと。なんでもfastfileに書きがち
  • 基本的にはRubyで、便利な独自機能もある
  • private_lane。内部からしか呼べないlane
  • private_lane と def は違う
  • returnではなくnextを使う
  • importを使って巨大なFastfileを分割できる
  • # vim: syntax=ruby と1行目に書くとシンタックスハイライトがつく
  • 公式ドキュメントのAdvancedに詳しく書かれている

読みやすいFastfile

  • Fastfileへの記述量を減らしていく
  • Fastfileはコードを書く場所ではない
  • 多くの変数定義をFastfileに書かない。環境変数を使う
  • 設定とロジックを分離する
  • 引数に渡すのではなく設定ファイルGymfileなどに書く
  • Actionを分離する
  • プロジェクトごとにActionを定義できる
  • new_actionコマンド
  • Action分離のメリット
    • パラメータのバリデーションがしやすいConfigItem
    • テストが書きやすいrspec
    • ConfigItemのtype:Arrayはカンマ区切りの文字列がくるとArrayに変換してくれる
  • コードサイン
  • 複雑になりがち
  • コードサインはXcodeで設定するといいがXcodeは不安定なので微妙かも

デバッグ技術

Depth in Depth

  • Depth:深度、奥行き
  • 写真をボケさせるのに使われている
  • その他にも背景を飛ばしたり、3Dスキャンしたり、できる
  • zozosuiteも使っている(っぽい)

深度の種類とセンサ

  • 視差:Disparity
  • 左右の見え方の違い
  • 7/8 Plus, X の背面カメラ
  • DepthはDisparityから計算できる
  • Time??? todo あとで修正
  • 光 Ture Depth??? todo あとで修正
  • iPhoneXの前面カメラ

実装

  • どの方法でも最終的にはAVDepthDataで取得
  • depthDataMap 深度マップのピクセルデータ
  • 方法1:写真から、ImageIO利用
  • 方法2:カメラからリアルタイム、AVFoundationを利用
  • 方法:ARキットから、captureDepthDataというプロパティ
  • 方法に優劣はない。用途によって選ぶ

背景合成について

  • CIBlendWIthMaskを使うだけ
  • CIFilterはMetalのパイプラインで実行されるので速い
  • 深度なので背景が???でうまくいかない
  • 顔認識して深度マップを2値化する
  • ギザギザもある。スムージングで対策
  • 深度が取れないところがある。holesという。RGBで保管
  • isFilteringEnabled便利なプロパティ
  • PortraitMatteがある
  • セグメンテーション特化したマスクを取得できる
  • 利用条件有り
  • 静止画のみ
  • 人が写っていないといけない

ARKit Maniacs

発表資料

QRコード読み取り?楽勝ですよ😙」=>「AVFoundationを信じたおれがバカだった😇」

発表資料

  • 今回の例ではQRコードが8つあった
  • 調べてみる
  • QRコードの連結機能なことを知る
  • 最大16個に分割可能
  • JISの規格を確認
  • 複数のモードがあることも知る
  • AVFoundationでは無理、、、ではなくなった
  • iOS11のCIQRCodeDescriptorで可能
  • ただし、デコードは自前。モード毎に実装する必要がある

Synchronized iPhones!

発表資料

やりたいこと

  • リフレッシュレートに合わせて同じ画面を表示する
  • 誤差は16.66msec以内に抑える
  • リフレッシュレートにあわせた描画にはCADisplayLinkを使う

時刻同期

  • iOSはどのように時刻を合わせているか
  • インターネット上の時刻サーバ(NTP)、GPS、携帯電話回線(NITZ)の3つ
  • どれが優先されているかは公表されていない
  • NTPとNITZはUTCGPSGPS TIME
  • JST, UTC, TAIとGPS TIMEについて

バイス同期

  • 時刻同期では実現できないことが判明Bluetoothを使うことに
  • 平均して20-40msecの遅延が発生した
  • 通信の遅延を消去する事を考える
  • 通信時間の削除
  • 通信時間は距離に依存する
  • PeripheralとCentralが相互に誤差を送り合って補正することで遅延を収束させられた
  • 通信障害が発生
  • 接続可能なCentral数は仕様上の制限はないが制限がある
  • 2階層から複数階層にしたが安定性に課題あり

UIViewとUITextInputで作る縦書きのTextView

発表資料

UITextInputの機能の紹介もあり有用

iOSDC 2018 day1 参加メモ

iOSDC 2018の1日目参加メモです。

Markdownをリアルタイムに解析する

  • Izumoの開発で使った技術の紹介
  • Githubに良いライブラリがなかったので自作した
  • カラーリングと入力補助を実装
  • 最小単位で解析(可能であればその行のみで)
  • 絵文字が大変。文字コードを意識する

Swift 4.2 はどのような進化をしているのか

発表資料

Swiftの歴史

  • 2014年、Swift発表
- Swift3で破壊的な変更がどっさり

Swift4.2

APIの変更、追加が7つ

  • ランダム生成
  • ランダム取得
  • 配列シャッフル
  • Bool値の反転
  • 配列の最後から2つ目の取得
  • 配列の全ての要素が一致するか allSatisfy
  • removeAll(where:)

言語仕様が8つ

  • hashを自前で実装しなくてよい
  • CaseIterableでenumで列挙可能に
  • Dynamic Member Lookup
  • IUO型 -> IUO属性、!の型がなくなる
  • Conditional conformancesの改善
  • モジュール間のインライン化

Swift Package Manager、マイナーな変更が3つ

  • ローカルパスも依存関係も指定できるように
  • Swiftバージョンをenumで指定するように

安定したチャットを実現するためのアプリと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を使うか選ぶ必要がある

iOSDC 2018 day0 参加メモ

iOSDC 2018の前夜祭参加メモです。

標準アプリから学ぶ、HIGが教えてくれないiOSデザインのこと

ドアの話

  • ドアはいろいろあるけど違いを意識しない
  • なぜか
  • 何度も利用したことある、同じふるまい
  • 自動ドアが大きな変化だった
  • 自動ドアはなぜ生まれたか
  • 技術の進化、ユーザの進化、高度な要件
  • ボタンが有る自動ドア、ストレスを感じる
  • 目的は達成するがストレスを感じる
  • 正しくデザインされてないものは、目的は達成されど、ストレスを感じる。

教訓

  • 広く利用されているものを利用する
  • 同じ見た目のものは同じふるまい
  • 新しい標準は背景や使い方を理解する

UITableViewについて

  • なぜ生まれたか
  • 技術の進化:スマホ、小さいディスプレイ
  • ユーザの進化;インターネットへの適用
  • 高度な要件:小さなディスプレイでPCと同じ情報量
  • UITableViewは小さなディスプレイを背景に生まれた
  • 近年、ディスプレイが大きくなってきている
  • それにともない全面を覆わないモーダルビュー(ここではSemiModalViewとする)が登場した
  • 初めはMusicアプリでその後、Mapアプリなど多くのアプリで使われ初めている
  • SemiModelViewを確認すると自己完結不要、タスクを完了されることを要求することもないことがわかる
  • このように新しい標準が登場した時はその背景を理解することが大事

キラリと光るテクニック、アプリをデモするときの心構え

発表資料

  • ハンズオンを円滑に行うテクニック
  • ARの普及とともにデモを機会が増えてくるかも
  • ARアプリのハンズオンでの心構えについて

場所

  • ネットワーク問題:オフラインでも動くようにしておくと安全。自前のインフラ以外は信用しない。
  • Wi-Fi/Bluttooth:人が多いとは接続できないケースが有る- 優先LAN:コントロールできるように
  • 電力:足りているか。請求はどれくらいか。
  • 光源:西日本と東日本で違うことがある。シャッタースピード露出を調整して回避

バイス

  • バッテリー;ARは消費が激しい。充電するデバイスとのローテーションを考慮。
  • 落下;ARでは大きく動かすので、落とすことがある。ストラップや保険を検討
  • 多くの人が触るとデバイスベタベタ

iOS

  • ストアからインストールしていないアプリの場合有効期限に注意
  • provisioning profileやtestflight
  • 他のアプリが起動しないようにロックしておくと安心

再利用可能なUI Componentsを利用したアプリ開発

発表資料

コンポーネント化の背景

  • 課題
  • テキストサイズが指定と異なる
  • Storyboadで指定している色の変更漏れ
  • 複数の画面で同じようなUI実装
  • デザインチームから出たアプローチ
  • デザインシステムを用意する
  • スタイルガイドを定義(カラースキーマ、テキストスタイル)
  • UIコンポーネントを定義(ボタンなど)
  • Sketchのライブラリでできる

コンポーネント化の戦略

  • atomic designに従う
  • 5つの階層:原子、分子、有機体、テンプレート、ページ
  • atomic designに沿って現状のデザインシステムを整理
  • 有機体がなかった
  • それは良いことなのか検討し、なくても良いと判断
  • 決めたこと
  • 原子と分子という2層で考える
  • 再利用されるものだけコンポーネント化する
  • inbision/zeplinでのデザイン共有を廃止。スタイル情報、シンボル情報が欠落するため

実装

  • enum, 関数, カスタムViewなど必要に応じて定義
  • Storyboardでのスタイル適用は行わない(IBInspectableにenumが使えないなどの理由により)

Playground駆動開発のすすめ

発表資料
デモプロジェクト

  • Playground駆動開発を行うための環境構築、進め方の発表
  • とても丁寧でわかりやすかった
  • デモプロジェクトに出来上がっているのでそちらを参考にすると良さそう
  • 実環境ではviewレイアをembedにするのが難しい

アルゴリズムを通じてよりよいアプリを

発表資料

  • 今年のWWDCのメージはアルゴリズム
  • ランダウの記号
  • iOS12でAutoLayoutが指数時間から線形関数に改善される
  • 線形関数であっても傾きがある
  • updateConstraintsでレイアウト成約の最初期化が走ることがありコストになる
  • Swift型とFoundation型の間にブリッジコストがある

ループ

  • Raw Loopを使うとバグが生まれやすい
  • 標準ライブラリで用意されているメソッドを使うこと

まとめ

アルゴリズムを勉強しましょう 標準ライブラリを読みましょう RawLoopを避けましょう

try swift 2018 tokyo day 2 参加メモ

try swift 2018 tokyo 2日目の参加メモです。

Expression Problem を解決する

発表資料
niwatakoさんのまとめ

  • 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

niwatakoさんのまとめ

  • 開発者が一箇所に集まって共同作業する場を提供した

Swift によるアルゴリズムの可視化

niwatakoさんのまとめ

  • Bezier曲線の話
  • アルゴリズムについて理解する必要がある
  • Playgroundを使ってSwiftで描いてみる
  • ライブコーディング

Kitura で Codable ルーティング

niwatakoさんのまとめ

  • JSONエンコード、デコードについて
  • jsでは簡単
  • swiftは型安全に処理する必要がある
  • Swift4からEncodable, Decodableが提供された
  • Encodableに準拠するコードも大変
  • Kitura: Build end-toend application in Swift
    • クライアント、サーバを同じ言語で書ける
    • Swiftはメモリのフットプリントが低くサーバサイドの実装に向いている
  • Kituraとクライアントの実装について。JSONのEncode/Decodeを中心に

⚡️🎤 超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する

niwatakoさんのまとめ

  • 超解像: 解像度の低い動画を高くする技術
  • SEMethod
  • Deep Learingを使ったテクニック
  • 低解像度の画像をダウンロードし、クライアントサイドでSR On Core MR
  • MLModelを学習して用意した
  • Modelをアプリに取り込む。とても軽量
  • OpenSourceで公開

iOSでCharlesを導入する

niwatakoさんのまとめ

  • プログラミングを学び始めた1985年ごろデバッグは難しかった
  • AdobeでFlushの開発をしていた
  • ネットワークを多く使う開発だった
  • 問題が発生するとネットワークが問題なのかクライアントが問題なのか判断が難しかった
  • iOSでCharlesを使うのは少しめんどくさい
    • wifiの設定を変更しなければいけない
  • iOS用のCharlesを用意しようと思った
  • CharlesはJavaで実装されていた。大変だった
  • iPadでも動く
  • iOSのCharlesにデータが残る
  • デスクトップで確認することができる
  • プロキシ設定不要
  • コンピュータ不要
  • wifi不要(mobile通信でもOK)
    • まだAppleレビュー中

拡張現実における体験設計

niwatakoさんのまとめ

  • 現実の種類
    • VR
    • AR
    • Mixed R
    • 素晴らしいAR体験をするためにどうすればいいのか
  • デザインプロセスの話
  • 頭にあるアイデアは完璧に思えるので紙にかけ
  • イテレーションのサイクルを短くする

Swift エンジニアのための Kotlin 入門

niwatakoさんのまとめ

⚡️🎤 Swift5のOwnershipに備える

niwatakoさんのまとめ

  • メモリのパフォーマンスの高度な制御が可能になる
  • sharedキーワードを使う
  • コピー不可能な型の提案もされている
  • 先発のRustでも学習コストが取り上げられている
  • Rustは理解必須だが、Swiftはオプトイン機能

デジタル信号処理 in Swift

niwatakoさんのまとめ

  • DSP
  • 信号を操作するテクニック
  • デジタル音声はフーリエ変換なしに考えられない
  • フーリエ変換とは音を聞いたときの耳の反応
  • AVFoundaionはかなり強力
  • Swiftで見逃しがちの事に焦点を当てたい

内容が難しく理解できなかった。

15:25 - ⚡️🎤 Codableが導く型安全な世界

niwatakoさんのまとめ

  • Codable: Support Encoding, Decoding
  • Codableはjson以外にも使える
  • protocolと組み合わせるとうまく使える
  • userDefaults/keychainにも使える
  • Dictionary, URLQueryのCordableを実装してみた

iOS / Swift における対話型インターフェースの作成

niwatakoさんのまとめ

  • 対話型インターフェースの音声のインターフェースについて
  • おじいちゃん、おばあちゃん。対話型インターフェースなら使える
  • 魅力:面倒なことはソフトウェアが行ってくれてユーザの負担が少ない
  • 音声認識を行う方法はいくつもある
  • いずれも音声認識はサーバ側で行われ、結果がクライアントに戻ってくる
  • iOS Speech Recognition APIの実装の紹介
  • Amazon Lexの実装の紹介

UIImageView vs Metal

niwatakoさんのまとめ

  • Metalを通してGPUレイアについて
  • UIImageViewとMetalのグラフィックスレンダリングパフォーマンスの比較

画像表示とGPU

  • 画像表示の基本的な処理の流れ
    • processor -> FrameBuffer -> screen
    • 60フレームならprocessorが1秒に60回書き込む
  • processerは2種類
    • CPU:スポーツカーのイメージ。はやいが多くの人は乗せられない。
    • GPU:バスのイメージ。はやくないが多くの人を乗せられる。
  • pixelの処理順番が変わってOK。画像処理はGPUに向いている

metalとopenGL

  • yourapp -> metal -> GPU
  • metalとopenGL
    • openGLiOS以外の多くのプラットフォームで動く
    • metalはAppleのハードウェアに最適化されている

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の性能比較

niwatakoさんのまとめ

  • Ubuntu 14.x and 16.x
  • Swiftのバージョンアップにより安定した環境を用意するのは難しい
  • Dockerを使う
  • vaporのDocker Imageを用意した
  • Ubuntuバージョン間のパフォーマンス比較をしたが、差がほとんどなかった
  • imageの容量の差 16.xのほうが小さかった

⚡️🎤 型とパフォーマンスで見るType-erasureの利点

niwatakoさんのまとめ
https://github.com/tarunon/try-erasure

  • closuereを使用しないtype erasureの実装の紹介
  • 各type erasureのパーフォマンスの比較
  • 詳しくはgithubを見る

VisionとCoreGraphicsで顔をでかくする

niwatakoさんのまとめ

  • 顔の領域を取得する方法を探した
  • Visionでは顔の下半分しかとれない
  • Visionの下半分の情報を反対側にも描くことでやってみた
  • 点の操作にCoreGraphics
  • うまくいった

開発者ツールと経験への時間投資

niwatakoさんのまとめ

いくつか例を見ていく

コンパイルに時間がかかる

フレームワークを分ける

フレームワークを分けられない場合

データに対する依存

手動データ入力(ログイン画面など)

  • 開発時にいちいちデバイスに手入力するのは面倒
  • 自動化すべき
  • breakpointを設定して設定すると一番簡単
  • 多くのステップが多い場合は向かない
  • #if でデータを設定するようにする

問い合わせ対応

  • ユーザが見た最後のViewModelをシリアライズ化して保存し、バグレポートに含める
  • 単方向アーキテクチャを使うとログをすべて記録できて再現できるようになる
  • 本当に素晴らしい

ボイラープレートコードを書くこと

  • 毎回お決まりのコードを書く必要はない
  • ライブラリを作った
  • ライブラリが動くなくなったら削除し、コードを書く作業に戻すだけ。導入しやすい・
  • テストのFakeオブジェクト作成にも使える

asset

try swift 2018 tokyo day 1 参加メモ

try swift 2018 tokyo 1日目の参加メモです。

裏 Swift Tour

発表資料

  • 以下の順で紹介
    • 値への代入
    • オプショナルな値への代入
    • Closure
    • enum
    • Never
    • inout
    • return
    • didSet
    • defer
    • init, deinit

以下、気になった点のみメモ

  • オプショナルな値への代入を使って、成功時のみ処理を実行する事ができる
    • (obj.v = 10)?.map { /* do */ }
  • int?にintを足し算できない。一度アンラップしなければならない。
    • 自前でint?にintを足し算するoperationを追加できる
  • Int!を使っているところでIntを使うテクニック
    • 初期値としてnil, 意味のないダミーの値ではなくクロージャを使って解決
    • クロージャはどんな型でもとれる
    • let a: Int = { fatalError() }()
  • inoutの挙動   - didSetがある変数を渡すとコピーが渡され、inoutの関数の最後に代入される   - didSetがない変数を渡すと参照が渡され代入される度に代入される
  • differ
    • initでの値設定ではdidSetが呼ばれないがdiffer内の変更は呼ばれる

SIL入門

niwatakoさんまとめ

  • Swift Compailerの開発の中で得た学びを共有
  • Swift Compailerの中のSILについて
  • なぜSILなのか
    • Swiftの型システムが学べる
    • いろいろな最適化が行われている
    • 楽しい

Clang モジュールの探検

niwatakoさんまとめ

  • Cocoapodsの開発者の発表
  • インポートとかモジュールマップに関する話
  • Ccoapodsの苦労が垣間見える

レスポンダチェーンを知ろう

niwatakoさんまとめ

関心の分離と単純化のためのSwiftコードの最適化

niwatakoさんまとめ

  • コードは書かれることよりも読まれる事のほうが多い
  • howからwhatを切り離す

関心の分離と単純化を行ったサンプルを紹介

  • 1,2: extensionの例
    • utf16.countが複数
    • 例えば3ヶ月後にわからなくなる
    • private extensionでurf16.countをどうして使っているのかの意図を明らかにする
  • 3,4: Autolayoutの例
  • 5: UITableViewの例
  • 6: UserDefaultsの例
  • 7: SafeAreaの例
  • 8: Viewの例
    • タップ領域を確保するViewクラスを用意した
  • 9: UIStackViewの例
  • 10: ViewControllerの例

コーダーがデザインすべきなのか

niwatakoさんまとめ

  • デザインとはどう機能するか
  • コンテキストの欠如を回避する必要がある
  • デザイナは考えないエッジケースをエンジニアが見つける
  • エンジニアとして技術的に何が可能化をチームメイトに理解させる手助けをすべき
  • ユーザはデザインに習慣化していく(ios標準のアラートなど)
  • 子供からは多くの質問が上がってくる、そのようは質問に全て応えられるようにすべき
  • 子供の視点を大切にすべき。未来はそうなっているかもしれない。
  • Appleの3例
    • 録画時のシャッター音を消す
    • Active Device
    • Face ID

Event driven networking for Swift

niwatakoさんのまとめ

変性のダイヤモンド

niwatakoさんのまとめ

  • Swiftの共変、反変の話

SwiftyPi

発表資料 登壇者のリポジトリ
niwatakoさんのまとめ

  • RaspberryPiでSwiftを使う話
  • Swiftがいろいろな環境で使えるようになってきた
  • OSを選ぶ。 Raspbianかubuntuがおすすめ
  • ラズパイをどう立ちあげるのか
  • Swft4.1のARMv7対応はまだ
  • Swift3.1.1をバイナリダウンロード
  • Swiftからpinを指定するにはGPIO番号を使う

我が家を支えるSwiftの技術

niwatakoさんのまとめ

使ってるサービスや技術

UI Test の楽しさとメリット

発表資料
niwatakoさんのまとめ

  • Trelloのエンジニア
  • コードのテストは簡単
  • UIのテストは難しい
  • たくさんのレベルがある。どこのテストを自動化するのか検討する。
  • XCUITestを採用することにした
    • 原因不明の失敗が20%発生するので導入はおすすめしない
  • kickstarterはUnitTestでほとんどテストできているのでUIテストを行っていない
  • 現状のTrelloのGOAL
    • smokeテストの自動化
    • MockAPI
    • Snapshot testing

ブロックチェーンのクライアントをSwiftで実装する

niwatakoさんのまとめ

  • ethereumはAppstoreのようなもの
  • objc or js で実装する
  • block chainはクライアント開発に向いている
    • web3.jsは、ReactNative or webKitを使う

Protocol Oriented WebAPI Abstraction

niwatakoさんのまとめ

👾

niwatakoさんのまとめ

  • Swiftでゲーム開発する話
  • Xcodeでゲーム開発環境は充実している
  • SpriteKitを使って開発
  • SpriteKitはSceneとNodeからなる。UIViewControllerとUIViewの関係のようなもの
  • GameplayKitにゲーム開発のデザインパターンがまとまっている
  • ゲームでrx
    • rxSpritekit

AST メタプログラミング

niwatakoさんのまとめ

  • Abstract syntax tree
  • SourceKitが生成したASTを使ったライブラリがいくつもある
  • ASTはSourceKitのものだけではない
    • SourceKit, SwiftKitten
    • swiftc -dump-parse, SwiftSyntax
    • swiftc -emit-syntax
    • swiftc -dump-ast
  • SoureceKitはc++。SourceKittenはswiftのラッパー
  • swiftc -dump-ast はすべての型情報が含まれている。ただパーサーはない。文字列出力のみ
  • swiftc -emit-syntax jsonフォーマット
  • SwiftSyntax ASTの生成から変更するAPIを提供している
  • SwiftSyntax, swiftc -dum-pastはspecがまだ固まっていない

Aspect Oriented Programing in Swift

  • レイアにまたがった処理の実装。ロギングなどに向いている
  • Swiftのbuildphaseをインターセプトする方法は用意されていない
  • コード生成して再ビルドする仕組みを作った
  • 作ったもの

Droidkaigi2018 day2 参加メモ

詳解 ViewGroupのレイアウト内部実装

http://seto-hi.hatenablog.com/entry/2018/02/03/163035

各ViewGroupの内部実装がどうなっているのか理解できる素晴らしい発表でした。
内容が盛りだくさんでほとんどメモ取れていないので少しだけ。詳しくは資料で。補足も充実してる。

  • MeasureSpecでどの程度でMeasureしてほしいか指定する
  • ConstraintLayoutはCassowaryを使っている
  • Cassowaryを使うほど複雑ではないViewの場合にOptimizerを使う実装になっている

Elastic Team Building

https://www.slideshare.net/YukiNanri/elastic-team-building

  • 現場の生々しい話
  • エラスティックリーダーシップは良い本
  • フェーズ毎に取るべきリーダーシップは異なる
    • サバイバルフェーズ: チームに学習する時間が十分にない状態
    • 学習フェース: 十分なゆとり時間があり、その時間を使って学習や検証を行っている
    • 自己組織化フェーズ: 自分がいなくてもチームがある程度回る
  • それぞれのフェーズでどのようなことがあったか紹介

サバイバルフェーズ

採用

  • 採用に苦労した。コネがない、エンジニアのことがわからない、誰も来ない。
  • グローバルの存在に気がつき、グローバルもターゲットにした。
  • 面接効率が悪い。
  • 面接を2段階にした。1段階目がダメならそこで終了し、効率良くした。

チャットコミュニケーション

  • プライベートメッセージでコミュニケーションする人が多い。情報共有が一部だけになる。
  • プライベートメッセージが来たらパブリックに促すようにする
  • slackのAnalyticsでプライベートとパブリックの比率が見れるので定量的に傾向を分析できる

会議

  • 会議が増えてきた。会議は何も生み出さない。
  • アジェンダのない会議が多く、非効率
  • アジェンダを事前共有してもらうように促していった。フォーマットも用意。
  • ブレストはOK。だが、ブレストで何を決めるかまで明確にして効率的にする。

グローバルメンバーとのコミュニケーション

  • 日本語で始まった会話でも英語になるように促してあげる
  • コミュニケーションを定量化して評価することが難しい
  • 英語を学んでいこうという雰囲気にはなった

学習フェーズ

ドメイン設計

  • ドメイン知識がプランナーからエンジニア等に広がっておらず、認識のずれが大きくなってきた
  • DDDのユビキタス言語の整備と分からないと発言しやすい環境にする

技術的負債

  • 問題になっている箇所をメンバーで話し合う
  • 定量化しずらいなのでどのように評価するかチームで話し合う必要がある

自己組織化フェーズ

  • リモートワークで、自分がいない環境になった
  • 自分がいなくても機能していた
  • リモートワーク大変。解決できていない。

React Native Androidはなぜ動くのか

Reactとは

  • Viewがツリー階層になる。propsもツリー要素になる。
  • 再描画が強い

Reactではないもの

  • React, React DOM, React Nativeに役割分担されている

React Native Andriodとは

JSとJavaのブリッジ機構

  • JavaのクラスをJavaScriptの公開するイメージ
  • @ReactMethodのメソッドは先程のスレッドなのでネイティブのUI処理はUIスレッドで行う必要がある
  • jsとjava側の両方に仮想DOMがある

すばらしきGraphQLのSEKAIへようこそ

https://speakerdeck.com/gfx/subarasikigraphqlfalsesekaiheyoukoso

SSD Schema Driven Development

  • schemaとロジックの開発を同時に進めること

  • リソース取得系が非常に柔軟かつ強力

  • リソース更新系はメリットは少ない
  • GraphiQl
  • リクエストからレスポンスがだいたいわかる
  • 方は基本JSONと同じ。intとfloatの違いはある
  • non nullも定義できる
  • relay
    • ...
  • クエリは手書き

GraphQLとAndroid

  • Appolo Client。クエリからJavaコードを生成するライブラリ
  • 本命はjavascriptかなという感じはある
  • view componentとqueryを同じファイルに書く
  • モデルや腐敗防止層は不要になりそう

gRPCとProtocol Buffersで作る、一味違う通信周り

https://speakerdeck.com/kmats/protobuf

RPC

  • RPCは他のアドレス空間にある処理を実行すること
  • REST:リソースを中心に考える
  • RPC:アクションを中心に考える
  • RESTが向いているサービス:ブログAPI(CRUD)
  • RPCはURLにアクションが入ってくる(事が多い。仕様で決まっているわけではない)
  • CRUDに収まるのであればRESTの方が良い
  • RPCが向いているサービス:slackのようなチャットサービス   - チャンネルを去る leave   - チャンネルから強制的に退出させる kick   - 同じような処理だがちょっと違う   - RESTでは難しい。RPCにしてしまおう。   - 実際SlackのWebAPIはRPC

gRPC

gRPC-Android的に

  • 通信に必要なコードが自動生成される
  • RPCフレームワークとして無難。Googleの安心感
  • 双方向ストリーミング

デメリット

  • 世の中の情報がまだ十分ではない
  • セキュリティに不安
  • Twitch
    • 内部実装の浮く雑さに起因する問題
    • HTTP/1.1を使えない
  • TwitchがTwirpというフレームワークを使った   - シンプル   - HTTP/1.1化   - protobufだが、json mapping化(gRPCはない)prodobufにはある

protbuf

gRPC/protobuf

  • リクエスト部分までコード生成される

開発の工夫

  • 書く環境で.protoファイルをどのように同期するか
  • github webfuck - google cloud functions - digdag

ウィンドウサイズの変更に強い堅牢な画面の構築

https://speakerdeck.com/nakamuuu/droidkaigi-2018

  • 変更
    • 画面回転
    • マルチウィンドウ
  • 弱い画面とは?
    • レイアウト崩れ
    • 画面の状態を適切に保持できない

レイアウトの構築

  • マルチウィンドウ機能により
    • 幅高さともに狭い状態のレイアウトを考慮する必要がある
    • 通常と異なるシステムUIの配置
  • ステータスバーの高さを取得するというアプローチはいったん疑うべき
  • fitsSystemWindows問題
  • fitsSystemWindowsは一つのViewにしか設定できないのか。そんなことはない
  • View#onApplyWindowInsetsをオーバーライドしなくてもOnApplyWIんどwInsetsListnerで横取りすることができる
  • WindowInsetsの扱いを工夫する

画面の状態を適切に保持

  • android:configChangesを指定して自前でも管理できるが基本的にはなし
  • Handling COnfiguration Changeに詳しく書かれている
  • toolargetool
  • onSaveInstanceStas¥te or setRetainInstance
  • 寿命が違うのでデータの保持
  • 復元可能化どうかで使い分ける
  • サーバから取得して復元可能なものはsetRetainInstance
  • 入力途中の状態のものはonSaveInstanceState
  • onSaveInstanceStateからの移行
    • retainer を作った
  • 寿命が異なるものを用いたときの整合性を担保したい
    • AACのViewModelを使う

Gradleプラグインを作って開発効率を改善しよう

https://speakerdeck.com/tnj/guide-to-build-gradle-plugin-for-efficient-development

  • build.gradle
    • 純然たるGroovyスクリプト
    • .gradleファイルはリモートにおける
  • Projectはbuild.gradleと同義に考えて良い
  • Extension
  • 設定値を格納するオブジェクト
  • 実態はJavaBean
  • setting.gradleはルートを示すために必要なのでからで良い
  • バージョン指定するだけ
  • groupは先程のidの前半。 archivesBaseNameは先程のidの最後