この記事を読むのに必要な時間：およそ 1 分
Androidを支える技術〈Ⅱ〉──真のマルチタスクに挑んだモバイルOSの心臓部
（2017年3月，技術評論社）より転載
「Activityのライフサイクルの解説を，Low Memory KillerやActivityManager Service，そしてActivityThreadまで含めてしっかりと解説したい！」これが最初に，一連のAndroidを支える技術を書こうと思った動機でした。いろいろとあって2冊めとなりましたが，無事当初の目標を達成できたと思っています。
ガラケー時代に膨大な画面遷移のデザインについてうんざりするほど長時間議論して開発してきた身としては，既存のAndroid関連の画面遷移に関する文書の不完全さには大きな疑問を持っていました。Webの企業としては先進的なサービスを作り上げたシリコンバレーの企業などがAndroidではまったく素人のような遷移のアプリを出して，それが長いこと放置されていながらAndroidの開発スタイルなどを大手を振って発信しているのを見て呆然としたのもそれほど遠い昔のことではありません。
最初の頃はなぜ優秀なエンジニア達がこんな基礎的なことを理解していないのかと疑問に思っていましたが，やがてPCやWebから来たエンジニアは画面の遷移の重要さを過小評価している実態をさまざまな場面を通して理解するようになりました。今ではモバイルでの遷移のデザインはどうもWebとはまったく違うらしいということは広く知られていて，基本的なことは英語圏なら記事でも見かけるようになりましたが，それでもシステム側と合わせて総合的に解説されたのは本書が初めてのように思います。
「裏に回ったActivityはkillされることがある。その場合は表に来た時に再生成される」これはAndroidのアプリ開発者ならおそらく皆が知っていることですが，その影響範囲はいつも過小評価されています。例えば通信のライブラリを作るプログラマーは，AccountManagerから認証情報のtokenを取得して通信するケースでは，このtokenを依頼して戻ってくるまでの間にActivityがkillされて再生されることがあることを知っていないと困ったことになります。この例に限らずその他のUIが関わらないライブラリでも，この「Activityがkillされることがある」ことがコードの構成に与える影響は甚大です。
どのようなことに影響を与え得るかを列挙するのは膨大になってしまい，不可能なほどです。それよりも，そもそもこのActivityのkillがLinuxのレベルから見てどのようになっているのか，その再生成がプロセス構成なども含めてどのようなメカニズムとなっているのかを正確に理解してしまう方が，ずっと現実的です。ひとたびそういったレベルでこの仕組みを理解できれば，自分の取り組んでいる問題にどのような関わりがあるかを各エンジニアが考えることは十分に可能なはずです。OOM Killerが呼ばれるタイミングやshrink_slab()が呼ばれるタイミングなら，ベテランのエンジニアなら十分にわかります。本書はこうした，自分の問題にActivityのライフサイクルがどのような影響を与え得るかを，しっかりと自分で考えられるようになるための1冊に仕上がったのではないでしょうか。
モバイルのシステムにおいて，裏のアプリをどのくらい動かすのかはなかなか難しい問題です。PCと違いユーザーはアプリを明示的に終了しないですし，メモリもスワップがありません。裏に行ったアプリの影響で表のアプリの動きが遅くなると品質の低い端末だと思われてしまいますし，裏でいろいろ動けばバッテリーの持ちにも悪影響を与えます。
Androidのように，とにかく裏でもアプリを動かしながら，そういった数々の問題を技術力でひたすら解決していくというのは非常に変わったシステムだと思います。そして，その中心には本書のテーマとなるActivityがあります。本書を通じて，AndroidのAndroidらしさを十分に説明できたと思っています。
