LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

モバイルアプリの再定義:Facebook Paper開発の舞台裏

Apple原理主義者の大坪です。

「Google先生に"Facebook Paper Origami"+日本語記事でお伺いをたてた結果が何故これほど少ないのか」

と疑問に思う今日この頃です。ひょっとして私一人だけが錯乱しているのでしょうか。

という根本的な疑問からは目をそらして、昨日見つけた文章について紹介します。

Paperでもっともわかりやすい「新インタラクション」はiPhoneを傾けることで、画面より大きな画像を閲覧する“tilt-to-explore”でしょう。(下の動画の52秒あたりから)

それが初めて披露された時の様子は以下のようだったとのこと。

“Everyone’s jaws just dropped,” remembers Michael Reckhow, who was sitting beside Matas that afternoon. “Everyone started exchanging these glances that were like: ‘What did he just do?’” 引用元:Facebook Paper Has Forever Changed the Way We Build Mobile Apps | Wired Enterprise | Wired.com

いいかげんな訳:Matasの隣に座っていたMichael Rechhowはこう語る。「みんな顎が外れるほど驚いた。お互い顔を見合わせて”今彼はなにをやったんだ?”と言わんばかりだった」

しかしここで驚くべきはその結果だけではない。"tilt-to-explore"を開発したMike Matasはプログラマーではなく、Objective-Cは知らない。彼はOrigamiを使ってそのプロトタイプを作り上げたのです。

プロトタイプ作成にOrigamiを使うことのメリットは、このように表現されています。

“With your typical programming language, you have to type in a bunch of code and hit ‘compile,’ and a minute later, you see what you built,” he says. “It’s almost like you’re trying to learn how to play the piano and you have a piano where you hit a couple of keys and then hit a compile button and a minute later you hear what you played.” Origami changes this. 引用元:前掲記事と同じ

普通のプログラミング言語では、山ほどコードを書いて「コンパイルボタン」を押す。すると一分後にその結果をみることができる。これはまるでピアノの練習をしているのに、鍵盤を叩いてから一分後に音が聞こえるようなもんだ。Origamiはこれを変えた。

OrigamiはQuartz Composerで作られており、パラメータやパッチ(「何か」をしてくれる単位です)の結合やパラメータを変更すれば、即座にその結果が動作に反映される。このツールを使っての"tilt-to-explore"の開発はこんな風に行われたとのこと。

Matas had the idea one evening at home — after attempts to add an automatic “Ken Burns effect” to Paper failed to, well, pan out — and the next morning, he spent a few hours mocking it up with Origami. 引用元:前掲記事と同じ

自動的にKen Burns Effectがつくような機能を実現しようとして失敗した後、 Matasは家で良いアイディアを思いついた。そして次の朝数時間作業してOrigamiのtilt-to-exploreのモックを作り上げた。


さて、ここからは

「そうかー。デザイナーの皆さん、Origami使ってがんばってねー」

と他人ごとのように考えていたエンジニアの皆さんの顔が青くなるような話がでてきます。

Paperの実装方法を考えていて気がついたのですが、あのアプリは見かけよりずっと複雑にできている。少なくともApple標準部品を持ってきて「はいできました」という類のものではない。*1Engineer達は、そのアプリを作り上げるためにOrigamiとは別のTool-Tweakという名前-を作り上げたそうです。(このツールはまだ公開されていません)

There are times when the app runs literally dozens of physics simulations that all work in concert — Grant worked on an animation that involved 42 virtual springs — and Tweaks provides a way of instantly changing the behavior of each and every one of these simulations. 引用元:前掲記事と同じ

アプリ内部ではお互いに協調しあう物理シミュレーションが何ダースも同時に動いていることがある。例えばGrantは仮想的なバネが42個必要なアニメーションを作ったことがある。Tweakを使えば、そうした計算のパラメータを即座に変更することができる。

初期バージョンのPhoto Viewerは、車の中で使うと振動やら加速度で変な動きをしたとのこと。

“When we first built it, it felt pretty good in your hand,” he says. “But we noticed that, the more places we took it, it began to fall apart.” With Tweaks, as he rode home on the Facebook shuttle, he could instantly adjust and readjust the filters used to eliminate any irrelevant movement, identifying what worked and what didn’t without having to rebuild and recompile. 引用元:前掲記事と同じ

最初に作った時、普通に使うぶんには上手く動いた。しかしいろんな場所で使ってみると問題が見つかった。帰宅するために乗っていたFacebookシャトルバスの中で、Tweakを使いコンパイルなしでフィルターの調整を行い、何がうまくいって何がうまくいかないかを見つけることができた。

シャトルバスの中でそんなデバッグしたら車酔いするじゃないか、とか言っている場合ではありません。まだ観ぬtweakを使えば、どこでもパラメータチューニングができてしまうのです。つまり彼らは

「こんな複雑なモデルのデバッグは大変だから、モデルを簡単にしよう」

ではなく

「こんな複雑なモデルのデバッグは大変だから、デバッグを簡単にするツールをつくろう」

と考え実際に作ったわけです。

Ok, エンジニア同士諸君。話はまだ終わっていない。

このように、Paperの動作は、かなり複雑な計算の上に成り立っているので通常のアプリの作り方ではうまく動かないとのこと。UIに関連するタスクは全て同一CPUコアで動かし、他のタスクは別のコアに任せる必要があります。そうした「タスク毎のCPUコアへの割当」を柔軟に行うため、彼ら自身でアプリエンジンを開発したそうです。(名前はないそうですが)

この(名無しのアプリエンジン)を使えば、どのタスクをどのコアに割り当てるかが細かく制御できる。これによって、写真をスクロールしていくときに、前の写真がまだ開き終わってないうちに処理を中断し、別のCPUコアでデコードした画像をスムーズに表示できるとのこと。つまり彼らは

「このインタラクションは今のCPUじゃスムーズに動かないから、止めよう」

ではなく

「このインタラクションは今のCPUじゃスムーズに動かないから、動かす為のエンジンを作ろう」

と考え、実行した訳です。

彼らが作り上げたツールはOrigamiだけではなかったのですね...


などと書いているとだんだん気が滅入ってきます。あれですよ。マリアナ沖海戦の前に日本の造船所で一生懸命空母を作っちゃいるけれど、太平洋の向こう側では一週間に1隻空母が竣工していたような状況を思い浮かべたりするわけですよ。

いや、大丈夫。別に我々はFacebookと喧嘩をしているわけではない。Tweakや(名無しのアプリエンジン)もいつかきっとOpen Sourceとして公開されることでしょう。それらを使い、デザイナーとエンジニアがideaと知恵を合わせれば、きっとPaperチームが「公開するんじゃなかった」と後悔するようなインタラクションが実装できるに違いない,,と無理矢理かつ前向な言葉をもってこの文章を締めくくるのでした。

*1:具体的にどう複雑かはこちらのページを参照してください。