Android Studioはいつまでこの体たらくを続けるのか?

android-studio-logo

年に2回程度、私はちょっとしたAndroid開発をすることが必要なプロジェクトに関わっている。そこで、年に2回程度Googleのいわゆる統合開発環境であるAndroid Studioを、祈るような気持ちで立ち上げる。…そして年に2回、それがいまだにエレガントで直感的なRube Goldberg機械(複雑怪奇な仕掛けでちょっとしたことを行うだけの機械)であることに気がついて、苦い失望に顔をしかめるのだ。

私が特定のOSに肩入れしているわけではないことは急いで付け加えておきたい、というより私はどちらかといえばGoogle贔屓なのだ。これまでの私のスマートフォンは全てAndroidだった。最初にHTC Magicを買った2009年以来、私は職業としても趣味としてもAndroidアプリを書き続けて来た。その後もAndroidが続き、Galaxy S2、Nexus 4、Moto X、そしてピカピカのPixelを手にしている。

しかし私は、iOSやtvOSのアプリ書いている。そしてAppleのソフトウェアに対する覇権的態度は嫌っているものの、AppleのIDEであるXcodeを立ち上げると、少しほっとした気持ちになるのだ。それは高速で滑らかに動く。そして、それがあまり上手く動作しないときでも、足手まといになることは滅多にない 、だがAndroid Studioの場合、足手まといになることが基本機能なのだ。

例えば、私はそのビジュアルツールを利用して、スクリーン上に要素を本当に上手くレイアウトできた試しがない。もちろんそれが理論的に可能であることは知っている。しかし試す度に強度のフラストレーションに襲われて、結局XMLでレイアウトを直接書くことになるのだ。これが私1人だけの問題ではないことは確かだ。逆にXcodeでは、自由奔放に楽しく、ドラッグアンドドロップをするだけだ。

最初の状態ではAndroid Studioは自動的にJavaクラスをロードしていない。これを行うためには、不可解な迷路の中に埋め込まれたメニューに辿り着かなければならない。最初の状態では、Android Studioは、おそらく私が必要とする無数のサポートライブラリをどのようにロードすべきかを教えてくれないし、Androidエミュレーター(いまだに耐え難いほど遅い)をどのように実行すれば良いかも教えてくれない。この両者への秘密の扉は、信じようが信じまいが、”Tools”メニューの中の”Android”サブメニューの中に埋め込まれている。このことについて、少し考えてみよう。何故GoogleのフラッグシップAndroid開発ツールに、”Tools/Android”メニューがあるのだろうか?全部がAndroidツールではないのか?これらの重要な要素がメニューである必要があるのか?

…問題の1つは、もちろん、Android Studioがゼロから作られたものではないということだ。それは今やもう年老いたJava IDEであるIntelliJ IDEAプラットフォームに基づいている…まあそれでお分かりだろう。15歳という年齢を感じさせるソフトウェアだし、それはAndroid開発のために作られたというよりも、対応させたということが明らかなものなのだ(”Tools/Android”を思い出してみよう)。そして、もちろんそれはJavaで書かれていて、マルチプラットフォームで動作する…しかし動作は遅い。

Androidのエコシステム自身が、さまざまなライブラリとSDKの、目まいがするような過剰なバージョンへと断片化し、扱いにくくかつ複雑であることは事実だ。例えば、ビルドツールのGradleが開発者泣かせということは有名な話だ(とはいえビルドそのものは難しい。Appleのビルドツールも開発者の手をがっちりと掴んでいてはくれない)。しかし、良く設計されたIDEは、少なくともこの苦痛を緩和できる。Android Studioがマルチプラットフォームでなければならないのに対して、Xcodeは1つのOSだけで走れば良いというのは真実だ。しかし、他でもないGoogleは、マルチプラットフォーム上でネイティブコードをサポートできるリソースを持っている筈だ。

巨大怪物のGoogleが、10億台以上で使われているそのモバイルプラットフォーム向けのフラッグシップ開発環境を、これほどまでに遅く、ツギハギだらけで醜いもののままにしていることは本当に驚異的だ。負の効果は測り知れない。iOSの開発をより早くより効率的にしているものの理由の1つが、良いツールが提供されていることだ。両方のエコシステムに慣れた開発者たちは、AndroidよりもiOSの方を好む。なぜならそちらの方が遥かに使いやすいからだ。そのため私たちはスマートフォンソフトウェアとしてiOSを優先することになり、Androidは二の次になってしまうのだ。AndroidアプリはiOSプリよりも大きくなりがちなことで有名だ、それなのにIDEがそれに対処できないということは信じがたい。

まあ身勝手な話だが、仮にGoogleのIDEが優れていた場合には、Appleに対して改善を迫るとは思う。Xcodeは完璧からは程遠い。クラッシュもすれば、ハングアップもする。しかしそうした欠陥があるとしても、比較するまでもなく、iOSの開発はAndroidの開発よりも遥かに苦痛が少ないものだ。(まあ、それもデプロイしようとするまでの話だが。そこから先はAndroidには苦労がない。Appleの「改善はされたもののしばしば不可解な」、ビルド、署名、アップロード、提出、そしてベータ版ビルドですら承認を待たされるプロセスは、iOS開発者に深い恨みと怒りを引き起こすものだと知っている)。

しかし最近、半ば疑いながらの期待ではあるが、真のライバルが初めて現れてきたようだ。このことは、最近Microsoftによって買収されたXamarinのおかげで、.NETプログラマーたちにとっては既に知られていたことだ。Xamarinを使えば.NETを用いてAndroidとiOSに対してネイティブアプリを作成することが可能になる。しかし最近ではFacebookのRact Nativeが、(あまり沢山の)ネイティブコードを書くことなしに、クロスプラットフォームネイティブコードを書くための現実的なソリューションとなりつつある。すなわちAndroid StudioもXcodeも利用する必要がないのだ。

私はAppleとGoogleの開発環境が消え去ってしまうと言っているわけではない。しかしAppleとGoogleのデファクトで塞がれた道を、誰かが少なくとも押し退けようと努力しているのを見ることができることは良いことだ。彼らは、特に後者は、競争の欠如によって自己満足的に成長してきた。彼らがReactに、どのように対応(react)するかを見守ろう。

[ 原文へ ]
(翻訳:Sako)

投稿者:

TechCrunch Japan

TechCrunchは2005年にシリコンバレーでスタートし、スタートアップ企業の紹介やインターネットの新しいプロダクトのレビュー、そして業界の重要なニュースを扱うテクノロジーメディアとして成長してきました。現在、米国を始め、欧州、アジア地域のテクノロジー業界の話題をカバーしています。そして、米国では2010年9月に世界的なオンラインメディア企業のAOLの傘下となりその運営が続けられています。 日本では2006年6月から翻訳版となるTechCrunch Japanが産声を上げてスタートしています。その後、日本でのオリジナル記事の投稿やイベントなどを開催しています。なお、TechCrunch Japanも2011年4月1日より米国と同様に米AOLの日本法人AOLオンライン・ジャパンにより運営されています。