2012-02-16 18 views
7

मेरे पास छवियों का एक ब्लॉक है जिसे मैं अपनी स्क्रीन पर लोड करना चाहता हूं। सभी छवियां वे फ़ाइलें हैं जिन्हें मैंने डाउनलोड किया और एसडी-कार्ड पर संग्रहीत किया।एंड्रॉइड फास्ट बिटमैप लोडिंग

अब तक मुझे इसे करने के दो तरीके मिलते हैं, पहली बार मुख्य धागे पर लोड हो रहा है, जब गतिविधि शुरू हो रही है, (मुझे लगभग 70 छवियां मिलीं और मुझे उन्हें लोड करने के लिए लगभग 2.1 सेकंड लगते हैं)।

एक और तरीका यह है कि मैं अभी परीक्षण कर रहा हूं। उन्हें अलग थ्रेड पर लोड करें, इसलिए इस बीच मैं उपयोगकर्ता के लिए लोडिंग एनीमेशन दिखा सकता हूं। अब के लिए ThreadPoolExecutor के साथ मेरा अपूर्णता 4.3 सेकंड लिया। मैंने इसे 10 धागे पर किया।

और आखिरी विधि, (यह एकमात्र चीज है जिसे मैंने अभी तक परीक्षण नहीं किया है) स्प्राइट शीट के साथ काम कर रहा है।

मैं एप्लिकेशन कैश का उपयोग नहीं कर सकता क्योंकि मेरे आवेदन में मेरे पास बहुत सी स्क्रीन हैं और प्रत्येक स्क्रीन की अपनी छवियां सेट हैं।

आपको क्या लगता है, बड़ी मात्रा में छवियों को लोड करने का सबसे तेज़ तरीका क्या है और एक्सेलेरेशन टेक्निक्स क्या आपको पता है जो मेरी मदद कर सकता है?

+0

आप अपने छवियों का आकार का उल्लेख नहीं किया है और यदि आप अपने आकार को कम कर सकते हैं जब आप उन्हें लोड (जैसे ले एक 5 मेगापिक्सल जेपीईजी और इसे 320x240 थंबनेल के रूप में लोड करें)। यदि आप इसे अनुमति देते हैं, तो यह छवियों की लोडिंग को तेज कर सकता है। – BitBank

उत्तर

2

एक विकल्प वीक रेफरेंस का उपयोग करके छवि कैश बनाने का उपयोग करना होगा ताकि सिस्टम को स्मृति से हटा दिया जाएगा जब सिस्टम कम स्मृति स्थिति का सामना करेगा। इस तरह आप छवियों को स्मृति में रख सकते हैं और जब वे स्मृति में नहीं होते हैं तो केवल एसडीकार्ड से लोड की आवश्यकता होती है। तो आपकी वर्तमान गतिविधि हमेशा बिटमैप की जरूरी हार्ड संदर्भ रखेगी और छवि कैश बिटमैप के कमजोर संदर्भ को बनाए रखेगी।

के बाद कमजोर संदर्भ के बारे में कुछ और जानकारी है:

JavaDoc weakReference

StackOverflow post discussing using weak reference for cache

+1

-1: यह दृष्टिकोण एसडीके 9 और ऊपर के सभी उपकरणों पर व्यावहारिक रूप से बेकार है क्योंकि कचरा कलेक्टर इतनी आक्रामक है कि यह लगभग सभी कमजोर ताज़ाता को साफ करता है, वर्तमान अनुशंसा दृष्टिकोण एलआरयू कैश है (देखें http://developer.android.com/training /displaying-bitmaps/cache-bitmap.html) – for3st

8
  1. मुख्य धागे पर लोड न करें। यदि आप मुख्य धागे को अवरुद्ध करते हैं तो 2.1 सेकंड विलंब के साथ आप ANR (ऐप प्रतिसाद नहीं दे रहे) त्रुटि के साथ मारे जा रहे हैं।

  2. अलग थ्रेड में लोड करें। 10 धागे न बनाएं, लेकिन एक AsyncTask, और doInBackground में अपनी सभी छवियों को एक के बाद लोड करें।

    AsyncTask में लोड हो रहा है (लगभग) मुख्य थ्रेड में लोड होने के रूप में (लगभग) लेना चाहिए। बहुत अधिक फैंसी एनीमेशन न डालें, ताकि मुख्य धागा बहुत अधिक CPU समय का उपभोग न करे।

0

ऐसा करने का एक तरीका श्रोता/पर्यवेक्षक को लागू करना होगा।

अपने यूआई थ्रेड से, अन्य थ्रेड लॉन्च करें जो छवि को लोड करेगा। एक बार छवि लोड होने के बाद, थ्रेड संबंधित छवि दृश्य को अपडेट करने के लिए गतिविधि कक्षा में लागू कॉल बैक विधि का आह्वान करेगा।

एंड्रॉइड एसिंच कार्य के बजाय, मैं अपने धागे (पूल/एक्जिक्यूटर्स) के लिए जाऊंगा। मुझे उन्हें लोड करने से पहले सभी संभावित छवि पथ मिलेंगे, और उन्हें छवि लोड करने के थ्रेड को प्रेषित किया जाएगा। और कॉल में वापस मुझे पता है कि छवि को कहां अपडेट किया जाए।

वैकल्पिक रूप से आप यह भी जांच सकते हैं कि लोडर आपके मामले में कैसे प्रदर्शन करता है।

0

स्पष्ट रूप से, आपको यूआई थ्रेड में 2 एस-लम्बा ऑपरेशन नहीं छोड़ना चाहिए।

मुझे लगता है कि ThreadPoolExecutor एक ईश्वरीय समाधान है, लेकिन यह आपके पूल में कई धागे बनाने के लिए अनुकूल नहीं है। पृष्ठभूमि धागे पर पर्याप्त है। मुझे यकीन है कि आप इसे बदलकर बेहतर प्रदर्शन करेंगे।

मैं गतिविधि से सीधे AsyncTask की अनुशंसा नहीं करता, क्योंकि it is fragile to config change

मैं sprites के साथ काम करने की सिफारिश नहीं करता। एक छवि के आकार में वृद्धि मोबाइल पर बहुत खतरनाक है जहां स्मृति सीमित है। विशेष रूप से sprites के साथ, आपको Bitmap के कुछ हिस्सों को प्राप्त करना होगा, इसलिए एक पल के लिए स्मृति में पूर्ण बिटमैप होना चाहिए।

अब जब मैंने आपके विशिष्ट प्रश्नों को अनदेखा किया है, तो मुझे लगता है कि आप Lazy loading of images in a listview throuh पर जाते हैं क्योंकि समस्या बहुत समान है।

संबंधित मुद्दे