10 ข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนา Android ทำ: บทช่วยสอนการเขียนโปรแกรม
เผยแพร่แล้ว: 2022-03-11แอนดรอยด์ อะไรที่ไม่ชอบเกี่ยวกับแพลตฟอร์มนี้? ได้ฟรี ปรับแต่งได้ เติบโตอย่างรวดเร็ว และใช้งานได้ไม่เพียงแค่บนโทรศัพท์หรือแท็บเล็ตของคุณ แต่บนสมาร์ทวอทช์ ทีวี และรถยนต์ด้วย
ด้วยการอัปเดต Lollipop ล่าสุด การเขียนโปรแกรม Android ยังคงปรับปรุงต่อไป แพลตฟอร์มได้เติบโตเต็มที่ตั้งแต่เปิดตัว AOSP ครั้งแรก และกำหนดแถบความคาดหวังของผู้ใช้ค่อนข้างสูง ลวดลายดีไซน์ Material ใหม่ดูดีแค่ไหน!
มีอุปกรณ์หลายพันเครื่อง โดยมีขนาดหน้าจอ สถาปัตยกรรมชิป การกำหนดค่าฮาร์ดแวร์ และเวอร์ชันซอฟต์แวร์ต่างกัน ขออภัย การแบ่งกลุ่มลูกค้าเป็นราคาที่ต้องจ่ายสำหรับการเปิดกว้าง และมีหลายวิธีที่แอปของคุณอาจล้มเหลวบนอุปกรณ์ต่างๆ ได้ แม้ในฐานะโปรแกรมเมอร์ Android ขั้นสูงก็ตาม
บั๊กส่วนใหญ่มักถูกนำมาใช้เนื่องจากข้อผิดพลาดทางตรรกะ โดยไม่คำนึงถึงการแบ่งส่วนขนาดใหญ่ดังกล่าว บั๊กเหล่านี้ป้องกันได้ง่าย ๆ ตราบใดที่เราเข้าใจพื้นฐานที่ถูกต้อง!
ต่อไปนี้คือบทช่วยสอนการเขียนโปรแกรม Android เพื่อจัดการกับข้อผิดพลาดทั่วไป 10 ข้อที่นักพัฒนา Android ทำ
ข้อผิดพลาดทั่วไป #1: การพัฒนาสำหรับ iOS
ด้วยความยินดีอย่างยิ่ง ความผิดพลาดของ Android นี้ไม่ค่อยเกิดขึ้นบ่อยนักในทุกวันนี้ (ส่วนหนึ่งเป็นเพราะลูกค้าเริ่มตระหนักว่าวันที่ Apple กำหนดมาตรฐานการออกแบบทั้งหมดนั้นหมดไปนานแล้ว) แต่ถึงอย่างนั้น เราเห็นแอพที่เป็นโคลน iOS เป็นระยะๆ
อย่าเข้าใจฉันผิด ฉันไม่ใช่ผู้เผยแพร่การเขียนโปรแกรม Android! ฉันเคารพทุกแพลตฟอร์มที่ขับเคลื่อนโลกของมือถือให้ก้าวไปข้างหน้า แต่นี่คือปี 2014 และผู้ใช้ใช้ Android มาระยะหนึ่งแล้ว และพวกเขาก็คุ้นเคยกับแพลตฟอร์มนี้มากขึ้น การผลักดันมาตรฐานการออกแบบ iOS ให้กับพวกเขาเป็นกลยุทธ์ที่แย่มาก!
อย่าทำอย่างนั้น เว้นแต่จะมีเหตุผลที่ดีอย่างยิ่งในการละเมิดหลักเกณฑ์ (Google ทำสิ่งนี้ตลอดเวลา แต่อย่าคัดลอกและวาง)
ต่อไปนี้คือตัวอย่างบางส่วนที่พบบ่อยที่สุดของข้อผิดพลาด Android นี้:
- คุณไม่ควรสร้างแท็บคงที่และไม่ได้อยู่ด้านล่าง (ฉันกำลังชี้ไปที่ Instagram ของคุณ)
- ไอคอนการแจ้งเตือนของระบบไม่ควรมีสี
- ไม่ควรวางไอคอนแอปไว้ในสี่เหลี่ยมมุมมน (เว้นแต่จะเป็นโลโก้จริงของคุณ เช่น facebook)
- หน้าจอเริ่มต้นซ้ำซ้อนนอกเหนือจากการตั้งค่า/การแนะนำเบื้องต้น ห้ามใช้ในสถานการณ์อื่น
- รายการไม่ควรมีคาเร็ต
นี่เป็นเพียงส่วนเล็กๆ บางส่วนที่สามารถทำลายประสบการณ์ของผู้ใช้ได้
ข้อผิดพลาดทั่วไป #2: การพัฒนาสำหรับอุปกรณ์ Android ของคุณ
เว้นแต่ว่าคุณกำลังสร้างแอปคีออสก์/โปรโมชันสำหรับแท็บเล็ตเครื่องเดียว แอป Android ของคุณจะดูไม่ดีในทุกอุปกรณ์ ต่อไปนี้คือเคล็ดลับการเขียนโปรแกรม Android บางส่วนที่ต้องจำไว้:
- พิกเซลที่ไม่ขึ้นกับความหนาแน่น (dp) แตกต่างจากพิกเซลปกติ (px)
- รวมทรัพยากรหลายครั้งเพื่อพิจารณาความหนาแน่นและทิศทางที่แตกต่างกัน
- Drawable 9 แพทช์ถูกยืดให้พอดีกับหน้าจอ
มีหลายพันสถานการณ์ที่เป็นไปได้ แต่หลังจากนั้นคุณก็พัฒนาความรู้สึกที่จะครอบคลุมพวกเขาทั้งหมดด้วยกรณีไม่กี่อย่าง
คุณไม่ได้เป็นเจ้าของอุปกรณ์นับพันใช่ไหม ไม่ใช่ปัญหา. Android Emulator นั้นยอดเยี่ยมมากในการจำลองอุปกรณ์จริง ยิ่งไปกว่านั้น ลอง Genymotion ซึ่งเร็วดุจสายฟ้าแลบและมาพร้อมกับอุปกรณ์พรีเซ็ตยอดนิยมต่างๆ มากมาย
คุณลองหมุนอุปกรณ์ของคุณหรือยัง นรกทั้งหมดสามารถหลุดพ้นได้ ...
ข้อผิดพลาดทั่วไป #3: ไม่ใช้ความตั้งใจ
ความตั้งใจเป็นหนึ่งในองค์ประกอบหลักของ Android เป็นวิธีการส่งข้อมูลระหว่างส่วนต่างๆ ของแอปหรือแอปต่างๆ ในระบบที่ดียิ่งขึ้นไปอีก
สมมติว่าคุณมีแอปแกลเลอรีที่สามารถแชร์ลิงก์ดาวน์โหลดไปยังรูปภาพบางรูปทาง SMS ได้ ตัวเลือกใดในสองตัวเลือกนี้ดูสมเหตุสมผลกว่า
ตัวเลือกที่ 1:
ขออนุญาต SEND_SMS
<uses-permission android:name="android.permission.SEND_SMS" />
- เขียนรหัสของคุณเองสำหรับส่ง SMS โดยใช้
SmsManager
- อธิบายให้ผู้ใช้ฟังว่าเหตุใดแอปแกลเลอรีของคุณจึงต้องการเข้าถึงบริการที่อาจใช้เงินได้ และเหตุใดจึงต้องให้สิทธิ์นี้เพื่อใช้แอปของคุณ
ตัวเลือกที่ 2:
เริ่ม SMS Intent แล้วปล่อยให้แอปที่ออกแบบมาสำหรับ SMS ทำงานแทน
Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);
ในกรณีที่คุณมีข้อสงสัย วิธีที่ดีที่สุดคือตัวเลือกที่ 2!
วิธีนี้ใช้ได้กับเกือบทุกอย่าง การแชร์เนื้อหา ถ่ายภาพ บันทึกวิดีโอ การเลือกผู้ติดต่อ เพิ่มกิจกรรม เปิดลิงก์ด้วยแอปที่มาพร้อมเครื่อง ฯลฯ
เว้นแต่จะมีเหตุผลที่ดีในการปรับใช้แบบกำหนดเอง (เช่น กล้องที่ใช้ตัวกรอง) ให้ใช้ Intent สำหรับสถานการณ์เหล่านี้เสมอ จะช่วยประหยัดเวลาในการเขียนโปรแกรมได้มาก และตัดการอนุญาตที่ไม่จำเป็นของ AndroidManifest.xml
ข้อผิดพลาดทั่วไป #4: ไม่ใช้ชิ้นส่วน
ไม่นานมานี้ใน Honeycomb นั้น Android ได้แนะนำแนวคิดของ Fragment คิดว่าสิ่งเหล่านี้เป็นหน่วยการสร้างที่แยกจากกันโดยมีวงจรชีวิต (ค่อนข้างซับซ้อน) ของตัวเองซึ่งมีอยู่ในกิจกรรม สิ่งเหล่านี้ช่วยได้มากในการปรับให้เหมาะสมสำหรับหน้าจอต่างๆ พวกมันจัดการได้ง่ายโดยกิจกรรมของผู้ปกครอง สามารถนำกลับมาใช้ใหม่ รวมกัน และจัดตำแหน่งได้ตามต้องการ
การเปิดกิจกรรมแยกกันสำหรับแต่ละหน้าจอแอพนั้นไม่มีประสิทธิภาพอย่างมาก เนื่องจากระบบจะพยายามเก็บไว้ในหน่วยความจำให้นานที่สุดเท่าที่จะทำได้ การฆ่าคนใดคนหนึ่งจะไม่ทำให้ทรัพยากรที่ผู้อื่นใช้เป็นอิสระ
เว้นแต่ว่าคุณต้องการเจาะลึกลงไปในแกนหลักของ Android และอ่านบทความนี้ เพื่อสนับสนุนการใช้ส่วนย่อย คุณควรใช้ส่วนย่อยทุกครั้งที่ทำได้ โดยทั่วไปจะบอกว่าแฟรกเมนต์และตัวโหลดเคอร์เซอร์มีจุดประสงค์ที่ดี แต่มีการใช้งานที่ไม่ดี
ข้อผิดพลาดทั่วไป #5: การบล็อกเธรดหลัก
เธรดหลักมีจุดประสงค์เดียว: ทำให้ส่วนต่อประสานผู้ใช้ตอบสนอง
แม้ว่าวิทยาศาสตร์ที่อยู่เบื้องหลังการวัดอัตราเฟรมที่ตา/สมองของเราสามารถรับรู้ได้นั้นซับซ้อนและได้รับอิทธิพลจากปัจจัยหลายอย่าง กฎทั่วไปก็คือสิ่งใดที่ต่ำกว่า 24 fps ที่มีความล่าช้ามากกว่า 100 มิลลิวินาทีจะไม่ถูกมองว่าราบรื่น
ซึ่งหมายความว่าการกระทำของผู้ใช้จะมีการตอบสนองที่ล่าช้า และแอป Android ที่คุณตั้งโปรแกรมไว้จะหยุดตอบสนอง การทำให้ผู้ใช้ไม่สามารถควบคุมแอปได้จะนำไปสู่ความคับข้องใจ ผู้ใช้ที่ผิดหวังมักจะให้ข้อเสนอแนะเชิงลบอย่างมาก
ที่แย่ไปกว่านั้น ถ้าเธรดหลักถูกบล็อกชั่วขณะ (5 วินาทีสำหรับกิจกรรม 10 สำหรับผู้รับบรอดคาสต์) ANR จะเกิดขึ้น

