一個安卓或iOS應用程式之前發送的請求指向A域名，現在需要更換B域名，有沒有比重新打包安卓更好的解決方案

重新打包的話，用戶不一定會更新應用，所以這個方案不太好

當然，最好是設計之初就將安卓應用請求的域名不定死，那麼這樣又該怎麼解決？也就是能否下載一段程式碼覆蓋本地的程式碼，這樣是否有安全性問題？

回覆內容：

重新打包的話，用戶不一定會更新應用，所以這個方案不太好

當然，最好是設計之初就將安卓應用請求的域名不定死，那麼這樣又該怎麼解決？也就是能否下載一段程式碼覆蓋本地的程式碼，這樣是否有安全性問題？

可以，你讓寫介面的人，在a域名發個請求到b域名，拿資料回傳給你，哈哈，我想問一下，重新打包很麻煩嗎？不懂行動開發

可以在啟動app的時候請求一次後台資料。設定一個標籤，如果為1則載入A位址，如果為0載入B位址。

如果你已經有上線的應用出現這個情況。那麼基本上只有一個解決方案：那就是讓後端的開發人員辛苦一下，把發送到A點的請求都redirect去B點，並回傳回應的資料。 注意：這些資料的格式最好不要出現不必要的變化。否則，容錯不夠的話會出現Crash的情況。

當然應用本身也有解決這個問題的方法，但是需要事先已經在架構上做好這樣的設計。例如iOS和Android都有熱修復的一些實作技術。如果你的APP都已經有這樣的架構，那麼可以在server端放上開發好的補丁，讓APP請求B點數據，APP自動把這些補丁下載並套用到APP本身。那麼APP自動就可以請求B點資料了。

兩種情況權衡一下的話，你會發現如果B點已經開發完畢。那麼第一個方案是最省事，也是最快的。

1、服務端角度：讓服務端的同學配置好nginx，分分鐘的問題
2、App角度：網域的變更應該不會很頻繁吧，個人覺得用推送的方式下發，然後app端保存；或者，準備一個藉口用於獲取域名的

看起來服務端解決起來更省力

重新打包，打個包裝分分鐘，只不過需要用戶更新