हालांकि आईफोन जेएसओएन का मूल रूप से समर्थन करता है, एएमएफ एक बाइनरी प्रोटोकॉल है और यह बहुत कम बैंडविड्थ का उपयोग करने का अनुमान लगाता है। क्या आपको लगता है कि एएमएफ का उपयोग करना एक अच्छा विचार है? http://www.jamesward.com/census/आईफोन पर जेएसओएन के बजाय एएमएफ का उपयोग करें? (वेब सेवाओं के लिए)
जिम ने कहा:
उपरोक्त उदाहरण AMF0 में थे, लेकिन मुझे नहीं लगता कि AMF3 बहुत अलग होगा।
यह इतना असत्य है। एएमएफ 3 डेटा के परिणामस्वरूप एएमएफ/जेएसओएन से 5 से 8 गुना कम हो सकता है। AMF3 इसे एक ही आइटम का संदर्भ देकर प्राप्त करता है जिसे एक बार उपयोग किया गया है। न केवल तार। कोई भी ऑब्जेक्ट, कुंजी सहित, संदर्भित किया जाता है (ऑफ़सेट के साथ) जैसे ही इसे एक बार उपयोग किया जाता है।
बड़े डेटासेट पर, यह एक बड़ा अंतर बनाता है।
यहां बहुत महत्वपूर्ण अंतर है। AM3 को सही उत्तर के रूप में चिह्नित किया जाना चाहिए ... हम्म आश्चर्य है कि क्या मैं उत्तर संपादित कर सकता हूं? –
तुम भी plist की कोशिश कर सकते: http://github.com/nesium/cocoa-amf/
यहाँ प्रसिद्ध बेंचमार्क पता चलता है कि AMF छोटे और JSON की तुलना में तेजी + gzip फ्लेक्स में है:
बस कोको में इस AMF पुस्तकालय (ऑब्जेक्टिव-सी) में पाया गया , एक मूल बाइनरी प्रारूप। किसी भी प्रारूप में, एएमएफ या यहां तक कि एक्सएमएल प्लिस्ट भी शामिल है, ज़िप द्वारा कम किया जा सकता है। zlib आईफोन का हिस्सा है।
thx, लेकिन प्लिस्ट अधिकांश वेब सर्वरों के साथ अच्छी तरह से काम नहीं करता है। – Henry
अपनी आवश्यकताओं को स्पष्ट करने के लिए आपको अपने प्रश्न में पर्याप्त विवरण जोड़ना चाहिए। अस्पष्ट प्रश्न अस्पष्ट जवाब प्राप्त करते हैं। प्रारंभ में, एएमएफ का उपयोग करने का आपका एकमात्र कारण बैंडविड्थ को कम करना था, जिसमें ज़िप के साथ प्लेस्ट बेहतर विकल्प है। – drawnonward
मैं समझता हूं, मैंने आपका जवाब नीचे वोट नहीं दिया। – Henry
मुझे नहीं लगता कि एएमएफ JSON से काफी छोटा होगा। वास्तव में, यह कई मामलों में थोड़ा बड़ा हो सकता है। निम्नलिखित द्विपदीय प्रारूप में
AMF भंडार स्ट्रिंग "asdf":: मुझे एक उदाहरण में यह दिखा
0x12 /* type = string */
0x00 0x04 /* length */
'a' 's' 'd' 'f'
/* total: strlen(s)+3 bytes */
जबकि JSON स्टोर स्ट्रिंग "asdf" strlen (रों) + 2 बाइट्स में अगर वहाँ स्ट्रिंग में कोई उद्धरण नहीं हैं।
AMF भंडार JSON ऑब्जेक्ट निम्न द्विपदीय प्रारूप में {"key1":"asdf","key2":"foo"}:
0x03 /* type = object */
0x00 0x04 /* length of key1 */
'k' 'e' 'y' '1'
0x02 /* value type = string */
0x00 0x04 /* length of value1 */
'a' 's' 'd' 'f'
0x00 0x04 /* length of key2 */
'k' 'e' 'y' '2'
0x02 /* type of value2 */
0x00 0x03 /* length of value2 */
'f' 'o' 'o'
0x00 0x00 0x09 /* end of object */
/* total: 30 bytes, while the JSON string is 28 bytes */
उपरोक्त उदाहरण AMF0 में थे, लेकिन मुझे नहीं लगता कि AMF3 बहुत अलग होगा।
एएमएफ 0 में एकमात्र विशेषता जो बैंडविड्थ को काफी कम कर सकती है वह यह है कि इसमें एक संदर्भ प्रकार होता है: यदि आप एक ही बड़ी वस्तु को दो बार भेजते हैं, तो दूसरा ऑब्जेक्ट केवल पहले उदाहरण के लिए एक संदर्भ होगा। लेकिन यह एक दुर्लभ मामला IMHO है (और यह केवल वस्तुओं के लिए काम करता है, तारों के लिए नहीं)।
तो मैं JSON (यदि आप वास्तव में बाइट्स पर छोड़ना चाहते हैं, तो आप इसे ज़्लिब या कुछ भी के साथ संपीड़ित कर सकते हैं) की सिफारिश करेंगे: यह पढ़ने के लिए बहुत आसान है, और अधिक कार्यान्वयन हैं, और विनिर्देश स्पष्ट है (जबकि फ्लैश कार्यान्वयन कभी-कभी विनिर्देश से अलग होता है - हम सभी को एडोब पसंद है;))
रुचि! धन्यवाद। – Henry
लेकिन पाठ से किसी भी तरह HTTP पर अधिक कुशलता से बाइनरी परिवहन नहीं कर रहा है? – Henry
बिलकुल नहीं! हो सकता है कि आप इसका जिक्र कर रहे हैं कि _HTML form_ का टेक्स्ट डेटा ब्राउज़र द्वारा एन्कोड किया गया URL है (उदाहरण के लिए यह स्पेस कैरेक्टर% 20 से बच जाता है), जो लंबाई बढ़ाता है। लेकिन HTTP पर डेटा भेजने के लिए इसकी आवश्यकता नहीं है। और वैसे भी, पाठ वर्ण "बाइनरी वर्ण" (0-255 के बीच की संख्या) का उप-समूह हैं, इसलिए यदि आप बाइनरी डेटा के रूप में एक टेक्स्ट भेजते हैं, तो इसका "वास्तविक" बाइनरी डेटा से अधिक लागत नहीं हो सकती है! (वास्तव में, केवल विपरीत ही हो सकता है: कुछ प्रोटोकॉल की आवश्यकता होती है कि डेटा ASCII वर्णों में भेजा जाता है, इसलिए बाइनरी डेटा 7-बिट सीमा तक अनपॅक किया जाना चाहिए ...) – gyim
यदि आप बाइनरी प्रोटोकॉल का उपयोग करना चाहते हैं तो आप हेसियन या Google प्रोटोकॉल बफर को देख सकते हैं। मुझे पता है कि एक तथ्य हेसियन आईफोन पर बहुत अच्छा प्रदर्शन प्रदान करता है।
वास्तव में यह एक बहुत अच्छा सवाल है और मैं यह भी है। मैंने आज डब्ल्यूडब्ल्यूडीसी में आईफोन के साथ क्लाइंट/सर्वर के बारे में बात करते हुए एक सत्र में भाग लिया। और उन्होंने हमें बताया कि जेएसओएन और एक्सएमएल की तुलना में बाइनरी प्लिस्ट कहीं अधिक कुशल थे, खासकर जब यह पार्सिंग समय की बात आती है। लेकिन समस्या यह है कि मैं अभी भी एक रिमोटिंग प्रोटोकॉल के रूप में प्लिस्ट के किसी भी सर्वर-साइड कार्यान्वयन को खोजने की कोशिश कर रहा हूं, जबकि एएमएफ के पास सर्वर-साइड पर बहुत सारे महान कार्यान्वयन हैं: वेबोरबी, ज़ेंडैमएफ, ब्लेज़डीएस इत्यादि। इसलिए एएमएफ को एकीकृत करना सर्वर पक्ष एक हवा है। दुर्भाग्य से, क्लाइंट साइड पर, मुझे मिला एकमात्र विकल्प नेसियम का कोको एएमएफ था, लेकिन दुर्भाग्यवश यह चैनल सेट प्रमाणीकरण का समर्थन नहीं करता है और यह क्लाइंट-साइड स्टब जनरेटर को याद करता है। मैं इसमें देखता हूं लेकिन चूंकि यह कोई छोटा काम नहीं है और मुझे यकीन है कि आईफोन डेवलपर्स के बहुत सारे पहले से ही इस मुद्दे का सामना कर चुके हैं, मैं यह सुनिश्चित करना चाहता हूं कि वास्तव में कोई अन्य विकल्प नहीं है।
अब तक, मैं हैसियन का उपयोग हेसियनकिट के साथ कर रहा हूं, लेकिन यह प्रमाणीकरण का समर्थन नहीं करता है और यह एक सीमा बनना शुरू कर रहा है।ऐप्पल फ्लैश के बारे में सब कुछ कह सकता है, लेकिन कम से कम वे रिमोट सर्वर से कनेक्ट करना बहुत आसान बनाते हैं।
अभी तक प्लास्ट का कोई जावा कार्यान्वयन नहीं है? शायद यह एक ओपन सोर्स प्रोजेक्ट शुरू करने का समय है। :) – Henry
यह निश्चित रूप से आपके द्वारा स्थानांतरित किए जा रहे डेटा पर निर्भर करता है। मुझे मिनी-जनगणना ऐप बनाने की ज़रूरत है जो छोटे डेटा सेट करता है। :) –
सुनिश्चित करें कि आप @ user562816 उत्तर पढ़ते हैं, AMF3 बहुत छोटा होना चाहिए। –