nashcft's blog

時々何か書く。

久々の日記的な

色々あり3週間弱もの間日記的なものを書かないでいた...

先々週の土曜日までは JJUG CCC の発表資料を作っていたとか、先週は業務でタスクが突然押し寄せてきたので残業しまくっていたとかそういう言い訳をすることもできるが実際それを言い訳に忙しいから落ち着いてから再開すればいいやとか考えてた。
とまあそんな感じで最近は細かいバグ取りタスクを捌くことに気を取られていたので他のことはあまりやっておらず、でも休日には怪獣惑星を観るなどはしていた。ところでバグ捌きをしているとQAチームとのコミュニケーションが増えるのだけどここもまたニャーン

ニャーン

先週で怒涛のようにバグを潰したので今週は結構落ち着いていて割と余裕がある雰囲気。今日は息抜きに社内wikiを眺めていたら若者がいつの間にか日報を始めていたのに気づいて最新の分までさらりと読んでいた。日報って1人でやってると虚無になってしまうので私も日報仲間になろうかなーと思っている。

前回の記事のことを思い出したけど、あれは後から見直して正しくなさを感じたので調べ直して修正する予定。業務の方では Intent に保存するデータ量を雑に記録して適当な上限を設けるなどしてなんとなく解決した。感覚的には端末間で binder transaction buffer のサイズにばらつきがあるという方がしっくりくるのだけど、とりあえずAndroid One S2は600KBくらい放り込むとTransactionTooLargeExceptionを吐いて死ぬがXperia系は問題なく処理する。別件でXperia系に苦しめられていてどちらかというとXperia系の方がいい加減なのではないかという気持ちになりつつある。

とりとめがないけどおしまい

Binder transaction buffer は1MBとは限らないかもしれない話

今開発しているアプリで特定の端末・条件でとある画面への遷移時に画面が真っ暗になって操作を受け付けなくなったり、該当する中で古い端末だとアプリが強制終了したりしてしまうという現象に出くわして、ログを眺めてみたら以下の例外が出続けていた:

Exception thrown launching activities in ProcessRecord{(略)}
    android.os.TransactionTooLargeException: data parcel size 645548 bytes
        at android.os.BinderProxy.transactNative(Native Method)
        at android.os.BinderProxy.transact(Binder.java:615)
        at android.app.ApplicationThreadProxy.scheduleLaunchActivity(ApplicationThreadNative.java:893)
        at com.android.server.am.ActivityStackSupervisor.realStartActivityLocked(ActivityStackSupervisor.java:1330)
        at com.android.server.am.ActivityStackSupervisor.attachApplicationLocked(ActivityStackSupervisor.java:892)
        at com.android.server.am.ActivityManagerService.attachApplicationLocked(ActivityManagerService.java:7116)
        at com.android.server.am.ActivityManagerService.attachApplication(ActivityManagerService.java:7194)
        at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:542)
        at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3032)
        at com.android.server.am.ActivityManagerServiceEx.onTransact(ActivityManagerServiceEx.java:594)
        at android.os.Binder.execTransact(Binder.java:565)

それでリファレンスを読んだりQiitaの記事を漁ったりして、上記の例外は Binder transaction buffer に対して上限を超えたサイズのデータをやりとりしようとした時に発生するっぽいことがわかった。

読んだ記事: qiita.com

qiita.com

確かに問題の画面遷移では Intent にそれなりなサイズになるデータを1つ保持させるのでそれかなーと納得しかけたが、ちょっと変なことに気がついた。
読んだページの中で Binder transaction buffer の上限は1MBと書かれているが、上の例外には data parcel size 645548 bytes とある。つまり読み方が間違ってなければだいたい650KB弱のデータで音を上げていることになる。さっきの「それなりなサイズのデータ」以外に保持させている大きなデータは無いし、そうなると transaction buffer の上限が1MBならばこれで too large と判断されるのはおかしいはず。

それで気になってググってみたら StackOverFlow の以下の記事がすぐに引っかかった:

stackoverflow.com

The limit is supposed to be 1MB but it varies by device from little less than 512KB up to almost a full 1MB.

質問は2013年、上で一部引用したベストアンサーの回答も2015年とやや古いが、端末によって transaction buffer のサイズが異なるとある。それで "binder transaction buffer size vary" とかでさらにググってみたら他にもいくらか引っかかる様子。

https://www.neotechsoftware.com/blog/android-intent-size-limit

リファレンスはまるで一律1MBだと定めているように読めるのでなんだかなーという気持ちになった。リファレンスの記述は以下の通り:

The Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process.

さてどうやって対応したものかね...

JJUG CCC 2017 Fall に参加した

20分枠で Eclipse Collections の紹介をした。

slides.com

発表時の様子をコミッタの1人である @itohiro73 さんがまとめてくださっている。

togetter.com

発表後の振り返り

余談

