2017年04月16日

「Androidを支える技術T」を読んで その1

 次の書籍を読みました。Androidを支える技術〈T〉

 一言で言うと、大変感動しました(^^)/

 この書籍は、android のGUIを解説したものです。主に以下の内容となります。
  1. タッチとマルチタッチ
  2. UIスレッドとHandler
  3. Viewのツリーとレイアウト
  4. OpenGL ES を用いたグラフィックシステム
  5. バイトコード実行環境
 ですが、もともと想定されているのが専門的な開発者レベルなので、サンデープログラマでしかない私にとっては理解できないところの方が多かった(^_^;)のですが、それでもandroid開発大好きな私としては、感動しまくりでした(^^)/

 以下、感動したところを中心に…というか、それしかできませんので、書いてみますm(__)m

1.見事なまでにチューニングされたViewレイアウトの構築

 これは、「3.Viewのツリーとレイアウト」の部分です。

 私なんか、Android StudioのGUIツールは使わず、手動でLinearLayoutをばりばりに入れ子にしてxmlを作っていく訳ですが、それでもあんなに素早く画面に表示されるのは凄いなぁと思っておりましたが、これを読むと、以下の部分から納得できます。

 イアウトのリソースから動的に生成と聞くとパフォーマンスが気になるところですが、バイナリ形式のリソースからのViewのツリー生成はカリカリにチューンされていて相当速く動きます。

 作成するViewごとに別々のAttributeSetインスタンスを作らず、各Viewの作成時に共通のインスタンスを使いまわすので、不必要に一時的なメモリを確保しません。そのため、不要なGCも防ぐことができます。

 バイナリ形式自体が最初からこのResXMLParserで必要な機能が高速に実装できるように決まっているため、このパースはプログラムからハードコードでViewツリーを生成するのに近いレベルの効率性を実現できています。

 日々androidを構築されている方々って、実にすばらしい(^^)/

 …その2へ続きます。
posted by 【なかま】 at 23:24 | Comment(0) | android

「Androidを支える技術T」を読んで その2

 Androidを支える技術〈T〉を読んでのその2です。

2.GPUを利用した究極の描画システム

 これは、「4.OpenGL ES を用いたグラフィックシステム」の部分です。

 実は、私は自作アプリと言っても、過去のバージョンの互換性のため、つい最近まで、コンパイルは2.3.3つまりapi levelを10にしたままで公開しておりましたので、4.0からハードウェアアクセラレーションが標準で有効になっているのをつゆ知らず(^_^;)、canvasでの描画速度はこの程度だろうなぁと思っておりました。

 ですが、つい先日コンパイラを4.0以降にしたところ、今のandroidの描画は何も苦労しなくても、実になめらかにスクロールするようになっているんですね、知らんかった(^_^;)

 …ということで、以下の部分は、時代遅れの私には、まさに驚愕の仕組みでした(^^)/

 描画は、Viewのdraw()メソッドの時点では行われず命令列を保持するだけにして、実際の描画は別のスレッドで非同期に行います。(中略) 命令列の実体はOpenGLの命令列を表すDisplayListというものです。

 DisplayListの再作成がなるべく少なくして済むような単位で分解しておくことで、画面の一部が変更された時に、その変更された所と関係のないViewサブツリーは以前のDisplayListを使いまわして必須な所だけ再構築するようにしておくことができます。

 DisplayListのシステムでは、アニメーションの時に影響を受ける要素をシステムが把握しているため、影響を受ける部分だけを更新して画面を描画することができます。アプリの開発者はアニメーションを指定するだけで、システムが高速でなめらかなアニメーションを実現してくれます。

 裏に隠れる不要な描画命令をスキップしたり、他のオブジェクトが上に来て隠れたり、逆に他のオブジェクトが上から移動して画面に現れたりした時にも、Viewのコードまでわざわざ戻らずにDisplayListを再利用するだけで対応できます。

 OpenGLで描画した後、(中略) 合成用のハードウェアを最大限使いつつ、(中略) 画面に表示します。

…このような仕組みのおかけで…

 アプリ開発者がそれほど特殊なことをしなくても、大量のアイテムをスクロールさせてもずっと60fpsが維持される、JITが走って、GCが走って、データベースのためのファイルIOが走って、ユーザーコードのレイアウトが動的に走って、それでも引っ掛からない。

