怎麼說呢~~一個是“應用級別提供返回功能”，一個是“系統級別提供返回功能”說的通俗點，手機app的上下層頁面關係就有點像web網頁的前一頁後一頁的那種關係。安卓提供的方法是瀏覽器包含一個返回按鈕(或者有快捷鍵)可以從瀏覽器層面發起這個返回操作。iOS的的搞法就是本身並不提供返回上一個頁面這個操作，而是要求開發者製作的每一個網頁都自帶一個返回上一個頁面的連結(按鈕，途徑……等等叫法)那麼區別就在這裡，頁面自帶的「返回」自己當然清楚的知道要返回到的頁面的地址是什麼？(app裡面基本就描述成記憶體當中的某一段地址的資料)。那麼系統級別的返回如果CPU剛好正在專注處理當前頁面當中的一些任務，那麼有很大機率CPU快取會被處理這些任務的資訊塞滿。當你突然之間返回操作的時候，CPU並不一定知道當前頁面的上一個頁面資料儲存在哪一段地址裡……那麼它所要做的操作就是去詢問app我應該到哪裡去讀取上一個頁面的記憶體地址資訊，或者去翻找系統裡的歷史記錄。這裡就多了一部或者幾部操作了~~~如果加上各種中斷延遲app又沒有對這個操作做專門的最佳化(不是很多時候app還會在這個時候要求記錄甚至傳送一些周邊資訊資料已獲得分析使用者發起這個返回操作的原因)那麼的確很有可能這個過程就有可能被放大到操作者可以感知到的程度。反正我在使用過程中的確也觀察到有些app無論什麼時候返回依然流暢，順滑。但是也有一些app，特別是不少流量很大很熱門的官方應用反而這方面的問題異常嚴重~~~說的好聽也只能說這些官方app做的是在不夠純粹。說的不好聽點就是執行的流氓操作太多……

反正我一直這樣認為以後也會這樣認為。安卓的大部分讓你不舒服的地方都是有應用導致的，安卓系統是沒錯的，錯的是那些用不恰當方式過多的挖掘使用者行為的應用開發者。其實你去用幾個諸如第三方微部落格戶端這樣的應用就知道問題的所在了……

怎麼說呢~~一個是“應用級別提供返回功能”，一個是“系統級別提供返回功能”說的通俗點，手機app的上下層頁面關係就有點像web網頁的前一頁後一頁的那種關係。安卓提供的方法是瀏覽器包含一個返回按鈕(或者有快捷鍵)可以從瀏覽器層面發起這個返回操作。iOS的的搞法就是本身並不提供返回上一個頁面這個操作，而是要求開發者製作的每一個網頁都自帶一個返回上一個頁面的連結(按鈕，途徑……等等叫法)那麼區別就在這裡，頁面自帶的「返回」自己當然清楚的知道要返回到的頁面的地址是什麼？(app裡面基本就描述成記憶體當中的某一段地址的資料)。那麼系統級別的返回如果CPU剛好正在專注處理當前頁面當中的一些任務，那麼有很大機率CPU快取會被處理這些任務的資訊塞滿。當你突然之間返回操作的時候，CPU並不一定知道當前頁面的上一個頁面資料儲存在哪一段地址裡……那麼它所要做的操作就是去詢問app我應該到哪裡去讀取上一個頁面的記憶體地址資訊，或者去翻找系統裡的歷史記錄。這裡就多了一部或者幾部操作了~~~如果加上各種中斷延遲app又沒有對這個操作做專門的最佳化(不是很多時候app還會在這個時候要求記錄甚至傳送一些周邊資訊資料已獲得分析使用者發起這個返回操作的原因)那麼的確很有可能這個過程就有可能被放大到操作者可以感知到的程度。反正我在使用過程中的確也觀察到有些app無論什麼時候返回依然流暢，順滑。但是也有一些app，特別是不少流量很大很熱門的官方應用反而這方面的問題異常嚴重~~~說的好聽也只能說這些官方app做的是在不夠純粹。說的不好聽點就是執行的流氓操作太多……

反正我一直這樣認為以後也會這樣認為。安卓的大部分讓你不舒服的地方都是有應用導致的，安卓系統是沒錯的，錯的是那些用不恰當方式過多的挖掘使用者行為的應用開發者。其實你去用幾個諸如第三方微部落格戶端這樣的應用就知道問題的所在了……