一、運行方式

1.運行 (Run)

????????當您選擇“運行”時，Android Studio 會編譯您的應用并將其安裝到目標設備或模擬器上。這通常用于：

• 快速部署: 您只想看看應用是否能正常啟動并運行，或者進行一些基礎的用戶界面測試。

• 性能測試: 在正常運行模式下測試應用的實際性能。

• 發布版本: 模擬用戶實際使用應用時的環境。

????????在運行模式下，雖然您可以看到應用的輸出日志（Logcat），但您無法在代碼執行過程中暫停、檢查變量或逐步跟蹤代碼的執行路徑。它更像是一個“黑盒”測試，您只能根據應用的外部表現來判斷其行為。

2.調試運行 (Debug Run)

????????當您選擇“調試運行”時，Android Studio 會以調試模式編譯并部署您的應用。這意味著它會啟用額外的工具和功能，讓您可以對代碼的執行過程進行精細的控制和深入的檢查。調試運行主要用于：

• 問題排查: 當您的應用出現錯誤、崩潰或行為異常時，調試是定位問題的最有效方法。

• 理解代碼邏輯: 逐步跟蹤代碼，了解不同變量的值如何變化，以及代碼的執行流程。

• 驗證假設: 在特定條件下驗證您的代碼是否按照預期工作。

在調試模式下，您擁有以下強大的功能：

????????斷點 (Breakpoints): 您可以在代碼的任何行設置斷點。當程序執行到斷點時，會自動暫停。

????????單步執行 (Step Over, Step Into, Step Out):

• Step Over: 執行當前行代碼，如果當前行有方法調用，則直接執行完該方法，不進入方法內部。
• Step Into: 執行當前行代碼，如果當前行有方法調用，則進入該方法內部的第一行。
• Step Out: 從當前方法內部跳出，執行完當前方法剩余的代碼，并返回到調用該方法的地方。

????????變量檢查 (Variables): 在程序暫停在斷點時，您可以查看當前作用域內所有變量的實時值。

????????表達式求值 (Evaluate Expression): 您可以即時執行代碼片段或計算表達式的值，以測試不同的邏輯或查看復雜對象的狀態。

????????調用棧 (Call Stack): 查看當前代碼執行的調用路徑，了解是哪個函數調用了當前的函數。

3.installDebug 是什么運行方式？

????????installDebug 并不是一個直接的“運行方式”，而是 Gradle 中的一個任務 (Task)，用于將您的 Android 應用的 debug (調試) 版本安裝到連接的設備或模擬器上。

????????在 Android Studio 中，當您點擊“調試運行”按鈕時，幕后執行的一系列操作中就包含了 installDebug 這個 Gradle 任務。它通常涉及以下步驟：

1. 編譯 Debug 版本: Gradle 會編譯您的應用代碼和資源，生成一個帶有調試信息的 .apk 文件。這個 .apk 文件包含了調試器需要的所有信息，以便您可以在代碼中設置斷點、檢查變量等。

2. 簽名 Debug 版本: 這個 .apk 文件會使用一個特殊的調試密鑰庫進行簽名。

3. 安裝到設備/模擬器: 編譯和簽名完成后，installDebug 任務會將這個 .apk 文件安裝到您當前連接的 Android 設備或正在運行的模擬器上。

????????總結來說，installDebug 是構建和安裝應用調試版本的一個自動化步驟，它是您在 Android Studio 中進行調試的基礎。 您通常不需要直接調用這個任務，Android Studio 會在您執行調試操作時自動處理。

????????與 installRelease 任務相對，后者用于構建和安裝發布 (release) 版本的應用，通常不包含調試信息，并使用您的發布密鑰庫簽名，適用于最終用戶發布。

4.為什么會產生“運行 installDebug 后才能使用 appDebug 發生變化”的錯覺？

????????Android 項目的構建由 Gradle 負責。Gradle 通過一系列的 任務 (Tasks) 來完成從源代碼到最終 APK 的整個過程。

????????installDebug 和 appDebug (或類似的運行/調試任務，例如 runDebug 或通過 IDE 的運行按鈕觸發的) 都是 Gradle 任務。

• installDebug 任務： 這個任務的主要職責是將 Debug 構建類型 的 APK 文件安裝到連接的設備或模擬器上。它不負責編譯或打包代碼。它只是將已經構建好的 APK 推送到設備。

• appDebug (或 IDE 運行/調試) 任務： 當你點擊 Android Studio 中的“運行”或“調試”按鈕時，IDE 會觸發一系列的 Gradle 任務。這些任務通常包括：

