enabled.エンジニアリングENGINEERINGデザインDESIGNカルチャーCULTUREエンジニアリングENGINEERINGデザインDESIGNカルチャーCULTUREk2019.09.20Android版ニコニコ漫画アプリの軌跡(2018~2019)Androidニコニコ漫画アプリチームのKです。読書メーターの開発を担当しています。チームに加わったのが2018年7月の半ばなので1年程経過した事になります。キリもいいのでこの1年のAndroid版漫画アプリの軌跡について紹介していきます。スタンプ導入チームに加わった時点のアプリバージョンは1.3.53でした。1.3系最後のバージョンであり1.4.0が翌月にリリースされます。1.4.0から数えると40回リリースしてきました。計画では週に1度のリリースが考えられていたので概ね計画通りにリリースできていたことがわかります。多くの機能追加や改善を行ってきました。中でも特に影響1の大きかったタスクは次の通りです。具体的にそれぞれ振り返っていきます。DIコンテナ変更チーム加入時点ではRoboGuiceが使用されていました。2016年にサポートの終了が宣言されていたこともあり別のDIライブラリへの移行を余儀なくされていました。候補はいくつかありましたが、最終的にDagger2を導入しています。決め手は読書メーター側で既に導入されていたこともあり知見があった為です。漫画アプリではAndroid用のDaggerサポートライブラリを利用して可能な限りのボイラープレートコードを除去しています。Vol.02」にてDaggerに関して執筆しています。競合する他DIライブラリとの比較や、Daggerが生成するコードを読み解きDIの実現方法について紹介しています。生成コードから依存性が注入されるまでの実際の流れを追うことで容易に理解できます。興味を持たれた方は技術書典7にて販売を行なっておりますので是非お立ち寄りください。minSdkVersion変更バージョン1.4.14からminSdkVersionを19から21としました。これによりAndroid4.4系がサポート外となりました。開発コスト、ユーザーシェア(2.9%)を考慮し総合的に判断した上での対応となります。変更のタイミングについて明文化されたルールは存在していませんがシェア5%を切ったら検討を始めるようにしています。10を合わせたシェアは56.5%(読書メーターは50.3%)です。TargetSdkの変更26から28への更新を予定していましたがパーミッションの問題があり現在は27を設定しています。この問題については時間をかけてマイグレーションを進めることで対応することにしました。Android版ニコニコ漫画アプリをご利用中のお客様への大切なお知らせお知らせにある通り、バージョン1.5.7以降のアプリを一度でも起動すればマイグレーションが行われ、APIレベルを28以上にターゲットしても問題は発生しなくなります。次回TargetSdkの更新のタイミングについては、現時点ではまだはっきりとした日時は不明ですがgoogleからのアナウンスにある通り11月までには必ず実施いたします。アプリ内課金サービス開始バージョン1.5.0(2019/02/20)よりアプリ内課金を開始しました。コインを購入することで掲載が終了したエピソードの視聴や後述のギフト機能が利用できるようになりました。消費系アイテム処理の構造上どうしても稀にコインが付与されないといった問題が発生することがあります(多くがネットワークに起因する問題)。それを低減すべく可能な限りのレジューム処理が講じられています。ギフト機能開始アプリ内課金サービスと同時にギフト機能が開始されました。こちらは現在アプリのみの提供となっております。漫画コインを消費して贈ることができます。贈られたギフトの種類に応じて、作者のクリエイター奨励スコア2が加算され、作者の創作活動の手助けに繋がります。次のギフトが存在します。読了後ギフトスタンプギフトギフトはアプリ内課金と同時にサービスを開始し、遅れてスタンプ機能が導入されました。スタンプはコメントとの共通処理を抽出しそれをリアクションと再定義した上で単純なステートパターンで実現しています。描画に関してはスタンプについてはImageView、コメントについてはCanvasを利用しています。webp)を使って実現しています。低スペックなデバイスでも動作するように調整されており、スペックに応じて同時表示数やフレームレート等に違いが出てきます。5)」では表示数に制限がかかります。全ての作品がギフト可能ではないので利用シーン次第では全く目にしないこともあるかもしれません。そこで2019/09/20時点でギフトの多い作品を紹介します。Exceptionが発生しやすいアプリでした。具体的にはこれらに起因するクラッシュが1日あたり700件前後発生していました4。それでも発生した時のユーザーに与える影響5を考えれば無視できるものではありませんでした。ローカルキャッシュの利用を促進することで対処しました。この対応により現在は1日あたりのcrash数を100件前後へ抑制することが出来ています。残っているクラッシュの多くは端末に依存している問題となりますが、可能な限り削減に努めていきます。終わりに今回はこの1年の中で影響の大きかった公開可能なタスクについて紹介しました。ここでは紹介できなかったタスクも数多く存在します。今後もアプリ、延いてはサービスの価値を向上すべく様々な取り組みを行なっていきます。なくUX変更に伴う影響も意味しています。29、30話あたりで多く利用されています。↩その多くはアプリがノンアクティブ(background)時のクラッシュでありユーザーへの影響は軽微でした。↩アプリをバックグラウンドにするとOSによってはクラッシュのダイアログが表示される。ページ途中であった場合、TOPから開き直しになる。