このライブラリは今勤めている会社のサーバサイドチームで Stream API の代わりとして1年半くらい使われていて、最近はチーム加入後に取り組むハンズオントレーニングの題材にも組み込まれるようになった。
プロダクトの中で両方が混在していると混乱するだろうということで Stream API を使わないように規約で決まってるので面白がって以下のようなやりとりをすることがある。

Eclipse Collections と私と今後

まとめのところで何かコントリビュートするぞと口走ったので来年末くらいまでに何かできたらいいなあと考えている。Immutable なコンテナでできることを増やしていきたいなあとか。
仕事ではサーバチームから Android アプリ開発チームに移動して使う機会がなくなってしまっているのがネックかなー...

日記

チームの人からのサーバサイドAPIの挙動に関する質問を聞いていたらAPIの不備が見つかったのでシュッと直してプルリクを投げた。
大した規模の修正ではなかったのでその場ですぐプルリクにしたのだけど、弊社では基本的にタスクをチケット化するのが決まりで、チケットも作らずにこういうことをしていると見えないタスクを生み出してしまい、誰が今どのくらいタスクを持ってるかとか誰がどの期間で何をどのくらいやったかといったトラッキングを正確にできなくてよくないですねということが考えられる。でも縦割りチームだとチームをまたいだ作業は記録しても見えにくいし開発タスクはGitHubの草でも見たらいいじゃーんというか、そういう行動データがJIRAだったりGitHubだったりetcだったり散っちゃっててそもそも上手くトラッキングできてないじゃーんウワーつらい眠いのでおわり。

日記的な

風邪治った

昨日今日でタスク1個こなして、あと Effective Java の読書会したりコードレビューしたりした。最近読書が疎かになりつつあるのでよくない。
今日のタスクでは ViewHolder まわりをいじっていたのだけど、 RecyclerView における ViewHolder とそれに紐つく (?) View の関係やライフサイクルとか、layout のxmlと実際に表示されている view がどうのとか、再利用とかメモリ効率がどうのとかってどうなってるんだろうなーというところが気になった。
そう言えば gradle plugin の移行はもうちょっと先になりそう。

今日読んだ本:

  • 融けるデザイン -> 63%
  • Effective Java -> 6章入った

Effective Java の読書メモを会社のwikiに残しているけどそのうちこっちに持ってこよう。

😷

今日は出社したら Android Studio 3.0 がリリースされていたので早速アップデードした。とりあえず新しくできるところは新しくして、引っかかるところがどこかだけ眺めておいた。来週くらいから Gradle の android plugin のマイグレ作業をすることになる。

午後は半分ミーティングで残りの殆どは社内勉強会だった。今日は若者数人で『テスト駆動開発』のもくもく写経会を始めた。参加者全員がJava経験者というわけではなかったので取り組む際の言語は自由として、私は色々と折角な機会だったのでKotlinで進めることにした。ところでこの会では git レポジトリやプロジェクトを作ってもらうところからやってもらったのだが、今年新卒で入った人がその辺の知識・経験がなくて苦戦しており、それのサポートに結構時間がかかったので本の進みは1章の途中くらいまでだった。 git は普段から使っていて仕事始めてからもう半年も経つのだから問題ないかなーと思っていたのだけどそうでもなかったのは結構意外で、ちょっとこれはフォローしないとなとなり次回は git 会にすることにした。

風邪、直に治ると思っていたのに帰宅してから熱をはかったらまた上がってしまったので今週はもうおしまいです。

風邪と情報共有と

風邪を引いてて治りつつあるものの鼻水が辛い...

今日は小さいタスクを1つ片付けた以外はほとんどコードレビューをしていた。
昨日まで ConstraintLayout で苦戦していて自分しかこれを使っていないから頑張るしかないと思っていたら先行して別の画面を開発していたメンバーが実は ConstraintLayout を使っていたことに今更気づいた。割と和気藹々とやっているチームだけどこういう所の情報共有が課題なんだなあと思った。プルリクエストを出すまでの間のコミュニケーションがあまりに少ないのでそこから改善できないかなあ。

情報共有をはじめとしたコミュニケーション関連の問題はチーム内だけでなくチーム間でも以前からあって、チーム移動を経験してその辺の実害を割と具体的に実感していてどうにかしないとなーとなっている。今も前いたチームと今いるチームの間で地味な問題を抱えていて、今いるチームの人とは普段の会話の中でその辺の事情やら背景やらのお話をしてじゃあどうやっていきましょうかと話を進めることができているのだけど、前いたチームは自分がいた頃はそういう話を聞いたことなかったしどのくらい認識してるのかなーというのが掴めてなくてどういう切り口でお話をしたらいいかなーと変に気になって進められていない。

夜中のテンションでこういう悩ましいことについて考えるとよくない方向にしか進まないのでこれで、コミュニケーションはとても難しいのに無頓着な人が周囲に多くてつらい気持ちになるなあということだけ吐き出しておしまい。