2013-02-02 69 views
-2

現在我想讓應用程序顯示服務器的圖片,但發現它是如此緩慢,使圖片出來。有什麼方法或代碼可以使http請求更快嗎?有沒有任何方法或代碼使http請求更快?

+3

獲取更快的網絡? :) –

+0

更好的網絡或智能緩存:) – AndrewShmig

+3

HTTP並不神奇,iOS也不是。沒有'make_this_faster()'函數。 – 2013-02-02 07:32:43

回答

4

從不同角度處理問題。認爲它是一種熵/經濟的東西。

在描述的問題中存在兩個問題,他們希望在它們之間傳輸數據。假設這將花費100個單位在理想條件下實現。再次讓我們假設不可能進一步降低這個成本。這個成本是傳輸所需能量最小的地方

現在假設傳輸速率不在我們的控制範圍之內。以下是一些理論上的「看似」改進,它們實際上只是不同的權衡集。

  1. 正向緩存/緩存:預載/下載的所有圖像儘可能所以他們會在用戶請求他們做好準備。在第一次安裝時安裝一切都是靜態的。

    權衡:你在磁盤空間和預處理能力上花費了大部分100分,這可能會讓你的應用總是慢一點,但是一旦它們加載到磁盤上,性能就會很好。壓縮/映射:如果您的瓶頸處於傳輸速率,您可以儘可能多地壓縮/映射圖像,這樣它們將以低成本進行傳輸,但是當它們到達時,您將使用很多處理器能力一旦到達應用程序。

    權衡:CPU功耗比以前使用的多得多,但在傳輸過程中它們將快速移動。壓縮側使用更多的內存和解壓縮的側面也使用更多的內存和CPU。只有當你的圖片因爲巨大而緩慢移動時纔會有效,那麼你會看到這種折中的好處。如果你想嘗試這個安裝7z和檢查先進的壓縮設置,並嘗試真正巨大的地圖。

  2. 繪圖算法:如果您的圖像是圖形而不是位圖/真實圖片。只發送矢量圖形格式,將所有圖片(光柵圖像爲技術)更改爲矢量圖像。將大大減少將圖像載入應用程序的字節數,但最終需要更多的處理器能力。

    權衡:除了不是所有的圖片都可以轉換成矢量圖形。你將會使用更多的CPU和內存,但是那裏已經建立了非常優化的優秀庫。你也可以認爲這是「數學壓縮」,其中一個單一的無限行不能存儲在宇宙中的任何一臺計算機上,一個簡單的一行數學表達式如x = y + 1將使它發生。

  3. 編寫你自己的服務器:如果你確定瓶頸在與服務提供者的通信時間(在這種情況下,最有可能是非常有效的http服務器)。寫你自己的服務器,它非常快速地回答你並開始發送文件。這種改進的可能之處在於低甚至談論權衡。

  4. 永不被迫發送重複信息:以這種方式設計和標記您的信息和圖片。您只會發送非重複塊,接收方將存儲接收到的任何塊以進一步改進其緩存信息。

    權衡:1,2和3的組合你只是另一種令人不安的100點成本。你明白了。

  5. BitTorrent意識形態:如果瓶頸是您的服務器帶寬,有一個簡單的公式來查看使用您的用戶帶寬是否符合邏輯並具有積極影響。如果你的數據集非常大,它可能只會有效。

    權衡:這是一個有趣的選項來討論權衡。您將使用您的用戶帶寬和鄰近度來彌補您的服務器缺乏帶寬。它需要多一點點的CPU採集數據(保持更多的TCP連接)

作爲一個閉注的那麼傳統的方式:有不能是一個函數調用,可以改善並從100傳遞信息的成本指向95分。在目前的技術水平上,似乎我們真的接近於有效轉移。我的意思是壓縮,映射和其他各種技術相當成熟,包括網絡傳輸方法,但總是有改進的空間。例如,目前我們認爲以光速發送數據是絕對最大值,因爲它們是電信號,但觀測技術拒絕這個限制,其中兩個糾纏粒子在理論上以無限速度在宇宙(??)發送和接收information。另外如果你可以開發一個更好,更有效的壓縮方式,那將是非常棒的。

無論如何,因爲您已經提出了一個問題,它沒有提供我們可以交談的許多信息。我強烈建議像工程師一樣思考,創建一個指向主要原因的測試環境,並用你所得到的來攻擊它。如果你能用更好的數學表達式來定義問題或指出瓶頸,我們可以比通用的information theory更好地回答它。

也是最後一個註釋。我並不是說信息傳遞不會更高效,明天它可能會上漲1000%,我只是說這個領域相當成熟,在沒有數學和理論多年的工作的情況下得到任何巨大的改進。像其他任何研究領域一樣。

+0

有趣的答案。 –

+0

不錯的,很多東西描述爲學習者。 –

+0

@Ail Akdurak很驚訝!讓我深思!非常感謝你的出色答案。我會爲你深思。 – Guixian

相關問題