2018年4月22日日曜日

東方VGS Lite 1.0.2 (不具合対策版)

不具合対策版の東方VGS Lite 1.0.2 を先程(AM2:30頃)リリースしました。
曲の再生が途中で止まってしまうという連絡を受けて調査していたのですが、結構難航しました。

デベロッパーコンソールで確認した限り、クラッシュレポートが挙がってきているので、アプリ側のバグであることは間違い無いのですが...
色々と厄介そうな感じです。

まず、「発生元不明」ってのが厄介そうですね。これは恐らく、stack traceを吐かずに強制したものと推測できるので、大方ActivityManager辺りにkillされたのだろうと思います。まぁ、それ自体はAndroidならよくある事です。

最も厄介なのは、私が再現環境(Android5.0以降の実機)を持っていないことです。(私物のスマホはiPhoneなんですよねぇ)

何とか知り合いからNexus6を借りることができたので、それで実機確認してみたところ、それらしき現象を確認。再現できればもう勝ったも同然だと思っていたのですが、そこからがまた長かった。

どういう修正をしたのかは、アプリのアップデート内容に無駄に事細かに書いておきましたが、(1)の修正が恐らく決め手です。これで治ってくれる・・・はず。
無駄に事細かに書いておいた修正内容
(500字制限なので実はこれでも結構削った)

2018年4月7日土曜日

東方VGS Liteを公開

GooglePlayで公開しました。
https://play.google.com/store/apps/details?id=com.suzukiplan.tohovgs2
開発着手から約2週間でリリースという超短期間で完成させたのですが、旧東方VGSのソースコードは1行も使っていなくて、完全フルスクラッチで作り直しました。言語はKotlinで。

音源モジュール部分はC言語(下記)ですが。
https://github.com/suzukiplan/vgs-bgm-decoder

言語の構成比率としては下図のような感じです。

ここまで短期間(実働では3人日ぐらい)で作れたのは、Kotlinの言語としての良し悪しというよりは、Android Studio(IntelliJ)の生産効率がメチャクチャ高いからですね。単純に私の開発速度が尋常じゃなく速いのもあるのですが、それでもiPhoneアプリで同じものを作ろうとしたら最低でも3倍(10人日)ぐらい掛かります。

iOS版の東方VGS Liteは多分作らないです。

東方VGS Lite (3)


東方VGSをオーバーホールするこの機会に、一部機種でバックグラウンド再生時に音飛びするあの問題の解消を試みました。

まず、この問題が発生する原因を簡単に解説します。

VGSでは、波形メモリ音源エミュレータが短い間隔で波形データ(PCM)を生成し、それをOSの音源ドライバへ逐次的に書き込むことで音を再生していて、音飛びはこの波形データ生成処理が遅延することで発生します。そして、アプリがバックグラウンド状態に入るとOSがアプリのCPUプライオリティを引き下げることが原因で波形データ生成処理が遅延します。

これを回避するため、AndroidにはWakeLockという仕組みがあります。東方VGSでは、バックグラウンドに入る時にPARTIAL_WAKE_LOCKというCPUプライオリティを維持するWakeLockを取得することで、CPUプライオリティを引き下げられないように要求していますが、それが一部機種で効いていないことが原因で「バックグラウンドにした時に音飛びする」という問題が発生していました。

それ効かない原因としては、WakeLockの権限の取り方が誤っている(アプリ側の問題)か、OSがアプリのWakeLock要求を無視している(OS側の問題)が考えられますが、WakeLock#acquire自体は成功しているので、後者が原因だろうと思っています。

ここまでが既に分かっていたことです。旧東方VGSでは、このアプローチで問題解決を試み続けていた訳です(最近は全くノータッチだったけど)。ただ、疑わしいと思いつつ、結構大変だった為に試せなかった方式があって、それは音源ドライバのAPIをOpenSL/ESからAudioTrackに変更するというものです。

そして今回、この変更を試みたのですが、かなりアッサリとバックグラウンド再生時の音飛び問題が解消されました。

オーバーヘッド的には、OpenSL/ESよりもAudioTrackの方が重いです。

ただ、OpenSL/ESの場合、バッファリングと再生の処理を全てネイティブスレッド(Cスレッド)で動かしているので、JavaスレッドのCPU使用率が上がらないため、OSが「CPU使ってないならWakeLock要らないよね?」的な感じでWakeLockを無効化させていたのではないかなと。対してAudioTrackの場合、バッファリングはJNI経由でJavaスレッド、再生はJavaスレッドのみで実行されるので、JavaスレッドのCPU使用率が上がるため、音飛びがしなくなったと。

ひとまず、一番大きな問題を解消できたので、後は細かい所を片付ければリリースできそう。
(今日中にはリリースできるかも)

2018年4月5日木曜日

東方VGS Lite (2)

ランドスケープ用のデザインを雑に作ってみました。
VGSだと割と面倒だし、どうせバックグラウンド利用が大半だからと Portrait 専用にしてましたが、ネイティブUIだと楽ですね。

