【解決済】HTC 10 HTV32など、複数のAndroidデバイスでデレステがもたつく現象について

2016年8月4日

既に解決済みの情報です。(2017年6月24日現在)

 

 

簡潔に書き直したものはこちら→デレステの高負荷問題とその対処法

 

 

HTC 10 HTV32はauから販売されているHTCのフラッグシップモデル。Snapdragon 820を搭載しており、ハードウェア上は新しいグラフィックAPIであるVulkanに対応。メモリも4GB搭載しているので今後に期待出来るデバイスであると言えます。

さて、そんなHTC 10において「アイドルマスター シンデレラガールズ スターライトステージ(デレステ)」がもたつく場面が多々ありました。WQHD解像度とはいえ、正常にプレイ出来るときは今までのHTC機の中で最も快適な動作を見せてくれていただけに購入当初から疑問に思っていました。

色々と検証してみた結果、HTC 10ではなくデレステ側の問題だったのですが、本記事では自分のできる範囲で原因を探ってみた内容を綴ってあります。

サーマルスロットリングが効いているのではないか

連続プレイによる発熱でサーマルスロットリングが効いているのではないかという推測。CPU温度を確認するためにCPU-Zとデレステを行き来するのは面倒なので、バッテリー温度をオーバーレイ表示出来るアプリを用いてプレイしました。また、CPU周波数も同時にオーバーレイ表示してあります。

丁度イベント中ということもあり、Grooveイベントを用いて実際にプレイを始めると3曲目をプレイしている途中でもたつき出すようになりました。3曲とも2D軽量設定でのプレイです。4曲目のイベント曲を試しに3D標準に切り替えてみたところ、尋常ではないコマ落ちが発生し、とてもプレイできる状況ではありませんでした。

プレイ中の温度遷移はスタート時点で34℃、2曲目で36.5℃、3曲目では38℃程度でした。CPU周波数を監視していると、4コア中2コアが常時最大クロックで固定されており、2曲目の途中で最大クロックが2150MHzから1824MHzに低下。3曲目で更に1555MHzへ低下しました。1555MHzに最大クロックが落ちたときに目に見えて動作が悪くなったのが分かりました。変化の瞬間ガクッっとフレームが飛ぶような感覚もありました。

cap01

34.0℃/2150MHz

cap02

36.5℃/1824MHz

38.2℃/1555MHz

38.2℃/1555MHz

ここだけを見るとサーマルスロットリングが効いてしまっているように思います。もちろんバッテリー温度を基準にしていないと思うのでこれはあくまでも目安です。サーマルスロットリングは「CPUの温度」を基準に動作するはずなので、バッテリーが38℃であっても最大クロックが低下していないこともあります。HTC10実機では暗号化?されていて確認ができませんでしたが、CM13のthermal-engine.confでは平文で確認することが出来ました。非公式の設定ファイルではありますが、BC_MONITORを見ると、”thresholds 37000 39000 42000″ “thresholds_clr 35000 37000 41000” “action_info 1824000 1555200 1324800″との記述があり、msm_thermの温度値を基準に35~37℃→1824MHz、37~39℃→1555MHz、41~42℃→1324MHzといった制御をしていることが推測できます。大体上記の検証通りです。GPUについても39℃を超えた辺りから510MHzから約100MHzづつクロックを落とすような記述がありました。とはいえ38℃からはなかなか上がらなかったので、炎天下での酷使などをしなければサーマルスロットリングの影響はほぼ感じないと言っても良いでしょう。

さて、問題はたった3曲程度プレイしただけでオーバーヒートしてしまうということです。もうお気づきの事かと思いますが、4コア中2コアが最大クロックで固定されているのがおかしいのです。

最大クロックで固定されるときと固定されないとき

Snapdragon 820は最大クロック1593MHzのコアが2つと、最大2150MHzのコア2つの合わせて4コアでbig.LITTLE HMP構成を取っているプロセッサです。4コア中2コアだけが最大クロックのままになっていたというのは、big側のコアが何らかの原因でフルに稼働してしまっていた為です。

デレステが常時CPUをフル稼働させるほど重たいアプリかというと決してそういうことはなく、正常動作時であればCPU使用率は30%台、big側のコアも300~1800MHz辺りを変動しながら動作しています。ベンチマークアプリである3DMarkなども最大クロックで固定されるような場面はほとんどないです。正常に動作している場合は3曲以上プレイしてもオーバーヒートすることはありません。実際にGroove4周分(16曲)を2D標準で連続プレイした際は37℃台をキープし、引っ掛かりもありませんでした。

