東方VGS（iOS）コードレビュー③ VGSView

VGSViewについて解説します。
https://github.com/suzukiplan/tohovgs-ios/blob/master/Touhou%20VGS/VGSView.m

VGSViewはiOS版VGSのグラフィックス描画処理を実装したViewです。
VGSのグラフィックス描画は、vgs2_putBG（BGを描画）やvgs2_putSP（スプライトを描画）といったVGS API（C/C++）を用いて行いますが、それらを用いて描画された情報はVGS VRAMというメモリ上に記憶されています。

VGSViewの責務（役割）を箇条書きで書くと、

• VGSのメインループを回す（VGS VRAMに1フレームの描画がされる）
• VGS VRAMを、iOSの描画処理系に合わせた形式に変換
• 画面に出力（表示）
• 上記を1秒間に60回の間隔（60fps）で繰り返し実行

となります。

iOSのゲームに適したグラフィックス描画機能としてはOpenGL/ESやMetal（GPU Renderer）がありますが、これらは上述の用途で使うのは不適当です。というのも、GPU Rendererで上記要件を満たそうとすると、

• 毎フレームVGS VRAMをテクスチャ変換して描画 or
• 1pixelを2つのポリゴンで表現して、（変化があったpixelの）色情報を設定

といった処理方式で実現することになりますが、前者（テクスチャ変換）は変換オーバヘッドが物凄く大きく、VGS VRAMのサイズ（東方VGSの場合は240x320）のテクスチャを毎フレーム生成することは現時点最新のGPUでも恐らく不可能です。仮にできたとしてもGPUが火を吹く勢いで回り熱暴走を起こします。

後者の処理は前者よりは現実的ですが、その場合全画面のpixelの色情報を変えようとすると最大240x320（76800）回のパレット変更命令をGPUに飛ばす必要があり、GPUへのデータ伝送は物凄く遅いので60fpsではとても動けないようになるでしょう。

つまり、VGSの要件を満たすことができるのは、GPU描画ではなくCPU描画一択になります。

まず、VGSViewを生成するとCALayer（Core Animation Layer）を独自のもの（VGSLayer）へ差し替えます。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L156-L159

そして、CADisplayLinkを用いて垂直同期の発生間隔でsetNeedsDisplayをコールするようにしています。これでVGSLayerの描画更新が1/60秒間隔で行われるようになります。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L170-L171

VGSLayerが初期化されると、まず2枚のCore GraphicsのBitmap Contextを生成します。これが変換後のVGS VRAMバッファになります。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L101-L115
2枚準備している理由は、VGSLayerがダブルバッファリングと呼ばれる方式で描画出力を行っている為です。ダブルバッファリングとは、一方のバッファの内容を表示中にもう一方のバッファ更新を非同期で行うことで、60fpsの描画がスムースに行われるようにするためのものです。（実のところ、最近のiPhoneならこんなことしなくてもシングルバッファで余裕で回せますが...）

その後、ダブルバッファリングを実現するためのGameLoopスレッドを生成して起動しています。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L117-L121

GameLoopスレッドでは、100μs間隔で描画指示が発生するのを待機して、
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L34
描画指示が発生したら、VGSのメインループを１回回し、
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L35-L42
その後、VGS VRAMの内容をCore GraphicsのBitmap Contextの形式に変換しています。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L48-L61

GameLoopが本来必要な処理は以上ですが、VGSにはグローバルリクエストという機能があり、それに応じてAppStoreのページを開くといった要求処理を実装しています。（東方VGSでは使ってませんが、VGSからのネイティブ広告の表示制御などはこのグローバルリクエストで実現しています）
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L63-L88

最後に、CADisplayLinkにより1/60間隔で発生するVGSLayerの描画要求のコールバック（display関数）では、描画指示を出しつつ、描画が確定している方のCore Graphics/Bitmap ContextをViewの表示内容（content）としてセットする処理を行っています。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSView.m#L131-L139

以上でVGSViewの解説は終わりです。

この部分は東方VGSに限らず、VGSを最初にiOSへ移植した時から一切変更していないので、あまり面白い内容ではないですね。だから、実装内容を淡々と解説しましたが、このVGSViewを最初に作った当初はもの凄く苦労しました。
というのも、市販のiOSアプリ関連の書籍には、役立つ内容が書かれたものが一切無かったので。（仕方が無いのでApple公式の分かり難いCore Graphicsのドキュメントを読むなどして理解しました）
ゲームのグラフィックス描画処理というと、最近ではOpenGL or MetalといったGPU Rendererを用いた方式に一本化されていて、スプライトやラスタといった昔ながらのコンピュータグラフィックスの描画方式は、完全に過去のものになってしまったのかな。

