Android Wear LG G Watch (LG-W100)

Android Wear の利用には連携を行う Android 端末が別途必要です。
通信や設定管理など多くの部分を連携する Android 端末に依存しています。

しかしながら Android Wear のハードウエアは単独で動作する Android 端末と
違いはなく、OS も最新の Android 4.4W (API Level20) 。
専用アプリケーションのインストールも可能となっています。

LiveView 系 SmartWatch がホスト端末のリモートモニタとして機能していたのに対し、
Android Wear の場合は主従が逆です。
通信や操作上の都合など、足りないものを補うために連携した端末を利用している形です。

スマートウオッチには大きく分けて、単独で使用できるものと
自分ではアプリが動かないクライアントタイプの 2種類あります。

1. クライアントタイプ (ホスト端末が必要)
 ・通知だけ受けるタイプ
 ・アプリケーションはホスト側で動き、入出力だけ行うもの(SONY LiveView)

2. 単独で動作するタイプ
 ・機能固定 (スポーツなど特定用途向け)
 ・独立したコンピュータとして機能するもの

Android Wear は独立したコンピュータとして機能しますが、
連携した Android 端末が近くになければ活用できない仕組みになっています。
通知などのネット接続はもちろん、Android Wear の有効な入力手段は音声なので
ボイスコマンドやテキスト入力にもインターネットが必要になります。
逆に歩数計 (Fit) のように、ネット接続がなくても特に困らないアプリもあります。

● SmartQ Z Watch との比較

gwatch_lgw100_01.jpeg
↑左が LG G Watch LG-W100, 右が SmartQ Z Watch

見た目はほぼ同じ大きさで、数値上は G Watch の方が少し小さいようです。
実際に手にすると G Watch の方が表面積が大きくだいぶ薄く感じます。

スペック        LG G Watch LG-W100      SmartQ ZWatch
-------------------------------------------------------------
SoC             Snapdragon 400 MSM8226  JZ4775
CPU             Cortex-A7               XBurst
ISA             ARMv7A                  MIPS32-R2
Clock           1.2GHz                  1.0GHz
Core            4 core                  1 core
FPU             VFPv4+NEON              FPU
3D GPU          Adreno 305              --
OpenGL          ES 3.0                  --
OS              Android 4.4W            Android 4.4 (GApps無し)
RAM             512MB                   512MB DDR
ROM             4GB                     4GB
Display         280x280 (1.65inch)      240x240 (1.54inch)
Bluetooth       4.0                     4.0
Wi-Fi           --                      b/g/n
Size            46.5x37.9x9.95          49.9x38.5x12.2
Weight          63g                     42.5g
Battery         400mAh                  300mAh
Application     Wear専用                Android汎用
Sensor          Acc,Gyro,Compass,Mic    Acc,Mic
Button          --                      Power,Back
Connector       充電(USB)               3.5 Headphone(USB/充電兼)

Android Wear LG G Watch の GPU
SmartQ Z Watch Specifications

2014/07/11修正: G Watch は 4core のうち 1core しか使われてないものと考えられます(詳細はこちら)

◎時計として

Z Watch は腕の傾きで画面を表示させるオプションがありますが、
何かと誤動作が多く不安定です。
傾き以外のスリープ解除はボタン操作なので、
腕時計としては時刻を確認しづらいのが難点。

LG G Watch は常に画面を表示させておくことが可能です。
一定時間経つと背景が暗転して輝度が落ちますが時刻表示は残ります。
時計として活用するには十分でしょう。
バッテリーの持ちが心配なら完全に画面 OFF にすることもできます。
この場合も画面に触れるだけですぐ点灯するので面倒はありません。
Z Watch 同様に腕の傾きでも復帰します。
腕につけていると知らないうちに画面が光ってる場合あり。

待機状態への移行 (画面全体を手で覆う操作) は、輝度センサーではなく
画面の広範囲のタッチで判定しているようです。
3本指のタッチでも認識します。

◎ストレージ

Z Watch は USB 接続 (MTP) で直接データを送ることが可能。
音楽データを転送すればプレイヤーとして利用できます。

