การเปรียบเทียบไลบรารีเครือข่าย Android: OkHTTP, Retrofit และ Volley [ปิด]

คำถามสองส่วนจากนักพัฒนา iOS ที่กำลังเรียนรู้ Android ซึ่งทำงานในโครงการ Android ที่จะทำการร้องขอที่หลากหลายจาก JSON เป็นรูปภาพเพื่อสตรีมมิ่งการดาวน์โหลดเสียงและวิดีโอ:

1. บน iOS ฉันใช้โครงการเครือข่าย AFNอย่างกว้างขวาง มีห้องสมุดที่เทียบเท่าสำหรับ Android?

2. ฉันได้อ่านOkHTTPและRetrofit by Square และVolley แล้วแต่ยังไม่มีประสบการณ์ในการพัฒนา ฉันหวังว่าบางคนสามารถให้ตัวอย่างที่ชัดเจนของกรณีการใช้ที่ดีที่สุดสำหรับแต่ละคน จากสิ่งที่ฉันได้อ่านดูเหมือนว่า OkHTTP จะแข็งแกร่งที่สุดในบรรดาสามประการและสามารถจัดการกับข้อกำหนดของโครงการนี้ได้ (ดังที่ได้กล่าวไว้ข้างต้น)

ฉันหวังว่าบางคนสามารถให้ตัวอย่างที่ชัดเจนของกรณีการใช้ที่ดีที่สุดสำหรับแต่ละคน

ใช้ชุดติดตั้งเพิ่มหากคุณกำลังสื่อสารกับบริการบนเว็บ ใช้เพียร์ไลบรารี Picasso ถ้าคุณกำลังดาวน์โหลดรูปภาพ ใช้ OkHTTP หากคุณต้องการใช้งาน HTTP ที่อยู่นอก Retrofit / Picasso

วอลเล่ย์แข่งขันกับ Retrofit + Picasso อย่างคร่าวๆ ด้านบวกเป็นห้องสมุดเดียว ในด้านลบมันเป็นสิ่งที่ไม่มีเอกสารไม่มีการสนับสนุน "โยนรหัสข้ามกำแพงและทำการนำเสนอ I | O บน" ห้องสมุด

EDIT - Volley สนับสนุนโดย Google อย่างเป็นทางการแล้ว โปรดดูคู่มือนักพัฒนาซอฟต์แวร์ของ Google

จากสิ่งที่ฉันอ่านดูเหมือนว่า OkHTTP จะแข็งแกร่งที่สุดในบรรดาทั้งสาม

ชุดติดตั้งเพิ่มใช้ OkHTTP โดยอัตโนมัติหากมี มีส่วนสำคัญจาก Jake Whartonที่เชื่อมต่อ Volley กับ OkHTTP

และสามารถจัดการกับข้อกำหนดของโครงการนี้ (กล่าวถึงข้างต้น)

อาจเป็นไปได้ว่าคุณจะไม่ใช้สิ่งเหล่านี้ในการ "สตรีมมิ่งดาวน์โหลดเสียงและวิดีโอ" โดยนิยามดั้งเดิมของ "สตรีม" กรอบงานสื่อของ Android จะจัดการคำขอ HTTP เหล่านั้นแทนคุณ

ที่ถูกกล่าวว่าหากคุณกำลังพยายามที่จะทำสตรีมมิ่ง HTTP ของคุณเอง OkHTTP ควรจัดการกับสถานการณ์นั้น ฉันจำไม่ได้ว่าวอลเล่ย์จัดการกับสถานการณ์นั้นได้ดีแค่ไหน Retrofit และ Picasso ไม่ได้รับการออกแบบมาสำหรับสิ่งนั้น

การมองมุมมองของวอลเล่ที่นี่มีข้อดีสำหรับความต้องการของคุณ:

ในอีกด้านหนึ่ง Volley นั้นให้ความสำคัญกับการจัดการคำขอ HTTP ขนาดเล็กเป็นรายบุคคล ดังนั้นหากการจัดการคำร้องขอ HTTP ของคุณมีข้อผิดพลาดบางอย่างวอลเล่ย์อาจมีตะขอสำหรับคุณ หากในมืออื่น ๆ ที่คุณมีมุมแหลมในการจัดการภาพของคุณเบ็ดจริงเท่านั้นที่คุณมีคือImageCache "มันไม่ใช่อะไร แต่มันก็ไม่มาก! เช่นกัน" แต่มีข้อได้เปรียบอื่น ๆ เพิ่มเติมเช่นเมื่อคุณกำหนดคำขอของคุณการใช้พวกเขาจากภายในส่วนหรือกิจกรรมนั้นไม่เจ็บปวดไม่เหมือน AsyncTasks แบบขนาน

