iOSDC 2017 day 1 午後 参加メモ

ios event

iOSDC 2017 1日目午後の参加メモです。

Build high performance and maintainable UI library

  • SpreadsheetViewを題材にした発表

高速なUIコンポーネントを書くためには

  • パフォーマンスチューニングのために大切なこと
    • 計測すること
    • 多くの場合トレードオフがあることを理解すること
  • 基本は負荷の高い処理を減らす
  • UIを遅くする要因を知る
  • UIViewが何をしているのかを理解する
  • UITableView/UICollectionViewのテクニックを学ぶ
  • UIViewについて
    • ビューの数が増えるほど遅くなる
    • 生成のコストは比較的高い
  • パフォーマンスチューニングにはコードの読みやすさやテストのしやすさが犠牲になることが多い
  • バランスの見極めが腕の見せ所

メンテナンスしやすいコード

  • テストしやすいコードはメンテナンスしやすいコード
  • 内部状態、入力、出力が明らかだとテストしやすい
  • UIのテストが困難な理由
    • 内部状態が複雑
    • 状態を変化させる要因が多い
  • テストしやすいコードのために大切なこと3つ
    • データの流れを1方向にする
    • 状態をモデルに分離する
    • 振る舞いを分離する
  • アクション→モデル→ビューと一方向にする
  • 役割を複数担っていても1方向にすることは価値がある
  • 依存関係には2つある
    • 状態の依存関係
    • 振る舞いの依存関係
  • 状態をモデルに分離する。こちらの方が簡単に分離できる
  • 振る舞いの依存関係をなくすにはMockを使う
  • テストしやすいコード、薄いビュー、分厚いモデルで良いコードに

RxSwiftのObservableとは何か

資料置き場
口頭発表原稿

  • ドワンゴの人
  • Reactive ExtensionのObserverbleについて
  • RxSwiftのコードを読む時に参考になる情報がまとまっっている

Observerパターンについて

  • 通知について考えてみる
  • 通知元が通知先に伝える時にどうすればいか考えてみる
  • 通知元が通知先に通知することが解決できる
  • 通知元が複数の通知先に伝える時にどうすればいか考えてみる
  • 通知先のInterfaceが共通でないと、通知先が追加された時に通知元の実装も変更しなければならない
  • そのため通知先に共通するプロトコルを切り、インタフェースを共通化
  • 通知先を配列で持てるようにもなる
  • 通知元がObservable観測可能なオブジェクト
  • 通知先がObserver観測するオブジェクト

Observerパターンのバリエーション

  • pull型のObserverパターン
  • 通知先に通知が届き、通知先が通知元の詳細を知る必要がある場合は取りに行く（pull)
  • push型のObserverパターン
  • 基本構造はpullと同じ
  • 通知先に通知元の詳細を通知する

Rxについて

  • RxのObservableは3点拡張している
    • 通知先に通知する値はEvent(next, error, completed)
    • next以外のEventが通知されるとそれ以降は通知されない
    • unsubscribeの責務をDisposableに分離している
  • push型でもunsbscribeのときはもとのオブジェクトに参照する必要があったがそれを避けるためにDisposableが用意されていると考えている

File数が1300ある巨大SNSアプリを全てSwiftに書き換えてるNow

  • ひま部 学生限定SNSアプリのiOSエンジニア
  • ViewController106個あった（＝画面数が106個という意味ではない）
  • 現在のアーキテクチャ積極的な継承を認めるMVC
  • 最大継承数7, 平均継承数3くらい
  • 直面した問題
    • BaseClassの変更で意図しないところでBugが発生する
    • BaseClassの管理が難しくなり開発スピードが下がる
  • Class継承は変化の伝達が横方向
  • Protocolは変化の伝達が横方向

メルカリで実施した過去最大規模のABテスト「ドロワー vs 下タブ」の舞台裏

  • メルカリでUSアプリの下タブ開発を担当した方

下タブ化とメルカリUSについて

  • 下タブ化は一人で担当した
  • スピード最優先
  • コードベースは4年物
  • 画面数200くらい

メルカリのABテスト

  • 独自実装
  • サーバー側でコントロール
  • 開発当時は20個程度並行して実施
  • 現在のメルカリJPだと40個程度並行して実施
  • ABテストの目的
    • 効果測定
    • 不具合発生時のリスク軽減
    • 深観測のための段階リリース

下タブのABテスト

  • rootViewControllerを変えてABテストを実施
  • AppDelegateがでかくなりそう
  • AppDelegateを見直す
  • Windowいらない
  • WindowのサブクラスのMainWindowを作成
  • obj-cから使えないのでNS_FEFINED_FOR_SWIFTを使ったりした
  • 初回起動時にAB切り替えたいと言われて苦労した
  • depplinkの情報にタブのIndexがなくて苦労した

ABテストの結果

  • 圧倒的な差が出て下タブになった
  • しかし、下タブと同じタイミングで他の変更もしたので本当にタブが良かったのかわからなかった

The latest info of ReactiveSwift and ReactiveCocoa

  • ReactiveSwift と ReactiveCocoa の最新情報について

第３の課金形態「寄付モデル」ってどうなの？

  • Bitcoinによる寄付モデル
  • 最終的にTip Jarにした
  • 今のところ寄付率0%

SwiftでShift_JISをデコードする

Swiftで音楽を奏でる

  • AVAudioEngine, AVAudioNodeを使って音楽を奏でた話

iOSDCだけではもったいない！iOSアプリケーションエンジニアの他言語コミュニティ生存戦略

  • みんなにカンファレンスのスタッフに興味をもってもらうための話

多次元宇宙と画面遷移

  • 画面遷移をrootViewControllerで管理した話

ARC vs. GC？ARC in GC？

  • GCの話
  • ARCもGCの一部
  • GCは参照カウント
  • JVMのGCはトレーシングコレクタ
  • トレーシングコレクタと参照カウントの比較
  • GCは静的自動と動的自動に分類できる

iOSで利用できるデバイスファームのメリット・デメリットの紹介

  • デバイスファームを使った見た話
  • AWS Device Farm, Xamarin Test Cloud, Testdroid TextObjectの比較

ローカライズの苦しみに立ち向かう

発表資料

  • 日本語英語対応しているsansaniOSアプリのローカライズで苦しんだ話

この単語、なんて読むんだっけ？

  • 開発で出て来る読みづらい単語の紹介

クラス名に個人の名前を含めるとこうなる

  • BASEアプリに個人名（イニシャル）を含めた話
  • Crashlyticsに出てきたりISSUEになったりしてねたになる

はじめよう！OSSコードリーディング！

  • コードリーディングのメリットデメリットについて
  • コードリーディングのはじめかた

IPAファイルの中身を覗いてみよう

  • 仕事柄ipaファイルを確認するDeploygateのエンジニアの方の発表
  • ipaファイルをunzipして中身を確認した話

子育てエンジニアの家庭内生存戦略

  • 子育て用のアプリを開発した話

これ、リークしますか？