特集:builder的Lionのみどころ--開発環境:API周りの変更点(後編)

小池邦人 (有限会社オッティモ)
2011-08-02 20:05:00
  • このエントリーをはてなブックマークに追加
最新特集【一覧】

 前回は、Lion(Mac OS X 10.7)の開発環境のおさらいと、iCloud関連のAPI、サンドボックス、オートセーブとバージョン管理を解説した。後編の今回でもLionの開発環境を確認していきたい。

 Lionでは、SDK(Software Development Kit)についても大きな飛躍が成されている。SDKの主役は、IDE(統合開発環境 )の「Xcode 4.1」とパフォーマンス解析ツールの「Instruments 4.1」の2つだ。特にXcode 4.1の機能アップは大きい。例えば、以前は別アプリケーションとして提供されていたGUI(グラフィックインターフェース)のレイアウトツール「Interface Builder」もビルトインされている。

 AppleがSDKの改善に力を入れる最大の理由は、社内でのソフト開発にも同ツールが使われているからだろう。開発ツールに問題点や能力不足があれば、まず最初に自社内プログラマーからの大きな反発を招くはずである。

LionにはXcode 4.1が、Snow Leopard(10.6)には4.02が提供されている※クリックで拡大画像を表示 LionにはXcode 4.1が、Snow Leopard(10.6)には4.02が提供されている※クリックで拡大画像を表示

LLVMとAutomatic Reference Counting(ARC)

 Xcode 4.1のデフォルトコンパイラもGCCからLLVMに変更されている。より効率の良いコード作成や、C++ライブラリの高速化など多くの改善があるが、その中のひとつであるARC(Automatic Reference Counting)と呼ばれる仕組みに注目が集まっている。

 ARCは、Objective-Cソースコードの解析機能を用い(Xcode 3からの機能)、コンパイルが不用オブジェクトの解放処理を適切なコード位置に挿入する仕組みである。この機能は「Apple LLVM compiler 3.0」から利用可能となる。現状、Lion用Xcode 4.1のコンパイラは「Apple LLVM compiler 2.1」であり、3.0を搭載したXcode 4.2の方は、iOS 5やiCloudの正式版と一緒にリリースされることが予定されている。

 Objective-Cでは、メモリ確保(alloc)したオブジェクトの解放タイミングをreleaseやretainメソッドで自己管理する。そうした手間の多くを省くためにNSAutoreleasePoolなどの仕組みもあるが、この管理手法を間違えるとメモリーリークの原因を作り、アプリケーションのクラッシュを招く。Objective-C 2.0から、不用オブジェクトの自動解放のためのガーベージコレクションも搭載されている。しかし、処理開始のタイミングや速度といったガーベージコレクション固有の問題から、あまり活用されていないのも事実である(筆者も不使用)。

 ちなみに、iOSの場合にはガーベージコレクションも存在しない。そのため、デバイスの搭載メモリの少なさ、新規参入開発者のObjective-Cの経験の少なさなどが影響し、初期には「メモリ不足で落ちるアプリケーション」が多数出現した。

 ARCは、不用オブジェクトの解放を高速かつ確実に実行し、メモリリーク対策の労力を大幅に軽減する。これは結果的にアプリケーションの質を高め、それを購入したユーザーが一番の恩恵を受けることになる。Xcode 4.2とARCの早期登場が望まれるが、ARCに関する技術的な内容は、iCloud同様にドキュメントとして既に公開されている。

オートレイアウト(Auto Layouto)とフルスクリーンアプリケーション

  • 新着記事
  • 特集
  • ブログ