東方VGS（iOS）コードレビュー② ViewController

大規模なアプリの場合、ViewControllerが幾つもあったりしますが、東方VGSのViewControllerはひとつだけです。
https://github.com/suzukiplan/tohovgs-ios/blob/master/Touhou%20VGS/VGSViewController.m

更に言うと、その唯一のViewControllerが管理するViewも最大5つ（iPhone4s以前 or iPadの場合は4つ）だけしか無いので、ViewControllerの実装は物凄くシンプルになっています。

※上図では省略していますが、全てのViewの親（ルートView）としてVGSScreenViewというものがあります。

ViewControllerが生成されるとiOSからデリゲートメソッドのviewDidLoadがコールバックされますが、VGSViewControllerでは、そこで上述のViewを作って並べつつ、VGS特有の初期化処理を行っています。

以下、VGSViewControllerのviewDidLoadに実装されている処理内容を見ていきます。

(1) 多重初期化の抑止
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L38-L40
これは、iOS8の時にviewDidLoadが2回実行され結果的にアプリが起動時にクラッシュするバグ（※iOS側のバグ）が発生したので、その時に入れた対処コードです。

このバグ自体、発生条件がかなり限定的なのですが、東方VGS（というか私が作った全てのiOSアプリ）は不運にもその条件に該当してしまったので、当時公開していた全てのアプリにこの対処コードを入れてアップデートしました。（物凄く大変でした）

そういえば、この対処バージョンの東方VGSをアップデートするついでに、東方幻想郷から「Bad Apple!!」を追加しましたが、これは当然そういう意図で追加されたものです。

iOS版東方VGSをAppStoreで公開していた約4年間ほどの短いようで長い歴史の中で、ほぼ唯一不評のレビューが付き、総平均レビュー値を4.9から4.8に下げる原因となったのがコレでした。ただ、普通のアプリだったら「起動すると落ちる☆１」と低評価レビューの嵐となる所、「起動すると落ちる☆5」という風に、不満を言いつつも評価を下げないでくれる人が結構居ることに少し驚きました。

このiOS8デグレード事件以外に、もう一つ不評を買ったのが、AppStoreだとアップデート時の更新内容の説明文を最大4000字書けたので、「4000字きっかり埋める説明文を書いてみよう」と思い立ち、少し長めのポエムを書いた時ですね。 

逆に一番評価が高かったのが「神々が恋した幻想郷」と「芥川龍之介の河童」を追加した時のレビューで、平均☆5.0（約300件ついたレビューがオール☆5）でした。オール耳コピで作る必要がある風神録の楽曲全曲収録という無謀な挑戦ができたのは、この時のオール☆5が原動力になりました。

(2) バージョン切り分け
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L44-L67
この辺のバージョン切り分けは色々と謎ですね。
過去バージョンとの互換性を保つ為に色々な試行錯誤が行われていたようです。（他人事）
iOSの場合、Androidと違ってOSバージョンがフラグメント化しないので、古いバージョンはガンガン切ってしまって良いかと思うのですが、東方VGSではApple側から「おい、やめろ！」と言われるまで最低サポートバージョンをiOS4.3（東方VGSの機能を実現する上で最小限の機能セットが実装されているiOSの最低バージョン）以降にしてました。（最終的には、古すぎるバージョンのiOSをサポートしているとAppleから審査提出を拒否されるようになったので、最低サポートバージョンをiOS6.1にまで引き上げました）

(3) ルートViewの作成
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L68
ViewControllerのルートViewとしてVGSScreenViewというものを作成して追加しています。VGSScreenViewには「タッチイベントを取得してVGSへ送信する」という役割があります。（その役割が無ければルートViewは単なるUIViewでも良かったとも言えます）
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSScreenView.m
普通のiOSアプリを作った事がある人なら、「タッチイベントの処理は各Viewが担えば良いのでは？」と考えるかもしれません。実際にタッチを受け付けるのはVGSViewなので、わざわざタッチイベントを処理する専用のViewなんて設けるのはナンセンスだと言えます。ただし、UIViewは存在自体が結構重いモノなので、Viewをグルーピングする用途しか持たない空のUIViewをルートに配置するのではなく、そこにタッチイベント処理を集約させる機能を持たせ、VGSViewの責務範囲を減らしつつロジック分散するのは、ある意味（※VGSというスペシフィックなモノに限れば）合理的かもしれません。

