The King's Museum

ソフトウェアエンジニアのブログ。

『Androidを支える技術〈Ⅰ〉 ~ 60fps を達成するモダンな GUI システム』を読んで

『Androidを支える技術〈Ⅰ〉 ~ 60fps を達成するモダンな GUI システム』を読みました。

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

感想

単純にとても面白かったです。

昔、Web ブラウザのレンダリングエンジンをいじっていた頃があって、ちょっとだけそのときのことを思い出した。 ツリーがあって、それをレイアウトして、描画ライブラリに投げて、その先が GPU で、っていう一連の処理とか。(ブラウザだと DOM Tree と Render Tree が別だったりしたね)。 大して理解もしないままその世界から離れてしまったけども。

思い出話は置いておいて、この本の何がすごいかというと、

  • 上は View ツリーの話から、下はシステムコールの話まで書いてある
  • 豊富な図解と分かりやすい説明
  • 現実のコードをベースにした展開
  • 著者が中の人じゃない

というところ。

知識を文字にする時って、実際にアウトプットすることの数倍の知識が必要だと思う。 だから、この筆者はこの本に書かれた数倍の知識を持ってるんだよなーと思って、すごいなーと思った(小並感)。 というか、書籍にまとめるレベルになると10倍くらい必要かもね、、、

感心したところ

HWC と GPU 周りはとても感心して、とくに SurfaceView の仕組みはなるほどーと思った。

  • SurfaceView の View としての特性は「単に領域に穴をあける」だけ(下の描画結果を透過する)
  • アプリレイヤでは SurfaceView.getHolder().getSurface() で Surface が取得できる
    • Surface というのは gralloc() で確保したメモリ領域へのハンドラ。
    • gralloc() は端末ベンダーによって実装される。大抵は描画ハードウェア(GPU や HWC)に近いメモリに置かれる。
  • アプリレイヤで取得したこの Surface を、メディアコーデックに渡す。
    • 結果、コーデックチップが Surface が指す先のメモリに直接結果を書くことができる、
    • そすうれば CPU を使う必要がなくて電池も消費しないしハッピー。
    • さらにいうと、合成に HWC が使えるなら GPU も使わなくていい!

図にするとこんな感じ(本から引用) ^(1)

f:id:hjm333:20170905223646p:plain

うーん、仕組みもよくできているし説明もすごく分かりやすかった。 (gralloc とかなんだよって話だけど、それは本書を読んでください)

(1): 有野和真.『Androidを支える技術〈Ⅰ〉~ 60fps を達成するモダンな GUI システム』,技術評論社,2017.図 6.16(p.250).

得られたもの

この本を読むとなんとなく Android が理解できた気分になれる。

結局、得られるのは気分だけなんだよね。 当たり前だけど。 実際に自分でコードを追ってデバッグしてってやらないと本当に使える知識/技術にはならない(少なくとも自分にとってはね)

だけども、このなんとなく理解出来た気になるのはけっこう重要かなぁという気もしている。 どこかに誰かも書いていたけど、例えばクラッシュログを見ていて、

うーん、この ViewRootImpl.java ってシステム側だからなぁ、、、とりあえずクローズかな、、、

と思っていたのが

そういえば、ここらへん本に出てたし、ちょっと見てみるかな(キリッ

という根拠のない自信に変わったりする。

そう思ってコードを読んだところで、なかなか結果は変わらないんだけど(だって変化したのは気分だけだからね)、こういう姿勢の変化は結構重要だったりする。 めげずにコード読んでるとたまーに結果が出て幸せになれたり、そもそも実際に読んでみないことには知識も得られないままだからね。

Android に対して「まあ、ちょっとコード読んでみるか」というメンタリティが持てるようになったことが、この本を読んで得られた最大のポイントかな。 あとは普通に読んでて楽しかったです(2回目)

Vol. 2 も出ていて、話題的にはこちらの方が興味があるので読むのが楽しみー。

Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)

Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)

Chapter 8 Pragmatic Projects【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 8. Pragmatic Project を読んだ。内容は次の通り。

  • 41 Pragmatic Teams
  • 42 Ubiquitous Automation
  • 43 Ruthless Testing
  • 44 It’s All Writing
  • 45 Great Expectations
  • 46 Pride and Prejudice

Great Expectation

他人の期待を正しく理解することが非常に重要という話。結局、プロジェクトは誰かの期待に応えられているかどうかで判断されるわけで。

コンサルタント業界では "Expectation Management" なんて言葉もあるようだ。この本では「俺たちはそこまでしろと言ってるわけじゃない。ただ、顧客の期待を正しく理解しよう」と説いている。

Tip 69 Gently Exceed Your Users' Expectation

