一、後台執行
這是一條很通用，也容易理解的方法。使用者不會願意盯著進度條傻傻地等待，除了「取消」沒有其他選擇。在系統處理一些網路任務的時候，完全可以允許使用者做一些其他的事情。
二、在載入前顯示內容
客戶端與web的乙個不同點，客戶端的顯示內容包括本地資料和網路資料兩部分。在設計介面時，將更多的資訊放在本地，在網路資料未載入時即顯示本地資料，讓使用者產生一種「已經載入一半了」的錯覺，即使最終的耗時一樣，心理感受也會更快。當然把資料過多地寫在本地，會犧牲一些靈活性，需要根據具體情況考慮。
三、充分利用好快取
四、介面先行，網路互動隨後
五、**使用者行為，提前開始任務
使用者在某個介面停留的時候，**下一步可能做abc三個任務，系統於是把這些任務都提前做完。當使用者做出選擇比如a時，介面可以迅速響應，並且同時把bc兩個任務從記憶體中清空掉以節省資源。當然，這種會花費使用者的額外瀏覽。
六、使用動效來掩護載入過程
優秀的動效設計，讓產品更好用且讓人眼前一亮。其實，動效還有另一大用處，吸引使用者的注意，讓本來枯燥的等待載入的過程，變成愉悅欣賞的過程。
報表查詢速度優化建議
今天老闆要求說，報表查詢速度太慢了，需要優化。怎麼搞呢?嘿嘿，有幾種常見方法。計算前置 我先提前算好，你到時候看到的只是我的統計結果 優點 速度快 缺點 需要額外建表和儲存空間 靈活性沒有寫sql 改sql來的快，擴充套件性不強，適用於需求變更不大 對查詢速度有較高要求的報表。換db和儲存介質 不是...
c c 程式優化幾個建議
第一 記住，寫完後一定要做一下系統優化，無論上面是否這樣要求，但是這點很重要，是一種態度，當然優化可以借助各種工具如ibm和intel系列的優化工具，一般80 的時間被20 的 所占用。第二 如果你所在公司，對程式效能優化不重視，那麼就請跳槽吧。第三 要知道你所用編譯器是怎麼去優化多維陣列訪問的，如...
語言的速度優化
for 語句可能是我們最常用的。大家習慣可能是這樣。比如對乙個資料屢遍 for int i 0 i這樣寫有什麼不好呢？先看下面這段 for int i 0,len array.length i顯然兩種寫法的效果一樣 但是就第一種寫法而言 迴圈中不得不對記憶體的兩次查詢 首先在當前作用域中查詢到arr...