Android - 重複片段交易和電話資源（複雜）

前言 - 我創建的代碼到目前爲止已經提供了所需的用戶界面，我的問題是關於手機資源以及是否存在「更好」的實現。另外，我對Android開發相對較新，可能會誤解一些基本概念。Android - 重複片段交易和電話資源（複雜）

我正在開發帶有選項卡的應用程序，並且一些選項卡有多個視圖。目前，每個視圖都由片段管理，當用戶在選項卡上並打開新視圖時，視圖會水平轉換。

（該應用程序是現有iPhone應用程序的Android端口，儘管我工作的人員很容易理解需要將Android應用程序製作爲儘可能原生Android的應用程序，但他們需要基本的用戶界面和控制保持不變，這樣，如果iPhone用戶購買了Android手機併購買了其應用的另一個副本，則不存在根本性差異）。

然而，主選項卡不同 - 它會自行重新加載。該應用程序本質上是一個學習助手;想象一下，每個視圖都是代表信息的卡片，以及用戶是否翻閱卡片。

這是通過讓'卡片'片段請求片段管理器分離然後重新附加它自己來完成的。這是通過調用在執行所述FragmentActivity的方法來實現以下的（從實際的代碼簡化）：

FragmentTransaction ft = .... .beginTransaction(); 

ft.setCustomAnimations(int out,int in) 
ft.detach(relevantFragment); 
ft.attach(relevantFragment); 

ft.commit(); 
.... .executePendingTransaction();

其中 '出' 是fromXDelta = 「0」，toXDelta = 「 - 100％」

and'in'isXDelta =「100％」，toXDelta =「0」

因此，舊視圖向左滑出，同時新視圖從右側滑入。

這工作得很好，事實上就用戶體驗而言，它正是我想要的。然而，我們正在重新加載的片段具有複雜的視圖層次結構，我對片段的理解是整個事情將在每次轉換時被垃圾收集和重新實例化，用戶可能很容易調用大量次（100+），同時使用應用程序進行學習。

幾乎所有我讀過的東西都表明我應該避免沉重的對象創建/收集，因爲它會導致我的應用程序吞噬用戶的電池，而不管處理器是否足夠強大，無任何視覺滯後。

。

實際問題：有什麼辦法來模擬這種行爲不強制手機完全破壞並重新創建每個視圖秒爲用戶點擊瀏覽的看法？

事情我已經考慮：

消除交易/動畫，只是有段負荷的新信息。這當然很容易，但不是我的僱主想要的。
在XML中創建視圖層次結構的兩個相同副本，並使用自定義ScaleAnimation嘗試模擬此行爲，從View.VISIBLE和View.GONE來回切換它們。我不確定這是否會起作用，但乍一看似乎相當......馬虎。
這是一個不必要的和/或愚蠢的優化，我不應該擔心，由於手機和/或Android系統的運作方式，我根本沒有意識到我在浪費時間。

任何有關操作系統工作方式的建議，建議或說明都會得到很大的讚賞。

來源

2012-03-25 HeMightBeTodd

我片段的理解是，整個事情將是垃圾收集，如果你看一下你的代碼上的每個過渡

重新實例化，這是不可能的，至少在片段水平。您不會放棄Fragment對象，也不會爲Android創建全新的相同片段提供一些手段。因此，Fragment將不會被垃圾收集。

可以想象，Android會爲您的片段再次調用onCreateView()並丟棄舊視圖，儘管這似乎不太可能。您可以通過設置斷點或添加日誌記錄來測試這一點。

幾乎所有的東西我已經閱讀指示我應避免重物創建/集，因爲它會導致我的應用程序來吞吃了用戶的電池

完成了數百萬次，絕對。完成「100+」次，它不會「吞食」電池。也許是輕咬一口。

事情我已經考慮：

我會專注於＃3。至多，確定片段的視圖層次結構是否被重新創建，以多次調用onCreateView()的形式。如果是這樣，那麼使用Traceview來確定這個操作消耗多少時間。

來源

2012-03-25 18:28:50 CommonsWare

感謝您的回覆。 onCreateView（）毫無疑問每次附加片段時都被調用，而不依賴於它作爲單個對象被實例化的事實。大部分設置視圖的業務都是在onCreateView（）中完成的，如果沒有調用，我會轉換到包含與前一個相同信息的新視圖。這由代碼中已經存在的各種日誌記錄來證實。我會結帳Traceview。（然後可能只是不用擔心） – HeMightBeTodd 2012-03-25 18:51:49

@HeMightBeTodd：然後你可以嘗試自己緩存視圖。我期望'Fragment'做到了 - 它確實在'setRetainInstance（true）'路徑中。 – CommonsWare 2012-03-25 19:04:39

經過幾次測試後，它看起來像片段數據更新和視圖轉換的總時間，大約70％的包含CPU時間被ViewRoot使用。performTraversals（），在onCreateView（）中佈局通貨膨脹期間調用要求最高的子ViewRoot.draw（）（父代的80％）和View.measure（）（父代的15％）。這與直接與我的應用程序直接相關的最昂貴的業務邏輯相比，2個對SQL數據庫的調用佔用了3.5％的時間。 – HeMightBeTodd 2012-03-25 19:50:34

總結與CommonsWare在上述評論（以及隨後調查解決此問題的方法）中的討論，這不是一個有效的優化。保留視圖層次結構以供重用，而不是允許它被銷燬和重新創建，只會節省幾毫秒的CPU時間。絕大多數是通過手機呈現視圖而不是實例化來消耗的。

CommonWare在他的初始答案（大部分）中是正確的。每次附加片段時都調用Fragment.onCreateView（），但沒有有效的方法來優化視圖渲染。沒有什麼可以做的，沒有什麼可擔心的。

來源

2012-03-26 01:47:37 HeMightBeTodd

Android - 重複片段交易和電話資源（複雜）

回答

相關問題