G Watch の内部ストレージには直接アクセスすることができません。
端末情報にストレージや空き容量の項目が無いのでもともと想定していないようです。
adb 接続では普通にアクセス可能で、/sdcard/Music や DCIM もありました。
3GB 近く空いていることを確認。

◎アプリケーション

Z Watch は通常の Android をスマートウオッチ向けにカスタマイズしてあります。
非常に小さい Android Tablet のようなもの。
普通のアプリも動きますが、画面が小さいため使い物になるかどうかはアプリ次第です。
特に操作面で難があります。

G Watch は Android 端末側でインストールすると自動的に同期が行われます。
専用の管理画面はないので、正しくインストールされているのかどうか
少々不安になることがあります。
デバッグ実行できるので adb を使った直接 install も可能。

一見そのままアプリが動く Z Watch の方が便利そうに見えますが、
使ってみると操作上の問題が非常に大きいことがわかります。
小さい画面にレイアウトを合わせるだけではだめで、細かい操作や文字入力が苦手です。

Android Wear はこれらの問題を解決することに重点が置かれているようです。
極力操作しなくて済むよう徹底されており、文字入力は音声を用い
アプリの導入管理や設定も連携した Android 端末側で行います。
本体の操作は画面のスライドなど非常に簡単なアクションのみ。

その代わり専用に作られたアプリケーションが必要です。
当初は数が少なくても、使えるものだけ揃っていることになります。
快適さや実用度は大きく上回っていると言えます。

●トラブル等

Android 4.3 以降の条件は結構敷居が高く、日本だと半年前に発売された
スマートフォンでも使えない可能性があります。(半年前)
手持ちのスマートフォン端末にも無かったので Nexus 7 とペアリングしました。

最初アプリケーションの導入ができず、G Watch に反映されない問題ではまりました。
Android Wear アプリの再インストールや、LG G Watch の初期化(リセット)
が有効でした。
試してから気がついたのですが、メニューにある「端末をリセット」は
再起動ではなく端末の初期化(消去)のことでした。

●最後に

4 core CPU に 3D GPU 搭載と、予想以上に性能が良かったので今後登場するアプリや
さまざまな活用方法に期待できます。
Chromecast よりも総合スペックは高いです。
普段腕時計している人にとっては、時計として使える点も重要でしょう。

2014/07/11訂正: 実測結果より、cpu0 しか使われておらず実質 single core 700MHz 相当でした(詳細はこちら)

関連エントリ
Android Wear LG G Watch の GPU
Android SmartWatch ZWatch で 3Dゲーム (ChiRaKS)
Android SmartWatch スマートウオッチのスペック比較表
Android SmartWatch SmartQ ZWatch (3) 腕に関数電卓
Android SmartWatch SmartQ ZWatch (2)
Android 4.1 SmartWatch SmartQ Z Watch
Android LiveView MN800 プラグインの作り方
LiveView MN800 Android のマイクロディスプレイ

Android Wear LG G Watch の GPU (スペック)

LG G Watch を入手したので CPU/GPU を調べてみました。
プロセッサは Snapdragon 400 MSM8226、1.2GHz で 4 core あります。
GPU は Adreno 305。
Low End ですが 300番台なので OpenGL ES 3.0 に対応しています。

SmartQ ZWatch は Single Core かつ 3D GPU も無かったので、
比較すると LG G Watch がかなり高性能に見えます。
RAM 容量以外はおそらく低価格帯のスマートフォンと同等でしょう。
2014/07/11修正 (実測結果)

Smart Watch スペック一覧

その代わり Z Watch のような Wi-Fi やヘッドホン端子は無く、単独での利用は考えられていません。
通信は Bluetooth だけ。ペアリングした親機 (Android 端末) が必要です。

Android Wear では adb も親機を介した bluetooth 経由で接続できるようになっています。
付属の充電クレードルを使えば、今までどおりの USB 接続もできるようです。

LG G Watch Android 4.4W
Qualcomm Snapdragon 400 MSM8226
Cortex-A7 1.2GHz Quad core, Adreno 305
RAM 512MB

-------------------
CPU
-------------------
processor	: 0
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 38.40
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 1
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 38.40
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 2
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 38.40
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

processor	: 3
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 38.40
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 3