ちなみに、このViewのグルーピングという考え方でAndroidとiOSで決定的な違いがあります。Androidの場合、Viewのグルーピングを行う専用の機能（ViewGroup）をViewとは分離して定義した一方、iOSの場合Viewのグルーピング機能をそのままView（UIView）に持たせています。結果的に、Viewグルーピングの実装はAndroidの方がシンプルになった反面融通が効きにくいものになり、iOSの方はかなり融通が効く反面実装コストが高く付くものになりました。何れにせよ一長一短あるのですが、だいたいどのアプリも似たり寄ったりなmaterial designとかいうクソみたいなデザインを採用している現状を勘案すると、この部分のスキームは結果的にAndroidの方が優れたものだったのではないかと思っています。

(4) romdata.binの読み込み
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L69-L77
VGSの場合、グラフィック、音声（効果音、BGM）、テキストなどのアセットデータは独自形式のバイナリデータとして「romdata.bin」というファイルに集約しています。そのromdata.binファイルを読み込みメモリ上に配置する処理をここで行っています。そして、ここで読み込んだメモリ上のデータ（ROMデータ）は、アプリのプロセスが生存中維持し続けます。これにより、東方VGSでは一般的なiOSネイティブアプリやUnity等で書かれたゲームアプリを作る時に悩まされる「ガーベージコレクト」が一切発生しません。（その代わりに表現力が貧弱になる）

(5) VGSViewとUIImageViewの作成+配置
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L79-L114
VGSViewというVGSのコア機能を持つViewと、上下の画像イメージの作成と配置をココで行っています。
16:9の端末と4:3の端末で処理が分かれていますね。
iOSアプリを作ったことがある方なら、「これだとiPhone6や6 plusで画面下にスキマが出来てしまうのでは？」と疑問に思うかもしれませんが、東方VGSはiPhone6（4.7"）やiPhone 6 plus（5.5"）の場合は互換モードで動くので、特に問題なく配置されます。（iPhone Xでどうなるかは知らない）
この部分はちょっと直したいですね...

(6) VGSBarViewの作成+配置
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSViewController.m#L116-L118
最後にVGSBarViewという画面最上部の時計を表示しているViewを作成して配置しています。リリース当初の東方VGSにはこのViewは無くて、iOS標準のステータスバーを表示していました。しかし、iOS側の度重なる仕様変更で嫌気が差し、最終的にはiOS標準のステータスバーを削除して自前のステータスバーを置く形に落ち着きました。
iOSはバージョンアップの都度、かなりラジカルに仕様変更をしてきますが、最も煽りを食うのがこのiOS標準のステータスバーの部分です。ステータスバーはiOS側の持ち物なので、当然といえば当然ですが。（最近では、iPhone Xのあの変態的な形状のステータスバー...ハードレベルで変えてくるから堪ったものではない）

東方VGS（iOS）コードレビュー① AppDelegate

先日OSSとして公開したiOS版東方VGSのアプリ実装を眺めつつザックリと解説するシリーズ。（シリーズが続くかは不明）
本稿は、iOSアプリケーション開発経験者ではなくても意味が分かるように書いていき、最終的にはiOS版東方VGSの全体的な作りが何となく分かるようになることを目標にしています。
第1回の今回はAppDelegateというiOSアプリの一番根っこの部分で何をやっているかを見ていきます。

↓このソースの解説
https://github.com/suzukiplan/tohovgs-ios/blob/master/Touhou%20VGS/VGSAppDelegate.m

(1) AppDelegate（起動時の処理）

iOSアプリの場合、起動が完了するとAppDelegateのdidFinishLaunchingWithOptionsが呼び出されます。（もっと正確に言えば他のUNIXプログラムと同様main関数から起動して、そこでAppDelegateが登録されます。そして、iOS側の制御でアプリの起動処理が完了した時にdidFinishLaunchingWithOptionsがコールバックされます）
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSAppDelegate.m#L23

そこでやっていることは大まかに、
・ViewControllerの登録
・OpenALの初期化
・AudioSessionへのproperty-listenerとinterruption-listenerの登録

