1.
インドの低速な
ネットワーク環境の攻略法

2.
About Me
• 辰濱健一（Kenichi Tatsuhama）
• 徳島県生まれ、徳島県神山町在住
• Sansan株式会社＠神山ラボ
• リモートワークで Eight アプリの開発
• GDG Shikoku スタッフ（Google Developer Group）
• Contacts
• Twitter : @tatsuhama50
• Facebook : kenichi.tatsuhama

3.
徳島県神山町
2
古民家再生や、サテ
ライトオフィスの進
出等で、地方創生の
事例になっている

4.
Sansan 株式会社 神山ラボ
3

5.
インドの低速な
ネットワーク環境の攻略方法

6.
Agenda
5
• Eight のインド展開
• インドのネットワーク事情
• 分析
• 対応

7.
Agenda
6
• Eight のインド展開
• インドのネットワーク事情
• 分析
• 対応

8.
Eight のインド進出
7
https://jp.corp-sansan.com/news/2017/171122_8932.html https://jp.techcrunch.com/2017/11/22/sansan-eight-india/

9.
8
日本でそれなりに動いているので、
英訳をあてたら大丈夫！
と思ってました。。。

10.
Global Feedback
9
日本では再現しない問題ばかり…
• 起動のスプラッシュから切り替わらない
• 名刺画像送信が1分経っても終わらない
• 編集を確定しても全然画面が遷移しない
• 「通信エラー」のトーストがよく出る
etc…

11.
10
これらの問題の
調査・解決のために…

12.
Go India（3/12-24）
11

13.
Go India（3/12-24）
12
↓エベレスト
ランチ約60円

14.
Agenda
13
• Eight のインド展開
• インドのネットワーク事情
• 分析
• 対応

15.
インドのネットワーク事情
14
https://www.sankeibiz.jp/macro/print/180406/mcb1804060500007-c.htm

16.
インドのネットワーク事情
15
• 半径数百mの弱いアンテナを数立て
ている（らしい）
• 町中でも電波にムラあり
• 細い回線をみんなで取り合い
• 瞬断も多い
https://opensignal.com/networks/%E0%A4%AD%E0%A4%BE%E0%A4%B0%E0%A4%A4/jio-
%E0%A4%B5%E0%A5%8D%E0%A4%AF%E0%A4%BE%E0%A4%AA%E0%A5%8D%E0%A4%A4%E0%A4%BF

17.
インドのネットワーク事情
16
• 3GB/Day が 約500円/月 の激安プラン（ 1.6 JPY / Rs ）
→ インターネット人口急増中
https://www.jio.com/

18.
インドのネットワーク事情
17
• そんな環境では、重たいアプリはそもそもユーザに届かない
• 自動アップデート、YouTube 連続再生もデフォルトでオフ…
https://youtu.be/AdfKNgyT438?t=149

19.
Agenda
19
• Eight のインド展開
• インドのネットワーク事情
• 分析
• 対応

20.
分析
20
• 現地で受け入れられているアプリの UX
• New Relic Mobile による分析
• その他のツール

21.
分析
21
• 現地で受け入れられているアプリの UX
• New Relic Mobile による分析
• その他のツール

22.
現地で受け入れられているアプリの UX
22
• 現地で受け入れられているアプリ
• Facebook, Twitter, Instagram, WhatsApp（like LINE）, Uber, …
• いずれも低速なネットワーク環境でも、さほど不自由ない
• 送信に時間が掛かる前提の設計
• 送信に失敗してもオンラインになったら自動的に再送
• 送信中コンテンツの表示
• 画像の段階的表示

23.
Twitter の投稿 UX
23
• 投稿ボタンを押したら即画面遷移
（投稿完了まで待たない）
• 投稿が完了していない Tweet も表示
（網掛け）
• 上部に Progress 表示
↑Progress 表示
投稿中 Twieet
普通の Twieet

24.
Facebook の投稿
24
• 投稿後、即画面遷移
• トップ画面で送信中であることが
わかる
• Notification に進捗表示

25.
オンラインになったら自動再送
25
• オフラインでメッセージを送信しても
UI には送信中として反映する
• オンラインになったら自動で再送する
送信失敗とは出さずに
送信中の UI
オンラインになったら
自動で再送される
オンライン
になった

26.
Instagram の読み込み UX
26
• 画像の読み込みが4段階ぐらいで行われている
動画

27.
27
現地で受け入れられているアプリは、
低速ネットワーク環境を
ちゃんと考慮できていました。

28.
分析
28
• 現地で受け入れられているアプリの UX
• New Relic Mobile による分析
• その他のツール

29.
New Relic Mobile による分析
29
• https://newrelic.com/resource/mobile-monitoring-jp
• 30日間の無料トライアルもあり

30.
New Relic Mobile による分析
30
• HttpRequest Sort
• Response time
• Requests per time
• Total Time
• Total size

31.
New Relic Mobile による分析
31
• Geography Sort
• Response time
• Request per minute
• Total transfer size
• App launches
• Network failure late

32.
New Relic Mobile による分析
32
• Interactions
• Memory
• CPU
• Network
• Threads

33.
New Relic Mobile による分析
33
• Dashboard

34.
34
New Relic Mobile を使うと
様々な角度からの
分析が可能になります。