Hardware	: Qualcomm MSM 8226 DORY (Flattened Device Tree)
Revision	: 0007
Serial		: 0000000000000000



-------------------
GPU
-------------------
GL_VERSION: OpenGL ES 3.0 V@84.0 AU@  (CL@)
GL_RENDERER: Adreno (TM) 305
GL_VENDOR: Qualcomm
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.00

Extension:
GL_AMD_compressed_ATC_texture
GL_AMD_performance_monitor
GL_AMD_program_binary_Z400
GL_EXT_debug_label
GL_EXT_debug_marker
GL_EXT_discard_framebuffer
GL_EXT_robustness
GL_EXT_texture_format_BGRA8888
GL_EXT_texture_type_2_10_10_10_REV
GL_NV_fence
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth_texture
GL_OES_depth24
GL_OES_EGL_image
GL_OES_EGL_sync
GL_OES_EGL_image_external
GL_OES_element_index_uint
GL_OES_fbo_render_mipmap
GL_OES_fragment_precision_high
GL_OES_get_program_binary
GL_OES_packed_depth_stencil
GL_OES_depth_texture_cube_map
GL_OES_rgb8_rgba8
GL_OES_standard_derivatives
GL_OES_texture_3D
GL_OES_texture_float
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
GL_OES_texture_npot
GL_OES_vertex_half_float
GL_OES_vertex_type_10_10_10_2
GL_OES_vertex_array_object
GL_QCOM_alpha_test
GL_QCOM_binning_control
GL_QCOM_driver_control
GL_QCOM_perfmon_global_mode
GL_QCOM_extended_get
GL_QCOM_extended_get2
GL_QCOM_tiled_rendering
GL_QCOM_writeonly_rendering
GL_EXT_sRGB
GL_EXT_sRGB_write_control
GL_EXT_texture_sRGB_decode
GL_EXT_texture_filter_anisotropic
GL_EXT_multisampled_render_to_texture
GL_EXT_color_buffer_float
GL_EXT_color_buffer_half_float
GL_EXT_disjoint_timer_query

下記のページを更新しました
CPU/GPU OpenGL ES Extension (Mobile GPU)
SmartWatch スペック一覧

2014/07/11訂正: 実測結果より cpu0 しか使われておらず実質 single core 700MHz 相当でした(詳細はこちら)

関連エントリ
Android SmartWatch ZWatch で 3Dゲーム (ChiRaKS)
Android SmartWatch スマートウオッチのスペック比較表
Android SmartWatch SmartQ ZWatch (4) アプリの管理
Android SmartWatch SmartQ ZWatch (3) 腕に関数電卓
Android SmartWatch SmartQ ZWatch (2)
Android 4.1 SmartWatch SmartQ Z Watch

CPU 負荷が低い 新しい 3D API

昨年の AMD Mantle を皮切りに DirectX 12 が発表され、
つい先日 Apple から Metal も登場しました。
DirectX 11 以降停滞かつ安定していた状態から一変、
新しい GPU 向け API への流れが加速しつつあります。
どれも DirectX11, OpenGL とは互換性がない全く新しい API セットです。

これまでと趣が大きく異なっているのは CPU のための刷新だということ。
新しい描画機能への対応はなく GPU へのハードウエア追加も特に求められていません。
目的は CPU 負荷の軽減です。

API           Platform   Beta SDK   GPUs
-------------------------------------------------------------
Mantle        Windows    2014/5     RADEON GCN
Direct3D 12   Windows    ?          GCN,Fermi,Kepler,Maxwell
Metal         iOS 8      2014/6     PowerVR G6430

それだけ CPU の負荷の高さが問題になっていたことになります。

これまでは共通 API の互換性の代償として厚いドライバのレイヤーが存在し、
さらに性能向上により CPU が転送するコマンドの規模も大きくなりました。
Multi Core CPU が当たり前となっているにもかかわらず、
旧態依然とした OpenGL はスレッドによる最適化を阻んでいます。

ドライバのオーバーヘッドは、ゲーム専用機 (Game Console) と汎用機
PC/Smartphone の大きな違いの一つとなっていました。

●シンプルに