そして、できればその期待を少しだけ上回ろう。Gently というのはとても絶妙な表現なんじゃないかなと思った。それくらいなら、勘違いしてユーザーの期待から大きく離れてしまうこともないだろうからね。

おわりに

今年の頭くらいから読み始めて、中断して、帰りの電車でちょっとずつ読み進めてよーやく読み終わった。やはり英語の本を読むのは時間がかかる…。

全体を読んだ感想としては、こんなに頑張って読まなくてもよかったかな、という感じ。日本語版をぱらぱらと一週間くらいで読めば十分、という感覚ですね。

Chapter 7 Before the Project【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 7. Before the Project を読んだ。内容は次の通り。

  • 36 The Requirements Pit
  • 37 Solving Impossible Puzzles
  • 38 Not Until You’re Ready
  • 39 The Specification Trap
  • 40 Circles and Arrows

2つほど面白い章があったので感想を書いておこう。

37. Solving Impossible Puzzles

解くことが不可能に見える問題も、正しく制約を理解すれば簡単に解けることもあるよ、っていう話。

ここでのポイントは課された制約をきちんと認識して分類すること。分類は、

  • 必ず守らなければならない制約
  • 必ずしも守らなくてもよい制約

という単純な二種類で充分。私たちは「必ずしも守らなくてもよい制約」を「必ず守らなければならないもの」だと誤認してしまうことが多い。この誤認に気づくと、問題が一気に解決することがある。

38. Not Until You’re Ready

闇雲に何かを始めるのではなく、始めるタイミングを見計ろう、という話。

プロの曲芸師は自分のタイミングを知り尽くしていて、すべての条件が揃うまで静かに待っている。そして、タイミングが来たと感じたら一気に勝負に出る。プログラマも何かの作業をする時はタイミングを見計らうべきだし、また、その直感を鍛えるといい。

「タイミングを見計らう」っていうのは正しく準備することにも繋がるかなぁと思った。何かに向けて準備することはとても大事だなぁ、と最近強く感じる。

いつかだったか、テレビで凄腕の心臓外科医が、手術のヤマとなる血管を切り取る場面で「ここにたどり着いた時点で、僕の勝ちは決まってるんですよ。ここにたどり着くまでが仕事なんですよね。」と言っていて、たしかになーとは思った。

CODE COMPLETE にも、

ニ回測って、一度で切る

という格言が紹介されていて、コーディングにも似た側面はあるんじゃないかなーと思った。

Chapter 6. While You Are Coding【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter6. While You Are Coding を読んだ。 内容は次の通り。

  • 31 Programming by Coincidence
  • 32 Algorithm Speed
  • 33 Refactoring
  • 34 Code That’s Easy to Test
  • 35 Evil Wizards

印象に残る章がいくつかあったので書き残しておこう。

31. Programming by Coincidence

この章は、「自分が書いてるコードをちゃんと理解していますか」というような内容だった。

最近、以前よりも自分の書いたコードに自信が持てるようになったなー、と思っていて、『コンパイルする回数が減った』とか『一発でうまく動くことが増えた』とか、そういうところで開発に効いてきている。

いくつか要因はあると思うけど、大事なことの1つは「何を期待して目の前のコード片を書いているのかを常に意識する」ということだろう。プログラマは何かしらの『期待』を持っていて、それを実現するためにコードを書くわけだけど、どのコードが何の期待を満たすのか、自分の中でちゃんとマッピングさせておくのがとてもよい。コードに自信が持てるし、コードの理解につながる。

これには別の効果もあって、自分の『期待』をただしく理解しておくと、すごくデバッグが捗る。バグはたいていの場合、何らかの『期待』と異なる挙動をしているから発生する。だから、『期待』とコードのマッピングを持っておけば、必ず最後にはバグの原因にたどり着ける。まあ、たまに期待自体が間違ってたりするし、現実はそんなうまくいかないけど、バグ解決の確率はだいぶ高まる。

あとは、この『期待』と『コード』のマッピングはなるべく小さく保っておいて、それをベースにして大きなビルディングブロックを作ってくと、とてもいいコードが書けるんじゃないかなぁと感じている。

この『期待』ってのは『意図』とも言い換えられるかなーと思ったりして、そうするとこの章の言いたいこととつながるよなーと思った。

35. Evil Wizards

これは「ウィザードで生成されたコード使うならちゃんと中身読もうね」という話で、とても説得力があった。

ライブラリの場合、ライブラリ側のコード把握する必要はない。正しいインタフェースが切られていて境界がはっきりしてるからだ。

