Android Studio 2.2.1 で Built-in Shrinkerを試して死んだメモ
どんな機能か
に記載されているとおり、
- MultiDex
- proguard
を使わないで64k越えを対応する方法らしい。
確かにMultiDex使わなければ、2系端末へのインストールも可能との希望を持ちつつ試した
試した環境
- Android Studio 2.2.1
- android gradle plugin 2.2.1
android data-binding plugin 2.2.1
メモリ16GのMac環境
所感
optimizeかけない(？)ナンチャッテproguard(粗悪品)かと。
proguardじゃない発言を信じて動かしていて、data-bindingクラスが見つからないエラーでビルドエラーでハマる。
生成までは出来ているので*1、正直 Why? 状態でした。。
debug {
debuggable true
minifyEnabled true //★
useProguard false //★
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro', 'shrinker-rules.pro' // ← 追加
}
だけじゃ足りなくて
multiDexKeepProguard file('multi-dex-keep.txt')
で指定してた、multi-dex-keep.txt も追加が必要。
因みに debugのDSLで★ の記述があると、
問答無用で[Built-in Shrinker]と判定しているよう。
その状態で
multiDexEnabled = true
の記述があればチェックタスクで [multiDexと共存できません] エラーで終了
イケてない処
普通のprogardでは下記は無視してくれる
- AndroidManifest.xml 等のタグとか重複定義
- proguard.txtのファイル存在
- proguard.txt内の重複定義
Built-in Shrinkerだと
- 上記を厳密にチェックしてチェックタスクでエラー
- ＝＞ タスク終了
これ data-bindingの
- layout=>内部直下のlayoutにタグを追記 ＝＞この時res-auto の重複タグ有り
- チェックエラー ＝＞リソースエラー扱いでプロジェクト真っ赤っ赤
とかも同じ感じなんだよね。。使い勝手的にはskipしてほしいよな。。
ビルド時間
下記は環境依存の可能性もあるので、参考程度にしてください *2
| アクション名 | ビルド時間(通常) | InstantRun差分？ビルド |
|---|---|---|
| debugビルド | 10-30秒 | 5-20秒 |
| debugビルド+MultiDex | 20-50秒 | 15-40秒 [1] |
| debugビルド+progard | 30-60秒 | 20-50秒 [2] |
| Built-in Shrinker | 90-120秒 | 180-300秒 [3] |
- 4系以降の開発であれば、この構成でなんとか開発はできる感じ。
- debugビルド＋progard処理の時間のような感じ(MultidDexとほぼ時間は変わらない感じ)
- 常にフルビルドのような。。（汗
正直、debugビルドに通常のproguardかけたほうがいいんじゃね？
ビルドに時間かかりすぎて、ステップデバックできるかまでは確認できなかったかなー*3
学んだこと
G様が「新機能作ったぜ〜。使ってみなよ〜」を素直に信じてはいけない＞＜ *4
Android Studio，stableだからといって安心してはいけない。
— いまいまさのぶ (@masanobuimai) October 11, 2016
まさにこれｗ
Android Studio/cmakeのデフォルトclangだけど、libjpeg-turboのアセンブリでエラー出る。gccにしたら大丈夫。clang asmじゃなくてgasじゃないとダメとかかな。
— じん (@jin1016) October 11, 2016
たしかにgccじゃないと
- cocos-2dxとか
- 通常のライブラリリンク系のビルド(so作成)
がうまくいかない駄目とかのTwも どっかで見たな。。（遠い目
gccのサポートに関して(参考)
でも 今後gccは捨てられるみたいな話があるようなので、そのときは大混乱が起きそう
Android NDK r13が公開されてる。しかし、ファイルサイズがでかくなりすぎて、zipでの配布は無理がないか。7zで配布するのはダメなのかねえ。展開にサードパーティーアプリが必要な形式では問題がある？
— けいちゃ (@keicha_hrs) October 12, 2016
でもAndroid Studioのインストーラーでは、SDKを7z形式で圧縮したファイルをダウンロードしてるんだよね。だからGoogleとしては7zを採用はしているわけだ。Windows版は7z、Linux版はtar.xzで配布するのはありな気はするけど。
— けいちゃ (@keicha_hrs) October 12, 2016
NDK r12bが714MB、r13が650MBだから、若干小さくはなったのかw
— けいちゃ (@keicha_hrs) October 12, 2016
NDKのリリースノートに、gccはもう長くはサポートはしませんよってアナウンスが出てるね。r14あたりで全面的にclangに移行するのかな。
— けいちゃ (@keicha_hrs) 2016年10月12日
間違えました。r13からもうclangが標準なのね。gccはバックポートとして格納しているだけで、いずれ全面削除されますよと。
— けいちゃ (@keicha_hrs) 2016年10月12日
AS 2.2.1 の謎挙動集
Build Cache 有効化
offにした方がいいです。
- android gradle plugin 2.2.1
になってから、強力にこのキャッシュを見ているようです
- clean rebuild が中々聞かない
- .iml/.ideaフォルダを消してプロジェクトを開き直し
- File > Invalidate Caches/Restart でAS自体の古い動作キャッシュを消す(& AS自体再起動)
の対処も効かない。
具体的な対処法
- jpsでjavaのプロセスを見て kill -9 で強制終了させる
- gradlew --stop は gradleMainとかに終了シグナルを送るだけで、forkして実行しているjavaタスクが終わらないと掴んでしまっている
- $HOME/.android/build-cache の中を全削除
までしてなんとか。
- gradle.properties
android.enableBuildCache=false
でoffにすればいいんですけどね。これ AS 2.3以降ではdefaultでON になるらしいけど、今からこのクオリティで大丈夫？
2系 でInstantRunが動きそうな挙動をするが、 意味不明な挙動をする
- InstantRunがチェックがONの状態
- 昔は、InstantRun対応OSじゃない時 ＝＞通常ビルドで転送
- 今は、InstantRun対応OSじゃない時 ＝＞ビルドエラーにする
- コマンドラインでビルド成功する&InstantRunビルドのときでもエラーが出ていないので、凄くパニクった
ようは、「2系はもう開発するやついねーだろ」とG様が「4系以下ならビルドエラーにすればいいんじゃね？」という
雑な対応に振り回されただけorz
- [ADT形式のプロジェクトで開発するやつなんかいねーだろ]
と AS 2.2.0 で変更されたビルド対象外の対応と同じ臭いがするかなー（苦笑