ข้อดีและข้อเสียของการวอลเลย์:

ดังนั้นสิ่งที่ดีเกี่ยวกับวอลเล่ย์?

• ส่วนเครือข่ายไม่ได้มีไว้สำหรับภาพเท่านั้น วอลเล่ย์ตั้งใจที่จะเป็นส่วนหนึ่งของส่วนหลังของคุณ สำหรับโครงการใหม่ที่ใช้บริการ REST แบบง่ายนี่อาจเป็นชัยชนะครั้งใหญ่

• NetworkImageView มีความก้าวร้าวมากขึ้นเกี่ยวกับคำขอล้างข้อมูลมากกว่า Picasso และอนุรักษ์นิยมมากขึ้นในรูปแบบการใช้งาน GC NetworkImageView ขึ้นอยู่กับการอ้างอิงหน่วยความจำที่แข็งแกร่งและล้างข้อมูลคำขอทั้งหมดทันทีที่มีการร้องขอใหม่สำหรับ ImageView หรือทันทีที่ ImageView ย้ายออกนอกจอ

• ประสิทธิภาพ. โพสต์นี้จะไม่ประเมินการอ้างสิทธิ์นี้ แต่พวกเขาใช้ความระมัดระวังอย่างรอบคอบในการใช้รูปแบบการใช้หน่วยความจำ วอลเล่ย์ยังใช้ความพยายามในการแบทช์กลับไปที่เธรดหลักเพื่อลดการสลับบริบท

• เห็นได้ชัดว่าวอลเล่ย์ก็มีอนาคตเช่นกัน ตรวจสอบ RequestFuture หากคุณสนใจ

• หากคุณกำลังจัดการกับภาพที่ถูกบีบอัดความละเอียดสูงวอลเล่ย์เป็นทางออกเดียวที่ทำงานได้ดี

• วอลเล่ย์สามารถใช้กับ Okhttp (เวอร์ชั่นใหม่ของ Okhttp รองรับ NIO เพื่อประสิทธิภาพที่ดีขึ้น)

• วอลเล่ย์เล่นได้ดีกับวงจรชีวิตของกิจกรรม

ปัญหาเกี่ยวกับวอลเล่ย์:
เนื่องจากวอลเล่ย์เป็นของใหม่บางสิ่งยังไม่ได้รับการสนับสนุน แต่มันได้รับการแก้ไข

