RecyclerViewいわゆるVirtualScroll実装。Viewの初期化時の計算や転送コストを下げつつ、画面に表示されるリストを「見えてる分だけ」に制限してリストのガワを最大限再利用することで、レイアウトのレンダリングコストを下げる実装。似たような機構はiOSやwebでの無限スクロール系ライブラリにもある。VirtualDOM的なアレとは非なる。画像の再利用をしない問題リストの行を表現するxml上で直接drawableフォルダ内のimageリソースを指定したりすると、レイアウトの初期化時にどんどんメモリが確保されていってやがてOOMを迎える。新しいリストの生成時にも画像の確保コストでUIスレッドがブロックし、なんかカクカクするようになる。面倒でもPicassoやGlideなどのライブラリを使いながら、コード側で随時画像キャッシュを使ってリスト内の該当箇所にimageを当てていく。言うかAndroidにおいて直接imageviewにbitmapをアタッチすることは根本的にアンチパターンだと思っておく。確保時にOOMで死ぬ。Picassoなどは内部にWeakMap?的な実装を持てるため、割り当てたメモリ上限を超えると勝手にアクセス頻度の少ないものは捨ててくれる。adapter:::notifyDataSetChanged()を雑に叩くと計算コストが半端ない。予期せぬリストまでviewが再生成されたりする。今までのアプリでは実は表示するものの数が大したことないので割と問題なかったが、複数タブにそれぞれ複数のrecyclerView実装を抱えて、なおかつ巨大なリスト群を扱うとスレッドがブロックする。適切に追加/変更を伝える必要がある。無限スクロール実装のために、スクロール時に全体のリスト数と表示されているアイテムのindexを監視している。数十ms間隔でイベントが来る時とかもあって、そんなに毎回計算が要らない。あたりを使って、適当に前の時間との差分を取りながらスロットルする。リスナー内であまり複雑なことをしないなら必要ないかも。必要がなければデフォルトで設定しておく。notifyDataSetChanged()だともちろん重い。アダプターの機構でrangeをとって更新でもいいけど正直管理が複雑なのと融通が利かないのがある。ライフサイクルイベントで、適当なObserverパターン実装を購読し、各行viewが自分で差分を計算したほうが個人的には融通がきくと思われる。なんか負けた気がするけど。画面上に表示されているものだけになるので、observer側でたくさんイベントが走ろうが走査数は実は大したことないはず。横スクロールページャーなどをリストの一部に実装する問題スライダーやVideoViewがリストの一部になると、画面から出た際に随時detacheされ、状態が初期化してしまう時。int);のサイズを必要な分大きくしておくか、リスト再生成時に、適切に状態を復元する機構を用意しないといけない。VideoViewはPlayer部分とレンダリングされるViewを分離しなくてはいけないので、ちゃちゃっとビデオ表示したい用途だとだいぶ面倒くさそうだけど。ステートフルなコンポーネントだとまあしょうがないという気はする。別にAndroidに限ったことではないが、無限スクロール実装でだんだん表示すべきdataのリストが貯まっていく。解決リスト内で表示しないものは、行情報の取得時に別スレッド側であらかじめプロパティをどんどん捨てておく。サーバー側で抜けるならサーバー側で。リリースノートなど巨大な文字列を有するものには割と効く。あとは保持しているリストの上の方の過去のデータを適切に消したり、SharedPreference的なところに一時的に書き出しておく、などの実装が考えられる。複雑になりそうのでやってないけど。行ってきましたathena、Digdag、Embulkを使って予算消化済みの広告配信を停止するVueのコンテキストを侵しつつTypeScriptの型を効かせるGo言語を学習し始めて、簡単なCRUDアプリをクリーンアーキテクチャで作成するまで3Go言語を学習し始めて、簡単なCRUDアプリをクリーンアーキテクチャで作成するまで2Go言語を学習し始めて、簡単なCRUDアプリをクリーンアーキテクチャで作成するまで1AboutWanoグループのエンジニアやデザイナーが使っている技術、興味のある技術、(色んな意味で)はまっている技術などをお伝えしていきます。