固まった・落ちた・起動しなかった — Android を手元のPCで焼いた1か月、5回の故障にアプリのせいは1回も無かった — 制作日誌 #43
制作日誌

固まった・落ちた・起動しなかった — Android を手元のPCで焼いた1か月、5回の故障にアプリのせいは1回も無かった — 制作日誌 #43

画面の自動操作が10分返らない。組み立てが途中で消える。試験用の端末が数秒で落ちる。どれもアプリの不具合に見えたが、原因は全部PCの側にあった。メモリ、フォルダ名、仮想化、そして自分の台本。

KIYODO
#個人開発#アプリ開発#Android#失敗談#制作日誌

Android 版のタスク管理アプリは、ストアに出す前の試験版を自分のPCで組み立てている。組み立てた物は、PCの中に立てた試験用の端末(エミュレーター)に入れて、画面を自動で操作して確かめる。

9月から10月にかけて、この作業で5回つまずいた。症状はばらばらだった。固まる、途中で消える、文字化けして「場所が無い」と言われる、起動して数秒で落ちる、2本目が勝手に止まる。

最初はどれも、アプリか設定のどこかを疑った。実際には5回とも、アプリのコードは1行も関係がなかった。

1回目:10分返らないのを、広告のせいだと思った

9月6日。ログインした後の画面を自動で読み取る試験が、10分以上たっても返ってこなかった。

画面には広告の枠がある。広告が読み込まれ続けて画面が落ち着かず、読み取りが終わらないのではないか。そう見立てて、報告を書きかけていた。

念のため記録を見直すと、別の所にこう出ていた。

There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (malloc) failed to allocate 1551104 bytes.

1,551,104 バイト、つまり約1.5MB が確保できなかった。PCのメモリが尽きていた。

原因は、組み立ての道具(Gradle)だった。この道具は次の組み立てを速くするため、終わった後も裏に居残る。そこへ試験用の端末、画面の配信役、自動操作の道具が重なり、空きを食い潰していた。

居残りを止める命令を1つ打って同じ試験を流し直すと、一発で全項目が通った。

もしあのまま報告していたら、存在しない「広告で画面が固まる不具合」を探して、直す必要のないコードを触っていたはずだ。

2回目:同じ日に、逆向きでも起きた

同じ日の夕方、今度は組み立ての側が落ちた。

Gradle build daemon disappeared unexpectedly

組み立て役が予告なく消えた、という知らせだ。書き方の誤りを示すエラーには見えないので、設定や道具の版を疑いたくなる。だが中身は1回目と同じメモリ不足だった。試験用の端末を立てたまま組み立てたので、今度は組み立ての側が食い負けた。

1回目と2回目を並べると、同じ原因が正反対の顔で出ている。

何が動いていたか出た症状最初に疑った所
組み立て役が居残ったまま試験画面の読み取りが10分以上返らない広告の読み込み
試験用の端末を立てたまま組み立て組み立て役が消える設定・道具の版

メモリ不足は、エラーとして名乗り出ないことが多い。遅くなる、止まる、消える。アプリの不具合と見分けがつかない。

3回目:フォルダ名の日本語で、組み立てが落ちた

9月26日。試験版を作る台本が、2段階で落ちた。

1段目は、組み立ての準備をする道具が、記録を何も残さずに即死した。終了の番号は -1073740791。何が起きたかを示す文章は1行も出ない。

作業場のフォルダ名には日本語が入っている。試しに、そのフォルダを英字だけのドライブ名に見せかけて実行すると、1段目は通った。

ところが2段目で、組み立ての道具がフォルダの本当の場所(日本語入り)をたどり直し、文字化けした場所を探しに行って「その場所は存在しない」と止まった。見せかけでは逃げ切れなかった。

9月19日までは、同じフォルダで普通に組み立てられていた。間に道具の更新があったので、それで日本語の場所が通らなくなったのだと見ている。ただし原因はまだ確定していない。

対処は、英字だけの場所に作業場をもう1つ作ることだった。中身は同じで、置き場所だけが違う。そこから焼くと、10分41秒で最後まで通った。

4回目:試験用の端末が、数秒で落ちた

10月9日。試験用の端末を起動すると、数秒で落ちた。記録には、仮想化の区画を用意できなかったという趣旨の一文だけが残る。

困ったのは、仮想化が使えるかを確かめる命令では「使える」と返ってくることだ。使えると言いながら、起動はできない。

この日に試して効かなかったことは、次のとおりだ。

  • 端末のフォルダに残っていた「使用中」の印のファイルを消す
  • 前回の状態を読み込まずに起動する
  • 割り当てる処理の数とメモリを減らす
  • 起動の仕方を変えて、別の経路から立ち上げる
  • 仮想化を使わずに起動する(この種類の端末は、そもそも動かない)

最後に効いたのは、PCの再起動だけだった。9月にも同じ症状が出て、そのときも再起動まで直らなかった。今は、この一文を見たら試行を重ねずに再起動する、と決めている。

5回目:2本同時に焼いたら、先に終わった方がもう1本を止めた

10月12日。待ち時間を減らすため、試験版を2本同時に組み立てた。片方が途中で止まった。理由は「止める命令を受け取った」。

止めたのは自分の台本だった。台本は1回目の教訓から、最後に組み立て役の居残りを全部止めるようにしてある。「全部」なので、まだ動いているもう1本の組み立て役まで止めてしまう。この日、これを2回踏んだ。

1回目の対策が、5回目の原因になっていた。今は、焼くのは1本ずつと決めている。

31GBに何台まで載るか

5回のうち2回は直接のメモリ不足で、5回目もその対策から生まれた。そこで、このPCで同時に何を動かしてよいか、上限を決めた。

同時に動かすもの結果
試験用の端末2台+組み立て1本動く(上限)
試験用の端末3台(組み立て無し)動く
試験用の端末4台+組み立て1本固まる
組み立て2本片方が止まる(台本の仕様)

PCのメモリは31GB。組み立て1本で6〜8GBを使う。組み立てが終わったら居残りを止めて、試験用の端末の台数を戻す。

5回のうち、アプリのせいは0回

並べてみると、原因はメモリ不足が2回、フォルダ名が1回、仮想化が1回、自分の台本が1回。アプリのコードが原因だった回は無い。

それでも毎回、最初に疑ったのはアプリか設定だった。目の前にあるのがアプリの画面と組み立ての記録なので、そこから考え始めてしまう。

今は、症状を見たら先に次の3つを確かめる。

  • 空きメモリはあるか。記録のどこかに「メモリが足りない」と出ていないか
  • 作業場の場所に、日本語が入っていないか
  • 同じ時刻に、別の組み立てや端末が動いていないか

この3つで外れたら、そこで初めてアプリを疑う。1回目のように、存在しない不具合を報告しかけることは、それで防げる。

コメント (0)

まだコメントはありません。最初の一言を残しませんか?