固定機能は段階的に減っていき、3D 描画に必要なアルゴリズムのほとんどが
アプリケーション側のソフトウエアで実装されるようになりました。
汎用化が進んで GPU の用途が広がると、既存の高度な機能やドライバの手厚い保護が
かえってプログラミングの自由を妨げることがあります。

GPU はもともと進化が早く、機能も性能も使われ方も短期間で変化してきました。
Desktop から Mobile に移っても同様です。
高度なレベルで統合された API は大きな変化についていくのが困難になります。
何でもやってくれる命令は便利ですが、ある程度使われ方が決まっていないと
仕様を決められないからです。
変更が頻繁に行われるほど設計はよりシンプルになり、依存を減らす方向に進みます。

Direct3D 10 では Shader の統合やリソースの Buffer 化といった改革が行われました。
実際に使ってみるとリソース管理は思ったより簡単ではない事に気が付きます。
Resource View には細かなフラグ設定が必要で、
慣れるまでは組み合わせの制限に悩まされました。
本当に自由に感じたのは Direct3D 11 の ComputeShader からです。
用途もデータの仕様もすべてプログラマが決められます。

Texture Atlas は複数のテクスチャを巨大なテクスチャに統合します。
中の配置をプログラマが自分で管理しなければなりませんが、
その代わりシェーダーは uv だけで好きなテクスチャを読み出すことが可能です。
もし仮に GPU のメモリ全部を巨大な 1 枚のテクスチャとみなすことができたら
uv はポインタとほとんど同じものになるでしょう。
現状リソース管理はプログラマに開放されていませんが、
Texture Atlas は制限を超えるための手法の一つとみなすことが出来ます。

OpenGL の Shader 命令は DirectX よりもかなり後にデザインされたものなので、
Uniform の配置やシェーダー同士のバインドも自動化されています。
OpenGL 3.x 以降はメモリ配置をプログラマが決められるようになり、
4.x 以降はシンボルのバインドも単純な番号指定に置き換わりつつあります。
Direct3D の低レベル命令に近づいています。

GPU は汎用性を増していますが、互換性を維持した積み重ねは
必要以上に複雑になってしまうことがあります。
新しい API では、CPU 負荷の低減と同時に
よりシンプルで使いやすい API への回帰も期待できます。

● Command Buffer

描画時に CPU が行っているのは Command Buffer の構築です。
いわば GPU (Command Processor) が実行するプログラムそのもので、
アプリケーションは毎フレーム動的にプログラムを生成していることになります。

ドライバはできるだけ GPU の性能を引き出すように作られているので、
無駄な Command を省くなどの最適化が行われます。
ハードウエア毎に構造が異なるので、GPU Native な形式への変換も必要になります。
GPU Command の生成と発行はそれなりにコストがかかります。

ステートの値が必要になるのは Draw のタイミングなので、
Command の生成は描画命令まで遅延します。
Draw 命令に負荷が集中して見えるのはそのためです。

各種 Buffer 化は Command 負荷軽減手段の一つとなります。
パイプラインステートだと描画のたびに Command Buffer に書き込まれますが、
Buffer なら予め転送しておいたリソースをアサインするだけで済むからです。

●ゲーム専用機 (Console)

ゲーム専用機では PC と事情が大きく異なります。

 ・互換性の枷がない
  ・ハードウエア互換性が不要 (ハードは単一)
  ・ソフトウエア互換性を持たない (SDK の上位互換性を持たない)
 ・必要に応じてより低レベルな最適化手段が用意されている
 ・ハード内部の情報がある程度公開されている

ゲーム専用機は数年サイクルでリフレッシュされ、互換性の確保には
専用ハードウエアまたはソフトウエアエミュレーションが用いられます。
そのためソフトウエア (SDK) 互換性があまり重要ではありません。

最初から GPU Native な形式を使用できることもあり、
CPU のオーバーヘッドも PC と比べるとかなり低くなっています。

必要に応じてより低レベルな最適化が可能なことも専用機の特徴です。

最近は少ないと思いますが、例えば GPU Command を直接操作できるなら
事前にモデルデータを GPU Native な Command 形式に変換しておくことが出来ます。
メモリに Buffer Data と Command Buffer をロードするだけで描画が可能となります。
動的な Command 生成と比べて CPU 負荷はほとんど生じません。
(ただしいくつかのトレードオフが発生するので必ずしも最善とはいえない)