สิ่งนี้พบได้ทั่วไปใน Android 2.x ซึ่งในเวอร์ชันใหม่กว่า ระบบจะไม่ให้คุณโทรผ่านเครือข่ายในเธรดหลัก
เพื่อหลีกเลี่ยงการบล็อกเธรดหลัก ให้ใช้เธรดของผู้ปฏิบัติงาน/พื้นหลังเสมอสำหรับ: 1. การเรียกใช้เครือข่าย 2. การโหลดบิตแมป 3. การประมวลผลภาพ 4. การสืบค้นฐานข้อมูล 5. การอ่าน/การเขียน SD
ข้อผิดพลาดทั่วไป #6: คิดค้นล้อใหม่
“ตกลง ฉันจะไม่ใช้เธรดหลัก ฉันจะเขียนโค้ดของตัวเองที่สื่อสารกับเซิร์ฟเวอร์ของฉันในเธรดเบื้องหลัง”
ไม่! กรุณาอย่าทำอย่างนั้น! การโทรผ่านเครือข่าย การโหลดรูปภาพ การเข้าถึงฐานข้อมูล การแยกวิเคราะห์ JSON และการเข้าสู่ระบบโซเชียลเป็นสิ่งที่คุณทำบ่อยที่สุดในแอป ไม่ใช่แค่ของคุณเท่านั้น ทุกแอปที่มีอยู่ มีวิธีที่ดีกว่า จำได้ไหมว่า Android เติบโตและเติบโตเป็นแพลตฟอร์มได้อย่างไร ต่อไปนี้คือรายการตัวอย่างโดยย่อ:
- ใช้ gradle เป็นระบบสร้าง
- ใช้ Retrofit / Volley สำหรับการโทรในเครือข่าย
- ใช้ Picasso ในการโหลดรูปภาพ
- ใช้ Gson / Jackson เพื่อแยกวิเคราะห์ JSON
- ใช้การใช้งานทั่วไปสำหรับการเข้าสู่ระบบโซเชียล
หากคุณต้องการบางสิ่งที่นำไปใช้ได้ เป็นไปได้มากที่จะมีการเขียน ทดสอบ และใช้กันอย่างแพร่หลาย ทำวิจัยพื้นฐานและอ่านบทช่วยสอนการเขียนโปรแกรม Android ก่อนเขียนโค้ดของคุณเอง!
ข้อผิดพลาดทั่วไป #7: ไม่ถือว่าประสบความสำเร็จ
ยอดเยี่ยม. เราได้เรียนรู้ว่ามีวิธีที่ดีกว่าในการจัดการงานที่ใช้เวลานาน และเรากำลังใช้ไลบรารีที่ได้รับการจัดทำเป็นเอกสารอย่างดีเพื่อจุดประสงค์นั้น แต่ผู้ใช้ยังคงต้องรอ มันหลีกเลี่ยงไม่ได้ พัสดุจะไม่ถูกส่ง ประมวลผล และรับทันที มีความล่าช้าในการเดินทาง เครือข่ายล้มเหลว พัสดุสูญหาย และความฝันถูกทำลาย
แต่ทั้งหมดนี้สามารถวัดได้ การโทรผ่านเครือข่ายที่ประสบความสำเร็จนั้นมีโอกาสมากกว่าการโทรที่ไม่สำเร็จ เหตุใดจึงต้องรอการตอบกลับของเซิร์ฟเวอร์ก่อนที่จะจัดการคำขอที่สำเร็จ จะดีกว่าอย่างไม่สิ้นสุดที่จะถือว่าประสบความสำเร็จและจัดการกับความล้มเหลว ดังนั้น เมื่อผู้ใช้ชอบโพสต์ จำนวนการชอบจะเพิ่มขึ้นทันที และในกรณีที่การโทรล้มเหลว ผู้ใช้จะได้รับการแจ้งเตือน
ในโลกสมัยใหม่นี้คาดว่าจะมีการตอบรับทันที คนไม่ชอบรอ เด็กๆ ไม่ต้องการนั่งในห้องเรียนเพื่อรับความรู้ที่ไม่แน่นอนในอนาคต แอปต้องสอดคล้องกับจิตวิทยาของผู้ใช้
ข้อผิดพลาดทั่วไป #8: ไม่เข้าใจบิตแมป
ผู้ใช้ชอบเนื้อหา! โดยเฉพาะอย่างยิ่งเมื่อเนื้อหามีรูปแบบที่ดีและดูดี ตัวอย่างเช่น รูปภาพเป็นเนื้อหาที่ดีมาก เนื่องจากคุณสมบัติในการถ่ายทอดคำได้นับพันคำต่อภาพ พวกเขายังใช้หน่วยความจำจำนวนมาก ความจำเยอะ!
ก่อนรูปภาพจะปรากฏบนหน้าจอ จะต้องโหลดรูปภาพนั้นลงในหน่วยความจำก่อน เนื่องจากบิตแมปเป็นวิธีที่พบได้บ่อยที่สุด เราจะจัดทำคู่มือการเขียนโปรแกรม Android สำหรับกระบวนการทั้งหมด:
สมมติว่าคุณต้องการแสดงภาพบนหน้าจอที่คุณเพิ่งถ่ายด้วยกล้องของคุณ หน่วยความจำทั้งหมดที่จำเป็นสำหรับสิ่งนี้คำนวณด้วยสูตรต่อไปนี้: memory_needed_in_bytes = 4 * image_width * image_height;
ทำไม 4? การกำหนดค่าบิตแมปที่พบบ่อยที่สุด / ที่แนะนำคือ ARGB_8888
นั่นหมายความว่า สำหรับแต่ละพิกเซลที่เราวาด เราจำเป็นต้องเก็บ 8 บิต (1 ไบต์) สำหรับอัลฟา สีแดง ความโลภ และช่องสีน้ำเงินในหน่วยความจำ เพื่อแสดงอย่างเหมาะสม มีทางเลือกอื่น เช่น การกำหนดค่า RGB_565
ที่ต้องใช้หน่วยความจำมากกว่า ARGB_8888
ครึ่งหนึ่ง แต่จะสูญเสียความโปร่งใสและความแม่นยำของสี (ในขณะที่อาจเพิ่มโทนสีเขียว)
สมมติว่าคุณมีอุปกรณ์ใหม่เอี่ยมที่มีหน้าจอแบบ Full HD และกล้อง 12 MP รูปภาพที่คุณเพิ่งถ่ายมีขนาดใหญ่ 4000x3000 พิกเซล และหน่วยความจำทั้งหมดที่จำเป็นในการแสดงคือ 4 bytes * 4000 * 3000 = 48 MB
RAM 48 เมกะไบต์สำหรับภาพเดียว!? นั่นเป็นจำนวนมาก!
ทีนี้มาดูความละเอียดหน้าจอกัน คุณกำลังพยายามแสดงภาพขนาด 4000x3000 บนหน้าจอที่มีขนาด 1920x1080 พิกเซล ในกรณีที่เลวร้ายที่สุด (การแสดงภาพแบบเต็มหน้าจอ) คุณไม่ควรจัดสรรหน่วยความจำเกิน 4 * 1920 * 1080 = 8.3 MB
ปฏิบัติตามเคล็ดลับการเขียนโปรแกรม Android เสมอเพื่อแสดงบิตแมปอย่างมีประสิทธิภาพ:
- วัดมุมมองที่คุณกำลังแสดงภาพของคุณ
- ปรับขนาด / ครอบตัดรูปภาพขนาดใหญ่ตามลำดับ
- แสดงเฉพาะสิ่งที่สามารถแสดงได้
ข้อผิดพลาดทั่วไป #9: การใช้ลำดับชั้นของ Deep View
เลย์เอาต์มีการนำเสนอ XML ใน Android ในการวาดเนื้อหา จำเป็นต้องแยกวิเคราะห์ XML หน้าจอต้องมีการวัด และต้องวางองค์ประกอบทั้งหมดตามนั้น เป็นกระบวนการที่ใช้ทรัพยากรและใช้เวลานานซึ่งจำเป็นต้องได้รับการปรับให้เหมาะสม
นี่คือวิธีการทำงานของ ListView (และล่าสุดคือ RecyclerView)
หากเลย์เอาต์ถูกเติมลมหนึ่งครั้ง ระบบจะนำเลย์เอาต์ไปใช้ซ้ำ แต่ถึงกระนั้นการพองเลย์เอาต์ก็ต้องเกิดขึ้นในบางจุด
สมมติว่าคุณต้องการสร้างตารางขนาด 3x3 พร้อมรูปภาพ วิธีหนึ่งในการทำเช่นนี้คือ LinearLayout
แนวตั้งที่มี 3 LinearLayout
ที่มีน้ำหนักเท่ากัน โดยแต่ละอันจะมี ImageViews
3 รายการซึ่งมีน้ำหนักเท่ากัน
เราจะได้อะไรจากแนวทางนี้? คำเตือนว่า "น้ำหนักที่ซ้อนกันไม่ดีต่อประสิทธิภาพ"
มีคำกล่าวในโลกการเขียนโปรแกรม Android ว่าฉันเพิ่งสร้างขึ้น: “ด้วยความพยายามเพียงเล็กน้อย ลำดับชั้นทั้งหมดก็แบนราบได้”
ในกรณีนี้ RelativeLayout
หรือ GridLayout
จะแทนที่ LinearLayouts
ที่ซ้อนกันอย่างมีประสิทธิภาพ
ข้อผิดพลาดทั่วไป #10: ไม่ได้ตั้งค่า minSdkVersion เป็น14
นี่ไม่ใช่ความผิดพลาด แต่เป็นการปฏิบัติที่ไม่ดี
Android 2.x เป็นก้าวสำคัญในการพัฒนาแพลตฟอร์มนี้ แต่บางสิ่งควรทิ้งไว้เบื้องหลัง การรองรับอุปกรณ์รุ่นเก่าจะเพิ่มความซับซ้อนในการดูแลโค้ดและจำกัดกระบวนการพัฒนา
ตัวเลขชัดเจน ผู้ใช้เดินหน้าต่อ นักพัฒนาไม่ควรอยู่ข้างหลัง
ฉันทราบดีว่าสิ่งนี้ใช้ไม่ได้กับตลาดใหญ่บางแห่งที่มีอุปกรณ์รุ่นเก่า (เช่น อินเดีย) และการตั้งค่า minSdkVersion
เป็น 14 ในแอป Facebook หมายถึงการปล่อยให้ผู้ใช้สองสามล้านคนไม่มีโซเชียลเน็ตเวิร์กที่พวกเขาชื่นชอบ แต่ถ้าคุณกำลังเริ่มต้นใหม่และพยายามสร้างประสบการณ์ที่สวยงามให้กับผู้ใช้ของคุณ ให้พิจารณากำจัดอดีต ผู้ใช้ที่ไม่มีทรัพยากร หรือรู้สึกว่าจำเป็นต้องอัปเกรดอุปกรณ์/ระบบปฏิบัติการ จะไม่มีแรงจูงใจที่จะลองใช้แอป Android เวอร์ชันที่เหนือกว่าและใช้จ่ายเงินไปกับมันในท้ายที่สุด
สรุป
Android เป็นแพลตฟอร์มที่ทรงพลังที่พัฒนาอย่างรวดเร็ว อาจไม่สมเหตุสมผลที่จะคาดหวังให้ผู้ใช้ก้าวทัน แต่สิ่งสำคัญสำหรับนักพัฒนา Android ที่ต้องทำเช่นนั้น
การรู้ว่า Android ไม่ได้มีแค่บนโทรศัพท์หรือแท็บเล็ตของเราเท่านั้นที่สำคัญยิ่งกว่า มันอยู่บนข้อมือของเรา ในห้องนั่งเล่น ในห้องครัว และในรถยนต์ของเรา การทำให้ข้อมูลพื้นฐานถูกต้องมีความสำคัญสูงสุดก่อนที่เราจะเริ่มขยายขอบเขต