というような究極の描画システムが出来上がっている訳ですね、納得です(^^)。

 …その3へ続きます。
posted by 【なかま】 at 22:00 | Comment(0) | android

「Androidを支える技術T」を読んで その3

 Androidを支える技術〈T〉を読んで その3です。

3.進化し続けるバイトコード実行環境

 これは、「5.バイトコード実行環境」の部分です。

 私が初めてJAVAを知ったのは、前世紀です(^_^;)が、あれから、MSが本家よりも速く動作するJITを開発し、JVMがぐんぐん進化し、docomoのiアプリが徐々に早く動作するようになって、やがてandroidの時代が来ました。

 androidのバイトコード実行環境は、日々進歩しています。

 この本によれば、スマホでバイトコードを実行するためには、 @「厳しいリアルタイム性の要求」 A「少ないメモリ」だそうです。その2点に対する驚異の対策が、以下のように、androidのバイトコード実行環境には施されています。

 以下、androidのバージョンの移り変わりによって様々な対策が施されています。

 まず、JITが初めて入ってきた2.1~4.4の頃は…

 JITはバイトコードを読んで実行バイナリーをメモリ上に生成し、以後はその実行バイナリをCPUに実行する仕組み

 最終的にはほとんどフルアセンブルで書かれていて、相当にチューンされたVM

となっておりました。

 そして5.0からはご存知のARTの登場です。

 ARTはAndroid RunTimeの略で、アプリのインストール時にコンパイルが行われ、実行時には実行バイナリがそのまま実行されるというシステム

 JITと違い実行時にはコンパイルされず、一度コンパイルしたものを何度も使い回せるので、バッテリーに優しく、実行時にたまにコンパイルが走って遅くなることもない

 ということで、私もARTのことを聞いた時はこれで決まりだなぁ、当分これ以上のものは出てこないだろうと思っておりました。

 しかーし、いつ頃からでしょうか、やたらシステムのバージョンアップが多くなって、その度にスマホは再起動し、すべてのアプリがその都度最適化されるようになりまして、これって面倒だなぁと思っておりました。そのあたりの事情は以下のように書いてあります。

 androidのシェアが増えるに従い、セキュリティ的なアタックを受ける機会も増えて、セキュリティ修正をもっと頻繁に行いたくなった

 セキュリティアップデートの都度、全アプリの再コンパイルが走りかなりの時間がかかります。これは数十分とかのオーダーです。(中略) 2~3カ月に1回、さらには毎月更新といったことを行おうとすると、かなりの問題となります。

 システムアップデート以外の単体のアップデートも、(中略) アプリが大量にインストールされている端末だと、毎日なにかしらのアップデートは降ってくる。アプリのアップデートの都度コンパイルが走ってしまうのですが、このコンパイルが走っている間はスマホのパフォーマンスはかなり低下します。

…そうです。

 そこで、7.0の時代になります。7.0は一言で言うと

 アップデートやインストールの時には余計な事を行わず、けれど重要なところだけはあらかじめコンパイルするというシステムを目指したもの

となります。結果として、

 すべてをコンパイルしていたのが、7.0からは一部をJIT実行するように先祖返りしています。

 アプリ実行時だけ速ければコンパイルに時間をかけてもよいというわけではないというのが現在の結論

となり、さらに、

 アプリの実行時にはイメージファイルの採用により起動を高速化

 よく使うアプリのよく使うメソッドなどは、電源充電中でアイドル中の時にこっそりとprofile guidedコンパイルを行うことで、(中略) プロファイル情報を用いるため、あまり重要でないコードをコンパイルして時間やストレージを無駄にしてしまう問題を解決

するなどさらなる改善が施されています。

 先日、JAVA8に対応するためのJackコンパイラが非推奨になったというニュースがありましたが、これからのandroidのバイトコード実行環境がさらに進化していくことは間違いないようです。

 これからも、androidに大変期待が持てます(^^)/

 最後になりましたが、このような素晴らしい解説本を出して頂いた作者に感謝、感謝ですm(__)m
posted by 【なかま】 at 20:00 | Comment(0) | android