一方、ウィザードによって生成されたコードは、私たちのコードに直接入り込んでくる。「すぐにウィザードで生成されたコードをいじることになるから、理解してないとひどいことになるよ」というのはその通りだと思った。

『サピエンス全史』を読んで

ちょっと前、と言っても数ヶ月は経ったけど『サピエンス全史』を読んだ。

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

DEEP WORK を書いた人のブログに紹介されてて、ふーん、って思って、ぐぐったらどうやら邦訳が出てるらしい。 たまにはこういう読み物系も悪くないか、と思って読んでみた。

人類という種としての歴史、すなわちホモ・サピエンスという種の歴史が書かれている。

著者によるとホモ・サピエンスの歴史には3つの転換点があったようだ。

  • 認知革命
  • 農業革命
  • 科学革命

これらの3つの革命をベースにさまざまな話題がちりばめられた本だ。

感想

最初の認知革命から農業革命あたりの話が楽しく読めた。単にその時代あたりの歴史(数万年前)をあまりに知らなかったから新鮮だっただけかも。

狩猟時代の人類はとても生活レベルが高かったというのは面白い。まだ人口も少なく、食料や衛生面で困ったら移住するという手段があり、1日のうち少し狩りをしたらあとは自由に過ごしていたようだ。一方、農業が栄えてからは、人口も増え、農作物が不作になるリスクを抱え、定住による衛生面の悪化で苦労し、年中作物の面倒を見なければならなくなり、挙げ句の果てに、階層の高い一部の個体のために育てた農作物を献上しなければ生きていけなくなった。ここから「人類は本当に幸せになったのだろうか」という問いにつなげるあたりはなかなか。

一方、科学革命からの資本主義がどうとかってところは思ったほど面白くなくて、別に考え方・とらえ方は間違ってるとは思わないんだけど「ふーん」という感じ。資本主義についてから最後にかけての展開がこの本を際立たせてる要因だと思うのだけど、自分にはあまり響かなかったな。そこらへんで仕入れた知識を列挙してるだけ?と思ってしまった。

最後に、

ひょっとすると 、私たちが直面している真の疑問は 、 「私たちは何になりたいのか ? 」ではなく 、 「私たちは何を望みたいのか ? 」かもしれない 。この疑問に思わず頭を抱えない人は 、おそらくまだ 、それについて十分考えていないのだろう 。

って投げかけてきて、「あっ、はい」ってなったところで本は終わった。

Amazon の 2017 年のビジネス書大賞にも選ばれてたりして、これビジネス書?って思ったりしたけど、話題の作品なのは間違いないようですね。

https://www.amazon.co.jp/b?node=5026826051

Chapter 5. Bend, or Break【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 5. Bend, or Break を読んだ。

内容は次の通り。

  • 26 Decoupling and the Law of Demeter
  • 27 Metaprogramming
  • 28 Temporal Coupling
  • 29 It’s Just a View
  • 30 Blackboards

一通り読んだけど、あまり印象に残る話題がなかった。たぶん、どこかで一度は目にしたような話が多かったからだろう。30 の Blackboards は、「確かに、そうだね」って感じだったけど、イマイチ具体的な話が伝わってこず、消化しきれない感じ。


6割くらい読んできた感じとしては、技術的な話のところは大して面白くなく、精神論みたいな話の方が楽しい。

ただ、精神論を読みながら、「うんうん、ほんとそうだよねー」って自己完結しても大して身にならないので、気をつけないとね。

Chapter 4. Pragmatic Paranoia【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 4. Pragmatic Paranoia を読んだ。

内容は次の通り。

  • 21 Design by Contract
  • 22 Dead Programs Tell No Lies
  • 23 Assertive Programming
  • 24 When to Use Exceptions
  • 25 How to Balance Resources

契約によるプログラミングとか、Assertion 使いましょうとか、全体的に時代を感じる章だった。まずはクラッシュさせよう!とか聞くと、うーん…、って感じになる。確かに理解はできるが…。

そういえば、最近はあまり assert とか使ってないなぁと思った。昔は結構単体テストとか assert とか書きたがるタイプだったけど。

単に今の仕事ではそこらへんをきちんとすることへの優先度が低いと感じているだけかな。自分には時間も能力も限られたものしかなくて、何が一番効果的かと考えた時、assert や単体テストを拡充することが今の業務にとって有効だと感じていない。

やりたいこと/やった方がいいことがあったとしたら、きっと、そのうち 80% のことは諦めなきゃいけなくて、決意を持ってそのうちの 20% を選ぶことが仕事なんだと思う。そして、うまく選べればその20%で80%くらいの結果は出せるはず。

最近は人生もそんな感じかな、と思うようになった。

話が完全に本と関係なくなってしまったな。。。

(c) The King's Museum