2011年11月21日月曜日

Androidの開発環境:MacBookAirではダメだった・・・??

作ったアプリがどうしてもエミュレータで実行できない(eclipseからエミュレータにインストールされない)ことを書きました。しかしいくらなんでもこのキャッシュの強さは異常に思い始めました。javaだから動作が「もっそり」するのは仕方ないにしても、ファイルの更新が全然システム(この場合はeclipseやエミュレータ)に伝わらないのはおかしすぎます。マシンを何度も再起動しました。

ふと考えたんですが、自分が持っているMacBookAirは初期型です。(マイナーはしてますが)HDDは持っておらず、初期のSSDを積んでいます。初期のSSDは書き換え回数が厳しく、いろんな技を使っていますが、その中でも強力なバッファを設定してキャッシュを構成していたはずです。もしかして、Mac OSの方で特殊なことをしていて、それとeclipseの相性が悪いんでないか?(要は、ファイル更新の情報がなかなか伝わらない)単にバッファを大きく積んでいるだけなら、MacBookAirの終了の速さ(2,3秒で電源が落ちます)はおかしいんですが、どうも何かやってるんじゃないかという気がしてきました。(新しいMacBookAirなど最近のSSDは性能が改善されていると聞いているので、また話が変わっているかもしれません)
試しに、Windows7をつんでいるノートPC(普通のHDDです)にAndroid開発環境をもう一揃いそろえてみました。そこにMacBookAirで入力したプログラムをUSBで持ってきて、動かしてみると・・・ファイルの更新が少し遅れますが、ちゃんと伝わります!やはり、初期型のSSDのためにファイルシステムが何か特別なチューンがしてあるようです。う~ん、MacBookAirではAndroidの開発はあきらめるしかないですね。

追記:
その後、Windows7のマシンでも、ちょっとファイルを修正した後、どうしても再ビルドをしてくれない事態にあいました。メニューのからクリーンを選択して、プロジェクトのbin以下が削除されても再ビルドしてくれません。わけがわからず実行してみたら、さすがに再ビルドしてくれました。(エミュレータが動いて、アプリの更新に30秒くらいかかりましたが、特に再起動しなくても更新してくれただけMacBookAirよりましです)時々、eclipseのファイルキャッシュと同期がとれていませんというワーニングをMacBookAirのときは見ましたし、どうにも動きの予想がつきません。慣れれば、これはこれでいいんだろうか?有名なツールだし・・・

結論:
このクリーン、MacBookAirで試してなかったんでやってみたら、どうやら確実に修正できそうな手順が見つかりました。

①ソースを修正する。
②一度、当該プロジェクトをクリーンする。(選択したプロジェクトのみで行い、クリーン後すぐ再ビルドのオプションを選択してもビルドはなぜかされず。)
③実行、或いはデバッグを行う。(これで再ビルドが確実に行われます)
④Androidのエミュレータを起動する。(Windows7では自動的に実行してくれましたが、Macでは手動で行う必要がありました。たまたまかもしれませんが。)
⑤Windowsの方は30秒くらい待ってると、更新したパッケージがエミュレータにアップロードされ動きます。但しMacの方はだめで、一度アンインストールしてからエミュレータを起動、eclipseから起動しても中々アップロードしてくれないので、手動でインストールする。

Macでは特にエミュレータでアプリが動いている状態で終了すると、その状態をずっと覚えているようで、アプリの更新が働きません。(何もワーニングらしきものが出てこないのでわからない)そのため、特にMac側ではエミュレータでアプリを停止するなり、削除することが必要なようです。Macの方がやはりキャッシュが強い気持ちがしますが、それでも処理速度は速いです。古いCore2の方が、コア単体のクロックが速いせいか、あるいは単にOSの軽さからくるのかわかりませんが。それでもMacで開発できるならこちらの方が快適なんでいいです。

0 件のコメント:

コメントを投稿