優(yōu)化 UI 應(yīng)用啟動時間的方法

優(yōu)化 UI 應(yīng)用啟動時間的方法：

• 懶啟動：

  將與啟動主界面無關(guān)的代碼安排到啟動之后再執(zhí)行?？梢允褂枚嗑€程技術(shù)來低耦合地達到這一點。

• 使用緩存、池技術(shù)：

  某些事項如網(wǎng)絡(luò)連接、數(shù)據(jù)庫連接等往往有如下特點：單次來看，不算特別耗時，但連續(xù)重復(fù)執(zhí)行這種操作時，累積的時間還是非?？捎^。對于這種操作，如果需要連續(xù)重復(fù)執(zhí)行，可以考慮使用如下技術(shù)：

  • 緩存技術(shù)：只有第一次請求資源時是真實的請求，同時將這第一次請求的資源緩存。然后以后請求資源時都是從此緩存中讀取數(shù)據(jù)。不過要注意，使用此技術(shù)要考慮臟讀的問題。
  • 池技術(shù)：事先先在空閑時間中預(yù)建立一些連接或申請一些資源，這些資源不會在未來被使用完后立刻丟棄，而是不斷回收重復(fù)使用。這樣到以后真正請求多次資源時，可以減少請求的總成本。

• UI 代碼與非 UI 代碼分離：

  將與 UI 界面元素顯示無直接關(guān)系的代碼從 UI 線程 中剝離。不要將這些代碼放到 UI 線程、UI 線程安全函數(shù) 中執(zhí)行，應(yīng)該新建線程來執(zhí)行這些無關(guān)代碼。

• 鎖粒度檢查：

  減少上鎖的個數(shù)、次數(shù)與粒度。能用 volatile 就不要用鎖，能鎖局部就不要鎖方法。

• 使用 Thread.sleep(0) 來觸發(fā)線程調(diào)度：

  • 在多線程同步中，可能需要設(shè)定一個非阻塞請求循環(huán)來不斷請求某資源。這種請求有可能會大幅度占用 CPU 資源，抑制其它線程的執(zhí)行，從而導(dǎo)致短期死鎖。應(yīng)該在這種請求循環(huán)中插入方法 Thread.sleep(XXX) 來讓出此線程的 CPU 使用權(quán)，從而使其它線程得以過多地執(zhí)行，來結(jié)束這種短期死鎖。

• 普通的時間優(yōu)化檢查：

  • 能重用同一個變量就盡量重用，不要每次都新建一個變量。

    • 能用單例模式就盡量使用單例模式。

    • 將循環(huán)中的變量創(chuàng)建移動至循環(huán)之前創(chuàng)建。

• bug 檢查：

  • 記錄多線程執(zhí)行時的時間日志信息，用于排錯。

  • 對多線程、鎖的邏輯進行檢查，避免短期死鎖。

    • 一般說來，如果各個并發(fā)線程相互獨立，應(yīng)該會具有不可再現(xiàn)性。將應(yīng)用多次運行時，這些線程啟動的先后順序?qū)⒉煌?/p>

      如果發(fā)現(xiàn)實際上并不是這樣，這些線程每次啟動的先后順序都是一樣的，說明這些線程中可能有某種依賴關(guān)系。有某種依賴關(guān)系意味著這些線程不能充分的并發(fā)執(zhí)行，從而影響多線程的效益、降低應(yīng)用運行效率。如果這些依賴關(guān)系本不應(yīng)該存在，那就說明應(yīng)用的代碼邏輯有問題。有某種依賴關(guān)系有可能源于上鎖。應(yīng)當(dāng)排查這些線程的內(nèi)部運行機制。

  • 檢查是否有冗余代碼、重復(fù)代碼。

    • 在項目較大時，常常會出現(xiàn)反復(fù)初始化、過度封裝、過度執(zhí)行為保證安全的冗余代碼。應(yīng)該仔細排查、重構(gòu)這些代碼。

總結(jié)

以上是生活随笔為你收集整理的优化 UI 应用启动时间的方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。