ハードの内部構造がある程度公開されている点もプログラマの負担を減らしてくれます。
描画アルゴリズムの設計時に内部の仕組みがわかっていれば、
どの方法が効率が良いのかある程度判断できるからです。
あまり迷わなく済みます。

●互換性とこれから

・ゲーム専用機との差が小さくなる
・API の分裂

新しい API は今の CPU/GPU 性能と使われ方に合わせた再設計が行われます。
全体的な動作効率があがり、CPU オーバーヘッドの低減などパフォーマンス特性は
よりゲーム専用機に近づいていくものと考えられます。
その反面、現状ではプラットフォームごとに仕様が分断されており、
互換性においては新たな課題が残ります。

OpenGL ES 2.0 はモバイルからブラウザまでプラットフォームの枠を超えて
用いられており、統一された API として大きな意味を持っていました。
今後同じように OpenGL ES 3.0/3.1 が広く用いられるようになるのかといえば
必ずしもそうではないようです。
特に iOS の場合は Metal 対応デバイスと一致しているため、
性能や機能のために OpenGL ES 3.0 を選ぶメリットが無くなりました。

                                      ES2.0  ES3.0  Metal
----------------------------------------------------------
Apple A5/A6    PowerVR SGX543/554       Y      -      -
Apple A7       PowreVR G6430            Y      Y      Y

Android の ES 3.0 や Desktop の OpenGL 4.x と互換性を保つためには必要ですが、
性能や使いやすさを優先するなら Metal が選ばれる可能性が高まります。
用途に応じた使い分けが行われるでしょう。

とはいえ各種プラットフォームへの個別対応は大変です。
OpenGL なら Low Overhead Profile や Multi thread Extension のような、
プラットフォームを超えた新しい仕様が登場することを期待します。

関連ページ
3D Low overhead API

Android の新しい GPU BayTrail-T Intel HD Graphics

Bay Trail-T 搭載の Android 端末が発売されたので軽く調べてみました。
Android 端末に使われている GPU の種類に Intel HD Graphics が
新たに加わったことになります。

Qualcomm     Adreno
Imagination  PowerVR
NVIDIA       Tegra
ARM          Mali
Vivante      GC
Intel        HD Graphics   ← NEW

ASUS MeMO Pad 7 ME176

Adreno 320/330, Mali-T604, PowerVR G6430 (iOS) に続いて
入手可能な OpenGL ES 3.0 対応端末となっています。

対応している Extension は下記の通り。

// ASUS MeMO Pad 7 ME176 Android 4.4
// Atom Z3745 x86 RAM 1GB

GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics for BayTrail
GL_VERSION: OpenGL ES 3.0 - Build eng.yunweiz.20140425.225700

GL_EXT_blend_minmax
GL_EXT_multi_draw_arrys
GL_SUN_multi_draw_arrys
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_compression_s3tc
GL_EXT_texture_lod_bias
GL_EXT_color_buffer_float
GL_EXT_packed_float
GL_EXT_texture_rg
GL_INTEL_performance_queries
GL_EXT_texture_storage
GL_OES_EGL_image
GL_OES_framebuffer_object
GL_OES_depth24
GL_OES_stencil8
GL_OES_packed_depth_stencil
GL_OES_rgb8_rgba8
GL_ARM_rgba8
GL_OES_depth_texture
GL_EXT_color_buffer_half_float
GL_OES_vertex_half_float
GL_EXT_shadow_samplers
GL_OES_point_sprite
GL_OES_blend_subtract
GL_OES_blend_func_separate
GL_OES_blend_qeuation_separate
GL_OES_standard_derivatives
GL_OES_read_format
GL_OES_mapbuffer
GL_EXT_discard_framebuffer
GL_EXT_texture_format_BGRA8888
GL_OES_compressed_paletted_texture
GL_OES_ELG_image_external
GL_OES_compressed_ETC1_RGB8_texture
GL_OES_fixed_point
GL_OES_vertex_array_object
GL_OES_get_program_binary
GL_OES_texture_3D
GL_OES_texture_cube_map
GL_OES_fbo_render_mipmap
GL_OES_texture_float
GL_OES_texture_float_linear
GL_OES_texture_half_float
GL_OES_texture_half_float_linear
GL_OES_stencil_wrap
GL_OES_element_index_uint
GL_OES_texture_npot
GL_OES_texture_mirrored_repeat
GL_EXT_sRGB
GL_EXT_frag_depth
GL_APPLE_texture_max_level
GL_EXT_occlusion_query_boolean
GL_INTEL_timer_query
GL_ANGLE_texture_compression_dxt1
GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5
GL_EXT_texture_compression_dxt1
GL_OES_required_internalformat
GL_EXT_separate_shader_objects
GL_OES_surfaceless_context
GL_OES_EGL_sync
GL_EXT_robustness
GL_EXT_shader_texture_lod
GL_EXT_unpack_subimage
GL_EXT_read_format_bgra
GL_EXT_debug_marker
GL_KHR_blend_equation_advanced
GL_EXT_shader_integer_mix

