このインタビューでは Linaro のエンジニアである Bernhard Rosenkränzer 氏が，Android 4.0.4 で 20% から500% というパフォーマンス向上を達成した方法について，自ら解説している。
Linaro では，標準的な AOSP Android 4.0.4 のパフォーマンスを 20-30% から 500% (実行するベンチマークによって異なる) 向上することに成功した。彼らは libc ライブラリの文字列操作を最適化し，Google が Android バイナリ生成で設定しているものとは異なるコンパイラとフラグを使用することによって，最大の改善を実現したのだ。香港で行われた Linaro Connect Q2.12 では，TI OMAP4430 を使用した Pandaboard ベースのデバイス上で，ストックバージョンと同社の Android ビルドを比較 するデモが披露された。特別にボードが用意されたのは両方の Android バージョンをサポートするためだが，そこで実行されたテストは，必要ならば他のデバイスでも再現することができる。そこで使用したベンチマークでは，Linaro Android で動作する 3D グラフィックが 60 FPS であったのに対して，標準的な Android のパフォーマンスは 30 FPS だった。
以下のインタビューは，Linaro で Android 開発に従事するエンジニアの Bernhard Rosenkränzer 氏に，Android を改善した方法について質問したときのものだ。
InfoQ: 今回の改良によるパフォーマンス向上は，数値としてはどれ程のものなのでしょう？
BR: いつものように，何を行おうとしているかによってまったく違います。共有ライブラリをコールしない，手作業で記述されたアセンブリコードを実行するのならば，パフォーマンスがそれほど向上しないのは間違いありません。逆に memchr( ) や strlen( ) などに大きく依存するベンチマークを作れば，Linaro ビルドがストック Android に比べて５倍以上高速であるという結果を出すのは簡単です。現実のアプリケーションならば，20-30% のスピードアップといったところでしょうね。
InfoQ; ストック Android の 30 fps に対して 60 fps を記録したテストがありましたが，どのようなベンチマークだったのでしょう？
BR: 0xbench の 3D 部分です。Pandaboard 上の 720p の画面で実行しました。これが最高のベンチマークという訳ではありませんが，改善が確認できるもののひとつです。それに実行しているときの見栄えがよいのです。技術の専門家でない観客が大勢いますから，数値結果以外の方法で何かを見せるのは大切なことです。
InfoQ: 実際に改善されたのは，どの部分なのですか？
BR: ２つの事を行いました。実際のコード修正という意味でしたら，Bionic (Android の libc) がもっとも手を入れた部分です – 文字列操作関数のコアを ARMv7 CPU，中でも Cortex A9 用に特別に最適化した等価の関数で置き換えたのです。
次に Linaro ツールチェーン (gcc 4.7 ベース) を使って，システム全体を再構築しました。コンパイラフラグも違うものを指定しています (ストック Android ビルドシステムではデバイス対応のコンパイラフラグを使わない，という前提があるらしく，-mcpu= や -mtune= といったフラグは使用されていません)。また Android では，-fno-strict-aliasing ( C/C++ のエイリアシング規則に従ったコードに依存する最適化を行わない) というフラグがデフォルトで設定されています。私たちはこれをオフにして，代わりに Android のソースツリー全体がエイリアシング規則に従うようにコードを修正しました。(修正に要する労力に見合わないようなサブディレクトリのいくつかについては，そのディレクトリに対してのみ -fno-strict-aliasing をもう一度指定しました。規則に合わない一部のコードのために，OS の他の部分にペナルティが科されないようにしたのです。)
カーネルも更新して，オプションを微調整しました。それでもまだ，改善の余地はあります。例えば現在のカーネルは，デバッグサポートやパフォーマンスカウンタを組み込んで構築されています。これらオプションのいくつかはパフォーマンス的なコストを伴っていますから，開発プラットフォームではない，実行時の速度を最適化するめにはオフにするべきでしょう。
それと別に言っておきたいのは，私たちが何をしていないか，ということです (fps の改善について，ドライバの vsync をオフにした結果なのではないか，と考えた人もいたようです)。ドライバの修正はまったく行っていません。特定のプラットフォームに限定された改良は行っていないので (デモで Pandaboard を使用したのは，それがストック AOSP と Linaro Android の両方でサポートしている唯一のボードだったからです。それ以外に理由はありません），Origen や Snowball，あるいは iMX6 でも，Linaro Android が動作するボードならばどれでも同じ効果を得られます。
InfoQ: 改良された内容は，ストック Android にも反映されるのでしょうか？
BR: もう少しテストを行ったら，AOSP に提出するつもりです。次のバージョンでそれらが採用されるのかどうかは，当然ですが私たちの決めることではありません。ただし一部の Android 改造マニア [CyanogenMod] はすでに，今回の変更を自身のソースツリーに反映し始めているようです。
InfoQ: 拡張機能は，Linaro の設立会社が所有する Android ベースのデバイスでのみ使用されることになるのでしょうか？
BR: 先程と同じで，最終的な決定権は私たちにはありません – ただし彼らが使用を開始するかどうか (あるいはいつ開始するか) の決定に関わらず，コードの提供は行う予定です。
InfoQ: 今回の件に関して，Google からは何かありましたか？
BR: Google の技術者が Google Plus の関連ポストで +1 をくれたこと以外はありません。
InfoQ: Google とは協力していないのですか？
BR: いいえ，以前のことですが，Android を gcc 4.6 と gcc 4.7 でコンパイル可能にするためのパッチを提出したことがあります。いくつか採用されましたが，却下されたものもあります。彼らがすでに内部ツリーを別の方法で修正していた，という理由でした。
InfoQ: Linaro が行っているプロジェクトで，このプロジェクトのような Android 関連のものが他にもありますか？
BR: メンバ企業の開発ボードのために Android ビルドを毎月 (スナップショットは毎日) リリースしています。https://android-build.linaro.org/ を見て頂くと，私たちが現在行っている改良のほぼすべてがそこに含まれています。
全般的なパフォーマンス調整以外にも，プラットフォームへの対応 (ドライバ組み込みなど) や，新たな開発ツールの開発なども行っています – 例えば，Lonaro Android では busybox や perf，lrzsz，gator (ARM のグラフィカルなデバッグ/パフォーマンス測定ツールを動作させるために必要) などを提供しています。
編集者注： Linaro は ARM プラットフォーム用のオープンソースソフトウェアの統合と最適化を行うために，ARM が Freescale，IBM，Samsung，Ericsson，TI と共に設立した非営利組織である。