wx_chat_yj
ฉันทำงานในฉันมาระยะหนึ่งแล้วและคราวนี้ฉันบันทึกข้อผิดพลาดที่ฉันพบมาก่อน ฉันจะแบ่งปันส่วนแชทในภายหลัง ฉันหวังว่ามันจะเป็นประโยชน์กับทุกคน ในบรรดาโครงการที่ฉันเคยดูออนไลน์มาก่อนฉันไม่ค่อยได้พูดคุยเกี่ยวกับการเผชิญกับข้อผิดพลาดในระหว่างกระบวนการพัฒนา หากคุณเขียนแชทเป็นครั้งแรกคุณอาจพบปัญหาเพิ่มเติม ที่นี่ฉันจะพูดถึงข้อผิดพลาดที่ฉันพบเป็นหลัก ทุกคนยินดีที่จะถ่ายภาพ โปรดให้ความคิดเห็นที่แตกต่างกันขอบคุณ ทุกคนก้าวหน้าไปด้วยกัน!
หากเป็นประโยชน์สำหรับคุณโปรดจำไว้ว่าดวงดาว!
ฟังก์ชั่นพื้นฐานรวมถึง
การเพิกถอนการลบการคัดลอกข้อความ
เสียงข้อความรูปภาพ
จำนวนคนที่ยังไม่ได้อ่าน
รูปแบบข้อความอื่น ๆ ที่ปรับแต่งในโครงการ
ในโครงการจริงมีคลาวด์ดิสก์การเล่นวิดีโอและวงกลมของเพื่อน ...
1. เริ่มต้นด้วยเฟรมเวิร์ก
2. ฐานข้อมูลใช้ WeChat Open Source WCDB โดยไม่ต้องเขียนคำสั่ง SQL
3. ฉันพบข้อผิดพลาดบางอย่างต่อไปนี้
1. ความล่าช้าของอินเทอร์เฟซ
- เมื่อใช้เค้าโครงอินเตอร์เฟส UITableView+... การคำนวณความสูงอัตโนมัติของบุคคลที่สามของเซลล์จะใช้ เนื่องจากมีรูปแบบการแชทของโครงการมากมายเฉพาะรูปแบบซ้ายและขวาจะถูกวางเมื่อใช้เค้าโครง XIB และสไตล์ถูกควบคุมโดยการซ่อนและแสดง เนื่องจากการพัฒนาฉันไม่ได้ใช้ข้อมูลมากเกินไปในการทดสอบซึ่งทำให้ฉันต้องพูดติดอ่างมากเมื่อมีข้อมูลมากเกินไป เจ้านายกำลังพูดถึงคาคากะซึ่งพูดติดอ่างมากกว่าวัวตัวเก่าดึงรถหัก การพูดติดอ่างแบบนี้รู้สึกชัดเจนเมื่อเลื่อนหน้า
หลังจากค้นหาสาเหตุของปัญหาทางออกต่อไปนี้:
ขั้นแรกให้คำนวณความสูงด้วยตนเองและแก้ไขความขัดแย้งในเลย์เอาต์ XIB ความราบรื่นของหน้าเลื่อนเป็นที่ยอมรับได้ แน่นอนว่ามันอาจจะดีกว่าที่จะบรรลุเค้าโครงเฟรมที่ราบรื่นขึ้น
ในเวลาเดียวกันเมื่อ XIB ใช้เลย์เอาต์ XIB ลองมีระดับให้มากที่สุดเท่าที่จะทำได้ ระดับที่มากขึ้นจะส่งผลต่อความคล่องแคล่ว
2. ข้อมูลล่าช้า
- ในตอนแรกเนื่องจากเรามีส่วนร่วมในการประมวลผลจำนวนคนที่ยังไม่ได้อ่านต่อข้อความเราแทนที่โมเดลข้อความแชทปัจจุบันผ่านหมายเลขที่ยังไม่ได้อ่านของใบเสร็จรับเงินเซิร์ฟเวอร์ เมื่อจำนวน chatterers มาถึงระดับหนึ่งผู้คนจำนวนมากจะอ่านข่าว ใบเสร็จรับเงินเป็นประจำในเวลานี้ เมื่อใบเสร็จรับเงินกลับมารีเฟรชข้อมูลบางอย่างอินเทอร์เฟซจะกลับมาอีกครั้ง ในระหว่างกระบวนการนี้จะมีการประมวลผล UNREADS มีปัญหาบางอย่างกับลูกค้า เมื่อเลื่อนหน้าให้ส่งข้อความที่ยังไม่ได้อ่านไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์ส่งคืนได้สำเร็จเพื่อระบุว่าได้อ่านแล้ว ข้อความเซิร์ฟเวอร์ถูกคิวและได้รับบ่อยครั้งไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์มักถูกส่งไปยังลูกค้า สิ่งนี้ทำให้หน้าการรีเฟรชนั้นบ่อยเกินไป มันติดอยู่กับฝั่งลูกค้าของเรา (ปัญหาเกี่ยวกับการเปลี่ยนข้อความในเวลานี้คือการค้นหาข้อมูลที่จะถูกแทนที่ระหว่างการสำรวจข้อความปัจจุบัน)
หลังจากค้นหาสาเหตุของปัญหาวิธีการต่อไปนี้ถูกใช้เพื่อแก้ปัญหา:
- บันทึกข้อความที่คุณส่งแยกต่างหากและแทนที่หมายเลขที่ยังไม่ได้อ่านจะต้องแทนที่ข้อความที่ส่งในปัจจุบันเท่านั้น
- และเมื่อพิจารณาความสูง (ความสูง forrowatindexpath) วางตำแหน่งข้อความปัจจุบันในแต่ละรุ่น เมื่อเปลี่ยนข้อความคุณสามารถอ่านและค้นหาข้อความที่จะเปลี่ยนได้อย่างรวดเร็วตามต้องการ อย่าเขียนที่นี่ cellforrowatindexpath เพื่อกำหนดตำแหน่ง มิฉะนั้นจะเป็นการหลอกลวงอีกครั้ง
ความคล่องแคล่วของวิธีการข้างต้นโดยทั่วไปตรงตามข้อกำหนด เฉพาะค้นหาข้อมูลที่จะถูกแทนที่จากข้อความที่คุณส่งและระบุตำแหน่ง เพียงแค่แทนที่โดยตรง
3. ข้อความการอ่านฐานข้อมูลติดอยู่
- ในตอนแรกเราใช้ FMDB
- เมื่อจัดเก็บข้อมูลข้อมูลโมเดลจะถูกเก็บไว้โดยตรงและพบว่าเมื่อมีข้อมูลจำนวนมากมันจะพูดติดอ่างอีกครั้ง (เราใช้งานไม่ได้) ฉันรู้สึกเร็วขึ้นเมื่อประหยัด แต่เมื่อฉันอ่านมันฉันติดอยู่เมื่อฉันได้รับข้อมูลมากเกินไป มีอีกอันที่นี่ซึ่งคือการถ่ายโอนรูปภาพไปยังข้อมูลและบันทึกไว้เมื่อคุณเข้าสู่หน้าแรกหากคุณมีรูปภาพหลายสิบภาพติดต่อกันคุณต้องรอสักครู่เมื่อคุณคลิกจากภายนอก เธรดหลักติดอยู่
เราจะแก้ปัญหาเมื่อเราพบ:
- เราใช้ WeChat Open Source WCDB สำหรับฐานข้อมูลซึ่งสนุกมากขึ้นในทุกด้าน ไม่จำเป็นต้องขอบคุณคำสั่ง SQL
หากคุณบันทึกโมเดลคุณจะได้รับโมเดลโดยไม่มีความล่าช้า
- สำหรับการประมวลผลภาพเราใช้ภาพเพื่อเก็บข้อมูลเพื่อจัดเก็บ Sandbox และใช้ฟิลด์คีย์ในที่อยู่รูปภาพและข้อความเป็นกุญแจเพื่อจัดเก็บ Sandbox ในเวลานี้ฐานข้อมูลจำเป็นต้องจัดเก็บที่อยู่เท่านั้น ขึ้นอยู่กับคีย์ตามที่อยู่นี้ค้นหารูปภาพ หลังจากทดสอบรูปภาพหลายสิบภาพฉันไม่รู้สึกเลย ที่นี่เราแคชเฉพาะรูปภาพที่เราโพสต์ ภาพของอีกฝ่าย sdwebimageview ถูกแคช จุดประสงค์ของการแคชภาพของคุณเองคือการส่งไปใช้เพื่อใช้ในการประมวลผล ที่นี่เราใช้ Nscache Cache เพื่อประมวลผลรหัสในรหัส ...
4. เมื่อหน้าเต็มไปด้วยการแสดงออกมันจะติดอยู่
- หลังการรักษาข้างต้นความคล่องแคล่วเป็นที่ยอมรับแล้ว
แต่วันหนึ่งเพื่อนร่วมงานโพสต์หน้าทั้งหมดซึ่งเต็มไปด้วยการแสดงออกบนแป้นพิมพ์ระบบและฉันก็ไปและติดอีกครั้ง และเพื่อนร่วมงานคนอื่น ๆ ก็โพสต์ว่าเป็นคาคากะซึ่งทุกคนสามารถเข้าใจได้ (และนอกจากนี้ยังมีสถานการณ์การทดสอบใน บริษัท ของเราซึ่งทุกคนทดสอบครึ่งชั่วโมงทุกวันตั้งแต่วันจันทร์ถึงวันศุกร์และครึ่งชั่วโมงทุกวันหยุดสุดสัปดาห์เจ้านายและพนักงานทุกคนอยู่ที่นั่น) เพราะเราใช้ uilable ธรรมดาโดยไม่มีการประมวลผลใด ๆ
นี่คือสิ่งที่ฉันจำได้จากการเรนเดอร์ yylable, assynchronous ทำให้อินเทอร์เฟซราบรื่นและราบรื่นขึ้น หลังจากการแทนที่ความราบรื่นเพิ่มขึ้นมาก
5. พลาดข่าวอย่างจริงจัง
- หลังจากการแชทเวอร์ชันแรกออกมาหลายคนทดสอบด้วยกัน การรั่วไหลพบว่าร้ายแรงมาก หลังจากการสอบสวนปัญหาสำคัญเกิดขึ้นเมื่อเราเก็บข่าว
- วิธีแก้ปัญหาปัจจุบัน:
- ตามข้อความที่ผลักโดยซ็อกเก็ตตราบใดที่เชื่อมต่อซ็อกเก็ตมันจะถูกบันทึกไว้
- และหลังจากได้รับข้อความจะถูกส่งกลับไปยังเซิร์ฟเวอร์ (เซิร์ฟเวอร์ได้รับข้อความที่ใหญ่ที่สุดในขณะนี้เมื่อช่วงเวลาสั้นมาก) หากไม่มีใบเสร็จรับเงินเซิร์ฟเวอร์จะส่งข้อความหลายข้อความเมื่อส่งข้อความและคุณต้องจัดการโหลดหนักด้วยตัวเอง
- ยิ่งไปกว่านั้นเมื่อเครือข่ายตัดการเชื่อมต่อซ็อกเก็ตและการเชื่อมต่อใหม่มันจะดึงข้อความได้อย่างมีประสิทธิภาพ
6. พูดถึงความล่าช้าของอวตารหลายตัว
ที่นี่เราต้องการสร้างอวตารของ 9 คนเช่น Dingtalk และ WeChat และเมื่อไม่มีอวตารคำสุดท้ายของชื่อควรแสดงในตำแหน่งของอวตาร
ที่นี่ฉันใช้ 9 ปุ่มซึ่งสามารถใช้สำหรับรูปภาพและข้อความ ฉันคิดว่ามันจะติดอยู่เมื่อมีข้อมูลจำนวนมากเมื่อฉันเขียนมัน แต่ด้วยเหตุนี้ฉันจึงคำนวณตำแหน่งการปรับเฟรมตามจำนวนอวตารจริงและซ่อนปุ่มที่ไม่จำเป็น หลังจากเขียนผลลัพธ์ เอฟเฟกต์ค่อนข้างดี ความคล่องแคล่วสามารถตอบสนองความต้องการ เพียงแค่บอกว่าอวตารนี้เขียนโดยคนสามคน เฮ้-เธอ
7. เนื้อหายังคงได้รับการปรับปรุง ...