デレステの動作がおかしいと感じたときは、タイトル画面の時点で既にbigコアがフルパワーで動いており、メニューや曲選択画面でもクロックが変動することはありません。

タイトル画面の時点でbigコアが最大クロックのままになっているのがわかる。

グラフに変動がなく、タイトル画面の時点でbigコアが最大クロックのままになっているのがわかる。

2016-08-04-06.53

正常動作時。グラフが上下しており、クロックが変動していることがわかる。

ではこの状態がどのタイミングで起きるのか。厳密に検証することは難しいのですが、私が体験した限りでは、「デレステを起動したときから」「デレステを動かしたままスリープにし、復帰したとき」「デレステから別のアプリにタスクを切り替えたとき」の3パターンが確認できました。起動したときからというのはちょっと解せないところがありますが、1度だけ見かけた程度なのでおそらく見間違いでしょう。ほぼ起きないと言って良いと思われます。発生率は後者2パターンが圧倒的に多く、ほぼ確実に起こるようです。これについては端末温度はあまり関係ないように思います。

HTC 10 HTV32だけの問題なのか

これが個体不具合かというとどうやらそうではないらしく、同じHTC 10 HTV32を所持していてデレステやシャドウバースをプレイしている友人もそんなに遊んでないのに異常に重たくなる事があると聞いています。シャドウバースについてはプレイしたこともないためノーコメントとさせて頂きますが、Twitter上でもHTC 10でデレステ2D標準がもたつくという話もありました。

後述しますが、幾つか検証した結果これはAndroid版デレステの問題であり、HTC 10 HTV32固有の問題ではありませんでした。正常時であれば旧機種で稀に起きていたタッチ抜けのような現象もなく、デレステをプレイする上でHTC 10 HTV32はかなり遊びやすい製品であると感じています。まぁ、スピーカーは人を選ぶような変わった作りをしていますが。

対策方法は?

  • デレステプレイ中にスリープにしない。
  • デレステプレイ中にタスクを切り替えない、ホームに戻らない。

予防法としては上記2つが挙げられます。CPUコア0~3のうち、2か3番のコアの周波数をオーバーレイ表示するアプリで監視しておくのもありでしょう。

もし問題が発生した場合はアプリを一度終了させることで解決できます。現状、根本的な解決方法は発見できませんでした。なお、アプリの実行解像度をFHDに落とすBoost+のゲームバッテリーブースターを利用していてもbigコアが最大クロックのままになってしまう問題は発生するため、こちらも対策とはならないようです。ただ、ゲームバッテリーブースターを利用しているほうが解像度も抑えられてパフォーマンス向上が期待できます。

ここから追記情報。(2016/08/08更新)

Android全体で発生する問題だった。

これ、他のデバイスでも起きる可能性あるよな?と思っていた矢先、Twitter上でNexus 9(Android N)やXperia Z4(Android 6.0)でも再現性があるとの報告を頂きました。

HTCデバイスに限らず、Androidデバイス全体で発生する問題のようです。

ゴメンナサイ、モバイル端末だと表が変なことになってて物凄く読みづらいです。端末を横にすると読めるようになる…かもしれません。

デバイス名 Androidバージョン SoC コア数 通常時 問題時
Nexus 9 N Tegra K1 Denver  2  1600~1800MHz付近を変動  2GHzで固定
Xperia Z4 6.0 Snapdragon 810 4+4  LITTLEコアが1344~1555MHz付近を変動、bigコアは0MHzか384MHz LITTLEコアが1555MHzで固定、bigコアのひとつが1958MHzで固定

手元のデバイスで確認した結果は次のとおりです。

