剛開始學android的時候，對於fragment的切換問題，理所當然的使用FragmentTransaction中的replace方法來解決，但是這個方法時非常低效的，我們先來看官方文件對於這個方法的介紹：

replace

Replace an existing fragment that was added to a container. This is essentially the same as calling  for all currently added fragments that were added with the same containerViewId and then  with the same arguments given here.

簡單的翻譯一下：替換一個已經被新增進容器的fragment，其本質與對所有已經新增進同一個id的容器（xml檔案中的FrameLayout）的fragment呼叫remove(Fragment)方法然後呼叫add方法想要替換的fragment是相同的。

可以看出，呼叫replace的話，會先將原本處於容器中的fragment全部丟掉，然後再新增一個新的fragment，這樣在每次replace的時候就會進行一次初始化，非常低效

     if (fragment == null) {
            fragment = ActionFragment.newInstance();
        }
        FragmentTransaction transaction = getActivity().getSupportFragmentManager().beginTransaction();
        transaction.replace(R.id.content_frame_card, fragment);
        transaction.commit();

這段程式碼就是使用replace方法，我們在android monitor中看執行的時候瘋狂點選切換的話記憶體會怎麼樣

可以看到，一開始記憶體的上升速度很快，雖然期間有GC工作，但是對於整個上升的趨勢並沒有很大的影響，後面停止點選記憶體趨於平穩，最後我手動呼叫了幾次GC，記憶體迅速下降，雖然沒有導致記憶體洩漏的問題，但是毫無疑問這個辦法是很低效不可取的方法。

那麼圖和解決呢？我們可以參考點選開啟連結這篇文章中的解決方法，採用hide和show來實現fragment的替換

public static void replaceFragment(FragmentManager manager, Fragment to, int fgmId) {
        FragmentTransaction transaction = manager.beginTransaction();
        //遍歷隱藏所有新增的fragment
        for (Fragment fragment : manager.getFragments()) {
            transaction.hide(fragment);
        }
        if (!to.isAdded()) { //若沒有新增過
            transaction.add(fgmId, to).commit();
        } else { //若已經新增
            transaction.show(to).commit();
        }

    }
 

可以看到這一次在快速連續點選切換的情況下，記憶體沒有明顯的上升，上升趨勢非常緩慢，且後面手動進行一次GC即可，這種方法很好的解決了replace的低效問題和切換時候的重疊問題