ViewControllerはAndroidで言うところのActivityやFragmentのことで、アプリのViewを制御するコードを書きます。ViewとControllerが登場したということは、Modelを作ってMVCのデザインパターンで設計すべしと考えるのが普通ですが、東方VGSはMVCとかそういうデザインパターンでは作っていません。もちろん、DDDとかそういうモノでもなくて、デザインパターン的には好き勝手に作っています。一人でプログラミングする場合、それが一番生産性が高い。

OpenALは音を再生する為に使っています。普通音を再生するにはAudioPlayer等を使いますが、東方VGSの場合、VGSが音声を発生する装置をエミュレーションしてパルス符号データを時系列に吐き出し続け、それを拾って再生するのでAudioPlayerよりも波形を逐次直書きできるOpenALを使っています。（Androidの場合はOpenSL/ESを使っています）

AudioSessionのproperty-listenerは、kAudioSessionRouteChangeReason_OldDeviceUnavailableというハードウェアイベントを拾う為に登録していて、これは、ヘッドセットがデバイスから外された時に発生するイベントで、これを検知した時に音声の再生をポーズするために使っています。これは、アプリ公開後にユーザからそういった要望を受けて実装しました。（iTunesがそういう仕様だったらしく、東方VGSも同じ仕様だと思ってしまったのだとか。学校の休み時間に東方VGSを聴いて授業が始まる時にヘッドセットを抜いて仕舞ったところ、授業中にうっすらとBGMが流れてしまうハプニングがあったと伺ったので、申し訳なく思って速攻で実装しました）
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSAppDelegate.m#L72

interruption-listenerは、東方VGSのオーディオセッションに対して割り込みが発生した時にアプリを停止させる処理を実行しています。これは、バックグラウンドで再生中に電話が掛かってきたり、別の音楽アプリ（iTunesなど）を起動した時にアプリが動き続けると煩わしいので、それなら止めた方が良かろうということで実装しました。この影響で一部アプリ（オーディオセッションを奪うアプリ）とは共存できないという仕様になりました。この仕様については、アプリ公開中に一部ユーザから不満を言われていたので、直せばもっと高い評価が得られたかもしれません（ちなみにiOS版のレビュー評価件数は最終的に、DL数約20万に対して5千件ほどで平均4.8ぐらいでした）が、逆に治してしまうと電話が掛かってきた時にアプリがちゃんと止まってくれるか分からなかった（開発当時はiPhoneではなくiPod touchしか持っていなかった）ので、怖くて修正できなかったと記憶しています。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSAppDelegate.m#L84

(2) AppDelegate（バックグラウンド関連）

バックグラウンド関連での処理もAppDelegateで行われますが、ココでやっていることはバックグラウンドに入ったフラグのON/OFFぐらいです。
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSAppDelegate.m#L104
https://github.com/suzukiplan/tohovgs-ios/blob/71464aae09f107fbf02e9ce1989d9bfb80381e37/Touhou%20VGS/VGSAppDelegate.m#L119
後付で、音楽がプレイ状態でない時にバックグラウンド遷移する時はアプリをexitするようにしました。（その方が若干程度ではありますが電池が節約できたので）

もっと淡々と書こうと思ったのですが、コードの1行1行にそれなりに思い出が詰まっているので、全然淡々としていないな。

iOS版東方BGM on VGS（再公開）

iOS版の東方VGSを再公開しました。
ただし、AppStoreではなくGitHubでOSSとして。
https://github.com/suzukiplan/tohovgs-ios

※お手持ちのiPhoneへインストールするにはMac+XCODEが必要になります

流石にこれではあんまりなので、代行公開をOKにしようかとも考えたのですが、様々なリスクが考えられるのでそれについては原則NG（正確には事前許諾が必須）としています。

ImageViewで色を乗算方式で変える方法（programmatically）

AndroidのImageViewで色をプログラム的に変えたいと思って調べると、だいたい「元画像が単色」の場合の変更方法しか出てこない。マテリアルデザインの場合、原則アイコンは単色（tint-color）でデザインするのが基本だから仕方ないですね。

ここでは、元画像が複数色のものを全体的に色調を変える方法を書きます。

オリジナル ⇒ 全体的に色調を変更
（素材はいらすとやから借用）

ImageView#setColorFilter を使えば色を変更できるらしいという情報は、ググれば沢山出てくるのですが、全体的に色調を変える場合は、第二引数のModeに PorterDuff.Mode.MULTIPLY を指定してあげるだけで良いです。

上図のような全体的に緑がかった感じにする場合は、

imageView.setColorFilter(0xff00ff00, PorterDuff.Mode.MULTIPLY);