対応している圧縮テクスチャフォーマットは ETC2/EAC, ETC1, DXT(S3TC) 。
DirectX11 世代の GPU なので機能面での心配はおそらく不要でしょう。

Android 向けには、BayTrail の他にも新 Atom (Silvermont core) SoC として
Z3400/Z3500 (Moorefield) が発表されています。
搭載 GPU は PowerVR G6400 となっており Intel HD Graphics ではありません。

Impress: Intel、22nmのスマートフォン向けAtom Z3400/3500を発表

実際に 2014/5/8 に au から Z3580 を搭載した MeMO Pad 8 が発表されています。
発売自体は 8月とまだ先です。

Impress: LTE対応の8インチタブレット「ASUS MeMO Pad 8」

Tablet            SoC   core clock   display    GPU
---------------------------------------------------------------------
MeMO Pad 7 ME176  Z3745  4  1.86GHz  1280x800   Intel HD Graphics 4EU
MeMO Pad 8 ME181  Z3745  4  1.86GHz  1280x800   Intel HD Graphics 4EU
MeMO Pad 8 (au)   Z3580  4  2.33GHz  1920x1200  PowerVR G6430

Full HD モデルに使われているのは PowerVR G6430 の方です。
多くの Windows Tablet 同様に ME176/ME181 の画面サイズは 1280×800 なので、
純粋な GPU 性能では Intel HD Graphics (4EU) よりも PowerVR G6430 の方が
高いのではないかと思われます。

SoC core CPU-clock  GPU                   GPU-clock  fop   GFLOPS
-----------------------------------------------------------------
Z3745  4  1.86GHz   Intel HD Graphics 4EU   778MHz    64     49.8
Z3580  4  2.33GHz   PowerVR G6430           533MHz   256    136.4

Wikipedia Atom (system on chip)
Intel Atom Processor Z3745 (2M Cache, up to 1.86GHz)

Android でも x86 端末は珍しくなくなりました。
CPU 自体は x64 にも対応しています。

おそらく今後 Android も 64bit に対応すると思われますが、
既存の端末に対して 64bit 版が提供されるかどうかは不明です。
ここしばらくは、購入するタイミングが判断しづらく悩ましい状態となりそうです。

関連エントリ
BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)
コンパイル時間の比較 BayTrail
Atom Bay Trail の浮動小数点演算能力

Objective-C の Object を C++ で扱う (smart pointer)

iOS/OSX の API の多くは Objective-C の Interface となっています。
他のプラットフォームとのコード共有を考えるならば、
アプリケーション側はできるだけ普通の C/C++ で書きたいと思うかもしれません。
この場合 System の API 呼び出し部分を分離して、何らかの Wrapper 経由で
アクセスすることになります。

Applicaton     *.cpp : C++
Library header *.h   : C++ / Objective-C++
Library source *.mm  : Objective-C++

Wrapper Library のヘッダは C++ と Objective-C++ で共有されることになるので、
Objective-C の Object をそのまま記述することが出来ません。
ヘッダとソースで実装を分離して隠蔽すべきなのでしょうが、
扱う Class や Object が増えて結構手間がかかっていました。

おそらく一番簡単で確実な方法は、iOS/OSX の場合だけアプリケーション側の
.cpp (.cc) を Objective-C++ とみなしてコンパイルすることでしょう。

