2011-09-19 16 views
15

एंड्रॉइड स्टैक में आईपीसी ओवर (सेमफोर, संदेश कतार, पीआईपीईएस) के लिए बाइंडर का उपयोग करने का क्या फायदा है?एंड्रॉइड में आईपीसी के लिए बाइंडर का उपयोग करने के लाभ

+1

यदि आप सही उत्तर चुनते हैं तो इससे मदद मिलेगी। – JohnnyLambada

+0

एंड्रॉइड देव और कर्नेल देवों ने जून 200 9 में एलकेएमएल पर बाइंडर बनाम विकल्पों के बारे में चर्चा की थी (और अन्य बिंदुओं पर भी संभव है) जो दोनों दृष्टिकोणों पर सूचनात्मक पढ़ने को बनाता है, और विवरण के मुकाबले अधिक विशिष्ट सटीकता के साथ विवरण को संबोधित करता है अभी तक यहां पोस्ट किया गया। –

उत्तर

0

बाइंडर्स दूरस्थ प्रक्रिया कॉल सक्षम करने के लिए उपयोग किए जाते हैं। आप सिंक्रनाइज़ेशन टूल का उपयोग करके आरपीसी को कार्यान्वित कर सकते हैं लेकिन आपको इसे एक साथ लाने के लिए बहुत सारे कोड लिखने की आवश्यकता होगी ... एक बाइंडर (आमतौर पर केवल एंड्रॉइड सर्विस के भीतर उपयोग किया जाता है) के साथ आपके पास लिखने के लिए बहुत कम कोड होता है; आपके वास्तविक रिमोट फ़ंक्शंस से शायद ही अधिक।

+3

क्या बिंडर स्ट्रीम उच्च बैंडविड्थ, प्रक्रियाओं (जैसे ऑडियो, या वीडियो धाराओं) के बीच कम विलंबता डेटा के लिए उपयुक्त होगा – user48956

1

बाइंडर्स का उपयोग प्रक्रिया सीमाओं पर संवाद करने के लिए किया जाता है क्योंकि विभिन्न प्रक्रियाएं एक सामान्य वीएम संदर्भ => एक दूसरे के ऑब्जेक्ट्स (मेमोरी) तक सीधे पहुंच नहीं देती हैं। दोनों पार्टियां एक ही प्रक्रिया के भीतर (आमतौर पर चीजें जो एक ही ऐप के भीतर होती हैं) का मतलब है (imho) कि आपको बाइंडर्स का उपयोग नहीं करना चाहिए क्योंकि वे अनावश्यक चीजों को धीमा/जटिल बनाते हैं।

बाइंडर्स आमतौर पर सीधे "सेवा" या "मैसेंजर" कक्षाओं के माध्यम से उपयोग नहीं किए जाते हैं। जबकि एक सेवा के साथ संचार कार्यों के पूर्ण एपीआई के माध्यम से किया जाता है, मैसेंजर के साथ संचार को "संदेश" का उपयोग करना होता है। संदेशवाहक लागू करने के लिए बहुत आसान है।

अलावा बाइंडर का उपयोग कर आप कुछ भी है कि "LocalSocket" एस, फ़ाइलें, ContentProviders, उद्देश्य, जैसे किसी भी वीएम उदाहरण से उपलब्ध है का उपयोग कर सकते हैं ...

बाइंडर बड़े डेटा धाराओं (ऑडियो की तरह स्थानांतरित करने के लिए आदर्श नहीं हैं/वीडियो) चूंकि प्रत्येक ऑब्जेक्ट को पार्सल में (और वापस) में परिवर्तित करना होता है। सभी रूपांतरण समय लगता है। उस मामले में बहुत बेहतर उदाहरण के लिए एक स्थानीय सॉकेट होगा।

+0

"एक ही प्रक्रिया के भीतर दोनों पार्टियां (आमतौर पर एक ही ऐप के भीतर की चीजें) का मतलब है (imho) कि आपको चाहिए बाइंडर्स का उपयोग न करें क्योंकि वे अनावश्यक चीजों को धीमा/जटिल बनाते हैं। " इराद वास्तव में एक बाइंडर अमूर्तता है, इसलिए तेजी से होने की संभावना नहीं है। –

+0

@littleScala आप सही हैं। प्रक्रिया सीमाओं में उपयोग किए जाने पर भी 'ContentProvider' भी 'बाइंडर' का उपयोग करता है। मेरा जवाब बहुत बुरा है :) – zapl

+0

ध्यान दें कि * ऑब्जेक्ट * बाइंडर * आईपीसी तंत्र * (यानी,/dev/binder और its usermode wrappings, आदि) –

6
NDK के docs/system/libc/SYSV-IPC.html फ़ाइल से

:

एंड्रॉयड सिस्टम वी IPCs का समर्थन नहीं करता, यानी सुविधाएं निम्न मानक Posix हेडर द्वारा प्रदान की:

