私の本、Androidを支える技術、が増刷される事になりました。

ありがとうございます。

で、増刷なので誤植の修正くらいしか出来ないのだけど、Oreo時代にどのくらい変わったかは一応知っておこう、と思ってGoogle I/OのOreoの動画とか見直している。

OのPreviewの頃に軽く動画とソースはチェックしていたのだけど、当時は本の内容とかとは関係なく興味ある所だけ見てたので。（だいたい自分の興味は似たような所だけど）

で、I/Oの以下の動画を見てて面白かったのでブログにしておく。

Performance and memory Improvements in Android Run Time

このチームの動画は毎バージョン見ている気がするが、回を重ねるごとに進歩してて、ARTは凄いねぇ。

GCの時にフィールドアクセスの方にチェック入れるのは副作用も心配になる所だけど、正常時に遅くならないのかねぇ。まぁその位は確認してるだろうが。

コンパクションはガラケー時代に良く格闘していた所なので、一周して戻ってきた感はある（もちろんこっちの方がもっとずっと凄いが）

code sinkは面白いね。 JITではいまいちだろうけど、profile guided compileなら出来そう。 Nougatの頃にこの辺のコード読んだ時は、両者でoptimizeの内容に違いは無かったが、Oreoからは変わってるのかね。

dexのrelayoutもそうだが、この辺の最適化は洗練されてるねぇ。昔のdalvikくらいなら自分でも書ける範囲だったが、もう無理やね。

dexはrelayoutしたイメージを置く必要があると思うが、それって倍のストレージを使っちゃうよな。 良く使うアプリに絞っても全部やるのは駄目そうなので、なんかGC的な仕組みが要る気がするが、そういうのは無さそう。 まぁ全部AOTコンパイルしていた時代もあるから平気か。そういえばもともと最近は、アプリのイメージファイルも作ってたな。ってあれはメモリ領域だけか。

final勝手につけるの(・∀・)ｲｲﾈ!!

class loaderとか怖いケースもあるが、まぁその辺は頑張っているのだろう。

こういうのを見ると、やはりAndroidは動的コード生成でバリバリ行くよりも、optimizerに優しいコードの方が良さそうね。

loop optimizationはやばいな。 ただこの手のはベンチマークには効いても実際どこまで変わるかは怪しいよなぁ。

bound check消すとかも凄いねぇ。 これ、研究じゃなくて皆の実機で動くんだよなぁ。

vectorizationとか見てても、バイトコードバンザイだな。ARTはほんと、state of the art感あるねぇ。 cross fadeが速くなります！ってこういうの好きよ。
このアセンブリならもうC++で書くのと変わらんね。

全部合わせると、限定的な状況ならネイティブ並みになるね。 限定的な状況になるように書いてやる、というのも、CPUインテンシブな所では重要そう。

本の増刷という点では、新しい要素はあるけれど無効になった所は無い、という感じやね。