ですが、どうしても純粋な C++ としてコンパイルしたかったので、
C++ で Objective-C の Object を所有できるようにしてみました。

// IDPointer.h
class IDPointer {
    void*  iPointer;
public:
    IDPointer() : iPointer( NULL )
    {
    }
    ~IDPointer()
    {
        Clear();
    }
    void Clear();
#if __OBJC__
    void SetID( id obj )
    {
        Clear();
        iPointer= (__bridge_retained void*)obj;
    }
    id GetID() const
    {
        return  (__bridge id)iPointer;
    }
#endif
};
// IDPointer.mm
#import  "IDPointer.h"

void IDPointer::Clear()
{
    id  obj= (__brdige_transfer id)iPointer;
    obj= NULL;
    iPointer= NULL;
}

一見うまく動作するように見えますが、dealloc のタイミングが意図したものに
ならないことがあります。

void idpointer_test()
{
    @autoreleasepool {
      TempClass*  t0= [[TempClass alloc] init];
      IDPointer  ptr;
      ptr.SetID( t0 );

      TempClass*  p0= ptr.GetID();

      t0= NULL;
      p0= NULL;
      ptr.Clear();
      // --- (1)
    }
    // --- (2)
}

上の例は (1) ではなく (2) のタイミングで TempClass が dealloc されます。
原因は GetID() が id を返しているためで、ARC により autoreleasepool への
登録が行われているようです。
weak なポインタを返す場合、所有者の生存期間をコンパイラが保証できないため
autoreleasepool に委ねているものと思われます。
実際には autoreleasepool に入って欲しくないケースもあります。

IDPointer& operator=( const IDPointer& src )
{
    SetID( src.GetID() );
    return  *this;
}

例えば上のコードは SetID() が即座に retain しているため、
生存期間を考慮する必要がないのですが autoreleasepool に入ります。

void* のまま受け取ってから受け取り側が __bridge cast するか、または
__attribute__((ns_returns_retained)) をつけると autoreleasepool に
含まれないことがわかりました。

// IDPointer.h
class IDPointer {
    void*  iPointer;
public:
    IDPointer() : iPointer( NULL )
    {
    }
    ~IDPointer()
    {
        Clear();
    }
    IDPointer( const IDPointer& src );
    IDPointer& operator=( const IDPointer& src );
    void Clear();
#if __OBJC__
    explicit IDPointer( id obj )
    {
        iPointer= (__bridge_retained void*)obj;
    }
    void SetID( id obj )
    {
        Clear();
        iPointer= (__bridge_retained void*)obj;
    }
    __attribute__((ns_returns_retained)) id GetID() const
    {
        return  (__bridge id)iPointer;
    }
    IDPointer& operator=( id obj )
    {
        SetID( obj );
	return  *this;
    }
#endif
};
// IDPointer.mm
#import  "IDPointer.h"

IDPointer::IDPointer( const IDPointer& src )
{
    iPointer= (__bridge_retained void*)src.GetID();
}
IDPointer& IDPointer::operator=( const IDPointer& src )
{
    SetID( src.GetID() );
    return  *this;
}
void IDPointer::Clear()
{
    id  obj= (__brdige_transfer id)iPointer;
    obj= NULL;
    iPointer= NULL;
}

↑の場合は GetID() しても autoreleasepool に入ることがありません。

これで C++ 側でも比較的安全に Objective-C Object の所有や受け渡しを
行うことが出来ます。
Objective-C の Object の instance は ARC で管理されていますが、
C++ からは smart pointer (shared_ptr) として見えることになります。

使用例

// SampleAPI.h
class PlayerData : public IDPointer {
};
class Player {
    IDPointer  PlayerInstance;
public:
    void Init();
    void CreateData( PlayerData& data );
    void Play( PlayerData& data );
};
// SampleAPI.mm
void Player::Init()
{
    PlayerInstance= [MYPlayer newPlayer];
}

void Player::CreateData( PlayerData& data )
{
    data.SetID( [[MYPlayerData alloc] init] );
}

void Player::Play( PlayerData& data )
{
    id player= PlayerInstance.GetID();
    [player stop];
    [player playWithData:data.GetID()];
}