デバイス名 Androidバージョン SoC コア数 通常時 問題時
HTC One M8 6.0 Snapdragon 801(AC) 4 常時50~60%ほどのCPU使用率。1728MHz付近を変動しつつ高クロックで動作。→かなり長期間利用していたため、他の要因で高クロックのままだったようです。初期化後は他機種同様に待機中は低クロックで動作。 4コアとも1958MHzとなり殆ど上下しない。CPU使用率は90%近くなる。
HTC One M9 6.0.1 Snapdragon 810 4+4 主にLITTLEコアが動作。bigコアは4コアとも384~864MHzで動作。 最大クロックではないが、bigコアが1536MHzで固定化。グラフの変動がなくなる。
HTC J butterfly(B830x) 6.0.1 Snapdragon 810 4+4 上に同じ 上に同じ
Nexus 9 Remix OS 3.0(6.0.1) Tegra K1 Denver 2 CPU使用率35~40%、1538MHz付近を上下しつつ動作。 CPU使用率65~70%へ。2270~2295MHzを僅かに変動しつつ動作。
HTC One A9 6.0.1 Snapdragon 617 4+4 最大1517MHzのコアが2つ960~1344MHz辺りを変動。最大1210MHzの4コアがほぼ最大クロックのまま僅かに変動。 最大1210MHzの4コアが最大クロックで固定されるように変化。
Galaxy Note Edge 5.0.1 Snapdragon 805 4 CPU使用率は45~50%、全コアクロック変動しつつ動作。 CPU使用率は僅かに上昇。最大クロックの2650MHzで動作するコアが1つ出現。しばらくすると別のコアに交代し、常にどれかが最大クロックとなる。
Galaxy S6 Edge 6.0.1 Exynos 7420 4+4 LITTLEコアが400~1296MHz辺りを変動、bigコアが1200MHzで動作。 LITTLEコアが800MHz辺りで動作するようになり、bigコアが2100MHzで固定化。
AQUOS SH-M01 4.4.2 Snapdragon 800 4 653~1190MHz辺りを変動。たまに他のコアが動き出すが、基本的に1コアしか動いていない。 他2つが動き出し、3コアに。多少の変動や切り替わりがあるが、それら2つは最大クロックの2150MHzで動作している。

かなりメーカーの偏りがありますが、傾向としてはスリープやタスク切り替えを行うと高負荷になったまま戻らなくなるという結果となりました。極力少ないコア数でサボろうとする省エネに動作しようとする設計のSHARP機ですら4コア中2コアが最大クロックで動作するのですから、かなり負荷がかかる状態になっているのだと思われます。

では何故今まで気が付かなかったのかということですが、私の推測としては、まず「Androidは動作が重い、音ゲーに向いてない」といった固定観念があるということ。次に、Snapdragon 805辺りまでは比較的安定していたことや、デレステプレイ時は全体的に高負荷だったため最大クロック固定化が起こっても気がつきにくかったということ。最後に、熱い熱いと言われているSnapdragon 810機が出始めた頃(2015年夏モデルから)にデレステがリリース(2015年9月3日)されたため、発熱しやすかったことや、発熱したらすぐにSoCのせいにする考えが広まっていたことが考えられます。

今回、パフォーマンスが高く、大きく発熱することのないSnapdragon 820搭載のデバイスが出現したことで、連続プレイの出来るときと出来ないときが顕著に現れるようになったため、問題が発覚するようになったのではないかと私は考えています。恐らくGalaxy S7 EdgeやXperia X Performanceなどの性能に余裕のある類似スペックの製品でも、問題発生時とそうでないときとで顕著な差が現れることが予想されます。

ここで検証しなかったメーカーのものなど、例外的なデバイスはあると思うのですが、ひとまずAndroidでデレステをプレイする際は、スリープやタスク切り替えをしないようにし、もしそのような操作をしてしまった場合はアプリを立ち上げ直すようにすると安定したプレイが出来るのではないでしょうか。

本記事ではデレステのバージョンは2.1.1を使用して検証していますが、問題はそれ以前から起きているように思います。一応運営側に報告はされているようですので、もしかすると改善が見込めるかもしれません。iOSデバイスは検証していませんので分かりませんが、宗教的な問題やOSに対するこだわりが無ければ、デレステ等音ゲー用に最新のiPadを1台購入してきたほうが幸せかもしれませんね。すいません、私はこだわりのあるほうの人間ですので……。

 

2016/08/07 少しだけ追記。

2016/08/08 他のデバイスでの検証結果を追記。

2016/08/13 thermal-engine.confを見つけたのでついでに追記。

2016/10/09 HTC 10が悪いとも読み取れるようなタイトルだったので修正。記事内も幾つか加筆修正。パーマリンク設定はそのままにしています。尚、この問題はバージョン2.3.2現在修正はされていないようです。

Amazon