動筆前先答（兩題）

1.【決策邊界｜取捨與交付】 舊 App 有 21 個 Activity、135 個 Fragment，路線圖估計還剩約 80 個畫面要搬。目前定好的事有三件：

• 新 App 保留舊 App 的 applicationId，Play 上的身分不變。
• 功能對齊之前，新 App 只給作者與維運工程師測試。
• 重寫期間，舊 App 只修 crash。

剩下的畫面怎麼搬、什麼時候讓使用者換過去，有三個選項：

• (A) 功能對齊才換：全部畫面搬完，用同一個 applicationId 一次覆蓋上架，用 Play 的分階段發布控制拿到新版的人數比例。
• (B) 先給一小群使用者試用：用另一個 applicationId 的建置，跟舊 App 裝在同一支手機上。新 App 只做核心配送流程，其他功能請他們回舊 App 做。
• (C) 縮小「對齊」的定義：用同一個 applicationId 上架，但先拿掉一批少用的畫面，或改成網頁。上線後再補，或永遠不補。

不看下面的大綱，依序回答：

1. 優先序：約 80 個畫面要怎麼排？寫出你會用的三個排序依據，以及每個依據的資料從哪裡來。如果手上沒有使用量資料，在「舊 App 只修 crash」的前提下，你還能從哪裡拿到？哪些畫面你會判定「不搬、直接刪」？門檻是什麼？
2. (A)、(B)、(C) 各在什麼條件下成立？寫出會讓你從 (A) 改成 (B) 或 (C) 的條件。(A) 的「功能對齊」由誰驗收？驗收清單從哪裡來？
3. 假設選 (B)。同一位使用者在兩個 App 都登入了，後端會怎麼看待？推播會送到哪一個 App？同一張單在兩邊各操作一次，會發生什麼事？哪幾件事你要先問過後端，才敢選 (B)？
4. 退路：新版上線後出了嚴重問題，你要怎麼讓使用者回到舊版？Play 的分階段發布能做到什麼、做不到什麼？versionCode 要怎麼排，才留得住退路？
5. 賽後時程：拿 Day 01–12 實際做出來的量，估剩下的畫面要多久。這個估法在哪裡會失準？Day 01 說重寫期間舊 App 只修 crash，這個承諾你願意撐多久？到期時還沒對齊，你怎麼辦？

最後用兩句話收尾：你的結論，以及你願意承認的代價。

我的回答：（待補）

2.【預測再驗證｜持久化與離線】 新 App 沿用舊 App 的 applicationId，所以使用者更新時是「覆蓋安裝」：舊 App 留在手機上的資料，新 App 都看得到。現在的傾向是舊資料整批不搬，包括還沒上傳的照片、錄影和配送暫存；但另一條已定的規則是「證據照片不可直接刪檔」，兩者有衝突，正式決定要等到這項動工時才做。

準備一支測試機，用一份舊版的 dev 建置製造出下列狀態：

• 已登入、打過上班卡。
• 開飛航模式拍一張配送照片，讓它停在待上傳。
• 推播權限、定位權限、相機權限都允許。

然後用新 App 的 dev 建置覆蓋安裝。下面每一項先寫預測與依據，再驗證。驗證工具：adb install -r、adb shell run-as <package> ls -R、adb shell dumpsys package <package>、系統設定裡的 App 資訊頁。

1. 覆蓋安裝會成功嗎？如果失敗，最可能被哪一項擋下來：簽章、versionCode，還是別的？這一項在 dev 建置和正式上架時，答案一樣嗎？
2. 安裝成功後，在新 App 還沒啟動前，shared_prefs、files、cache、外部儲存的 App 專屬目錄裡，舊 App 的檔案各還剩哪些？那張待上傳的照片在哪裡？
3. 權限：舊 App 拿到的三個執行期權限，新 App 一開就有嗎？如果新 App 的 manifest 少宣告一個（例如背景定位），那個權限會怎樣？舊 App 建立的通知頻道，在系統設定裡還看得到嗎？新 App 要不要處理它們？
4. 舊 App 留下的背景排程工作（如果有的話），以及推播服務那邊的裝置綁定，覆蓋安裝後會怎樣？新 App 第一次啟動時，會不會撞上舊 App 留下的東西？你要用什麼方法確認？
5. 驗證完，回頭看「整批不搬」的傾向：
   • 那張待上傳的照片，在新 App 裡是什麼命運？使用者看得到嗎？它會在什麼時候、被誰刪掉？
   • 要做到「不違反證據照片不可直接刪檔」，最少要做什麼？最少只是「保留檔案」，還是一定要「接手上傳」？
   • 把你的答案寫成一條驗收條件，並說明這條是覆蓋安裝的實機驗證才抓得到，還是 JVM 測試也抓得到。

最後回答：哪些舊資料，你寧可讓使用者多登入一次、或重做一次，也不搬？哪一項不搬的代價，你不願意讓使用者承擔？

我的回答：（待補）