在手機上顯示圖片，速度是一個很是重要的體驗點，試想。假設您打開一個站點，發現裏面的圖片一直顯示失敗或者是x。略微作得好一點的，多是一個不消失的loading或者是菊花等等，但不管怎樣， 沒能高速的拉取和展現圖片對用戶體驗是一個極大的挑戰。那麼，手機上的圖片體驗怎樣作呢？這裏筆者有些小總結：
1，下降圖片的大小。
在失真度和圖片大小中作好折衷，儘可能利用工具下降圖片的size，也可以考慮利用不一樣的圖片格式。css
2。下降圖片的請求數。可以考慮把多個圖片利用類似css sprite的方式進行合併，這樣可以載入一次就能夠；
3。考慮緩存。對圖片在client進行必定的緩存，設置好緩存時長和更新機制。
4。考慮使用cdn進行載入圖片。作到就近接入訪問。
5。解決DSN劫持的問題。在手機業務上的經驗告訴咱們，很是可能某些地區，某些運營商把咱們的域名封掉或者劫持了。這樣，圖片的域名解釋出來的IP卻不是咱們提供圖片服務的IP，並且這樣的狀況很是難發現， 因爲。假設運營商經過抽樣隨機劫持，就很是難發現。html
解決的方法可以：
前端
.去掉dns，改爲直接訪問IP的方式，但需要解決依據用戶的ip獲取近期圖片服務的ip地址，實現上：這裏cgi在吐出訪問圖片的地址的時候，獲取用戶的來源網關IP，調用IP地址庫推斷來源IP所屬地和運營商。而後下發相應的圖片部署接入IP， client使用IP直連圖片服務器，高速的訪問資源。算法
問題是，有實現成本，得業務本身去實現類似一個dns解釋的邏輯，特別是圖片放到cdn的話，這樣改造就沒法使用cdn帶來的加速服務能力。後端
.作好dns劫持的監控。實際上圖片dns解釋到的vip list確定是在咱們的一個白名單內。假設不是，則確定屬於dns劫持，client可以在某個時候拉取一下咱們的vip list。做爲監控和推斷是否dns劫持的問題，假設dns的ip地址 不在白名單內。則替換使用白名單內的ip進行訪問。
.考慮備用域名的方式。即假設一個域名拉取不到，改用備用域名進行訪問。固然假設備用域名也被劫持，那就不行了。緩存
二，優化後臺的架構
後臺返回越快，前端的體驗就越好，所以，也需要對後臺服務的調用鏈進行梳理。避免循環調用，快慢混雜等問題。主要的原則比較簡單，都是一些設計方面的原則
1。輕重分離。服務中把訪問量大，需要速度快的服務和訪問量小，但業務邏輯複雜的流程從代碼實現和物理部署上進行完全分離。如用的接入cgi（甚至不一樣的域名），不一樣的後臺server。不一樣的集羣進行隔離。
假設放在一塊兒。慢的會拖住快的，這就像木桶原理同樣，終於的速度是由最慢的決定的，假設處理很差，可能致使整個服務阻塞不可用。
2，評估好業務的訪問流程和路徑設計。區分關鍵路徑和非關鍵路徑，設計上儘可能考慮把關鍵路徑轉換爲非關鍵路徑，關鍵路徑需要有多級容災的考慮，非關鍵異常需要有監控。
3，考慮異步化。異步化相比同步的實現來講略微複雜一些，或者說需要作的工做可能多些，但異步化的優勢也會很是明顯，特別是需要高性能的業務流程。常見的異步化實現策略是藉助mq做爲各個系統的緩衝， 生產者進程或者子系統把消息寫入mq就能夠立刻返回，而消費者進程或者子系統則定時從mq讀取消息繼續處理，並且把處理的結果經過回調通知或者寫入返回mq給到生產者查詢。固然，假設生產者是不關注結果的。那 就更加簡單了，丟到mq後就能夠，這裏的問題是整個mq是整個業務流程的關鍵。需要確保服務的高度可用和性能。
4，一些配置的動態載入，本地化存儲，加上基於版本號的更新機制。安全
筆者也發現過有些業務cgi之因此在較少請求量的時候就出現了較高的負載，終於不得不用不少其它的機器來承擔相應的請求量。定位終於緣由是cgi在啓動的時候需要載入 很是多配置的東西，甚至很是多配置並不是該cgi需要的，優化思路是：是按需載入。僅僅載入該cgi需要的；提早載入配置到共享內存。同一時候添加版本號號，維護好cgi自身進程的私有版本號和共享內存的版本號。cgi啓動的時候比較版本號號，發現不一樣。則 真正進行文件的又一次Load到內存。另外一種模式是採用配置中心進行推送的模式。實現集中管理。服務器
5，作好外部依賴的管理。微信
一個業務流程可能每每要調用到外部的系統，並且這些系統可能不是大家團隊維護的，假設該系統是非關鍵路徑還好，假設是關鍵路徑，那麼作好對外部依賴的管理就顯得更加劇要了，那麼怎樣作好外部依賴的管理呢？
這裏有幾個小的tips:
cookie
. 對外部調用的服務單獨進行封裝。如設計單獨的proxy去調用外部的服務。這樣的優勢是方便集中監控和容災邏輯等處理，在設計上把外部因素進行物理隔離的第一步，興許假設外部系統的協議或者ip地址得發生變化，則可以僅僅改動該模塊就能夠 高速修復；
. 嚴重建議對外部接口進行錯誤和超時的監控，一旦出問題，提早預警並高速解決，這裏是有血的教訓的，某業務和某平臺提供者兩方在糾結是誰的問題上吵得不可開交，不知道是誰的問題。業務說本身沒問題。平臺方說本身的服務也很是快，假設 你可以拿出你的監控數據。接口超時設置是 1s, 超時的記錄有n條，時間是ns。錯誤的記錄有m條，主要錯誤類型是xxx。那對高速定位是很是有幫助的。
. 考慮可否夠弱化爲非關鍵路徑？有些調用多是否沒法弱化爲非關鍵路徑的，如登陸態校驗，失敗了僅僅能是業務流程終止，給用戶返回失敗（固然可能存在部分業務緩存session id做爲異常的時候的備用，但這個不是很是建議，緣由很是easy，可能致使入口 不惟一。甚至形成安全漏洞，這裏需要詳細案例詳細分析）。有些路徑是可以設計爲非關鍵路徑的。如數據上報。
假設知道某個服務是關鍵路徑。比方在支付前的請求billno_server獲取惟一的訂單號，從業務流程看。這個確定是一個關鍵路徑，沒有訂單號就沒法下單，業務流程運行不下去，但假設每次下單都調用一次billno_server生成 一個訂單號，偶爾的網絡超時或者失敗都是可能的，而對用戶來講，就是這次下單提示你們都很是熟悉得不能熟悉的一句話：「系統繁忙。請稍後再試」。那麼可否夠作得更好呢？或者至少下降這樣的機率呢?
一種思路是每次請求一批billno緩存到本地進程空間， 而後使用的時候先從本地緩存中取，沒有了再去請求。一種是請求失敗的時候。可否夠考慮用本地隨機生成一個。在極端狀況下弱化對該關鍵路徑的依賴？
6。考慮到手機client的計算能力比較弱，在設計上是否把計算成本不少其它的往服務端移動，利用強大的服務器端計算能力提高用戶體驗，這一點也是微信架構設計給筆者的一個感覺。
三，優化連接
怎樣管理連接是一個老生常談的話題了，這裏主要長鏈接和短鏈接的問題。
固然另外一些什麼鏈接池等策略。
弱網絡環境下，創建連接的時間很是長，網絡質量測試數據顯示。創建連接佔用耗時接近1/3，走短連接又致使連接頻繁，因此考慮將短連接改爲長連接。在碎片時間內反覆利用，下降建鏈耗時。此外。還有下面幾個優勢：
1，C/S的持續連接使得後端可以主動push重要數據到client，好比實時的通知。新數字提醒等等。能很是好的改善體驗，在短連接的狀況下，僅僅能依靠client進行定時輪詢，不可避免的使新數據有所延遲。
2，進一步節省短連接過程當中的包大小，短連接狀況下，每次來回請求，都不可避免需要帶上一些公共數據。
長連接僅僅用在建連接成功後的第一個包中上行這些數據。興許包則可以省掉這些字段，進一步下降流量。
3。長連接還能有效的下降流量限制類手機軟件致使服務不可用的問題。有些流量限制類軟件會接管用戶的所有網絡請求。以達到流量計算和斷流的目的，這樣的本質上就是一種劫持。使用長連接+私有加密協議， 可以使得對方沒法準確分析包狀況，下降劫持到來的服務不可用狀況。
注意：使用長連接的時候。一定有長連接過時不可用的狀況。所以。業務實現需要埋入重連機制。
四，基於網絡質量的多級服務設計
手機的網絡環境比較多樣，如wifi, 3G, 4G 還有2G等。不一樣的網絡環境的體驗是不一樣的，對很是好的網絡環境咱們就不說了，關鍵討論一下在2G等比較惡劣的狀況下的一些思考。
1，不一樣的網絡環境是否具有多級的服務能力？如針對2g網絡的用戶。顯示的內容更少? 圖片變成文字？一些功能入口不可用？
在網速很是慢的狀況下，包的大小相當重要，直接影響成功率。可以考慮更加緊湊的協議（包含沒必要要的字段不發送）+壓縮算法。
這裏有個tips。你們知道cookie的內容都是每次跟在http請求一塊兒發送給到服務器的。 對圖片，js，ccs等建議部署其它域名進行cookie隔離，這樣也可以下降必定的包大小。