Android でデバイスの向き（方位角・ピッチ・ロール）を取得するには、加速度センサーと磁気センサーを組み合わせる方法が定番です。かつては LiveData を継承した独自クラスで実装するパターンが広く使われていましたが、2026 年現在のプロジェクトでは StateFlow + Kotlin coroutines を使う構成が主流です。
本記事では古い LiveData ベースの実装を出発点に、現代的な Flow ベースに移行するアプローチと、最終的に Jetpack Compose の UI へ流し込む全体像を解説します。
LiveData は Android のライフサイクルと自動的に連携できる点で優れていましたが、以下の理由で現代のコードベースでは扱いにくくなっています。
LiveData.observe() は LifecycleOwner を必要とするため、ドメイン層やリポジトリで使うと依存関係が逆転するLiveData は間引き（debounce / throttle）を標準で持たないStateFlow は suspend 関数や Flow 演算子と自然につながるStateFlow に移行することで、センサーのデータをパイプライン上で加工しやすくなり、ViewModel までの責務境界も明確になります。
まず、センサー購読を callbackFlow でラップするユーティリティを作ります。
import android.content.Context
import android.hardware.Sensor
import android.hardware.SensorEvent
import android.hardware.SensorEventListener
import android.hardware.SensorManager
import kotlinx.coroutines.channels.awaitClose
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.callbackFlow
import kotlinx.coroutines.flow.conflate
fun Context.sensorFlow(
sensorType: Int,
samplingPeriodUs: Int = SensorManager.SENSOR_DELAY_UI,
): Flow<SensorEvent> = callbackFlow {
val manager = getSystemService(SensorManager::class.java)
val sensor = manager.getDefaultSensor(sensorType)
?: run { close(); return@callbackFlow }
val listener = object : SensorEventListener {
override fun onSensorChanged(event: SensorEvent) {
trySend(event)
}
override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {}
}
manager.registerListener(listener, sensor, samplingPeriodUs)
awaitClose { manager.unregisterListener(listener) }
}.conflate() // 処理が間に合わない場合は最新値のみ保持
callbackFlow の awaitClose ブロックがコルーチンキャンセル時に自動で unregisterListener を呼ぶため、ライフサイクル漏れを起こしません。conflate() を付けることで、高頻度のセンサーイベントを UI 描画が追いつく範囲に自然に間引きできます。
import android.hardware.SensorManager
data class DeviceOrientation(
/** 方位角（北=0, 東= π/2）ラジアン */
val azimuth: Float,
/** ピッチ（前傾き）ラジアン */
val pitch: Float,
/** ロール（横傾き）ラジアン */
val roll: Float,
)
fun computeOrientation(
accelerometer: FloatArray,
magnetometer: FloatArray,
): DeviceOrientation? {
val rotationMatrix = FloatArray(9)
val orientationAngles = FloatArray(3)
val success = SensorManager.getRotationMatrix(
rotationMatrix, null, accelerometer, magnetometer
)
if (!success) return null
SensorManager.getOrientation(rotationMatrix, orientationAngles)
return DeviceOrientation(
azimuth = orientationAngles[0],
pitch = orientationAngles[1],
roll = orientationAngles[2],
)
}
2 つのセンサーフローを combine してまとめ、StateFlow に変換します。
import android.app.Application
import android.hardware.Sensor
import android.hardware.SensorManager
import androidx.lifecycle.AndroidViewModel
import kotlinx.coroutines.flow.SharingStarted
import kotlinx.coroutines.flow.combine
import kotlinx.coroutines.flow.filterNotNull
import kotlinx.coroutines.flow.map
import kotlinx.coroutines.flow.stateIn
import androidx.lifecycle.viewModelScope
class OrientationViewModel(app: Application) : AndroidViewModel(app) {
private val accelFlow = app.sensorFlow(Sensor.TYPE_ACCELEROMETER)
private val magnetFlow = app.sensorFlow(Sensor.TYPE_MAGNETIC_FIELD)
val orientation = combine(accelFlow, magnetFlow) { accelEvent, magEvent ->
computeOrientation(accelEvent.values.clone(), magEvent.values.clone())
}
.filterNotNull()
.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5_000),
initialValue = DeviceOrientation(0f, 0f, 0f),
)
}
SharingStarted.WhileSubscribed(5_000) によって、画面が 5 秒以上バックグラウンドに入ったらセンサー購読を自動停止します。画面が戻れば再開します。
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.lifecycle.compose.collectAsStateWithLifecycle
import androidx.lifecycle.viewmodel.compose.viewModel
import androidx.compose.material3.Text
import kotlin.math.toDegrees
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
@Composable
fun OrientationScreen(
vm: OrientationViewModel = viewModel(),
) {
val orientation by vm.orientation.collectAsStateWithLifecycle()
Column(modifier = Modifier.padding(16.dp)) {
Text(text = "方位角: %.1f°".format(orientation.azimuth.toDegrees()))
Text(text = "ピッチ: %.1f°".format(orientation.pitch.toDegrees()))
Text(text = "ロール: %.1f°".format(orientation.roll.toDegrees()))
}
}
private fun Float.toDegrees() = Math.toDegrees(this.toDouble()).toFloat()
collectAsStateWithLifecycle() は Lifecycle.State.STARTED 以上の場合のみ収集します。画面が非表示になれば自動的にコレクションを停止し、ViewModel 側の WhileSubscribed と組み合わさることでセンサーも停止します。
| 比較項目 | LiveData ベース（旧） | StateFlow ベース（現代） |
|---|---|---|
| ドメイン層での利用 | LifecycleOwner 依存で困難 | 依存なし、自由に使える |
| センサー停止タイミング | onInactive に依存 | WhileSubscribed で自動制御 |
| 複数センサーの統合 | MediatorLiveData が必要 | combine で宣言的に書ける |
| Compose との統合 | observeAsState |
collectAsStateWithLifecycle |
LiveData が「ライフサイクル問題を解決した」なら、StateFlow は「ライフサイクルへの依存そのものをなくした」と言えます。センサー処理のような高頻度イベントは特に Flow の恩恵が大きく、ドメイン層まで一気通貫でコードを整理できます。
Android 1.5の頃からアプリを作っていると、非同期APIは何度も主役交代してきました。AsyncTask、Loader、Rx、Coroutines。道具は進化しましたが、障害対応の現場で見る事故の根本原因は驚くほど似ています。
本記事では、各時代で実際に踏みがちな地雷を振り返りながら、2026年時点でも有効だった実務ルールに絞って整理します。ポイントは「どのAPIを使うか」より「キャンセル・責務・エラーハンドリングをどう設計するか」です。
AsyncTaskの時代は、とにかく画面回転とライフサイクルの相性で苦しみました。最も多かったのは、非同期処理中に画面が破棄され、結果をUIへ反映しようとしてクラッシュする問題です。
「処理がバックグラウンドで動ける」ことと「UIを安全に変更できる」ことは別問題です。UIのライフサイクルとの接続点を設計しない限り、どんな非同期APIでも事故は起きます。
Loaderはライフサイクル連携を前進させましたが、今度は責務の分散が問題になりました。データ取得ロジックがFragmentやActivityに寄りすぎると、見通しが急激に悪化します。
ライフサイクルに強い仕組みだけでは足りません。責務をUI層から分離し、ユースケース単位で再利用できる構造が必要です。
ReactiveX(Rx)は表現力が高く、複雑な非同期フローを綺麗に書けました。ただし、チームで運用するとDispose漏れとScheduler設計のばらつきが頻発しました。
subscribe() が散在して購読ライフサイクルを追えないCompositeDisposable の解放漏れで画面離脱後も処理継続observeOn / subscribeOn の設計が統一されずデバッグ困難Rxの難しさは演算子ではなく運用ルールです。購読開始・終了の責務を定型化しないと、実装者依存の品質になります。
Coroutinesは読みやすくなりましたが、地雷が消えたわけではありません。特に初期導入時は「軽く書ける」ことが裏目に出ます。
GlobalScope の使用でライフサイクル外に処理が残るlaunch と async を混在させ、例外伝播が意図通りにならないwithContext の乱用で責務境界が曖昧になるCoroutinesは「正しくキャンセルが伝播する設計」を作って初めて安全になります。書きやすさは設計品質の代替にはなりません。
どのような形で非同期処理をするにせよ、以下のことが地雷の要因になります。
この3つを放置すると、どのAPIでも「たまに落ちる」「再現しづらい」不具合の原因になります。
非同期APIは進化し続けていますが、地雷の本体は道具ではなく設計です。私が長年の移行で得た結論は次の3点です。
「新しいAPIに移行したのに不具合が減らない」と感じるチームでは、非同期処理の設計を見直すことが大切です。
]]>Androidアプリの規模が大きくなると、ほぼ必ず「マルチモジュール化するべきか」という議論にぶつかります。私自身、単一モジュールで育ったアプリを段階移行した案件と、最初から過剰分割して失敗した案件の両方を経験しました。
結論から言うと、マルチモジュール化は「正義」ではなく「投資」です。投資なので、回収できる条件を満たした時だけ実施するのが最適解です。本記事では、実務で使っている判断基準と、破綻しにくい移行ロードマップをまとめます。
以下のような状態なら、マルチモジュール化を検討してみる価値があります。
逆に、ビルド時間も保守性も問題ない段階で分割だけを先行すると、ほぼ確実にコスト先行になります。特に小規模チームでは、モジュール間の調整コストが純粋な実装速度を上回りやすいです。
最も多い失敗は、責務ではなく「雰囲気」でモジュールを切ることです。例えば、UI部品を細粒度で分けすぎた結果、変更1件で5モジュールのリリース調整が必要になるケースは珍しくありません。
まず依存関係とビルド時間を可視化します。ここを飛ばすと、移行後に「何が良くなったのか」が測れません。
次に、コードを動かす前に境界を合意します。
ここで初めてモジュールを切り出します。最初の対象は「変更が多いが境界が比較的明確」な領域が安全です。
// settings.gradle.kts
include(
":app",
":core:common",
":core:ui",
":core:data",
":feature:auth"
)
// feature/auth/build.gradle.kts
plugins {
id("com.android.library")
id("org.jetbrains.kotlin.android")
}
dependencies {
implementation(project(":core:common"))
implementation(project(":core:ui"))
implementation(project(":core:data"))
}
この段階では「完璧な分離」より「壊さず移す」を優先します。必要なら一時的なFacadeを置いて移行期間の差分を吸収します。
移行後に初めて最適化へ進みます。
internal修飾子を適切に使う）「分割したはいいけど、むしろ統合した方が楽じゃなかった？」ということがないか定期的に振り返り、時にはモジュールを統合する決断をとるのも大事です。
マルチモジュール化は、規模拡大に対する万能薬ではありません。効果が出る条件を満たした時にだけ実施し、段階的に進めることで初めて投資対効果が合います。
実務での要点は次の3つです。
これから着手するなら、最初の一歩は「どこを分けるか」ではなく「なぜ分けるか」の合意形成です。ここが揃うと、移行は驚くほど安定します。
]]>本記事は、Android端末上で動作するローカルLLM（Large Language Model）を構築するための実践ガイドです。オフラインでの推論とプライバシー保護に重点を置き、2026年現在の最新技術を解説します。開発環境のセットアップからモデルの最適化、実際のアプリケーションへの組み込みまで、Androidエンジニアが実務ですぐに使える知見を提供します。
現行のLLMは推論時にGPU/TPUを必要としますが、AndroidではARM CPUやNPUが主流です。以下のステップでモデルを軽量化できます。
AutoModel.from_pretrained(..., load_in_8bit=True) を用いてモデルを変換。python -m tensorflow_model_optimization.saving.configs.tflite_config \
--input_file=model/exported/pytorch_model.bin \
--output_dir=tflite/
最適化済みTFLiteモデルをAndroidアプリに統合するには、以下のコード例が参考になります。
class LlmInference(
private val interpreter: TFLiteInterpreter,
private val inputTensor: Tensor,
private val outputTensor: Tensor
) {
fun run(text: String, maxTokens: Int): String {
// テキストをtokenize（ここでは簡略化）
val encoded = tokenizer.encode(text, add_special_tokens = false)
inputTensor.flatBuffer().putInt(0, encoded.length)
inputTensor.flatBuffer().putFloatArrayOf(encoded.indices.map { it.toFloat() })
interpreter.run(inputTensor.buffer, outputTensor.buffer)
return tokenizer.decode(outputTensor.intValueAt(0))
}
companion object {
fun loadModelFromAssets(
context: Context,
modelAssetName: String
): LlmInference? {
val file = File(context.filesDir, "lmm.tflite")
if (!file.exists()) return null
val builder = InterpreterBuilder(FileInputStream(file), null)
val interpreter: TFLiteInterpreter by setter { it }
// モデルの入出力情報を取得
val inputDetails = interpreter.getInputTensor(0).shape
val outputDetails = interpreter.getOutputTensor(0).shape
return LlmInference(
interpreter,
Tensor(inputDetails),
Tensor(outputDetails)
)
}
}
}
メモリ管理
TFLiteインタプリタは推論中に数MBのヒープを消費します。process.onCreate() または onStart() でモデルを事前ロードし、アクティビティ切り替え時に解放することでクラッシュを防ぎましょう。
バックグラウンド処理
プライバシー保護のため推論をWorkerThreadまたはCoroutineScopeで非同期実行。メインスレッドでの操作はrunOnUiThreadで厳密に制限してください。
NNAPIデリゲートを指定し、GPU/CPUの消費電力を最小化。設定例：
val options = InterpreterOptions().apply {
setDelegate(NNDelegeate())
}
android:sharedUserId="android.uid_system"のアプリが所有するディレクトリに配置。外部ストレージへのコピー時はContentProvider経由でアクセス権限を明示的に付与。2026年現在、Android端末でのローカルLLM実装は「量子化」「剪定」「NPU最適化」の3本柱で実現可能です。Kotlinを用いたTFLiteインターフェースはシンプルかつ高速で、オフライン環境でも数秒以内に応答が得られます。メモリリークやバッテリー消費への対策を事前に施せば、企業システムにも安心して導入できます。
Tags: Android, AI, LocalLLM, 開発
]]>