java activity工作流，提高 Activity 跳轉速度

從一個頁面跳轉到另外一個頁面，這在 Android 中是很常見的操作；有的頁面跳轉是瞬間打開，有的是會微微鈍一下才打開；或者在頁面里彈出一個 Dialog 彈框，明明已經調用完了 show()方法，但彈框沒馬上彈出來，延遲了一百多毫秒才顯示出來，這樣給人的體驗就很不好了。為什么會出現這種情況呢？頁面跳轉遲鈍和彈框的展示延遲的原因都一樣，基本分為兩大類。

第一類就是看看是否在UI線程左耗時操作，這個經常是數據方面的問題，比如說要從數據庫里面查詢數據，或者說對數據做了一些復雜邏輯的操作，例如要對集合中的數據，根據bean的某些屬性做一些排序、合并等的操作，由或者需要三方sdk提供數據，結果他們提供數據的方法耗時了等等。針對上述情況，我們可以開啟一個子線程，來處理這些數據，數據處理工作完成后，再通過 Handler 來接收數據并刷新UI界面，這樣就不至于因為數據的原因而導致UI的卡頓了。

上述耗時操作如果是在 onCreate() 或 onResume() 中，必然會導致 Activity 的跳轉速度降低。ActivityThread 中已經描述了 Activity 的生命周期，通過它我們知道 UI 是在 Activity的 onResume() 之后才會繪制及顯示出來，那么問題就來了，如果在 onCreate() 或 onResume() 中耗時較多，那么 Activity 的跳轉速度肯定就慢了；同理，如果彈框的構造方法或 onCreate() 也耗時較多，那么彈框的展示速度也會被拖慢。

第二類就是布局，簡單的xml布局，很快就能被轉換為UI，但復雜的布局，比如層級比較深的，項目中就會有七八層深的布局，一個頁面的 view 加起來有50個，從 Xml 中獲取view的節點并轉為 FrameLayout、ImageView、TextView 等，是通過反射創建的，本身效率就比較低，再加上 findViewById() ，也可以想象到效率。所以針對這一點，我們可以使用 merge 、ViewStub 等，說白了，就是減少層次，延遲加載等。下面就著重說一下。

從減輕層級方法，對于復雜的布局，可以使用約束布局，這個布局很好用，是相對布局的加強版；有些布局可以通過自定義控件來合并，常見的一個線性布局里面有個文本和圖片，我們可以通過自定義view來繪制這些，減輕層級；可以直接代碼中創建view，但這種不直觀，不推薦。

java activity工作流？至于延遲加載，這個可操作的空間比較大，系統封裝的 ViewStub 就派上了用場。我們可以把同一業務的合并到同一個里面，這樣就可以把復雜的xml布局分割成幾小塊，我們在根布局中可以只保留一個 LinearLayout ，其他的用 ViewStub，這樣就相當于 xml 中只有這么一個控件，初始化起來速度就相當可觀了。在 Activity 中，我們可以使用

? ? ? ? getWindow().getDecorView().post(new Runnable() {@Overridepublic void run() {initView();}});

這個 Runnable 中的 run() 方法，會在布局初始化完畢后，馬上執行，這樣就可以在 initView() 中執行 ViewStub 的邏輯了。這樣做會導致UI山一下，畢竟這相當于是往空白的容器里添加控件，為了提高體驗，可以在跟節點 LinearLayout 中添加一個蒙版View，等 ViewStub 中代碼執行完畢后，再把這個蒙版給remove掉，這樣就沒那么突兀了。

在一些app中也看到過蒙版，主要作用就是上面描述的，其次是為了UI美觀。以前一個項目中，產品童鞋看這個蒙版比較好看，直接讓我們抄過來，至于它背后的產品邏輯，蒙版的作用及出現的動機，完全不管，抄東西也就只能抄個外形，抓不到精髓。深層次的東西，往往是被重重隱藏的，不會輕易被其他公司的人給抄去。
?