« Android 対応検討 | メイン | mozjpeg はどのようにして圧縮率を上げているのか？ »
2014年03月09日
吉里吉里Z 開発:: Android 対応必要項目と工数見積もり
Tweet @jin1016をフォロー必須部分で3人月 + テスト2人月
追加項目(優先度低いもの)を加えると4.6人月 + テスト2人月
他に考慮が漏れている項目がある可能性もある。
以下、詳細。
-----
事前対応項目
1. クラス間の結合度を下げる - 5人日
2. Screen クラスの追加 - 5人日
3. DrawDevice の機種依存部分を変更 - 0.5人日
4. Bitmap が逆順に格納されているのを正順に変更 - 0.5人日
5. パスデリミタとケースセンシティブ - 後述
-----
必須対応項目
OpenGL ES 2.0 対応 - 5人日
描画は最終的に OpenGL ES 2.0 で描画する ( Windows で DirectX 描画しているのと同じ )。
OpenSL 対応 - 5人日
サウンドは OpenSL によって対応する。
OpenMAX or ムービーテクスチャ対応 - OpenMAX 2人日
NDK は OpenMAX が使えるようだが、その場合 Window に対してのみで、全画面前提となるように見える(調査した範囲では)。
Java からは、ムービーテクスチャが使えるので、Java 経由でムービーテクスチャを使い動画再生可能にできると思われる。
初期は、OpenMAX での全画面再生を実装し、のちにムービーテクスチャの実装を試みる形になるかもしれない。
Screen クラス対応 - 7人日
各種入力イベント、描画への橋渡しなどを行う。
ファイルアクセス対応 - 3人日
ファイルアクセス部分、パスデリミタ、ケースセンシティブの対応が必要。
また、Assets へのアクセス対応も検討。
ただ、C++ からは Assets のフォルダへのアクセスが出来ないようなので、Java 経由が必要になる可能性もあり、どうするか検討する必要がある。
アクセス速度なども加味すると初回起動時に SD へコピーしてから実行する形が良いかもしれない。
スレッド対応 - 3人日
pthead による実装に変更する。
タイマー対応 - 2人日
Timer クラスは、独自スレッドでの実装だが、内部で使用しているタイマーは Windows 依存なので書き換える必要がある。
イベント対応 - 3人日
Android ではパイプを使用してイベント処理しているので、その形に応じたものへ変更する。
ただ、シングルスレッドではない場合は、独自の機構の組み込みが必要となる。
フォント対応 - 2人日
Android では /system/fonts にフォルトファイルが置かれているが、フェイス名などは分からない。
初回起動時に各ファイルを読み込んでフェイス名と対応付けなどして、保存して置くなどの対応が必要。
ただ、全端末で共通のフォントはないため、アーカイブにモトヤフォント(もしくは他のデフォルトフォント)を入れて対応する形が無難かもしれない。
フォント描画は、FreeType となり GDI は使用できない。
その関係で縦書き対応は初期は未実装。
各種システムメソッド対応 - 3人日
環境情報を取得するメソッドを Android に合わせて対応する必要がある。
Windows 固有のものは、Android 環境では使用できなくなる。
ドキュメント対応 - 4人日
Android 固有/Windows 固有の対応表や制限、新規に追加されたメソッドなどをドキュメント更新する必要がある。
ログ出力 - 0.5人日
コンソールではなく、LogCat への出力へと変更する。
また、出力を抑止することも可能にする。
ライセンス表示対応 - 0.5人日
使用するライブラリのライセンス表示のための対応を行う。
ライセンステキストを取得するメソッドを追加するなど。
グラフィック関係の固有部分対応 - 1人日
Bitmap などでWindows環境固有の部分があるので対応する必要がある。
固有メッセージ対応 - 2人日
エラーメッセージなどで環境固有部分の対応とWindowsリソースへ出力するスクリプトの変更が必要。
ライブラリのビルド対応 - 2人日
外部ライブラリを Android でビルドできるよう対応する。
ビルド環境整備 - 3人日
Android 用に楽にビルドできるように環境整備する。
メモリ初期化問題 - 1人日
Android では毎回なからずメモリが初期化されるわけではなく、メモリに余裕があってアプリ復帰した場合、前回のメモリ内容のまま復帰する問題がある。
吉里吉里ではグローバル変数(シングルトン)など使用しているので、この対処が必要。
メイン部分を Shared library 化し、読み込み、解放を行うことで毎回初期化が行われる形での対処を予定。
-----
以下は対応優先度が低いもの。
上のほうが優先度が高く、下のほうが低い
工数等の関係で初期は未実装となる可能性がある。
1. リリーサー - 5人日
他ツール等の都合上 Java での実装になる可能性が高い。
JRE, Android SDKの一部ツールが同梱される。
apk に全てのデータを組み込む or apk + xp3 という構成で生成する。
別ダウンロードなどが必要な場合は、別途自前でビルドする必要がある。
2. Vorbis 対応 - 3人日
Android (ARM) 環境を考えると Tremor を使用したものに書き換えた方が良いが、Opus で速度が出るのであれば、初期は Opus のみにしてもよい。
工数によって検討する。
3. NEON 対応 - 最小対応3人日
メソッド全て対応するのは工数がかかる。
ただ、まったく対応しないと速度的に厳しい可能性もある。
速度的に問題が出るようであれば、アルファブレンドなど使用頻度が高く速度に影響するメソッドのみは初期に対応することを検討する。
4. KAG3 対応 - 4人日
Window クラスを Screen クラスへ変更し、Yes/Noダイアログは書き換える。
5. プラグイン対応 - 4人日
Windows では DLL として動的読み込みされる形になっているものを、Android では Shared library として動的読み込みできるように対応する。
基本構造はそのままで持っていけるはずだが、読み込みの関数などは異なるのでその部分対応が必要。
また、プラグイン側も修正が必要。
その際マクロなどで共通化可能にする。
プラグインは、マルチプラットフォーム対応、Windows専用、Android専用の3種類に分類されることになる。
6. プラグインの組み込み化可能対応 - 2人日
プラグインとExtensionで共通のマクロやテンプレートでビルド可能にし、プラグインであればExtensionとして本体に組み込みできる形へ持っていく。
プラグインのほうが制約が多いので、プラグインを組み込みクラスへ持っていくのは、プラグインとして作られているのであれば可能な形にできるはず。
逆は個別に対応が必要になる。
Android であればプラグインとして独立している意味は薄い。
また、動的読み込みができない iOS のような環境へ対応する必要が出てきた時、本体へ組み込める形になっていないとまったく使えないことになる。
7. マウス入力 - 2人日
Android ではタッチ入力が主で、マウス入力はほぼ使われないことが想定されるので、優先度低。
8. キーボード入力 - 2人日
戻るキーは対応するが、他のキーは優先度低い。
9. ムービー再生(ムービーテクスチャ) - 3人日
最前面で単純に再生する以外の機能は実装が難しい可能性がある。
10. 文字入力 - 4人日
ソフトウェアキーボードとなるので検討しなければならないことが増える可能性あり。
-----
使えなくなる機能
ファイル選択・Susieプラグイン・クリップボードは Android では使用不可に。
他にも実装中に使用不可にする機能が出る可能性あり。
投稿者 Takenori : 2014年03月09日 06:03
comments powered by Disqus