1. 編譯 (Compile): 將你的 Java/Kotlin 代碼、資源文件等編譯成 DEX 文件和打包資源。
2. 打包 (Package): 將編譯后的文件和資源打包成 APK 文件。
3. 安裝 (Install): 將生成的 APK 文件安裝到設備或模擬器上。
4. 啟動 (Launch): 啟動應用程序的主 Activity。

????????并且Gradle 擁有強大的 構建緩存 (Build Cache) 和 增量編譯 (Incremental Compilation) 機制。這是造成“錯覺”的關鍵因素之一。

• 構建緩存： Gradle 會緩存之前構建的輸出，如果輸入沒有改變，它就不會重新執行某個任務，而是直接使用緩存的結果。這意味著如果你只更改了代碼中的一小部分，Gradle 不會重新編譯整個項目。

• 增量編譯： 增量編譯進一步優化了編譯過程，它只編譯那些發生變化的源文件，而不是重新編譯所有文件。

????????現在，我們可以解釋為什么你會產生“運行 installDebug 后才能使用 appDebug 發生變化”的錯覺：

1. IDE 行為和“運行”按鈕的簡化： 當你在 Android Studio 中點擊“運行”或“調試”按鈕時，IDE 實際上會為你執行一個完整的“構建、安裝、運行”流程。這個流程內部包含了編譯、打包和安裝等多個步驟。
2. installDebug 的直接性： 當你手動運行 installDebug 任務時，你僅僅是告訴 Gradle 去安裝 當前設備上已存在的、最新構建的 Debug APK。如果你之前已經通過 IDE 運行過項目（觸發了完整的構建流程），那么 installDebug 只是把那個已經構建好的 APK 重新安裝了一遍。
3. 未觸發完整構建： 真正的“變化”需要代碼被 重新編譯和打包。如果你只是在修改代碼后，直接運行 installDebug 而沒有先進行一次完整的構建（通過 IDE 的運行按鈕或者手動執行 assembleDebug 等任務），那么 installDebug 安裝的仍然是舊版本的 APK，因為你的代碼更改還沒有被編譯進新的 APK 中。
4. 構建系統優化： 在大多數情況下，當你修改代碼并點擊“運行”時，Android Studio 會智能地檢測到代碼變化，并觸發必要的編譯和打包任務。這意味著即使你覺得你只是“運行”了 appDebug，實際上整個構建流程已經悄悄地在后臺為你完成了。如果你沒有看到變化，很可能是因為你的更改未能正確觸發重編譯，或者緩存導致了舊代碼的加載。

????????“運行 installDebug 后才能使用 appDebug 發生變化”的說法是錯誤的。真正的變化來源于 代碼的重新編譯和打包，而 installDebug 僅僅是負責將 已構建好的 APK 安裝到設備上。

當你修改代碼后，要確保你的更改生效，你需要：

• 通過 Android Studio 的“運行”或“調試”按鈕重新運行應用。 這是最常見和推薦的方式，因為它會自動處理編譯、打包、安裝和啟動。

• 手動執行 assembleDebug (或 assemble 相關任務) 然后再執行 installDebug。 這種方式在你需要更精細控制構建過程時有用。

????????本質上，appDebug 并不是一個獨立的、能“使變化生效”的魔法任務。它是 Android 構建系統和 IDE 背后復雜流程的一部分，而這些流程的核心是確保你的最新代碼被正確地編譯和打包成可執行的 APK。installDebug 只是這個流程的最后一步，負責部署已經準備好的應用程序。

5.Attach Debugger to Android Process和Sync Project with Gradle Files的作用

Attach Debugger to Android Process 的作用

????????簡單來說，這個功能允許你在不重新啟動應用的情況下，將調試器連接到已經運行在設備或模擬器上的應用進程。

想象一下以下場景：

1. 你的應用正在后臺運行，或者你正在通過其他方式（比如從主屏幕點擊圖標）啟動它，而不是直接從 Android Studio 運行。
2. 你發現了一個 bug，想要在應用運行狀態下實時檢查變量的值、查看調用堆棧，或者設置斷點。

????????在這種情況下，你不需要重新編譯和運行整個應用，只需點擊 Attach Debugger to Android Process 按鈕。Android Studio 會彈出一個窗口，列出當前所有可調試的進程。你只需選擇你的應用進程，調試器就會立即連接上。這大大節省了開發時間，尤其是在調試那些需要特定啟動流程或長時間運行才能復現的 bug 時。它允許你在應用運行的任何時刻開始調試，而不是每次都必須從頭開始。

Sync Project with Gradle Files 的作用

