1.8秒の起動アニメを測ったら、6秒・1.36秒・4.17秒と出た — 測る道具が順番にずれていた — 制作日誌 #41

タスク管理アプリの起動画面に、短いアニメーションを入れた。アプリ名の文字が少しずつ濃くなり、わずかに寄ってきて、小さな星がまたたき、最後に画面全体がふっと消えて本体に切り替わる。全体で2秒に満たない動きだ。

作った本人の感覚では気持ちよく流れるはずだった。ところが実際に開くと、最後の「ふっと消える」だけがいつまでも残る。設計では1.26秒の時点で消え始めるのに、体感では4秒近く画面に居座っていた。

この記事は、その原因の話であると同時に、直したあと「本当に直ったか」を測ろうとして、測る道具に4回だまされた話でもある。

最初のずれ：1.26秒が4秒近くになった

アニメーションを作るときは、それぞれの動きに「どれだけ待ってから始めるか」と「何秒かけて動くか」を指定する。最後のフェードには「1.26秒待ってから消え始める」と書いていた。

使っている部品には、動きを端末側に任せて滑らかにする設定がある。それを有効にしていたので、時間の管理もすべて端末側でやってくれていると思い込んでいた。

実際は違った。端末側に任されるのは「何秒かけて動くか」の方だけで、「何秒待つか」はアプリ本体の処理の中で数えられていた。そしてアプリ本体は、起動直後がいちばん忙しい。画面の部品を組み立て、保存してあるデータを読み、サーバーとのやり取りを始める。その間、待ち時間を数える係の順番が回ってこない。

結果として、待ち時間を指定した段だけが、丸ごと数秒後ろへずれていた。文字が濃くなる動きは待ち時間なしで始まるので予定どおり動き、最後のフェードだけが置いていかれる。体感とぴったり合う。

ここで直し方は決まった。動きごとに待ち時間を持たせるのをやめ、時計を1本だけにする。0から全体の長さまで一定の速さで進む値を1つ用意し、文字の濃さも、寄りも、星も、最後のフェードも、すべて「その時計が今どこにいるか」から計算する。順番に並べる指定も、同時に走らせる指定も使わない。待つという行為そのものを無くせば、待ち時間が遅れることもない。

直した。あとは長さを測って、設計どおりかを確かめるだけのはずだった。

道具1：開発用の実行で測ったら、約6秒

まず、いつもの開発環境で起動して測った。開発中は、コードを書き換えるとすぐ画面に反映される便利な実行方法を使っている。

結果は約6秒。直す前より長い。

よく見ると、アニメが途中で数秒止まり、そこから再開していた。開発用の実行では、画面を組み立てる作業が重く、その間は動きを描く側まで固まる。これはアニメの性質ではなく、開発用の実行の性質だった。

本番の利用者はこの重さを経験しない。開発用の機能を外し、中身を圧縮した、本番に近い形で起動し直すと、途中で凍る現象は消えた。最初の教訓はこれだった。動きの長さは、開発用の実行では測れない。

道具2：画面を録画して数えたら、1.36秒

次に、エミュレーター（パソコン上で動かす仮想の端末）の画面を録画し、コマを数えて長さを出そうとした。

録画を1秒あたり50コマに並べ直して数えると、1.36秒。今度は短すぎる。設計は1.8秒前後のはずなので、2〜3割縮んでいる。

原因は録画の仕組みにあった。このエミュレーターの録画は、一定の間隔で撮っているのではなく、画面の絵が変わったときだけコマを残す。30秒の録画で残っていたコマは128枚、平均すると1秒あたり約4コマしかない。しかも、その間隔はばらばらだ。

それを「1秒に50コマ並んでいる」ものとして並べ直すと、本当は間が空いていたところが詰められ、時間が縮む。1.8秒の動きが1.36秒に見えたのはそのためだった。

正しい測り方は、コマを並べ直さず、それぞれのコマに刻まれている「撮られた本当の時刻」を読むことだ。最初の変化のコマと最後の変化のコマの時刻を引き算すれば、間隔がばらばらでも長さは正しく出る。コマの数ではなく、コマの時刻を見る。

道具3：直したのに、古い画面が出ていた

測っている途中で、直したはずのフェードがまだ古い動きをしている、ということが何度かあった。

Android向けの作業は、本体とは別の作業フォルダで行っている。開発用の配信の仕組みは、そのフォルダの変更を見張れていなかった。書き換えても端末に届くのは古い中身のままで、「直したのにまだこれ」が続く。

これは測り方というより、測る対象がそもそも新しくなっていなかったという問題だ。対策は、直すたびに配信の仕組みを空にして入れ直すこと。そして、端末に届く中身を直接取り出して、書き換えた箇所が入っているかを文字で探すこと。目で見て「変わった気がする」で済ませず、届いている物そのものを確かめるようにした。

道具4：終わりの合図で測ったら、4.17秒

最後は、アプリ自身に長さを報告させようとした。アニメの開始時刻を覚えておき、「動きが終わった」という合図が来た時刻との差を出す。

本番に近い形の実行では、ログ（動作記録）が端末の記録に出てこない。そこでパソコン側に小さな受け口を立て、アプリからそこへ数字を送り、受け口の記録で読むことにした。この仕組み自体はうまく動いた。

出てきた数字は4.17秒。設計上1.796秒の動きなのに、倍以上だ。

これも最初のずれと同じ根を持っていた。「動きが終わった」という合図は、アニメが終わった瞬間に届くのではない。アプリ本体の手が空いたときに、ようやく届く。起動直後は本体が忙しいので、動き自体はとっくに終わっていても、合図だけが数秒遅れて届く。合図が届いた時刻は、動きが終わった時刻ではない。

4つの数字を並べると

設計どおりの長さは、本番に近い形で動かし、録画のコマに刻まれた時刻を読んだときにしか出てこなかった。

同じ罠が、2回出てきた

振り返ると、最初の不具合と4つ目の測り違いは、まったく同じ構図をしている。「待ち時間」も「終わりの合図」も、起動直後にいちばん忙しいアプリ本体の手を借りていた。だからどちらも、本体が詰まった分だけ遅れた。

時計を1本にまとめた直し方は、この詰まりから動きを切り離すためのものだった。その直しを確かめるのに、同じ詰まりの影響を受ける道具を使っていた。測る側が、直したはずの穴にもう一度落ちていたことになる。

数字が出たからといって、それが測りたいものの数字だとは限らない。今は、新しい測り方を使うときに、まず「この数字は誰の時計で数えたものか」を先に確かめるようにしている。