Android Studio第83期-Android Studio 3.1キャッシュされたピットの構築
この文書は、Android Studioキャッシュに関する今日グループで述べた昨日踏んだ穴を記録しています.
まず背景を話します.私が担当しているプロジェクトは、グラフライブラリに外部依存しています.このグラフライブラリは私がメンテナンスしていて、新機能が開発中なのでSNAPSHOTバージョンを使ってOJO(oss.jfrog.org)にリリースしました.私はプロジェクトの中で依存を更新したばかりで、突然まだいくつかのAPIが少ないことを思い出して、SNAPSHOTバージョンを発表しました.物語はこうして始まった.
この時Android Studioに戻って
知らなくても大丈夫ですが、ここで補足して説明します.Gradleユーザーガイドの依存管理の章では、Gradleがダイナミックバージョンやバリエーションモジュールのキャッシュ時間のデフォルトは24時間です.ダイナミックバージョンとは?
ここでは、キャッシュサイクルも変更できます.Gradleユーザーズガイドでも、次の構成を追加することについて詳しく説明しています.
ただここで私は最初から手間を省いて、更新に頼って直すのがおっくうです.
それなら、どうしますか.
ここでくどくど言うと、
しかし、実際にはありません.この时、私は突然思い出して、私达の会社はアリクラウドサーバーの上で1つのmavenの私服を建てて、去年の时私は上でOJOに対する代理店を配置して、この时引き延ばしたのは私服の上のバージョンで、それが更新していませんか?大丈夫です.解決方法は簡単です.削除してください.そこでnexusにログインして、キャッシュされたこのライブラリを見つけて、右クリックして、バージョン全体を削除しました.サーバーの上のを削除した后に、また安心しないと感じて、そこで更に.gradleのキャッシュを探して削除しました.私はその時そうだったはずです.
nexusを使用してmaven私服を構築するにはいくつかのメリットがあります.1つは、社内のライブラリを置くことができます.第二に、他のmaven倉庫に対するエージェントを構成し、ある依存にアクセスする人がいるとキャッシュされ、次の他の人が同じ依存にアクセスするとキャッシュされ、国内でアクセスが友好的ではないjcenterのような倉庫に対して、待ち時間を効果的に減らすことができます.もちろん、社内LANを1つ導入すれば、向上効果はさらに顕著になります.
最後に前の手順を実行します.コマンドラインには、この依存が再ダウンロードされていることがわかります.そして、
そして再構築してキャッシュさせて、その時にすればいいのではないでしょうか.Android Studioで構築が実行され、再キャッシュされていることがわかりました.しかし——悲劇はこれで発展し、深い穴はこれで陥没した!
この時、新しく追加したAPIだけでなく、エディタのこのライブラリに関するコードが赤くなったことに気づきました.にもかかわらず!種目はやはり走ることができます!当時のスクリーンはこうでした:違います.どうしたの?
このとき,ここでキャッシュされたパスにはhashを名前として含むフォルダがあり,更新した後もhash値が異なるので,どこのインデックスが対応していないのかを機知的に考えた.そこで探してみると、
ヒントはバイナリファイルです.ああ、パラメータを追加します.
結果が出てきましたが、やっぱりありました.じゃ、また削除します.ちょっと待って--私はこの時慎重になったので、名前を変えたほうがいいです.名前を変更してから構築を実行し、このファイルが再生成され、予想通りに発展しているように見えます.しかし、このライブラリに関する参照は間違っています.
この時の私は考え込んで、他の方法を試しました. Sync with File System Sync Project with Gradle Files File -> Invalidate Caches/Restart
それとも無効ですか.憂鬱で、仕事が終わった.
この問題は今こんなに頑固に表現されていますが、最終的には私に解決されました.朝になると、私は少し急いでいると思います.結局、プロジェクトの開発時間は私に一日も引きずられましたが、運維の心を持つプログラマーとして、自分で踏んだ穴はどうしても平らにしなければなりません.そこで私は他のキャッシュの面で考え始めましたが、論理的に合わないとは思いませんでした.Gradleが構築時にタスクの入力をスナップショットすると思い、プロジェクトの
仕方なくgoogleを続け、前に述べたInvilate Cacheの方法を見た.ふとStackoverflowであまり見かけない回答を見ました.
Android Studioを終了し、すべてを削除します.imlファイルおよび.ideaディレクトリで、Android Studioを開いてプロジェクトを再インポートします.
あれ?この方法は試したことがない.では、試してみましょう.
そしてAndroid Studioを再開し、ポイント
胸の中の興奮を抑えながら、土鍋を破って精神を問いただす私は、この問題についてまだ考えを放棄していない.だから、いったい何が原因なのか.ちょっと見ました.imlファイル、異常はありません.じゃあまた見ましょう.ideaディレクトリ.
結果は以下の通りである.idea/librariesには、各サードパーティライブラリのclasses、javadoc、sourcesに対応するパスが記録されます.ここでclassesが対応するのは、前述したtransforms-1のディレクトリであり、同様に前述したように、含まれるパスにはhash値があり、更新依存後、hash値が異なり、新しいキャッシュパスも異なるが、ここでは元の削除されたパスを使用しているので、対応するファイルが見つからないのは当然エディタに
まず背景を話します.私が担当しているプロジェクトは、グラフライブラリに外部依存しています.このグラフライブラリは私がメンテナンスしていて、新機能が開発中なのでSNAPSHOTバージョンを使ってOJO(oss.jfrog.org)にリリースしました.私はプロジェクトの中で依存を更新したばかりで、突然まだいくつかのAPIが少ないことを思い出して、SNAPSHOTバージョンを発表しました.物語はこうして始まった.
この時Android Studioに戻って
Sync Project with Gradle Files
に行くのはきっと引き下がらないに違いない.周知のように、Gradleのキャッシュポリシーでは、SNAPSHOTバージョンのデフォルトのキャッシュサイクルは24時間です.つまり、前回更新した後、24時間以内に前回のキャッシュが使用されます.知らなくても大丈夫ですが、ここで補足して説明します.Gradleユーザーガイドの依存管理の章では、Gradleがダイナミックバージョンやバリエーションモジュールのキャッシュ時間のデフォルトは24時間です.ダイナミックバージョンとは?
3.+
のようなダイナミックバージョンを見たことがあります.チェックされた最高のバージョン番号を取ります.latest.integration
のような動的バージョンでもあります.変化モジュールは、0.2-SNAPSHOT
のような後部バンドSNAPSHOT
のバージョンです.この2つの違いは、前者はコードのバージョン番号の書き方が変わらないにもかかわらず、実際には倉庫の最新バージョンを取りに行くことです.後者は倉庫のバージョン番号が同じで、xxx-SNAPSHOT
ですが、実際にはこのバージョンに対応する内容が変わりました.ここでは、キャッシュサイクルも変更できます.Gradleユーザーズガイドでも、次の構成を追加することについて詳しく説明しています.
configurations.all {
resolutionStrategy.cacheDynamicVersionsFor 10, 'minutes' //
resolutionStrategy.cacheChangingModulesFor 10, 'minutes' // }1234
ただここで私は最初から手間を省いて、更新に頼って直すのがおっくうです.
それなら、どうしますか.
~/.gradle/caches
全体を乾かしますか?いやいや、それは大げさすぎる.実はこの問題は私はとっくに遭遇したことがあり、「漢化」したGradleユーザーガイドの私にとって簡単すぎる.コマンドラインの下で実行:./gradlew aTD --refresh-dependencies1
ここでくどくど言うと、
aTD
はプロジェクトのGradleタスクの略で、フルネームはassembleTestingDebug
で、そのうちTesting
はプロジェクトのProductFlavor
です.これは重要ではなく、後のパラメータ--refresh-dependencies
に重点を置き、このパラメータを加えると、強制リフレッシュ依存性を示す.しかしAndroid Studioに戻ってコードを書くと、コードプロンプトに新しいAPIが出てこないことに気づいた.Android Studioは更新されていないようです.でも大丈夫です.このことは私にも経験があります.右側のGradleパネルをクリックし、androidDependencies
タスク、右クリック、Create xxxxx Configuration
を見つけ、ポップアップパネルのArgumentsの欄に前述のパラメータ--refresh-dependencies
を入力し、追加し、実行したら実行を選択します.実行が終わったら、数年前の経験に従って、この時出てくるでしょう.しかし、実際にはありません.この时、私は突然思い出して、私达の会社はアリクラウドサーバーの上で1つのmavenの私服を建てて、去年の时私は上でOJOに対する代理店を配置して、この时引き延ばしたのは私服の上のバージョンで、それが更新していませんか?大丈夫です.解決方法は簡単です.削除してください.そこでnexusにログインして、キャッシュされたこのライブラリを見つけて、右クリックして、バージョン全体を削除しました.サーバーの上のを削除した后に、また安心しないと感じて、そこで更に.gradleのキャッシュを探して削除しました.私はその時そうだったはずです.
nexusを使用してmaven私服を構築するにはいくつかのメリットがあります.1つは、社内のライブラリを置くことができます.第二に、他のmaven倉庫に対するエージェントを構成し、ある依存にアクセスする人がいるとキャッシュされ、次の他の人が同じ依存にアクセスするとキャッシュされ、国内でアクセスが友好的ではないjcenterのような倉庫に対して、待ち時間を効果的に減らすことができます.もちろん、社内LANを1つ導入すれば、向上効果はさらに顕著になります.
最後に前の手順を実行します.コマンドラインには、この依存が再ダウンロードされていることがわかります.そして、
.gradle/caches/modules-2
の対応するソースjarパッケージもチェックしました.確かに更新されました.Android Studioに戻ると、まだ更新されていないことに気づきました.これはどういうことですか.私は疑問に思って、心の中の1つの音が響いた:ああ(ここは4回読むべきです)!この時、新版のAndroid Studioはスピードアップのために、サードパーティ依存に対して解凍し、~/.gradle/caches/transforms-1
ディレクトリに格納するキャッシュが増えたと思います.そこで続けます:削除!find . -name "hichart*" |xargs rm -rf1
そして再構築してキャッシュさせて、その時にすればいいのではないでしょうか.Android Studioで構築が実行され、再キャッシュされていることがわかりました.しかし——悲劇はこれで発展し、深い穴はこれで陥没した!
この時、新しく追加したAPIだけでなく、エディタのこのライブラリに関するコードが赤くなったことに気づきました.にもかかわらず!種目はやはり走ることができます!当時のスクリーンはこうでした:違います.どうしたの?
このとき,ここでキャッシュされたパスにはhashを名前として含むフォルダがあり,更新した後もhash値が異なるので,どこのインデックスが対応していないのかを機知的に考えた.そこで探してみると、
transforms-1/metadata-1.1
の中にresults.bin
という書類が見つかりました.そのライブラリの内容が含まれているかどうかをもう一度調べます.cat results.bin| grep "hichart"1
ヒントはバイナリファイルです.ああ、パラメータを追加します.
cat results.bin| grep -a "hichart"1
結果が出てきましたが、やっぱりありました.じゃ、また削除します.ちょっと待って--私はこの時慎重になったので、名前を変えたほうがいいです.名前を変更してから構築を実行し、このファイルが再生成され、予想通りに発展しているように見えます.しかし、このライブラリに関する参照は間違っています.
この時の私は考え込んで、他の方法を試しました.
それとも無効ですか.憂鬱で、仕事が終わった.
この問題は今こんなに頑固に表現されていますが、最終的には私に解決されました.朝になると、私は少し急いでいると思います.結局、プロジェクトの開発時間は私に一日も引きずられましたが、運維の心を持つプログラマーとして、自分で踏んだ穴はどうしても平らにしなければなりません.そこで私は他のキャッシュの面で考え始めましたが、論理的に合わないとは思いませんでした.Gradleが構築時にタスクの入力をスナップショットすると思い、プロジェクトの
.gradle/buildOutputCleanup
ディレクトリを見つけて削除しました.まだだめです..gradle/4.4
(現在使用されているGradleバージョン)を削除します.まだ間違っています.では、.gradle
全体を削除します.さらに、~/.gradle/caches/transforms-1/
、削除!依然として間違っています.では、Android Studioの構成フォルダ、~/.AndroidStudio3.1
、削除します.Android Studioのインポート構成を削除して再開すると、すでに前の問題ではないことがわかりましたが、問題は解決したと思いますか?いや!問題のアップグレードです!この時はもうあの庫報が赤くなったのではなく、第三者庫を引用したすべての場所が赤くなった!!!それでも、動くことができます!!仕方なくgoogleを続け、前に述べたInvilate Cacheの方法を見た.ふとStackoverflowであまり見かけない回答を見ました.
Android Studioを終了し、すべてを削除します.imlファイルおよび.ideaディレクトリで、Android Studioを開いてプロジェクトを再インポートします.
あれ?この方法は試したことがない.では、試してみましょう.
find . -name "*.iml" |xargs rm
find . -name ".idea" |xargs rm -rf12
そしてAndroid Studioを再開し、ポイント
Sync with File System
、この時奇跡がやっと出てきました.Android Studioはやっと正常になりました.エディタは赤くなりません.胸の中の興奮を抑えながら、土鍋を破って精神を問いただす私は、この問題についてまだ考えを放棄していない.だから、いったい何が原因なのか.ちょっと見ました.imlファイル、異常はありません.じゃあまた見ましょう.ideaディレクトリ.
find .idea -type f |xargs grep "hichart"1
結果は以下の通りである.idea/librariesには、各サードパーティライブラリのclasses、javadoc、sourcesに対応するパスが記録されます.ここでclassesが対応するのは、前述したtransforms-1のディレクトリであり、同様に前述したように、含まれるパスにはhash値があり、更新依存後、hash値が異なり、新しいキャッシュパスも異なるが、ここでは元の削除されたパスを使用しているので、対応するファイルが見つからないのは当然エディタに
cannot resolve symbol
と提示されている.したがって、正確で直接的な解決策は、.idea/libraries/
のサードパーティ製ライブラリのxmlファイルを削除して再生成させるか、xmlファイルの内容を直接修正して依存後のパスを更新することである.