35.
分析
35
• 現地で受け入れられているアプリの UX
• New Relic Mobile による分析
• その他のツール

36.
その他のツール
36
• Stetho
• Network Link Conditioner
• Charles
• 低速 SIM

37.
その他のツール
37
• Stetho
• Network Link Conditioner
• Charles
• 低速 SIM

38.
Stetho
38
• http://facebook.github.io/stetho/
• Android アプリの通信を Chrome Developer Tools で確認できる
操作したタイミングで
どんな通信が
行われているかわかる
（並列度も！）

39.
その他のツール
39
• Stetho
• Network Link Conditioner
• Charles
• 低速 SIM

40.
Network Link Conditioner
40
• https://developer.apple.com/download/more/
• Mac の通信速度をコントロールできる
• インターネット共有をすれば、スマホの通信速度を低速にできる

41.
その他のツール
41
• Stetho
• Network Link Conditioner
• Charles
• 低速 SIM

42.
Charles
42
• https://www.charlesproxy.com/
• プロキシをたてて通信内容をキャプチャできる
• レスポンスの書き換えも可能

43.
その他のツール
43
• Stetho
• Network Link Conditioner
• Charles
• 低速 SIM

44.
ロケットモバイル（神プラン）
44
• https://rokemoba.com/
↑本家アカウントからの Like

45.
45
これらのツールを使って
改善点を洗い出しています

46.
Agenda
46
• Eight のインド展開
• インドのネットワーク事情
• 分析
• 対応

47.
対応
47
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

48.
対応
48
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

49.
アプリのバイナリサイズ削減
49
• 日本国内とバイナリを分けて機能整理＆軽量化
• 海外で利用しない機能を決め、関連コード＆リソースを含めないようにした
• 60MB → 20MB（66%減）
• アプリ内画像の Webp 化
• minSdk 19 なので、透過 png も webp 化
• 16MB → 12MB（23%減）
• App Bundle 形式での Google Play Store へのアップロード（予定）
• 12MB → 9MB（25%減）

50.
App Bundle
50
• Google I/O 2018 で発表された、Google Play Store への新しいアップロー
ド形式
• その端末に必要なリソースのみをダウンロードできるようになる

51.
対応
51
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

52.
画像の送受信サイズを削減
52
• 送信
• 形式変更：Base64 → Multipart （25%減）
• Multipart → MessagePack にするかも？
• 長辺 max サイズを設定して、必要十分なサイズにリサイズ
• 受信
• 表示に適切な画像サイズ（サムネイル / 中繊細 / 高画質）でリクエスト

53.
対応
53
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

54.
直列通信を並列化する
54
• 直列通信
• A の取得（通信） → B の取得（通信） → C の取得（通信）→ 完了
• 並列化
• A, B, C の取得 ー（待ち合わせ）→ 完了
※もちろん、できる範囲に限る
flatMap を見ると
疑うようになった

55.
対応
55
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

56.
通信結果を待たない UX に変更
56
即画面遷移
＆
送信中名刺も一覧に表示
撮影 送信
送信
完了

57.
対応
57
• アプリのバイナリサイズ削減
• 画像の送受信サイズを削減
• 直列通信を並列化する
• 通信結果を待たない UX に変更
• 通信に失敗しても、オンラインになったら自動リトライ

58.
通信に失敗しても自動リトライ
58
• 従来
• 送信完了まで Progress Dialog を表示して待つ
• 一度通信に失敗したら、ユーザによるリトライが必要
• 対応後
• 送信したら即画面遷移
• オフラインでも、オンラインになったら自動リトライ
• 成功するまでリトライさせる
• これらを WorkManager により実現

59.
WorkManager
59
• Google I/O 2018 で発表されたバックグラウンド処理のためのライブラリ
• 実行条件を指定して、実行可能になったら実行される
• 例）オンライン、充電中、バッテリーが少ない
• リトライ設定も容易
• 並列で実行される
• 処理のチェーンや複数処理の結果の待ち合わせもできる

60.
WorkManager 調査メモ
60
• WorkManager に enqueue した Work は何並列で実行されるのか？
https://qiita.com/tatsuhama/items/83af70d57a1e7b9c9a21
• WorkManager に enqueue されている Worker クラスをアプリのアップ
デート時にリネームした場合の挙動
https://qiita.com/tatsuhama/items/0b8d190665cd632f798f

61.
61
インド展開に向けて
日々日々改善施策を行っています

62.
62
まとめ

63.
まとめ
63
インドの低速なネットワークの攻略法

64.
まとめ
64
インドの低速なネットワークの攻略法
• アプリを軽く
→ Flavor による機能整理・画像のWebp 化・App Bundle 対応

65.
まとめ
65
インドの低速なネットワークの攻略法
• アプリを軽く
→ Flavor による機能整理・画像のWebp 化・App Bundle 対応
• 通信結果を待たない UX に
→ 機内モードによる UX 確認を！

66.
まとめ
66
インドの低速なネットワークの攻略法
• アプリを軽く
→ Flavor による機能整理・画像のWebp 化・App Bundle 対応
• 通信結果を待たない UX に
→ 機内モードによる UX 確認を！
• ツールを活用して分析＆改善を
→ NewRelic Mobile, Stetho, Charles etc…

67.
Fin.