起因：

由於在最近接手了一個關於導航的App，發現地圖頁面跳來跳去實在是卡頓地不行（執行在車載裝置上的APP，機器效能實在是有限）。

初步判斷：

應該是是關於地圖等控制元件的反覆建立和銷燬，給記憶體GC帶來了很大的壓力。

簡單調查：

通過 命令 adb shell dumpsys meminfo com.xxxx.xxx  (後面那個是包名，當然你可以使用MAT等工具來看) 

帶有地圖控制元件的頁面之間跳來跳去，大量物件沒有及時被回收，導致記憶體佔用過高

解決方案：

利用Fragment來抽離各個有MapView的Activity中的業務邏輯，留下一個MapActivity就專門負責地圖業務邏輯的效果展示；

這樣多個帶地圖控制元件的Activity頁面，就可以複用首頁的地圖控制元件即可，這樣就可以複用地圖控制元件這樣的大物件了

上圖，僅僅做了一個涉及到地圖業務的優化（搜尋頁面），就少了10多M，效果還不錯，目前在首頁和搜尋頁面來回切換也都流暢許多了

探索高德地圖：

有了上面的解決方案後，我就猜想高德地圖可能也是這麼幹的，因為從首頁到線路規劃，再到導航，都是用了地圖控制元件，那也是肯定是地圖複用，才能減少大物件的建立和銷燬

通過命令來：adb shell dumpsys activity | grep -i run    檢視當前執行的activity，無論我在高德地圖中怎麼跳轉，始終都是NewMapActivity，因此更加印證我的猜想

通過ui automator viewer 工具，看到了id為：fragment_container的全面覆蓋頁面的控制元件，id名稱字面意思大家肯定都知道了，就是一個裝fragment的容器

我也反編譯了高德APK的程式碼，裡面確實也是通過Fragment來實現多個頁面的跳轉和切換的

總結一下

在日常開發中，能複用的程式碼或者說是元件，能複用的就儘量複用，不要反覆建立和銷燬物件，那樣真的很消耗系統資源；特別在後臺開發中，高併發場景中更是如此，當然還要處理好多執行緒的問題，在移動端的開發中，多執行緒的問題還是比較好處理的。