1. คำขอหลายส่วน (โซลูชัน: https://github.com/vinaysshenoy/enhanced-volley )

2. รหัสสถานะ 201 ถือเป็นข้อผิดพลาดรหัสสถานะ 200 ถึง 207 เป็นคำตอบที่ประสบความสำเร็จในขณะนี้ (แก้ไข: https://github.com/Vinayrraj/CustomVolley )

   อัปเดต:ในรุ่นล่าสุดของ Google วอลเลย์ข้อบกพร่องรหัสสถานะ 2XX ได้รับการแก้ไขแล้วขอบคุณ Ficus Kirkpatrick!

3. เป็นเอกสารน้อย แต่หลายคนที่จะสนับสนุนวอลเลย์ใน GitHub, Java เช่นเอกสารที่สามารถพบได้ที่นี่ บนเว็บไซต์ของนักพัฒนาหุ่นยนต์คุณอาจพบคำแนะนำสำหรับการส่งสัญญาณเครือข่ายข้อมูลโดยใช้วอลเล่ย์ และรหัสแหล่งวอลเล่ย์สามารถพบได้ที่Google Git

4. เพื่อแก้ไข / เปลี่ยนแปลงนโยบายการเปลี่ยนเส้นทางของ Volley Framework ใช้ Volley กับ OkHTTP (คอมมอนส์ที่กล่าวถึงข้างต้น)

นอกจากนี้คุณยังสามารถอ่านการโหลดรูปภาพเปรียบเทียบกับ Picasso

retrofit:

เปิดตัวโดยSquareข้อเสนอนี้ใช้งานง่ายมากของ REST API (อัปเดต: Voila! พร้อมการรองรับ NIO)

ข้อดีของชุดติดตั้งเพิ่มเติม:

• เปรียบเทียบกับวอลเล่ย์รหัส REST API ของ Retrofit นั้นสั้นและให้เอกสาร API ที่ยอดเยี่ยมและมีการสนับสนุนที่ดีในชุมชน! มันง่ายมากที่จะเพิ่มเข้าไปในโครงการ

• เราสามารถใช้กับไลบรารีการทำให้เป็นอนุกรมใด ๆ ด้วยการจัดการข้อผิดพลาด

อัปเดต: - มีการเปลี่ยนแปลงที่ดีมากมายใน Retrofit 2.0.0-beta2

• Retrofit เวอร์ชัน 1.6 กับ OkHttp 2.0 ตอนนี้ขึ้นอยู่กับOkioเพื่อสนับสนุนjava.ioและjava.nioซึ่งทำให้เข้าถึงเข้าถึงจัดเก็บและประมวลผลข้อมูลของคุณได้ง่ายขึ้นโดยใช้ByteStringและBufferเพื่อทำสิ่งที่ฉลาดเพื่อประหยัด CPU และหน่วยความจำ (FYI: นี้ทำให้ผมนึกถึงOIN Koush ของห้องสมุดด้วยการสนับสนุน NIO!) เราสามารถใช้ติดตั้งเพิ่มร่วมกับ RxJavaจะรวมและบริการโทรห่วงโซ่ REST ใช้rxObservablesเพื่อหลีกเลี่ยงการโทรกลับโซ่น่าเกลียด(เพื่อหลีกเลี่ยงการเรียกกลับนรก !!)

ข้อเสียของชุดติดตั้งเพิ่มสำหรับรุ่น 1.6:

• ฟังก์ชั่นการจัดการข้อผิดพลาดที่เกี่ยวข้องกับหน่วยความจำไม่ดี (ใน Retrofit / OkHttp เวอร์ชั่นเก่ากว่า) ไม่แน่ใจว่าได้รับการปรับปรุงด้วยการสนับสนุน Okio กับ Java NIO

• ความช่วยเหลือขั้นต่ำในการทำเกลียวอาจส่งผลให้โทรกลับนรกหากเราใช้วิธีนี้ในวิธีที่ไม่เหมาะสม

(ข้อด้อยทั้งหมดข้างต้นได้รับการแก้ไขในเวอร์ชั่นใหม่ของ Retrofit 2.0 เบต้า)

================================================== ======================

ปรับปรุง:

Android Async vs Volley vs การวัดประสิทธิภาพ Retrofit (มิลลิวินาทีค่าที่ต่ำกว่าดีกว่า):

(FYI ข้างต้นข้อมูลการติดตั้งเพิ่มเติมจะปรับปรุงด้วยการสนับสนุน java NIO เนื่องจากเวอร์ชันใหม่ของ OKhttp ขึ้นอยู่กับไลบรารี NIO Okio)

ในการทดสอบทั้งสามครั้งด้วยการทำซ้ำที่แตกต่างกัน (1 - 25 ครั้ง) วอลเล่ย์อยู่ที่ใดก็ได้จาก 50% ถึง 75% เร็วขึ้น ชุดติดตั้งเพิ่มเติมติดตั้งด้วยความเร็วที่น่าประทับใจกว่า AsyncTasks 50% ถึง 90% โดยกดจุดปลายทางเดียวกันตามจำนวนครั้งที่เท่ากัน ในชุดทดสอบแดชบอร์ดสิ่งนี้แปลเป็นการโหลด / แยกข้อมูลได้เร็วขึ้นหลายวินาที นั่นคือความแตกต่างในโลกแห่งความจริงที่ยิ่งใหญ่ เพื่อให้การทดสอบมีความยุติธรรมเวลาสำหรับ AsyncTasks / Volley จะรวมการแยก JSON เนื่องจาก Retrofit ทำเพื่อคุณโดยอัตโนมัติ

RetroFit ชนะการทดสอบเกณฑ์มาตรฐาน!

ในที่สุดเราตัดสินใจที่จะไปกับ Retrofit สำหรับการสมัครของเรา ไม่เพียง แต่มันจะขันเร็ว แต่มันก็เข้ากันได้ดีกับสถาปัตยกรรมที่มีอยู่ของเรา เราสามารถสร้างอินเทอร์เฟซผู้โทรกลับที่ดำเนินการจัดการข้อผิดพลาดแคชและการแบ่งหน้าอัตโนมัติโดยไม่ต้องใช้ความพยายามเล็กน้อยสำหรับ API ของเรา เพื่อที่จะรวมใน Retrofit เราต้องเปลี่ยนชื่อตัวแปรของเราเพื่อให้แบบจำลอง GSON ของเราเป็นไปตามมาตรฐานเขียนอินเทอร์เฟซง่ายๆสองสามลบฟังก์ชั่นจาก API เก่าและดัดแปลงชิ้นส่วนของเราเพื่อไม่ใช้ AsyncTasks ตอนนี้เรามีการแปลงเป็นเศษเล็กเศษน้อยอย่างสมบูรณ์แล้วมันค่อนข้างเจ็บปวด มีความเจ็บปวดและปัญหาเพิ่มขึ้นที่เราต้องเอาชนะ แต่โดยรวมแล้วมันก็ราบรื่น ในการเริ่มต้นเราพบปัญหา / ข้อบกพร่องทางเทคนิคเล็กน้อย แต่ Square มีชุมชน Google+ ที่ยอดเยี่ยมที่สามารถช่วยเหลือเราได้

เมื่อใดที่จะใช้วอลเล่ย์!

เราสามารถใช้วอลเล่ย์เมื่อเราต้องการโหลดรูปภาพรวมถึงการใช้ REST APIs!, ระบบการจัดคิวการโทรเครือข่ายเป็นสิ่งจำเป็นสำหรับคำขอ n / w จำนวนมากในเวลาเดียวกัน! วอลเล่ย์ยังมีข้อผิดพลาดเกี่ยวกับการจัดการหน่วยความจำดีกว่า Retrofit!

OkHttpสามารถใช้กับ Volley, Retrofit ใช้OkHttpโดยค่าเริ่มต้น! มันมีการสนับสนุนSPDY , การเชื่อมต่อร่วมกัน, แคชดิสก์, การบีบอัดแบบโปร่งใส! เมื่อเร็ว ๆ นี้ได้รับการสนับสนุนบางส่วนของ java NIO ด้วยไลบรารีOkio

แหล่งที่มาของสินเชื่อ: volley-vs-retrofitโดย Mr. Josh Ruesch

หมายเหตุ: เกี่ยวกับการสตรีมมันขึ้นอยู่กับประเภทของการสตรีมที่คุณต้องการเช่น RTSP / RTCP

RoboSpice กับ การระดมยิง

จากhttps://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ

• RoboSpice (RS) เป็นพื้นฐานของการบริการและให้ความเคารพปรัชญา Android มากกว่า Volley วอลเล่ย์เป็นแบบเธรดและนี่ไม่ใช่วิธีการประมวลผลพื้นหลังที่ควรเกิดขึ้นบน Android ในที่สุดคุณสามารถขุดทั้ง libs และพบว่าพวกมันค่อนข้างคล้ายกัน แต่วิธีของเราในการประมวลผลเบื้องหลังนั้นเป็น Android มากกว่าซึ่งจะช่วยให้เราสามารถบอกผู้ใช้ว่า RS กำลังทำอะไรบางอย่างในพื้นหลังซึ่งจะเป็น ยากสำหรับวอลเลย์ (จริงๆแล้วมันไม่ได้เลย)
• RoboSpice และวอลเลย์ทั้งสองมีคุณสมบัติที่ดีเช่นการจัดลำดับความสำคัญนโยบายลองใหม่ยกเลิกคำขอ แต่อาร์เอสมอบข้อเสนอเพิ่มเติม: แคชขั้นสูงยิ่งขึ้นและยิ่งใหญ่ด้วยการจัดการแคชการรวมคำขอและคุณสมบัติอื่น ๆ เช่นการเปลี่ยนเป็นคำขอที่ค้างอยู่จัดการกับการหมดอายุของแคชโดยไม่ต้องพึ่งพาส่วนหัวของเซิร์ฟเวอร์ ฯลฯ
• RoboSpice ทำนอกเหนือจาก UI Thread: การระดมยิงจะกำจัด POJO ของคุณบนเธรดหลักซึ่งเป็นสิ่งที่น่ากลัวในใจของฉัน ด้วย RS แอปของคุณจะตอบสนองได้ดียิ่งขึ้น
• ในแง่ของความเร็วเราต้องมีการวัดแน่นอน ตอนนี้ RS มีอากาศที่เร็วมาก แต่ถึงกระนั้นเราก็ยังไม่มีตัวเลขที่จะใส่ที่นี่ ในทางทฤษฎีวอลเล่ย์น่าจะเร็วกว่านี้เล็กน้อย แต่ตอนนี้อาร์เอสขนานกันอย่างหนาแน่น ... ใครจะไปรู้ล่ะ
• RoboSpice เสนอช่วงความเข้ากันได้ขนาดใหญ่พร้อมส่วนขยาย คุณสามารถใช้กับ okhttp, retrofit, ormlite (เบต้า), jackson, jackson2, gson, xml serializer, ไคลเอนต์ http http ของ Google, android ฤดูใบไม้ผลิ ... ค่อนข้างมาก วอลเล่ย์สามารถใช้ได้กับ ok http และใช้ gson แค่นั้นแหละ.
• วอลเล่ย์เสนอน้ำตาล UI ที่ RS มากขึ้น Volley มี NetworkImageView, RS จัดเตรียมอะแดปเตอร์ spicelist ในแง่ของฟีเจอร์มันไม่ไกลนัก แต่ฉันเชื่อว่าวอลเล่ย์จะก้าวหน้ากว่าในหัวข้อนี้
• RoboSpice มีมากกว่า 200 ข้อบกพร่องที่ได้รับการแก้ไขตั้งแต่เปิดตัวครั้งแรก มันค่อนข้างแข็งแกร่งและใช้อย่างหนักในการผลิต วอลเล่ย์มีอายุน้อยกว่า แต่ฐานผู้ใช้ควรเติบโตอย่างรวดเร็ว (เอฟเฟกต์ของ Google)
• RoboSpice มีให้บริการที่ maven central วอลเล่ย์หายาก;)

AFNetworking สำหรับ Android:

ระบบเครือข่าย Android ที่รวดเร็วอยู่ที่นี่

ห้องสมุดเครือข่าย Android ที่เร็วรองรับการร้องขอ HTTP / HTTPS ทุกประเภทเช่น GET, POST, DELETE, HEAD, PUT, PATCH

ห้องสมุดเครือข่าย Android ที่เร็วรองรับการดาวน์โหลดไฟล์ประเภทใดก็ได้

ห้องสมุดเครือข่าย Android ที่รวดเร็วรองรับการอัปโหลดไฟล์ประเภทใดก็ได้ (รองรับการอัปโหลดหลายส่วน)

ห้องสมุดเครือข่าย Android ที่รวดเร็วรองรับการยกเลิกการร้องขอ

ไลบรารีระบบเครือข่าย Android ที่รวดเร็วรองรับการตั้งค่าตามคำขอใด ๆ (LOW, MEDIUM, HIGH, IMMEDIATE)

ห้องสมุดเครือข่าย Android ที่รวดเร็วรองรับ RxJava

เนื่องจากใช้ OkHttp เป็นเลเยอร์เครือข่ายจึงรองรับ:

ห้องสมุดเครือข่าย Android ที่รวดเร็วรองรับการสนับสนุน HTTP / 2 ช่วยให้การร้องขอทั้งหมดไปยังโฮสต์เดียวกันเพื่อแบ่งปันซ็อกเก็ต

ห้องสมุดเครือข่าย Android ที่รวดเร็วใช้การเชื่อมต่อร่วมกันซึ่งช่วยลดเวลาในการตอบสนองการร้องขอ (หากไม่มี HTTP / 2)

GZIP โปร่งใสจะลดขนาดการดาวน์โหลด

ห้องสมุดเครือข่าย Android ที่รวดเร็วรองรับการแคชการตอบสนองซึ่งจะช่วยหลีกเลี่ยงเครือข่ายสำหรับคำขอซ้ำ

ขอบคุณ: ฉันสร้างห้องสมุดขึ้นมา

ไคลเอนต์ Async HTTP loopj vs. Volley

เฉพาะโครงการของฉันคือคำขอ HTTP REST ขนาดเล็กทุกๆ 1-5 นาที

ฉันใช้ async HTTP client (1.4.1) เป็นเวลานาน ประสิทธิภาพดีกว่าการใช้ vanilla Apache httpClient หรือการเชื่อมต่อ HTTP URL อย่างไรก็ตามเวอร์ชันใหม่ของห้องสมุดไม่ทำงานสำหรับฉัน: ข้อผิดพลาดระหว่างห้องสมุดตัดโซ่ของการโทรกลับ

การอ่านคำตอบทั้งหมดทำให้ฉันลองสิ่งใหม่ ๆ ฉันเลือกไลบรารี Volley HTTP

หลังจากใช้ไปสักพักถึงแม้จะไม่มีการทดสอบก็ตามฉันเห็นได้อย่างชัดเจนว่าเวลาตอบสนองลดลงถึง 1.5x, 2x Volley

บางทีชุดติดตั้งเพิ่มเติมอาจดีกว่าไคลเอ็นต์ async HTTP ใช่ไหม ฉันต้องการที่จะลอง. แต่ฉันแน่ใจว่าวอลเล่ย์ไม่เหมาะสำหรับฉัน

เพียงเพิ่มเล็กน้อยในการสนทนาจากประสบการณ์ของฉันทำงานกับ Volley:

1. วอลเล่ย์ไม่จัดการการอัปโหลดหรือดาวน์โหลดแบบสตรีมมิงในทุกกรณี นั่นคือร่างกายคำขอทั้งหมดมีอยู่ในหน่วยความจำและคุณไม่สามารถใช้OutputStreamในการเขียนร่างกายขอให้ซ็อกเก็ตต้นแบบหรือคุณสามารถใช้InputStreamในการอ่านการตอบสนองของร่างกายที่เป็นพื้นฐานHttpURLConnectionไม่ ดังนั้น Volley เป็นตัวเลือกที่ไม่ดีสำหรับการอัพโหลดหรือดาวน์โหลดไฟล์ขนาดใหญ่ คำขอและคำตอบของคุณควรมีขนาดเล็ก นี่เป็นหนึ่งในข้อ จำกัด ที่ใหญ่ที่สุดของวอลเล่ย์ที่ฉันได้พบเป็นการส่วนตัว สำหรับสิ่งที่คุ้มค่า OkHttp มีอินเตอร์เฟสสำหรับทำงานกับสตรีม

2. การขาดเอกสารอย่างเป็นทางการนั้นน่ารำคาญแม้ว่าฉันจะสามารถแก้ไขได้โดยการอ่านซอร์สโค้ดซึ่งค่อนข้างง่ายที่จะติดตาม สิ่งที่น่าเป็นห่วงคือเท่าที่ฉันสามารถบอกได้ Volley ไม่มีรุ่นวางจำหน่ายอย่างเป็นทางการและไม่มีสิ่งประดิษฐ์ Maven หรือ Gradle ดังนั้นการจัดการมันจึงขึ้นอยู่กับอาการปวดหัวมากกว่าห้องสมุดพูดใด ๆ . คุณเพียงโคลน repo สร้าง jar และคุณเอง กำลังมองหาการแก้ไขข้อผิดพลาด? ดึงข้อมูลและหวังว่าจะมี คุณอาจได้รับสิ่งอื่นเช่นกัน มันจะไม่ถูกบันทึกไว้ ในความคิดของฉันสิ่งนี้ได้อย่างมีประสิทธิภาพหมายความว่าวอลเล่ย์เป็นห้องสมุดบุคคลที่สามที่ไม่ได้รับการสนับสนุนแม้ว่าฐานรหัสจะเปิดใช้งานอย่างสมเหตุสมผล Caveat emptor

3. ในฐานะที่เป็น nit การมี Content-Type เชื่อมโยงกับคลาส / ประเภทการร้องขอ (JsonObjectRequest, ImageRequest ฯลฯ ) นั้นค่อนข้างงุ่มง่ามและลดความยืดหยุ่นของรหัสการเรียกบิตในขณะที่คุณเชื่อมโยงกับลำดับชั้นการร้องขอที่มีอยู่ของ Volley ฉันชอบความตรงไปตรงมาของการตั้งค่า Content-Type เป็นส่วนหัวเหมือนกับอื่น ๆ (อย่าทำเช่นนี้กับ Volley แต่คุณจะต้องจบด้วยสองส่วนหัว Content-Type!) นั่นเป็นเพียงความเห็นส่วนตัวของฉันและสามารถแก้ไขได้

ไม่ได้หมายความว่า Volley ไม่มีคุณสมบัติที่มีประโยชน์ มันไม่แน่นอน นโยบายลองใหม่ที่ปรับแต่งได้อย่างง่ายดายแคชโปร่งใส API การยกเลิกและการสนับสนุนสำหรับการกำหนดตารางเวลาคำขอและการเชื่อมต่อพร้อมกันเป็นคุณสมบัติที่ยอดเยี่ยม เพิ่งรู้ว่ามันไม่ได้มีไว้สำหรับการใช้งาน HTTP ทุกกรณี (ดูรายการที่ 1 ด้านบน) และมีอาการปวดหัวบางอย่างที่เกี่ยวข้องกับการทำให้วอลเล่ย์เข้าสู่การใช้งานจริงในแอพของคุณ (รายการ 2)

เมื่อเร็ว ๆ นี้ฉันได้พบกับ lib ที่เรียกว่าไอออนที่เพิ่มความพิเศษให้กับตาราง

ไอออนมีการสนับสนุนการดาวน์โหลดรูปภาพที่รวมอยู่กับ ImageView, JSON (ด้วยความช่วยเหลือของ GSON), ไฟล์และการสนับสนุนเธรด UI ที่สะดวกมาก

ฉันใช้มันในโครงการใหม่และผลลัพธ์ก็ดี มันใช้ง่ายกว่าวอลเล่ย์หรือชุดติดตั้งเพิ่มเติม

การเพิ่มคำตอบที่ยอมรับและสิ่งที่ LOG_TAG กล่าวว่า ... สำหรับวอลเล่ย์ในการแยกวิเคราะห์ข้อมูลของคุณในเธรดพื้นหลังคุณต้อง subclass Request<YourClassName>เป็นonResponseวิธีการที่เรียกว่าในหัวข้อหลักและการแยกวิเคราะห์ในหัวข้อหลักอาจทำให้ UI ล่าช้าถ้าการตอบสนองของคุณ ใหญ่. อ่านที่นี่เกี่ยวกับวิธีการทำ

ชุดติดตั้ง 1.9.0 vs. RoboSpice

ฉันใช้ทั้งคู่ในแอพของฉัน

Robospice ทำงานได้เร็วกว่า Retrofit ทุกครั้งที่ฉันแยกชั้น JSON ที่ซ้อนกัน เพราะ Spice Manger จะทำทุกอย่างให้คุณ ในชุดติดตั้งเพิ่มเติมคุณจำเป็นต้องสร้าง GsonConverter และเลิกทำการแปลง

ฉันสร้างสองแฟรกเมนต์ในกิจกรรมเดียวกันและเรียกในเวลาเดียวกันด้วย URL ชนิดเดียวกันสองรายการ

09-23 20:12:32.830  16002-16002/com.urbanpro.seeker E/RETROFIT﹕   RestAdapter Init
09-23 20:12:32.833  16002-16002/com.urbanpro.seeker E/RETROFIT﹕ calling the method
09-23 20:12:32.837  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ initialzig spice manager
09-23 20:12:32.860  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ Executing the method
09-23 20:12:33.537  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ on SUcceess
09-23 20:12:33.553  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ gettting the all contents
09-23 20:12:33.601  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation starts
09-23 20:12:33.603  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation ends

และอีกตัวเลือกหนึ่ง: https://github.com/apptik/jus

• มันเป็นโมดูลาร์อย่างวอลเล่ย์ แต่มีการขยายเพิ่มเติมและมีการปรับปรุงเอกสารประกอบรองรับสแต็ค HTTP และตัวแปลงที่แตกต่างกันออกไปนอกกล่อง
• มีโมดูลเพื่อสร้างการแมปอินเทอร์เฟซ API ของเซิร์ฟเวอร์เช่นชุดติดตั้งเพิ่มเติม
• นอกจากนี้ยังมีการรองรับ JavaRx

และคุณสมบัติที่มีประโยชน์อื่น ๆ อีกมากมายเช่นเครื่องหมายหม้อแปลง ฯลฯ