Windows環境でのInstantRunに関してのメモ(2.0-prev8)

でWindowでInstantRunが動く?ようになりましたので
そこら辺に関してちょっと挙動をメモしておく

まあMacAndroid開発できるような幸福な方にはあまり関係ない話かも。。。
その場合は雑知識的な感じで読んでいただければ・・・



Android Studio 2.0 Preview 8 の最新状況)

1)Win環境で 2回に1回はInstantRunのビルドが通るようになった

  • 失敗する時はCPUが100%で張り付くビルドの時っぽい

対策)
BES.exeでgradleがキックするjava.exeプロセスにCPUリミットをかける

  • limit.bat *2
start /B %BES_HOME%/BES.exe %JAVA_HOME%/bin/java.exe 70 -m

そのままだと終了しないので停止用のbatも作っておくこと

  • limits.bat
%BES_HOME%/BES.exe -u -e

これでgradleのjavaタスクでDEX処理ではりついてビルドが固まることはなくなります。
ただ
org.gradle.parallel=true
でビルドのヒットが悪くてビルドエラーになることはたまにありますね*3

2)余計なチェッカーが付いてビルドが失敗/大量のワーニングがでるようになった

  • prev7
    • genymotion(x86)の環境に、NDK(arm-v7)等のso同梱したapkを転送できなくなった*4

対策)
標準のNDKタスクを無効にするとNDKのチェックタスク自体も無効=>普通に転送できるようになる

  • prev8
android.dexOption.javaHeapSize=1024m
org.gradle.jvmargs=-xms1024m

と一致させないとワーニングがうざくなった。
また指定サイズが少なくても*5大量のワーニングが出るようになった。*6
でもサイズ増やさなくてもビルドが出来ないということはない。

そもそもtaskが失敗するの

  • buildフォルダの対象ファイルが削除できない
    • ファイル見つからない場合も含む
    • deadタスクがファイル掴んじゃってる場合もあるけど。。。*7

3) InstantRun自体の謎の挙動が。。。

  • gradle daemon が複数立ち上がって激重になることも・・・
    • InstantRunを数回動かしていたら、凄く重くなったのでjpsでPIDみたら gradle daemonが3コ立ち上がるとかわけわからん挙動が・・・
    • たぶん応答がなくなったGradleDaemon=>停止命令=>停止しなくても新しいdaemon立ち上げ とか遣ってそう。。。

対策)

alias jkill=taskkill /f /im java.exe

で余計なjavaプロセス殺せるようにしておくしか無い。。。

4) ビルドが凄く時間かかるようになった。
1.5のバージョンに比べて2.0ベースが凄くビルドかかるようになっている
Twitterのつぶやきでも AS2.0が激遅なので AS1.5に戻すとかやってる方がチラホラ。。。

  • 必ずcleanタスクを実行して作りなおしているから
    • 毎回フルビルドしていれば当たり前
    • これInstantRunのチェック外しても同じ挙動*8

5)apkが転送されない謎の現象が。。

  1. org.gradle.parallel=true の指定でビルドがコケる
  2. そのあと再ビルド=>成功
  3. でもapkが転送されない

これ apkに変更がなければ転送しないチェックが明らかに誤爆してると思う・・。
しかも再実行
またフルビルドから始まる

対策
作成済みのapkを adb installコマンドで手動で入れたほうがイライラもしなくて速い

みたいなナンセンスな状況があったりするんですよね・・すごく意味が無い・・・

Jrebelのように差分転送用の専用ボタン用意したほうがいいんじゃないか疑惑が・・


6)AS2.0自体が安定していなくて バギーな状況なので微妙

  • CTRL + ALT + O

Optimize Imports が2.0-prev5辺りから動かなくなってる><*9

    • で仕事場のほうでは1.5ベースで運用しようという話になってる。。
  • prev7までは デバック実行でローカル変数参照ができませんでした・・
  • logcatフィルタの正規表現保存ができなくなってたり
  • サードパーティ製のプラグインの参照がアップデートの度によく外れる




JRebel for Androidとの比較)

  • 初期転送でも速すぎ、、
    • assembleDebugで作ったapkにパッチを当ててるだけの挙動
      • めちゃくちゃビルドが速い
      • make Projectでビルドエラーを無くす => Jrebel実行 =>パッチ当て1秒以下

なんて状況だったりも


今週でた ver 1.0.16
あたりから再接続自動リトライ処理が凄く良くなったので、すごく使い勝手がいい。

バックエンドに行ってしまった時に、差分転送時にフロントエンド表示にして欲しい
あたりの希望はあったりするけど、FeedBackで質問したら
改修事案として検討はしていただけるみたい

ならマジで購入してもいいかもなーと凄く考えていたりしてる・・

*1:8GBメモリ環境

*2:70%ぐらいのCPUキャップ

*3:もう一度ビルド走らせると動きはするのですが。。。

*4:ARM-Transtrationでエミュレートしても入れられないなら論外orz><

*5:512Mとか。。

*6:正直すごくウザイ・・・

*7:Handle.exe https://technet.microsoft.com/ja-jp/sysinternals/handle.aspx あたりで確認は可能

*8:prevだからInstantRun前提のタスクとか作って人身御供やってよ!って感じなんだろうな。。

*9:思わずPCぶん投げたくなるぐらいすごい不便。。。