でOK。

実際にAndroid上で動かせるようにしたものをGitHubにアップロードしておきました。
https://github.com/suzukiplan/ImageViewTest

音ゲーの譜面を暗譜する方法

ガルパにせよデレステにせよ、音ゲーの譜面を暗譜するのはほぼ無理だと思っています。

音ゲーなんかより遥かに鍵盤数が多いピアノの暗譜なんて人間技じゃない・・・という風に思うかもしれませんが、ピアノの暗譜は音ゲーのそれと比べると遥かに易しい。
ピアノに限らず楽器全般の暗譜は、楽譜を完全に脳内にコピーしている訳ではなく、単に脳内で音を再現できる状態に過ぎないので。
「脳内で音を再現できる状態」とは、例えば、好きな歌を鼻歌でふふ～んと歌うことができる状態のことを言います。（これなら誰でも出来るはず）
そして、楽器演奏は音に紐づく動作を繰り返す運動行為（例えばギターなら一番低いEの音であれば、フレットを抑えずに1弦を弾くといった感じ）で、鳴らしたい音に紐づく動作が記憶できていれば、脳内で再生している音楽に対応づく動作パターンへの変換を行うだけで暗譜演奏ができるという事になります。（実際に楽器をやってみると分かることですが、これは想像するよりも遥かに簡単に誰でも出来ることです）

スマホの音ゲーで暗譜がほぼ無理な理由は、楽譜自体の形を暗譜しなければいけない為です。もちろん、出来ている人も居るかもしれませんが。（速度1でフルコンできるタイプの人は恐らくそれです）

ゲーム側に次のようなオプションがあれば、暗譜が簡単に出来るようになる筈。

（１）FX音のPANを左側と右側で変える
※FX音 = タップやスライド等で鳴る音のこと

こうすることで、音と動作（左の方を叩くとか右の方を叩く）を紐付けて記憶できるようになるので、音による暗譜が可能になります。

（２）FX音の音程を左側と右側で変える

左側の音程＝低い、右側の音程＝高いという感じ。
ただし、曲によってはFX音と合わなくなる可能性があるかも。
（その代わり（１）だけの場合と比べて圧倒的に記憶し易くなる筈）

なんでデレステにもガルパにもそういうオプションが無いのか？（特許絡みの何かがあるのか、あるいは単純に開発会社にそういう発想が無いのか）

まぁ、アプリの改修なんて期待してもしょうがない（こうしてネットで晒しておけばワンチャンあるかも程度の期待は無くはない）ので、ローカルフィックス案も一応あります。
それは、
①イヤフォンは使わない
②FX音をoffにする（アプリ設定）
です。
物凄くアナログですが、要するリアル打鍵音でプレイ。
これなら（１）はアナログ的に何となく実現できます。
まぁ、かなり微量ではありますが0とnone 0の間には大きな隔たりがあることを実感できるかと思います。
ついでに、デレステもガルパも実際にデバイスを叩いたタイミングと音が鳴るタイミングに微妙にズレがある（これは恐らく技術的には改修不可能だと思う）のですが、それも完全に無くなるというメリットもあります。

この分野を純粋に突き詰めていくと、曲の音声もOFFにするのがベストだったりする（完全なサイレントにすることでスライドのこすれる音も構成要素として成立するようになる）のですが、そこまでいくと「なんで、このゲームプレイしてるんだろ」という哲学的な感じになってきます。

スマホ時代の商業動画コンテンツ配信サービスについての簡単な考察

上図はNetflixのAppStore（アメリカ）での過去1年間のセールスランキング推移です。
もちろんガチャとかは一切無く、アプリ上での課金手段はサブスクリプション（定額課金）のみ。ガチャゲー一色の日本のセルランと違って、米国のセルラン上位はNetflix、Spotify、YouTubeなどのストリーミング配信系サービス（全てサブスクリプションの筈）が過半数を占めていて、ゲーム系ではクラクラ、キャンクラ、ポケモンとかぐらいでそれ程多くはありません。ちなみに、ストリーミング配信系以外の非ゲームだとTinder（出会い系）とかが強い。

Netflix補足：
・米国のオンラインDVDレンタル、ストリーミング配信会社
・1997年創業、1998年にウェブ上でのDVDレンタルサービスを開始
・2007年以降VODストリーミング配信を開始
・2002年からNASDAQに公開しているが2013年以降に急成長

