Dropbox & Mailbox: モバイルアプリでの共有ライブラリの利用

http://www.infoq.com/news/2014/05/dropbox-cpp-crossplatform-mobile?

1 comment | 0 points | by WazanovaNews 約3時間前 edited


Jshiike 約5時間前 edited | ▲upvoteする | link

InfoQの記事を読んでもっと詳しく知りたいと思ったので、元ネタを確認して個人的に興味をもったポイントをまとめてみました。

1) Dropbox

  • UIコードは全てnative API (Objective-C/UIkit on iOS & Java on Android)を利用し、モデルレイヤのコードのほとんどは、iOSとAndroidで共有のC++ライブラリにまとめている。
  • UIコードと共有ライブラリが個別のエンティティになっていることで、"separation of concerns"を実現。「サーバがオフラインにならず、遅延がゼロになるクライアントサーバアーキテクチャのようなもの。」
  • UIとC++レイヤは同じデータオブジェクトにはアクセスしない。メッセージでデータのコピーを渡している。
  • 建付けとしては共有ライブラリにあるべきだが、プラトフォーム独自の機能やAPIが存在する場合は厄介。例えば、iOSにおけるNSURLSessionのバックグランドダウンロードや、ファイルシステムのアクセス（デフォルトでiCloudが全てのファイルをバックアップする。）など。共有ライブラリで抽象化したものを用意し、クライアントアプリにネイティブで実装している。
  • その他のプラトフォーム独自のAPIについては代替えを用意。Cocoaで設定を保存するNSUserDefaultsシステムは共有ライブラリでは対応できないので、LevelDBを採用。
  • Objective-CとC++のインターフェースは、Objective-C++を利用。
  • AndroidにおけるC++の呼び出しはNDKを利用したが、使い勝手はよろしくない。Googleのメタビルドシステムgypはそこそこ便利で、Java Native Interfaceはやや大変。
  • 標準のSQLite C APIは今ひとつだが、オブジェクト指向インターフェースにおいてうまくラップしてくれるC++のライブラリ（Objective-CにおけるFmdbのような存在）はいくつかある。
  • UIとC++レイヤがデータを共有しないので、それぞれでスレッドを対処できる。メインスレッドは当然UIのためにリザーブしながら、C++レイヤはごく一部の例外をのぞき、バックグランドのシングルスレッドで実行される。ロックが発生することがほぼなくなるのでシンプル。ネットワークとディスクI/Oが非同期であるという前提に立てば、ほとんどのデバイスは現在二つのコアで構成されているので、その一つをメインスレッド、もう一つをデータストアとして利用することは理にかなっている。
  • Androidのベータテストプログラムを利用することにより、iOSアプリでも使われるコードを実ユーザでテストできるので、Appleへの申請前にしっかり確認ができるようになった。

2) Mailbox

  • 共有のC++ライブラリの役割にはクエリとデータの整合性のフレームワークもあり、それはCore Dataの機能と被る。必要なのはCode Dataの機能の一部であり、AndroidにはCore Data APIはフィットしないので、SQLiteをベースにした独自のフレームワークをつくった。
  • 各プラットフォームごとに、C++クラスをUIコードから抽象化する薄いラッパークラスをネイティブ言語で書いた。
  • DataViewにおいて、deleteは降順、insertは昇順で処理。（詳細説明）

3) Carousel

  • 画像のキャッシュを共有ライブラリで対応している。UIレイヤが現在のviewportのサイズと位置の情報を渡し、受け取ったC++レイヤがどの画像をキャッシュとして持つか判断する。iOSとAndroidでは基本的に同じviewのレイアウトを利用するので、アルゴリズムは共有できる。

Dropbox: ビデオ起動時間短縮の取り組み
Carousel by Dropbox: 遅延のない動きを実現する工夫

#dropbox, #mailbox

Back