画面構成要素としては、LandscapeもPortraitも全く同じで、
・上半分のヘッダー、ピアノ、コントローラの領域を PlayContainer
・リストのタブ(TabLayout)とリスト(ViewPager)を ListContainer
みたいな形で定義しておき、Landscapeの時はそれらを左右に並べるだけという感じ。
(5分で作れました)

2018年4月4日水曜日

Android版 東方VGS Lite(開発中)

東方VGSのAndroid版が新しいAndroidで動かなくなったという報告を頂いたので調べた所、VGSではなくネイティブUIで作り直してしまった方が手っ取り早そうだったので、作り直し中。
旧来の東方VGSはそのまま残しておき、東方VGS Lite(別アプリ)として公開予定です。
完成度は7割前後なのですが、ここから先が長い...
でも、4月中にはGooglePlayで公開できるかと思います。

2018年3月14日水曜日

サーバサイドのお勉強

スマホのソシャゲで使えそうなアカウントサーバを作ってみました。
https://github.com/suzukiplan/simple-account-server
https://github.com/suzukiplan/simple-ap-server

ただし、飽くまでも試作です。
実用的かは未知数。
現在の本職はクライアント畑の人間なのですが、サーバのことも把握しておこうかなと思いまして。要するに単なる興味本位です。

まずは、アーキテクチャ設計。

アカウントサーバというと、Web時代のソシャゲであれば、メアド(ID)とパスワードで作るのが一般的ですが、スマホ向けということで、POSTすれば自動生成され、アプリ側では preference / userDefaults にそれを記憶して使うのだろうと思います。この辺は実際にスマホのソシャゲを幾つか遊んでみた限り、だいたいそんな感じだろうと想像で作成。
初回起動時(アカウント生成)

自動生成されたIDとtoken(パスワードに相当するもの)を用いてログインするイメージは下図のような感じ。
ログイン

DBですが、アカウント情報というとRDB一択だろうとは思いつつ、スキーマ定義が面倒臭いというただそれだけの理由で MongoDB(NoSQL DBMS)にしてみました。MongoDBというと、どちらかというとログ用途というイメージなのですが。

どうしてもHiRDBなどのRDBじゃないとマズイのであれば、置き換えは割と簡単にできます(実際、試しにMariaDBに置き換えてみたのですが、コードの書き換えよりもスキーマ定義等の下準備の方が面倒だった)。なので、まぁこのまま良いかなと。

DBがMongoDBだから速いので、キャッシュとか要らないのではないだろうかと思ったのですが、実測してみた限りRedisの方が最大10倍ぐらい早かったので、Redisでキャッシュ(Read cache)も作ってみました。なお、Write cacheは現時点では実装してません。アカウントの情報更新量が多いとかで必要であれば、RabbitMQを使う感じでしょうか。

最後に言語。
言語の定番は PHP かな?と思いつつ, TypeScript + Node.js で。
理由としては、
・豊富なパッケージ(使おうとしたミドルのパッケージが全てnpmにあった)
・情報を見つけやすい(≒情報が多い?)
あたり。

サーバサイドの言語事情はよく分かりません。Goとかも興味ありましたが、習得するのも面倒だしNode.jsなら少し知っているから楽なので。実のところ、TypeScriptにする必要すら無い(=ダイレクトJSで良い)んじゃないかなと思ったのですが、modelの定義にclassが使えるのが便利だし、tscも色々良い感じになっていてコンパイル手間も無いに等しい状態だったから、ダイレクトJSはやめておきました。

ひとまずこんな感じで、ユーザ登録、ログイン、ユーザ情報参照、ユーザ情報更新といったアカウントサーバの基本的な仕組みを作ってみました・・・が、コレ、実用に耐えられるシロモノなんですかね?正直良くわからないので、誰かコレでソシャゲ作ってサービスインしてみて下さい。(責任は取らない)

2018年3月5日月曜日

NES emulator for iOS

先日作ったnes-emulator-androidをiOSにも移植。
https://github.com/suzukiplan/nes-emulator-ios

機能レベルでAndroidと同等にすることを目標にしてますが、この記事執筆時点ではサウンドキャプチャ機能が未実装です。(save stateとload stateが未実装であることはAndroid版と同じ)
一応以前、コア部分にLaiNESを使ったiOS用のインタフェースも作ったのですが、若干(というかかなり)作りが悪かったので、内部実装はかなり書き直しました。恐らくインタフェース的には実用に耐え得るレベルになったと思います。

あと、今回のnes-emulator-iosはcocoapodsでの配布もするようにしたので、Podfileに
pod 'NESView', '~1.0.0'
と書くだけで利用できます。
まぁ、利用するとそのアプリのライセンスをGPL3.0(か互換性のあるOSSライセンス)にする必要があるので、事実上商業利用不可みたいなものですが。

なお、READMEに補足してますが、ライセンス調整版(※ただしコア無し)というものも一応あります(そちらは private repo なので一般公開していませんが)。