http://www.nasdaq.com/symbol/nflx/interactive-chart?timeframe=1y&charttype=line

株価の成長具合から見て、正にスマホ時代に当たった商業動画コンテンツ配信サービスって感じでしょうか。

日本ではいまいちパッとしませんが。

Netflixの日本のAppStore上でのセールスランキングは100位付近。日本の同業種の他サービスとしては、dTV、RakutenTV、USENなどがありますが、どれもパッとしない印象。海外のその他サービスとしては、Amazonプライムビデオ、Huluなどがあり、Amazonプライムビデオはそこそこ好評ですが、Huluに関してはdTVやRakutenTVと同程度といった感じ。

Amazonプライムビデオは「prime会員になっていれば棚ぼた的に無料で動画が見れる」ことが好調の要因なので、Netflixのような「商業動画コンテンツ配信サービスとしての成功」と同列で考えるのは違和感があります。

Amazonプライムビデオ以外で日本でヒットしている同業種としては、少し毛色が違いますがAbemaTVとかでしょうか。（なお、YouTubeやニコニコ動画といった主にUGCを扱っているものは除外してます）

AbemaTVのAppStore上でのランキングは200位ぐらい。主に広告で収益化しようとしているようですが、有料会員登録するとVODで見れるようになるので、AppStore上のランキング=Netflixと純粋に同一形態と見做せるかもしれません。Netflixと違って国内向けのコンテンツ調達は十分できているであろうにも関わらず、Netflixにすら勝てていないところが中々興味深い。

単純に品揃えが原因では無いことは確かなようです。
そもそも品揃えさえ良ければ客が付くのであればdTVあたりがもっとヒットしている筈

以下、推測ですが、
米国は国土が広い関係で電波を隈なく配信することが（最初期の頃は）技術的に困難だったためケーブルテレビ中心に発達してきた一方、国土が狭い日本ではインフラ的な事情を割と簡単にクリアできたので、早期から電波放送中心に発達し、その結果米国では「多様なチャンネルの中から好みのチャンネルを買う文化」みたいなものが定着し、方や日本では（電波配信の性質上、垂れ流し状態にせざるを得ないので）「CM付きのコンテンツを無料で見る文化」が定着したと考えることができます。

参考資料：海外におけるケーブルテレビ市場の動向（総務省）
http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/2010cabletv/pdf/060421_2_3.pdf
2005年末時点の米国でのケーブルテレビ世帯加入率は84.6%で, 減少傾向ではあるが平成18年時点でも約69%程度とのこと。

参考までに、日本でのケーブルテレビの世帯普及率は実は（全く実感が無いのですが）そこそこ高いのですが、第三セクターが介入していたりするものが含まれているらしく、普通の（多チャンネル放送の受信に対応した）ケーブルテレビの普及率に絞ってみると1千万世帯に届いていない程度のようです。

もちろん、これは最初期の頃の話しで、今の米国には当然ですが地上波放送もあってアンテナさえ買えば無料で商業動画コンテンツを見ることができますが、それでもケーブルテレビの人気には根強いものがあります。

黎明期〜普及期に掛けてヒットすると、それに関わる強力な利権構造（日本なら電通とか）が同時に生まれることで、普及期以降に新たな方式を採り入れようとしても市場から排除される「三つ子の魂は百までメカニズム」と呼ばれる（※私が勝手に呼んでいる）市場原理が生まれます。これが（やや端折りますが）、サブスクリプション方式では商業動画コンテンツ配信サービスとして日本で成功出来ない原因の根本であろうと推測しています。

AbemaTVの広告モデルで何とかしようとする手法は、この推測が正しければ正攻法かもしれません。なので、長い目で見れば上手くいくんじゃないかと思っています。

ただし、仮に上手くいったとしてもせいぜいテレビCMと同程度のコンバージョンしかない（※テレビCMは、母数がメチャクチャ多いからコンバージョン率が低くてもそれなりにペイできるものだと思っている）となると、仮に私が広告を出す側の人間だったら「それならテレビでええやん」と思ってしまいそうな気がする。インプレッション等の数字が正確に分かるようになる筈なので、金を払って広告出稿する側からすると曖昧な「テレビの視聴率」よりもシビアな判断を下しやすいことがメリットといえばメリットかもしれませんが、それってプラットフォーム側からするとリスクでしかないかも。（AdSenceみたいにコンバージョン率が高いとかなら話しは別ですが、既存のテレビをインターネットに持ってきただけではその点はあまり期待できないと思っている）