Serializableで保存してたデータをMessagePackで置き換えてみた
おばかだから、どこで知ったのか忘れちゃったけど…
MessagePack
http://msgpack.org/
こんなん。すごい早いんだって。先読みとかせずにパースできるから効率いいんだって。
ようするに、jsonと同等ぐらいのデータを、より少ない容量でバイナリ符号化するんで効率いいですとか。
http://redmine.msgpack.org/projects/msgpack/wiki/FormatSpec
フォーマット仕様。
DroppShareに導入してみた。
http://github.com/vvakame/DroppShare/commit/88ec8d08d5e4ba3dc5eb4991a73ed011d643775b
ちょっと関係ないの混ざってるけど、このくらいの対応で終了。
ここに辿り着くまでに、それなりに詰まったりして結構時間かかりました…。
思ったこと。
nullの扱いめんどい
packするときはnullとかStringとか区別なく投げ込めるんだけど、取り出す時にnullかStringかとか区別しつつ取り出さないといけないので処理がごちゃごちゃする。
数字の扱いめんどい
intを投げ込んだとき、符号化するときに、なるべくちっちゃい型で符号化するっぽい。
だもんで、取り出す時にめんどくさいことになってる。
http://github.com/vvakame/DroppShare/blob/88ec8d08d5e4ba3dc5eb4991a73ed011d643775b/Android/src/net/vvakame/droppshare/model/AppData.java#L227
↑ByteかShortかIntegerかLongかを判定しなければならない。Object型として扱うためにboxingが発生しているので、高速を謳う割にそんなことしていいのかなーとか思う。
そもそもintの変数を符号化してるから一番大きくてもintのはずなのに、何故かLongのオブジェクトが来ることがあるのは何故…。
Java以外の複数の言語に対応しているから一番駄目なやつにまるめられているのかな？
人間が書きやすいかと言われるとすごい辛い
開発者の人曰く、あまり人間がコード書くような想定ではないみたい。
http://gist.github.com/473422
IDLが吐いたコードはこんな感じだそうだ。
AIDLと両立すんの？
すんの？今のところ必要ないから気にしてないけど…。
Unpackerから子Unpackerを取り出したい
自分でも何を言いたいかわからねーが、今回はAppDataなデータをListにつめて符号化した。
んで、バイナリデータを読んでいくと1つのAppDataをListとして返してくれちゃって、messageUnpackメソッドで処理できない。
データ的にはmessageUnpackメソッドで処理できるはずなんだけどなぁ…。という。なんか他にやり方あるのかも。
Versionの非互換に悩まなくてすむ
今までSerializableなデータをbyte[]とかにしてファイルに吐き出してたんだけど、ちょっとクラスの内容変えちゃうと復号化できなくなって困っちゃってました。でも、MessagePackだとそういうのないし、データの先頭にバージョン埋め込んでおけば、ちょっとバージョンアップしても前のデータを捨てずにある程度救済してあげることも出来ると思う。
前はこれが出来なかったのでXML+png with zip圧縮としてデータを作ってたのだけど、この悩みが解消されるかも。
処理速度が早くなった
体感だけどね！！(風説の流布
結論
自分の手で書くのがもっと楽になれば、有りかなぁと思う。
さぁみんなでやってみよう！！^^