読者です 読者をやめる 読者になる 読者になる

MacでCPU limit対策を考えてみた 

android gradle AS

発端

Mac 16G環境でも

AS 2.2.1 で GradleSync ビルドのタイミングで CPUが300-400%になってる

この状態だと、キーボードやマウスすら動かせない

android gradle plugin 2.1.X ではそんなことなかったんだけどな。。

環境差異としては

  • data-bindingを使うことを強いられている
    • MultiDexが前提になってる

あたりはあると思うんですけどね・・*1

他にも下記な問題もあったりするわけですが・・

まあG様のgradle対応って下記辺りから来てるしな・・

  • antやmaven使いたくない
  • ADTのように独自ビルド機構サポートしたくない


因みに windowsでは、

  • 2.1.x
    • 4G 32bitOS で動かせていた けど
  • 2.2.x
    • 8G 64bitOS でが最低環境らしい

ということらしいので。

gradleが馬鹿食いしてるのでなので、gradleのメモリ調整すれば動かせるとは思いますが。

あとASのindex処理も高負荷だけど、これ動かないと

  • コード補完
  • ソースのimportとか認識せず真っ赤っ赤

なので同しようもないよな。。*2

日本だと android開発者は未だWin機で頑張ってたりするのにな〜(遠い目

G様だと、開発機は基本 最新のMac Pro支給みたいな話を聞くので、そんなもんなのかもしれない。。

対処法

Windows OSで android gralde plugin 2.1.X 時代

rem "C:\path\to\bes.exe" "D:\path to\java.exe" [percentage] [--minimize]
"C:\path\to\bes.exe" "D:\path to\java.exe" 50 --minimize

Mac OSandroid gralde plugin 2.2.X 時代

java(名前無し gradleからのforkタスク)も対象にしてるけど

  • Preference>show system process で表示されるjavaタスク

ってビルドする度にPIDが違うんだよな・・というのが課題*4

あとはコマンドラインで指定できないのも微妙かも。。

Macで他の方法というと

なんか上手く動かせなかった。

sudoが前提なのと、sudo付けてもちゃんと期待通りに動かない感じ。

gradleからkickされているjavaタスクはユーザプロセスのはずなので

root権限は要らないはずなんだけどな。。(汗

ただG様的には

下記なアプローチもあるようなので、そこまで重要視されないんだろうなというのが現状かもしれませんね

CPU800%でマウスやキーボードが固まらない環境を毎月1万円でか・・

G様的には Google Compute Engine 使ってもらえば儲かりますし。

これって Firebase Test Lab 使うのと同じ感覚になるんですかね。。

tomoima525.hatenablog.com

富豪環境にかんする追記(AS 2.2.X upper)

AS 2.2.Xでは上記の富豪環境が既に動かないらしい。メモ

qiita.com

*1:だからどうしてもコマンドラインビルドとか必須になってしまう。。

*2:因みにPower Save Mode ONにしてもASだとまともに動かないよう

*3:このアプリもチャンネル増やすとCPU馬鹿食いする

*4:javaというプロセス名では引っかからない?gradle deamonのみに適応されているイメージ