ぐおおおおお、落ちていた針金踏んだ。。。
ちくっとくらいな感じだったんだけど、引き抜いたらそれは意外にも長く、5mmはささったんじゃないかってくらいで、抜いたとたんに血がドバドバでてあせった;そして時間がたつと痛みもこみ上げてくるわけで。。。うーん、足元には注意しないとね。
アクセス解析見てたら
こちらのブログさん を発見。
なにやら
iRemoteの記事があるじゃないですかー。しかも
ふたつ。
折角なのでレスっぽいものを書いてみる。
やっぱこういう記事にとりあえげられるってうれしいもので、実際に使ってくれている人がいるんだなぁ、と実感できる。
>画面の表示はmobile2PCと同等か速いくらいであり、カーソル移動がちょっとギクシャクするが良くできている。
ギクシャクはカーソル導入時から気づいてましたがほっときっぱなし。。。
ギクシャクの理由は多分描画中での通信を許しているからかなぁと。ケータイのスペック上、作り手が触れることのできない部分である実通信部の処理であっても結構な処理を食います。
現在iRemoteの描画fpsは15fps完全固定で、これは操作がないときも固定であって東方らしきものなどゲーム的な手法。時間的には66ms。実際に描画にかかってる時間自体は10msない程度で通信に処理を取られても十分に間に合うであろう時間です。
ここで何が問題になってるかっていうとおそらくは反映のタイミング。g.unlock()。
もしくは描画開始のタイミング。
これらのためにメインスレッドは必死にタイミングを見計らってるのに通信により突発的に大きな処理がでたりで、一定のタイミングで反映ができなくなってしまっているんだと思います。まぁ要するにワタシの腕が未熟なんですけどねーorz
デコードスレッドなんての動いていて中身は結構ひどい有様。描画安定化のために通信スレッドを一時的に停止するとか必要かも。
>一方のiRemoteはPC側のマウスを移動させても、ポインタはケータイ側でポイントした場所に引っ張られる。
多分PC操作中はケータイもそれに追従ってのが親切設計だと思われます。
そもそもなぜケータイの操作優先かというと、ケータイはカーソル位置を一方的におくりつけ、PCががんばってそれにあわせているだけだからで、ケータイは実際のところPCのカーソルがどこにあるかなんてわかっていないのです。
ケータイの操作がないときはPCのカーソル位置を取得するという機構をつけることでmobile2PCのようにもできるはず。
こんな機能がつけば操作ロック機能なんていらなくなりそうですね;これはもともとPC側で操作してアプリ側で動作を確認するとき、カーソル位置が固定されていてはテストしにくいためについた機能です。
>iRemoteは(たぶん)常に通信している。通信して画像を持ってきてそれを展開して表示するわけで、時間平均の占有帯域は125kbps程度だ。
125kbpsだったのかw たぶん常に通信しています。
当然のことながらPCが自発的にケータイに画面の更新があることは不可能なので、可能な限りケータイ側がPCに変更があったか確認しにいっています。ただ、変化がない場合は通信量は1KB未満で、一見少ないように思いますが、設計上「可能な限り通信」するので1KBをDLし終えたらすぐに次のリクエストを行います。1KBのDLなんて速攻で終わるわけで、bpsに直したらすごいことになるというわけですな。
しかし125kbpsかぁ、ふーむ。となれば、httpの擬似キープアライブでも常時125kbps程度の通信はできるってことになるなぁ。まぁ多少ラグはあるけど、、P2Pな対戦ゲームの参考になる。
>このあたりはPCの解像度やケータイ側での設定(画質その他)にもよるだろうとは思う。
画質50以下、通信頻度0.5秒が基本と思ってます。
画質は悪くても効率向上のために下げるのがベスト。画面の反映も、一回に反映される量も増えて体感速度がアップ。またメモリ使用量も低下するのでケータイにもやさしいかも。
通信頻度0.5秒ってのは
「0.5秒おきに通信する。0.5秒以上かかった通信の場合、すぐに次の通信を開始する」ではなく
「通信終了から次の通信までに0.5秒あける」の意味。
上にも書いたけど、画面変化の確認だけの場合は小さい通信が高頻度で発生する。結果的には画像取得しているときと同等の通信料になってしまっているようなので、これを抑えるのに使えます。多分。
>この通信頻度の違いは電池消耗量にも影響していて、iRemoteを使ったときのバッテリの減り方と来たら大変なものだ。
ホントこの電池消耗量はやばいですよねw 自分がiRemoteを使わない理由のひとつ。
リアルタイム性を追求したらこうなったって感じなので電池は仕方ないかなぁとおもってましたが、やはり対策を考える必要がありそう。
対策のヒントになるのはまず常時125kbpでているという点。これは不要の通信であるケータイのPCへのリクエスト頻度を抑えることで解決できるはず。たとえば変化なし、と返ってきた場合は1秒以上の間隔をあけるようにする。カーソル操作中の場合はこれらの制限を解除し、常時通信に切り替える。
これでも非操作時の電池消費量は激減のはず。
また小さい通信の場合、通信にかかっている時間のほとんどは再接続の時間。再接続の時間は画像等をやりとりできないが通信は行われている状況で、そこでも通信中と同等の電池を消耗する。かなり無駄が多いってことになる。小さい通信をいかに減らすかがポイントになりそう。
また、リクエストがあってから画像を用意するって仕組み上、画像作成中はケータイは待機することになる。ここでも何もしていない通信が発生し、電池の無駄になっているはず。
PC側がケータイの通信がなくても定期的に画面更新を確認し、画像をある程度用意しておくと効率的かもしれない。また、拡大アニメーションなど不要な画像の取得ってのも無駄で、検地側もあまりに大きな変化の場合は1秒間以内で変化が収まるかを確認してから画像を作成するような工夫もいるかもしれない。
ケータイ側にとって効率的にするとPC側が非効率になりそうだなぁ。
またゲーム的な描画方法もツールなんだし見直すべきか。
変化があったらの再描画で済む話。
そろそろiアプリ末期って感じがするので早いうちに対策打ちたいですね。
ワタシ自身次の機種変ではiPhone等のスマートフォンにしたいので…