iOSDC 2017 day 2 午前 参加メモ
iOSDC 2017 2日目午前の参加メモです。
新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減
- 日経新聞社のiOSエンジニアの方
- Live Photosのようなシーケンス画像を効率的に取り扱える
- 深度、透過に対応
- iOS11/iPhone7以上の写真がHEIFで保存されていることを確認
- WebにアップするときはHEIFからJPEGに自動変換される
- 日経新聞の朝刊画像を1週間分HEIF/WebP/JPEGで比較した
- WebPはJPEGと比較して32%削減
- HEIFはJPEGと比較して52%削減
- エンコード処理は細かく調査していないがHEIFが一番遅かった
- HEIFだとハードウェアデコードが可能（A9chip以降に限る）
- HEIFは特許的にグレー(ffmpeg, GPAC/MP4Box)のところがあるので商業目的で使うのは避けた方がいい
- 特許的にクリーンな方法を考えてみた（力技）
- iPhoneをサーバしてHEIFエンコードするシステム
結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発
- メルカリ カウルのiOSエンジニアの方
- 結婚式用のアプリを作成したアプリ
- 写真を取って、サーバに送る
- その写真にいいねできる
- お知らせの表示
- Push通知
- Firebase Storage, Firebase Database, Firebase Notificationを利用して実現
触り心地の良いInteractive Transitionをマスターしよう
- エウレカでリードエンジニアとスクラムマスターを経験
- アニメーションにこだわっているアプリは海外製が多い
- アニメーションの基礎をマテリアルデザインから持ってきた
- iOSのガイドラインにはあまりアニメーションについて書かれていない
- easing curveとdurationを意識
- duraionの基準を設けてアプリで統一すると良い
- 画面外への移動
- 画面内への移動
- フルスクリーンの移動
- 人が遅いと感じる限界は400ms。その基準も設ける
実装について
- アニメーションの2つのプロトコル
- AnimatedTransitioning 通常のアニメーション
- InteractiveTransitioning インタラクティブなアニメーション
- 遷移のアニメーションはTransitioningDelegateで決める
- 今日はInteractiveTransitioningについて
- PanGestureでdispossしていく
- duration 0.1にすると素早くジェスチャーした時に自然に見える
- 指を離した時にSpringAnimationをしたい
- UIViewAnimationのDurationを指定する必要がある
- 適切なDurationの値は連立方程式を解く必要がある
- そこでFacebookのpopを使う
AutoLayout と友達になる方法
- CyberAgentのエンジニアの方
- IB上で行うAutoLayoutの設定の話
- 友だちになる＝1人でAutoLayoutを組めるようになる
- 大切なこと２つ
- 制約の正しい付け方と種類を理解する
- 本当に正しい制約が貼られているか確認する
iOSDC 2017 day 1 午後 参加メモ
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？
iOSで利用できるデバイスファームのメリット・デメリットの紹介
ローカライズの苦しみに立ち向かう
- 日本語英語対応しているsansaniOSアプリのローカライズで苦しんだ話
この単語、なんて読むんだっけ？
- 開発で出て来る読みづらい単語の紹介
クラス名に個人の名前を含めるとこうなる
- BASEアプリに個人名（イニシャル）を含めた話
- Crashlyticsに出てきたりISSUEになったりしてねたになる
はじめよう！OSSコードリーディング！
- コードリーディングのメリットデメリットについて
- コードリーディングのはじめかた
IPAファイルの中身を覗いてみよう
子育てエンジニアの家庭内生存戦略
- 子育て用のアプリを開発した話
これ、リークしますか？
- メモリリークの話
iOSDC 2017 day 1 午前 参加メモ
iOSDC 2017 1日目午前の参加メモです。
Auto Layoutのアルゴリズム
内容が難しすぎたので間違っている可能性があります。
- Auto Layout制約はレイアウト属性と関係性を定義する
- Auto Layoutは宣言的に記述でき、ビュー階層に依存しないなどの特徴がある
- Auto Layoutは等式だけでなく、不等式も扱えるため、連立方程式ではなく最適解を求める必要がある
- 線形計画問題。実行可能領域を定義しそれに別の式を与えて解を求めていく。例としては、生産計画問題など。
- 解法はシンプレックス法と内点法がある。
- シンプレックス法は差分更新ができるので便利
- ここでcassowary。いくつかの言語でサポートされている
- 数式の説明
- Zを小さくしていく
- x1はマイナスなので大きくするとZが小さくなる
- x2はマイナスなので大きくするとzが小さくなる
- シンプレックス法は外側の線に沿って最適解を求める
- シンプレックス法で最適解が求められない場合がある
- 2段階シンプレックス法を使う
- さらに効率的な方法として双対シンプレックス法がある
- cassowary+シンプレックス法
- レイアウトはマイナスの変数がある
- シンプレックス法を適用するためにマイナスを含む制約と含まない制約に分ける
- autolayoutは2つの属性の関係性のみ制約をつけるが、cassowaryは2つの属性のみではない
- cassowaryのライブラリを公開しているが業務では使わないほうがいい
両OSやるマンという選択
- レアジョブで両OSやってる方
- アップデートはAndroidのほうが頻繁に行っている
売れ方について
- 日本でもAndroidのシェアが増え半々くらいなってきている
- 中国はPlay Storeがないがシェアが高い
- Androidはストアの内容をほぼ全てABテストできる
- ランキングにソーシャルの影響が出る
作り方について
- デザインガイドラインが異なる
- Androidのマテリアルデザインガイドラインに「マテリアルはメタファーである」とあるがよくわからない
- クロスプラットフォームはキャリアとして怖いのでネイティブでやっている
- Androidの方は開発環境と言語の依存が少ない
- CI/CDはiOS/AndroidともにBitriseを使っている
- 簡単に使えるのでおすすめ
- AndroidはPlay Storeに上げるために一手間必要
作るものについて
- SwiftとKotlinの違いをさくっと
質疑
アプリエンジニアはどのように事業に貢献すべきか
- Fablicのチームリーダの方。アプリエンジニア6年目
- アプリチームは3人チーム
- どうやってユーザを喜ばせるか、ビジネスを成功させるか、これらを両立させるかについて考えている
- 自分が考える理想のサービス：ユーザと自分たちでポジティブなサイクルを回せるサービス
- ユーザが価値を感じ、その価値に対して対価を払ってもらえること
- 対価をもって、よりよいサービスを提供していけること
- FRILの価値
- ものの売り買いを安心してできることがもともとの価値
- 遠く離れた知らない人でも安心して売り買いができること
- フリマアプリはUIや機能性による価値は弱まっているのが現実
- このような環境でもアプリエンジニアとしてどうやって貢献していけばよいか
- ポジティブなサイクルがあるならユーザに喜んでもらうことが一番
- アプリの重要度はさがっているかもしれないが、サービス本来の価値をもとにアプリを改善していく
- サービスの価値をアプリにどう落とし込むかがミッション
- ユーザからみたFRILの価値
- アプリは手段でしかない
- アプリの機能だけではなく取引体験を良くしていく必要がある
- 自分たちで課題を発見して改善していく仕組みを頑張って整備している
- アクセスログやBigQueryにExportしたFirebaseAnalyticsの生ログをRedashからアクセスできるようにしている
- アプリの変更点をサポートチームに共有しサポートしやすいように
iOSDC 2017 前夜祭 参加メモ
iOSDC 2017 前夜祭の参加メモです。
SiriKit and Me
SiriKitについて
- 対応しているアプリ
- 全国タクシーとUberでタクシーを呼び出せる
- LINEでメッセージが送れる
- OpenTableでレストランを予約できる
- Siriを使えば目の見えないユーザに対してもサービスを提供できる。
- HomePodの発売も控えている（今のところアプリの発表はされていない）
SiriKitの実装について
- SiriKitはフレームワークではなくIntentsとIntents UIフレームワークで実装する
- SiriKitはAppExtensionの一種
- iOS11では23種類のAppExtensionがある
- AppExtensionはHostAppと一緒にリリースされるが、プロセスは別
- iOSではメモリ空間がプロセスごとに制限されている
- HostAppとの情報共有はアプリ間で共通で使えるFile StorageのAppGroupを利用する
- Siwikitの処理にはタイムアウト制限がある
- ネットワーク処理は厳しいのでキャッシュを使う必要がある
- Sirikitはエラー情報の取得が難しい。成功、失敗しか返さない。
- エラーの情報はSirikitのフレームワークのログを見て確認する
- SiriKit更新が早い。マイナーバージョンアップで破壊的な変更やUIの変更がある。
- 英語では正しく動くけど日本語では動かないということよくある
- SiriKitは実装量は少ないが、デバックが大変
Objective-C++を使ってMRCで快適に開発する
- Objective-C, Objective-C++, C++を使うときのメモリ管理（ARC/MRC）について
Swaggerで始めるAPI定義管理とコードジェネレート
- なぜAPI定義を明文化するか
- サーバ、クライアントでOptionalなどの認識を合わせられる
- Swaggerはコードジェネレートも用意されている
- コードをジェネレート、設計とコードの乖離を防止する
- Swift, Kotlin Javaにも対応している
Swiftのコードジェネレート
節子、それViewControllerやない…、FatViewControllerや…。
- なぜViewControllerの責務分けが注目されるのか
- ViewControllerがiOS開発の重要な機能を多く持っている
- それゆえに多くの機能が実装される
- Fatはコード量ではなく責務が多いことが問題
- いかにして責務わけを実現するか。本日はMVPを紹介
- Presenterにおける描画処理をInterfaceとして定義
- ViewControllerがInterfaceを実装
良い目標の4つの特徴
- 明確
- 小さく
- 肯定的
- 行動の形
try! Swift Tokyo 2017 day1 参加レポート
先日、上記イベントに参加させて頂きました。その1日目のレポートになります。
各セッションの詳細は後日realmからアップ予定の動画や、niwatakoさんの聞き起こし一覧にお任せして、
本記事では各セッションの内容を簡単に紹介します。
10:00 - Swift開発者が知りたかったけど聞きにくい機械学習のすべて
- niwatakoさんの聞き起こし
- 機械学習の入門的な内容から、iOS開発者から見た機械学習について紹介されていました。
- iOSデバイスは曖昧な世界(現実の世界)からの入力を受け付けています。そういった点で機械学習にはよい環境だそうです。
10:20 - Swift on Android
- niwatakoさんの聞き起こし
- SwiftでAndroid開発をする話でした。
- ほとんどがCとC++の話で詳細は理解できずに、難しいことだけわかりました。
- Android NDKも関係してくるのですが、こいつはお粗末な実装になっていてGoogleのサポートも弱いそうです。
11:40 - SwiftのPointy Bits
- niwatakoさんの聞き起こし
- SwiftのメモリとSwiftでPointerを使う話。
- あまり使う機会がなく詳しくないのですが、非常にわかりやすくま止まっていたと思います。
12:05 - アプリを新次元に導く3D Touch
- niwatakoさんの聞き起こし
- 3D Touchで実現できる事とその実装に関する発表でした。
- 3D Touchはユーザに気が付かれにくく、実装しないことが多いと思いますが、3日目におこなられたハッカソンで優勝したチーム（1人チーム）は3D Touchをフルに使ったアプリを開発していました。
12:30 - Pixcels、プロセスと情熱
- niwatakoさんの聞き起こし
- 情熱を持ってプロダクト開発に取り組むアプリをリリースした話でした。
- 「大変なのは技術ではなく人」というフレーズが印象的でした。
- Swiftと関係ない発表でした。
14:30 - 毎日リアクティブ
- niwatakoさんの聞き起こし
- Swiftでリアクティブの話というよりは、リアクティブの話をSwiftのサンプルコードを使って紹介するという感じでした。
- なので、Swiftではこうやるみたいな話はありませんでした。
- 発表者はUstreamのエンジニアで、リアクティブライブラリは何を使っているかという質問にたいして、自社で開発したライブラリを使っていると言っていました。
14:55 - ⚡️🎤 Unsafe Swiftの安全性
- niwatakoさんの聞き起こし
- hashValueの生成にStringではunsafeを使うというLTでした。
15:05 - クックパッドアプリのテストを味わう
- niwatakoさんの聞き起こし
- クックパッドアプリのテストどのような方針で取り組んでいるか(テスト設計?)という発表でした。
- Swiftと関係ない発表でした。
15:25 - ⚡️🎤 データレイヤを分離する
- niwatakoさんの聞き起こし
- データレイアを分離して、データレイアの複雑性をUIレイアなどに持ち込まいないようにしようというアーキテクチャの話でした。
- Swiftと関係ない発表でした。
15:35 - UIをSwiftyに書く
- niwatakoさんの聞き起こし
- UIの実装に限った話ではなく、WebAPIを叩いて表示するシンプルなアプリをSwiftyに書く発表でした。
- enumやprotocolの強力な面を紹介していました。
16:30 - SwiftのWeb APIとアプリをともに構築する
- niwatakoさんの聞き起こし
- WebAPIの設計と、Server Side Swiftに関する発表でした。
16:50 - ⚡️🎤 楽しく便利なSwiftチャットボット
- niwatakoさんの聞き起こし
- LINEのエンジニアによるチャットボットに関する発表でした。
- UIが改善されればもっと良いものになると言っていました。（今後に期待！？）
- Swiftと関係ない発表でした。
17:05 - Realmを使ってコラボレーションアプリを作る
- niwatakoさんの聞き起こし
- お絵かきアプリ(?)をRealm Mobile Platformを使って実装する発表でした。
- Swiftの発表というよりはRealmの発表でした。
17:30 - 独自のツールを構築する
- niwatakoさんの聞き起こし
- SwiftをやめてReact Nativeでアプリを開発した話でした。
- Swiftのメリット・デメリット程度の話はありましたが、React Nativeメインの発表でした。
18:00 - ⚡️🎤 リアルタイム物体検出アプリでよりよいフィードバックを提供する
- niwatakoさんの聞き起こし
- Wantedly Peopleの複数名詞を読み取る機能を実装した際に得た画像処理に関するナレッジを紹介していたLTでした。
18:10 - ⚡️🎤 UXエンジニアという働き方
- niwatakoさんの聞き起こし
- アプリエンジニアもUXを意識しようといLTでした。
第7回ペパボテックカンファレンス～ minneアプリのミライ～ 整理されていないメモ
こちらの勉強会の整理していないメモです。
網羅性はないし、タイポもたくさんあって、自分にしか理解できない内容になってしまっています。
それではどうぞ。
19:35 TableView, CollectionViewのパフォーマンスチューニング minneで実践したこと minne事業部 プロダクトチーム 菊池 和紀（@kichikuchi）
- CollectionView, CollectionView in TableVIew ネスト
滑らかタイムライン
- 無限スクロールの話
- もともとはFooterView表示されたらAPIリクエスト叩いていた
- 先読みしてreloadDataしたけど、reloadDataで画面が一瞬固まった
- 常にEndrefreshing読んでた。isRefreshingでチェックして必要な場合だけ呼ぶようにした
- cellの高さ計算をキャッシュした
カスタムカメラロール
- デフォルトカメラロールは１つずつしか選択できないので複数選択できるカスタムカメラロールを実装
- 選択時にreloadData読んでいたが古い端末でちらついた
- 対策
- visibleCellsをwillDisplayCellでCell更新するようにした。
19:45 minneとマテリアルデザインコンポーネント〜DesignSupportLibraryを添えて〜 minne事業部 プロダクトチーム 望月 美帆（@mochicon)
- TabLayout
- 最初は独自実装していた
- SupportLibraryが提供されてからはそちらを利用する
- FABとBehavior
- Behaviorで位置0が返ってくる不具合？があり使わなかった
- BottomSheet
- Ripple
- ViewにThemeを設定するだけで実装可能
- v21
19:55 minne Androidアプリにおけるチーム開発 minne事業部 プロダクトチーム チーフテクニカルリード 久田 一輝（@hisaichi5518）
- CTLの人
- CTLは部署内の技術方針と技術者組織をマネジメント
- テックリードの役割も担っていく
- テックリードとしてチームの生産性を上げる。一人では無理。
- テストの日を設定。今はみんな慣れたので廃止した。
- 新しくメンバーが入ってきたらテストの日再開してもいいかも。
- Device Farm導入
- MVPアーキテクチャ採用
- テスト書きづらいとかがあったので
- リリース担当を設置
- 環境づくり
- Androidチームでふりかえり
- Androidチーム夕会
- 実際にアプリを見ながらやる
- かんばん
- アナログなかんばんを導入
20:05 minneのApple Pay開発 minne事業部 プロダクトチーム プリンシパル 中島 大地（@nakajijapan）
- Apple Payを導入した話
- ユーザにとって支払いがかんたん
- TouchIDでSecure
- 開発者にとってカード決済不要
- AppleIDの情報入力が結構ザル
- 配送コストを計算する時に名前は取得できない。
- 必要なものを必要なときにというAppleの仕様
- プロパティ更新しても状態変わらないので更新必要なときは毎回インスタンス化している
- ゲスト向けにContactsUIで住所の自動入力などを実装した
- 下記によくまとまっている。
