Androidアプリの開発方針

Android開発においてはJavaを用いることができ（一部では既にScalaを用いた開発も行っているようだが）、 Objective-Cのような中途半端な言語を使用しない点は評価できるのだが、しかし現代のJava開発の常識が汲まれているとは到底言いがたく、不可解な点も散見される。これに盲目的に従ってはならない。

すべてをラップすること

一般的に言えることであるが、APIを直接使用してはならない。ラップして使うべきである。なぜなら、

• 一般にAPIはありとあらゆるケースを想定して仕様が決められているものである。その一部をラップしてその機能に限定して開発チームに使わせた方が効率がよい。
• APIは大きく変更されることがある。ラップしていれば、その変更を吸収することができる（可能性がある）。
• 特にAndroidの場合には、APIを直接使ってしまうとエミュレータ上か実機上でしかテストを実施することができない。Eclipse上では不可能なのである。
• また、Logクラスでも明らかであるが、冗長なこのクラスを使用するより、ラップして簡単なインターフェースを作成した方が素早く書け、短いコードになる。

リソースをできるだけ使わないこと

リソースには意味が無い。というよりも、コードで生成することのメリットよりも、リソースを使うことのメリットが勝ることを説明する文書はどこにも見当たらない。 つまり、この仕組みの開発者でさえそれを説明することができないし、それを盲目的に利用しているあまたの本やウェブサイトの著者も明確な答えは持っていないのである（反論を歓迎します）。

さらに、リソースを使用しないことにより、モジュールを単純なjarファイルにまとめることができ、 それを再利用することができるのである。

Androidの「ライブラリ」のやり方は答えになっていない。 私の理解が正しければ、現在のところリソースを含むAndroidプロジェクトをjarのような形で配布することはできない （もちろんZIPで配布してプロジェクトとして展開することはできる）。

Eclipse上でテストすること

ユーザインターフェース自体は現在のところエミュレータ上でテストするしかないが、それ以外はできる限りEclipse上（Eclipseを使わないのであればJUnitのみで）テストできなければならない。

なぜJavaのコードであるのに、Eclipse上で動作させられないのであろうか？あるいは、通常のJavaとして動作させられないのであろうか？これはまことに不可思議であるとしか言いようがない。この点について、Android SDKの作者は根本的な間違いを犯していると断言できる。

プレゼンテーションとビジネスロジックを分離すること

巷の多くのサンプルはこれらをごたまぜにしている。 このような小さな機器のプログラムであってもそれらは分離されなければならない。

これらは先人達が培ってきた、現代では常識とされることである。

ただし

AndroidのVMであるDalvik VMのGCは単純なMark&Sweep方式だそうで、通常のJava VMに比べると効率が悪い。しかもCPU自体も非力なものだから、これを考慮してやらなければならない。具体的には、できる限りゴミを出さないことが望まれる。

AndroidのAPIが「おかしい」のはこれがためと思われる。例えば、Swingであれば、一つのイベントを表すのに一つのオブジェクトを生成し、イベントハンドリングが終了すればそれをすぐさまゴミとしてしまうわけだが、Androidではこのような方式は採用できなかったものと思われる。

Javaでは明示的に「ゴミ」とマークすることができず、たとえオブジェクト指向プログラミングでなくとも必ずゴミが発生するわけで、この（おそらく）遅いGCは不可避であるのだけれども、このことを考慮するとしないとではパフォーマンスに影響は出るものと思われる。