????????這個功能的作用是同步你的項目配置，確保你的代碼、資源和依賴項與 build.gradle 文件中的設置保持一致。

????????Gradle 是 Android 項目的構建系統，它負責編譯你的代碼、打包你的資源，并處理你的依賴項。你的項目的所有配置信息，比如應用的 SDK 版本、應用的依賴庫（如 AppCompat、Glide、Retrofit 等），以及構建類型等，都定義在 build.gradle 文件中。當你對 build.gradle 文件做出任何修改時（例如，添加了一個新的依賴庫，或者修改了應用的 targetSdkVersion），Gradle 需要重新構建項目以應用這些更改。

????????這就是 Sync Project with Gradle Files 按鈕的作用。點擊它之后，Android Studio 會執行以下操作：

1. 解析 build.gradle 文件：讀取你所有的配置更改。

2. 下載新的依賴項：如果你的 build.gradle 文件中新增了依賴庫，Gradle 會自動從 Maven 中央倉庫或其他倉庫下載這些庫。

3. 生成項目結構：根據新的配置，重新組織和生成項目的內部結構，使得你的代碼編輯器（比如自動補全）能夠正確識別新的類和方法。

簡而言之，每次修改 build.gradle 文件后，你都必須點擊“Sync Project with Gradle Files”按鈕，否則 Android Studio 將無法識別你的更改，你的項目可能會無法編譯。

二、git的保存方式

1.git-stash的使用

????????git stash 是 Git 中一個非常有用的命令，它允許你臨時保存你當前工作目錄中那些還沒有提交的修改（包括已暫存和未暫存的改動），然后將工作目錄恢復到 HEAD 提交時的干凈狀態。這在你需要切換分支處理緊急問題，但又不想提交不完整的修改時非常方便。

• it stash 或 git stash push: 不帶任何參數執行 git stash 或 git stash push 會將所有已修改和已暫存的文件保存起來，并生成一個默認的描述信息。

• git stash push -m "你的描述信息": 強烈推薦使用此命令。 -m 選項讓你為你的 stash 添加一個有意義的描述信息，這在你有多個 stash 時非常有用，可以幫助你記住每個 stash 的內容。

• git stash -u 或 git stash --include-untracked: 默認情況下，git stash 不會保存未跟蹤的文件（即你剛剛創建但尚未通過 git add 添加到 Git 跟蹤的文件）。使用這個選項可以包含這些未跟蹤文件。

• git stash -a 或 git stash --all: 這個選項比 -u 更強大，它不僅包括未跟蹤的文件，還會包括 Git 忽略的文件（由 .gitignore 指定的文件）。使用此選項時要小心，因為它可能會保存你不想保存的文件。

git stash list:這個命令用于查看你當前保存的所有 stash 列表。

git stash pop:這個命令用于取出并應用最近（即 stash@{0}）的 stash，并從 stash 列表中刪除該 stash。

2.stash 和 shelf 的區別

????????git stash 是 Git 版本控制系統的一個內置功能。而 "Shelve" (擱置) 通常是 IDE (集成開發環境)，特別是 JetBrains 系列 IDE (如 IntelliJ IDEA, WebStorm, PyCharm 等) 提供的一個獨有功能。

????????Stash: 是 Git 本身的功能。你可以在任何 Git 倉庫中使用 git stash 命令，無論你使用什么編輯器或 IDE。在內部：Git 將你的改動打包成一個特殊的 commit 對象存儲在 .git 目錄下，并維護一個 stash 列表。這些 stash 可以像普通提交一樣被 Git 命令行工具操作、查看、應用或刪除。git stash 默認會保存你整個工作目錄中所有已修改和已暫存的改動（包括未跟蹤的文件，如果指定了 -u 或 -a）。總結主要是Git功能

????????Shelf: 是 IDE 特定的功能。它由 IDE 管理和實現，通常無法在 IDE 之外使用或查看。IDE 通常會將你的改動保存為補丁文件（patch files）或其他內部格式，存儲在 IDE 的配置目錄中。這些擱置的改動只能通過 IDE 的界面進行管理和應用。大多數 IDE 的擱置功能允許你更細粒度地選擇要擱置的改動，例如只擱置某個文件、某個變更列表 (changelist) 或文件中的某一行改動。這在只處理部分改動時非常方便。

最后的保證：Local History 是許多現代 IDE (如 JetBrains 系列 IDE、VS Code 等) 提供的一個非常強大的本地文件版本管理功能。它獨立于任何外部版本控制系統 (如 Git)，在你的代碼發生變化時自動保存文件的快照。