<sys/sem.h> /* SysV semaphores */ 
<sys/shm.h> /* SysV shared memory segments */ 
<sys/msg.h> /* SysV message queues */ 
<sys/ipc.h> /* General IPC definitions */ 

इस का कारण यह तथ्य यह है कि के कारण है , डिजाइन द्वारा, वे वैश्विक कर्नेल संसाधन रिसाव के लिए नेतृत्व करते हैं।

  • एक बग्गी या दुर्भावनापूर्ण प्रक्रिया
  • एक गैर गाड़ी और गैर दुर्भावनापूर्ण प्रक्रिया दुर्घटनाओं बाहर निकालता है या है:

    उदाहरण के लिए, कोई तरीका नहीं होता एक SysV सेमाफोर कर्नेल में आवंटित जारी करने के लिए जब है स्पष्ट रूप से मारा गया।

एंड्रॉइड के एप्लिकेशन लाइफसाइक्ल कार्यान्वयन का एक महत्वपूर्ण हिस्सा स्वचालित रूप से नए लोगों के लिए जगह बनाने के लिए प्रक्रियाओं को मारना एक महत्वपूर्ण हिस्सा है। इसका अर्थ है , यहां तक ​​कि केवल गैर-बग्गी और गैर-दुर्भावनापूर्ण कोड मानते हुए, यह बहुत अधिक संभावना है कि समय के साथ, SysV IPC को लागू करने के लिए उपयोग की जाने वाली कर्नेल वैश्विक तालिका भर जाएगी।

उस बिंदु पर, अजीब विफलताओं की संभावना होने की संभावना है और उन प्रोग्राम को रोकें जो सिस्टम के अगले रीबूट तक ठीक से चलाने के लिए उपयोग करते हैं।

20

पुराने प्रश्न (और संभावना पोस्टर द्वारा unmonitored), लेकिन जवाब देने लायक:

ए) सभी फाइल सिस्टम आधारित या फाइल सिस्टम-प्रदर्शनीय आईपीसी तंत्र (विशेष रूप से पाइप), की कमी की वजह से नहीं किया जा सकता एक विश्व-लेखन योग्य निर्देशिका, जहां सभी प्रक्रियाएं उनके आईपीसी पोर्ट (/ dev/सॉकेट के बावजूद फाइल सिस्टम/सॉकेट प्रस्तुतीकरण को mkfifo/बना सकती हैं, जिसका उपयोग सिस्टम प्रक्रियाओं के लिए किया जाता है, उदाहरण के लिए राइल, ज़ीगोट, और उनके जैसे)।

बी) सुझाए गए तंत्रों में से कोई भी "सेवा स्थान" की क्षमता नहीं है जो एंड्रॉइड के लिए आवश्यक है। यूनिक्स में, एक आरपीसी पोर्टमैपर है, और एंड्रॉइड की समान कार्यक्षमता की आवश्यकता है। दर्ज करें: सेवा प्रबंधक, जो संदर्भ प्रबंधक के रूप में पंजीकरण करने के लिए बाइंडर का उपयोग कर सकता है, फ्लाई

सी पर पंजीकरण सेवा हैंडल करने के लिए, सीरियलाइजेशन के लिए एक व्यापक आवश्यकता है - यह इरादा है, या अन्य संदेश। बाइंडर पार्सल अबास्ट्रक्शन प्रदान करता है, जिसका उपयोग Parcel.java द्वारा डेटा मार्शलिंग के लिए किया जा सकता है।

डी) एसआईएसवी के पास श्री लम्बाडा के उत्तर से अन्य मुद्दे हैं जो अधिक सर्वोपरि, विशेष रूप से दौड़ की स्थिति और प्राधिकरण की कमी हैं।

ई) संदेश कतार और पाइप वर्णनकर्ताओं को पास नहीं कर सकते हैं। यूनिक्स डोमेन सॉकेट्स (ए) (फिर से), जब तक कि आप रूट/सिस्टम नहीं हैं, जैसे कि ज़ीगोट, रिल्ड, इंस्टालल्ड ..)

एफ) बाइंडर वास्तव में हल्का है, और बनाया गया है प्रमाणीकरण तंत्र में। इसमें निफ्टी फीचर्स भी हैं जैसे प्राप्तकर्ता प्रक्रिया को जागृत करना, साथ ही स्मृति साझा करना, जो कि अन्य तंत्रों में बस नहीं है। (और याद रखें, नामित मैपिंग के लिए फ़ाइल समस्या (ए) में कोई समस्या नहीं है (2)।

और - चलो भूल नहीं

जी) बाइंडर पाम (आह, पुरानी यादों) (q.v. OpenBinder) पर शुरू किया गया था। पूर्व-हथेली एंड्रॉइड के पास पहुंचे, और उनके साथ उनके कोड लाए।

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

  • कोई संबंधित समस्या नहीं^_^