Android DDMS: คำแนะนำสำหรับ Ultimate Android Console

การพัฒนาเป็นธุรกิจที่ยุ่งยาก เป้าหมายยังคงเคลื่อนไหว เทคโนโลยีและโดเมนใหม่ๆ ปรากฏขึ้นเป็นระยะ เครื่องมือใหม่ปรากฏขึ้นทุก ๆ ครั้ง และภาษาเปลี่ยนแปลงไปในสิ่งที่ดูเหมือนว่าจะได้รับการจัดการอย่างหายนะ

แม้จะมีการเปลี่ยนแปลงทั้งหมดเหล่านี้ กฎพื้นฐานยังคงเหมือนเดิม กฎพื้นฐานที่สำคัญที่สุดข้อหนึ่งระบุว่าในการสร้างซอฟต์แวร์ที่ยอดเยี่ยม คุณจะต้องได้รับการพิจารณาอย่างละเอียด ถี่ถ้วน ในระบบดำเนินการของคุณ การ วินิจฉัย การ ดีบัก และ การทำโปรไฟล์ บางครั้งใช้ในบริบทนี้ แต่กฎมีความลึกกว่า นักพัฒนาระดับแนวหน้า "รู้สึก" ระบบของเขาอย่างแท้จริง เขารู้ว่าสิ่งที่จะเกิดขึ้นคือการรอหน่วยความจำเพิ่มเติมที่จะปล่อยออกมา สิ่งที่จะทำให้เธรดของมันเข้าสู่ภาวะขาดแคลน CPU ซึ่งการกระทำจะส่งผลให้มีการเข้าถึง I/O หรือเครือข่ายอย่างกว้างขวาง ซึ่งจะทำให้การทำงานทั้งหมดช้าลง

ไม่มีทางเลยจริงๆ คุณอาจเป็นนักพัฒนาที่ฉลาดมากในการเขียนโค้ดที่ยอดเยี่ยม แต่จนกว่าคุณจะไม่มีทักษะดังกล่าว กล่าวคือ สามารถตรวจสอบและศึกษารายละเอียดพฤติกรรมรันไทม์ของระบบของคุณได้ คุณจะยังคงล้มเหลวในการส่งมอบสิ่งที่เหนือกว่า แอปพลิเคชัน

ในความเป็นจริง หลังจากได้รับประสบการณ์บางอย่าง คุณจะตรวจพบ "โรครหัส" ทั้งหมวด ซึ่งสามารถสืบย้อนไปถึงการละเลยกฎของการวิปัสสนา กล่าวสั้น ๆ ว่า การเขียนโค้ด (บางครั้งเป็นสมาร์ทโค้ด) โดยไม่มีการตรวจสอบผลกระทบต่อแพลตฟอร์มจริงอย่างต่อเนื่อง .

DDMS ใน Android: อาวุธที่ฉันเลือกเพื่อการวิปัสสนา

โชคดีสำหรับเรา ชุมชน Android สามารถส่งมอบเครื่องมือวิปัสสนาชั้นยอดได้มากมาย Stetho ของ Facebook อยู่ในกลุ่มที่ดีที่สุด ARO ของ AT&T (“Application Resource Optimizer”) นั้นค่อนข้างเก่าแต่ยังคงอยู่ในระดับสูงสุด โดยอาจเป็นคอนโซลการตรวจสอบเครือข่ายที่ดีที่สุด ในขณะที่ LeakCanary ใช้แนวทางที่จำกัดมากขึ้นในการมุ่งเน้น (และทำได้ดีที่ มัน) บนไลบรารีการตรวจจับการรั่วไหลของหน่วยความจำรันไทม์ เรื่องสั้นโดยย่อ ไม่มีปัญหาการขาดแคลนเครื่องมือแก้ไขข้อบกพร่องของ Android

อย่างไรก็ตาม เพชรในมงกุฎ เครื่องมือวิปัสสนาที่จะไว้วางใจเมื่อจำเป็นต้องดึงข้อมูลที่สำคัญ ถูกต้อง และจัดรูปแบบที่ดีเกี่ยวกับพฤติกรรมรันไทม์ของแอปของคุณยังคงเป็น Dalvik Debug Monitor Server (DDMS) แบบเก่าที่ดีใน Android Studio ซึ่ง อยู่กับเราแล้ว (แต่น่าเสียดายที่หลายๆ ทีมใช้งานไม่ได้) ตั้งแต่สมัยของปลั๊กอิน Eclipse Android

DDMS สำคัญแค่ไหนในการพัฒนา Android? การรู้ว่าตอนนี้ฉันรู้อะไรบ้างเกี่ยวกับ DDMS และการตรวจสอบแอปบนอุปกรณ์เคลื่อนที่โดยทั่วไปเมื่อ 5-6 ปีที่แล้ว ในฐานะนักพัฒนา Android ที่มีประสบการณ์น้อย จะช่วยฉันให้หายปวดหัวและต้องแก้จุดบกพร่อง หลาย คืน

และที่สำคัญคือ DDMS นั้นง่ายต่อการควบคุม!

แน่นอนว่าการใช้งานส่วนใหญ่อย่างถูกต้องเช่นเดียวกับเครื่องมือซอฟต์แวร์อื่น ๆ นั้นมาพร้อมกับประสบการณ์ คุณต้องฝึกฝนทักษะทางวิชาชีพของคุณสักระยะหนึ่งจนกว่าคุณจะเก่งด้านการตรวจสอบประสิทธิภาพรันไทม์ แต่แม้ในเวลาไม่กี่ชั่วโมง พูดหลังจากอ่านบทความนี้ ถ้าคุณทำตามคำแนะนำของฉันและนำไปใช้กับแอปถัดไปของคุณ ผลลัพธ์จะน่าทึ่ง! การทำโปรไฟล์และการปรับแต่งแม้แต่ระบบที่ซับซ้อนก็ไม่ใช่เรื่องยาก ก็สามารถสนุกได้เช่นกัน!

มักมีคำถามเกี่ยวกับความแตกต่างระหว่างนักพัฒนามือถือมือใหม่และนักพัฒนาซอฟต์แวร์ระดับมาสเตอร์ การเรียนรู้ DDMS ใน Android หรือในแง่ทั่วไป ความสามารถในการทำโปรไฟล์แอปพลิเคชันและวิปัสสนา—เป็นข้อแตกต่างที่สำคัญอย่างหนึ่ง

หมายเหตุ: ส่วนสำคัญของการเป็นนักพัฒนาระดับแนวหน้าคือการใช้ไลบรารีที่ดีที่สุดในโดเมนของคุณ ในบทความ Toptal ก่อนหน้านี้ ฉันได้ระบุไลบรารีสำหรับนักพัฒนาที่ดีที่สุดสำหรับ Android ในแง่หนึ่ง บทความนี้เป็นผลสืบเนื่องของบทความ "ห้องสมุด" และครอบคลุมหนึ่งในเครื่องมือ Android จำนวนมาก หากคุณตั้งเป้าที่จะพัฒนาทักษะนักพัฒนา Android โปรดอ่านเลย!

คู่มือฉบับย่อสำหรับ DDMS ใน Android Studio

และตอนนี้โดยไม่ต้องกังวลใจอีกต่อไป ให้เราเจาะลึกรายละเอียดของ DDMS ซึ่งเป็นหนึ่งในเครื่องมือสำหรับนักพัฒนา Android ขั้นสูงสุด

เมื่อชั่งน้ำหนักโดยเปล่าประโยชน์ อาจไม่มีเครื่องมืออื่นใดที่สามารถปรับปรุงคุณภาพของแอปและช่วยคุณในการค้นหาจุดบกพร่อง ที่ ยุ่งเหยิงและเข้าใจยากที่แอปนั้นมีอยู่ แต่ด้วยเหตุผลบางอย่าง (ความเกียจคร้านใคร?) หลายทีมจึงใช้ DDMS ไม่ได้

เริ่มต้นด้วยหลักสูตรเร่งรัดใน DDMS:

DDMS สามารถเข้าถึงได้ผ่านทาง Studio > Tools > Android > Android Device Monitor แล้วคลิกปุ่ม DDMS บนเมนู คุณยังสามารถวางเป็นไอคอนทางลัด (ฉันทำได้) ในแผงด้านบนของคุณ

เมื่อเปิดแล้ว นี่คือสิ่งที่คุณจะเห็น:

แผงด้านซ้ายช่วยให้สามารถเลือกอุปกรณ์/แอปได้ และคอนโซลด้านขวาจะมีมุมมองหลายมุมมอง โดยแต่ละรายการจะอยู่ในแท็บของตัวเอง โดยแต่ละรายการจะแสดงมุมมองเฉพาะของแอป

บริการหลักที่จัดเตรียมโดย Dalvik Debug Monitor Server คือ:

• สถิติการใช้หน่วยความจำของแอป (สถิติทั้งหมดของฮีปและการจัดสรรอ็อบเจ็กต์)
• สถิติเธรดของแอป
• แคปหน้าจออุปกรณ์
• ตัวสำรวจไฟล์อุปกรณ์
• สายเรียกเข้าและ SMS ปลอมแปลง
• การปลอมแปลงข้อมูลตำแหน่ง
• Logcat

ในการรับค่าหน่วยความจำฮีปปัจจุบันที่แอปของคุณใช้ ให้ทำดังนี้:

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

บรรทัดสุดท้ายนี้อาจต้องการคำอธิบายเพิ่มเติม การใช้หน่วยความจำเป็นหนึ่งในค่าวิเคราะห์ที่ ไดนามิก ของมันมีความสำคัญมากกว่าค่าเริ่มต้น สำหรับแอปส่วนใหญ่ เราจะไม่สนใจค่าการใช้ฮีพเริ่มต้นมากนัก เราจะใส่ใจอย่างมากเกี่ยวกับความคืบหน้าของค่านี้ เนื่องจากจะช่วยให้เรามองเห็นฝันร้ายที่แท้จริงที่รอนักพัฒนาอุปกรณ์พกพาได้อย่างชัดเจน นั่นคือหน่วยความจำ Android รั่ว:

การใช้โมดูล heap stat ของฉันเป็นเรื่องง่าย เป็นส่วนหนึ่งของวงจรชีวิตการพัฒนาแอป หลังจากแนะนำการเปลี่ยนแปลงที่อาจส่งผลต่อการใช้ฮีพ ฉันจะเปิดใช้งานโมดูล "สาเหตุ GC" เพื่อเริ่มการรวบรวมสถิติ เปิดใช้งาน (โดยปกติมากกว่าหนึ่งครั้ง) ตำแหน่งที่เน้นฮีปของแอปของฉัน และ "ทำให้ GC" รีเฟรชเป็นระยะ หากการใช้ฮีพเพิ่มขึ้นเรื่อยๆ ฉันมีหน่วยความจำรั่วในมือและต้องแก้ไข (รายละเอียดวิธีการ - ด้านล่าง) ถ้าไม่ใช่และไม่ว่าขนาดฮีปที่แท้จริงจะเป็นเท่าใด ฉันก็โอเค

หากตรวจพบหน่วยความจำรั่ว เครื่องมือต่อไปที่ฉันจะใช้คือ Object Allocation Tracker มาดูกันว่ามันทำอะไรได้บ้างสำหรับการจัดการหน่วยความจำใน Android

ตัวติดตามการจัดสรรวัตถุ

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

ในการเริ่มติดตาม ให้ทำดังนี้:

• เลือกอุปกรณ์/กระบวนการที่เกี่ยวข้องเหมือนเดิม
• สลับไปที่แท็บ Allocation Tracker แล้วคลิก Start Tracking เพื่อเริ่มต้น
• จากนี้ไป การจัดสรรใหม่ทั้งหมดจะถูกติดตาม
• คลิก "รับการจัดสรร" เพื่อดูรายการการจัดสรรล่าสุดทั้งหมด (ล่าสุดตั้งแต่ "เริ่มต้น")
• หากต้องการทราบว่าใครเป็นผู้มีอำนาจในการจัดสรร ให้คลิกบรรทัดที่ระบุในรายการ

จากประสบการณ์ของฉันเอง การดำเนินการที่เน้นการจัดสรรในแอปของคุณตามด้วยการคลิก "รับการจัดสรร" เพื่อดูตัวนับการจัดสรร โดยทั่วไปแล้วควรนำคุณไปสู่การรั่วไหลอย่างตรงไปตรงมา บางครั้ง เมื่อการรั่วไหลไม่เป็นเชิงเส้น (เช่น เกิดขึ้นเป็นครั้งคราว) หรือเมื่อแอปของคุณมีการรั่วไหลหลายครั้งที่อาจใช้งานไม่ได้ ในกรณีเช่นนี้ และฉันไม่เคยเจอสิ่งเหล่านี้มาก่อน คุณจะต้องใช้วิธีสร้างไฟล์ดัมพ์ HPROF ด้วยตนเองและวิเคราะห์มัน บทความนี้จะไม่กล่าวถึงการวิเคราะห์หน่วยความจำและการจัดการหน่วยความจำ Android ในเชิงลึก ดูที่นี่สำหรับโอกาสในการขาย

คอนโซลข้อมูลเธรด: การใช้งาน CPU ของ Android ทำได้ง่าย

เส้นทางตรรกะของการดำเนินการแบบซิงโครนัสเป็นที่รู้จักกันดีสำหรับนักพัฒนาทุกคน โดยจะจัดกลุ่มเป็นเธรด โดยแต่ละเส้นทางจะประกอบขึ้นเป็นลำดับขั้นตอนของการดำเนินการภายในแอปของคุณ แท้จริงแล้วแอพทั้งหมดใช้การดำเนินการมากกว่าหนึ่งเธรด บางคนใช้หลายสิบคน

การตรวจสอบปัญหาที่อาจเกิดขึ้นโดยรวมเมื่อใช้ชุดข้อความอยู่นอกขอบเขตของบทความนี้ ให้เรามุ่งความสนใจไปที่หัวข้อเดียว กล่าวคือ ความอดอยากของเธรด ซึ่งเป็นปัญหาหลักที่คุณจะไปที่คอนโซลข้อมูลเธรด

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

คอนโซลเธรด Android DDMS เพื่อช่วยเหลือ!

เมื่อคุณเข้าสู่มุมมองเธรด คุณจะเห็นรายการที่ประกอบด้วยเร็กคอร์ดของเธรด ซึ่งแต่ละรายการมีชื่อและ ID ของเธรด และตัวนับเพิ่มเติมสองตัวที่เรียกว่า utime และ stime Utime วัดเวลาทั้งหมดที่ใช้โดยเธรดที่รันโค้ดผู้ใช้ (ให้นึกถึงฟังก์ชันของคุณและไลบรารีของบุคคลที่สาม) ในขณะที่ stime จะวัดเวลาทั้งหมดที่ใช้ไปกับโค้ดระบบ (สลีป ซิงโครไนซ์ การเรียกใช้ระบบ—ล็อต) อันแรก—utime—มักจะน่าสนใจกว่าสำหรับเรา แม้ว่าฉันจะนึกถึงปัญหาที่ส่วนใหญ่จะแสดงออกมาเองโดยตัวนับเวลา

ตกลง เรามีโค้ดของเราทำงานอยู่ รวมถึงหลายเธรด และเราต้องการให้แน่ใจว่าเธรดทั้งหมดของเราได้รับส่วนแบ่งของเวลา CPU สำหรับสิ่งนี้ อันดับแรก เราปล่อยให้ระบบของเราทำงานชั่วขณะหนึ่ง จากนั้นจึงเปิดแท็บเธรดและเริ่มค้นหาค่า Utime ที่ "แปลกประหลาด" Zero สามารถแสดงถึงปัญหาได้อย่างแน่นอน—เธรดไม่มีเวลา CPU และไม่มีการใช้งาน CPU อย่างแท้จริง แต่ค่าที่สูงเกินไปอาจแสดงถึงแง่มุมที่แตกต่างกันของปัญหาเดียวกัน กล่าวคือ เธรดที่มีลำดับความสำคัญสูงจนทำให้ผู้อื่นอดอยาก

โปรดทราบว่าสำหรับเธรดประเภทหนึ่ง ค่า Utime ที่เป็นศูนย์หรือใกล้ศูนย์จะไม่ระบุถึงปัญหาที่แท้จริง นี่คือเธรดที่ผูกกับ I/O เธรดที่ส่วนใหญ่ทำการเข้าถึงเครือข่ายหรือดิสก์ (หรือฐานข้อมูล) เธรดเหล่านี้ ควร ใช้เวลาส่วนใหญ่ในการรอให้ข้อมูลมาถึงหรือปิดกั้นการเรียกของระบบที่ค้างอยู่ การกระทำเหล่านี้จะไม่เพิ่มตัวนับ utime รู้หัวข้อของคุณ!

เคล็ดลับ: อย่าใช้ชื่อเริ่มต้นของเธรด มันไม่มีความหมายอะไรเลย และโดยทั่วไปแล้วคุณจะตรวจไม่พบในมุมมอง DDMS เมื่อใดก็ตามที่สร้างหรือดึงเธรดจากพูลเธรด ให้เริ่มการโต้ตอบของคุณโดยกำหนดด้วยชื่อที่อธิบายตนเองได้ สิ่งนี้จะทำให้ชีวิตของคุณง่ายกว่าการดีบัก/การทำโปรไฟล์ระบบของคุณ ฉันมักจะเติมชื่อแอปไว้ข้างหน้าเพื่อแยกความแตกต่างระหว่างเธรดที่สร้างโดย Android และเธรดที่สร้างด้วยรหัสของฉันเอง เช่น: MyApp-server-connector, MyApp-db-interactor เป็นต้น

เคล็ดลับ: ลำดับความสำคัญของเธรดหมายถึง (พูดอย่างหลวมๆ) จำนวนเวลา CPU ที่ตัวจัดกำหนดการจะมอบให้ ลำดับความสำคัญที่กำหนดให้กับเธรดผู้ปฏิบัติงานของคุณมีความสำคัญอย่างยิ่งต่อประสิทธิภาพโดยรวมและ "ความราบรื่น" ของแอป และในหลายกรณี อาจมีความแตกต่างระหว่างการทำงานที่เร็วและลื่นไหลและการทำงานที่ช้าเป็นหลุมเป็นบ่อ กฎนี้เรียบง่าย: ลำดับความสำคัญเริ่มต้นที่กำหนดโดย Android ซึ่งคือ NORMAL=5 มักไม่ใช่ลำดับความสำคัญที่คุณต้องการใช้ สำหรับเธรดของผู้ปฏิบัติงานส่วนใหญ่ คุณต้องการผลกระทบที่น้อยลงต่อการใช้งาน CPU โดยรวม เมื่อต้องการทำเช่นนี้ เมื่อเริ่มต้นเธรด ให้ตั้งค่าลำดับความสำคัญเป็นค่าที่น้อยกว่า ฉันมักจะใช้ Priority=3

คอนโซลสถิติเครือข่าย

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

แกน y ในแผนภูมิเครือข่ายแสดงความเร็วการถ่ายโอนของการส่งที่วัดเป็น KB/วินาที ในขณะที่แกน x แสดงถึงเวลาที่ผ่านไปในหน่วยวินาที ดังนั้น เพื่อให้ได้ค่าประมาณอย่างรวดเร็วของขนาดการส่ง ให้ลองประมาณพื้นที่ของยอดแหลมที่เกี่ยวข้อง หลังจากนั้นไม่นานสิ่งนี้จะค่อนข้างง่าย

โปรดทราบว่าหลังจากป้อนคอนโซลนี้ คุณจะต้องคลิกปุ่ม "เปิดใช้งาน" ด้านบนเพื่อให้การวัดเครือข่ายเริ่มปรากฏขึ้น

ก่อนที่คอนโซลเครือข่ายจะเติบโตจนถึงระดับที่เป็นอยู่ตอนนี้ นักพัฒนามักจะต้องหันไปใช้แอปดมกลิ่น (บางคนยังคงทำอยู่) เพื่อรับข้อมูลที่คล้ายกัน

สิ่งที่ยอดเยี่ยมเกี่ยวกับคอนโซลนี้คือการแสดงภาพพฤติกรรมการใช้แบตเตอรี่หลักอย่างหนึ่ง นั่นคือการสื่อสารขนาดแพ็คเก็ตขนาดเล็กอย่างต่อเนื่อง หลายๆ คนคงทราบกันดีอยู่แล้ว สิ่งที่ทำให้แอปของคุณเป็นตัวระบายแบตเตอรีนั้นไม่ใช่เครือข่ายแบบเข้มข้นเพียง 5 นาที แต่เป็นการสร้างเครือข่ายซ้ำๆ ในระยะเวลาอันสั้น เช่น เพื่อรักษา การวินิจฉัย หรือการอัปเดตสถานะ

เมื่อตรวจพบรูปแบบดังกล่าวแล้ว และการแสดงแพ็กเก็ตที่มองเห็นได้ของคอนโซลเครือข่ายทำให้คิดแบตช์ได้ง่ายยิ่งขึ้นในทันที ฉันสามารถแบทช์การส่งข้อมูลขนาดเล็กหลาย ๆ อันให้เป็นอันเดียวขนาดใหญ่ได้หรือไม่ ผลกระทบของแบตเตอรี่จากการเปลี่ยนแปลงนี้ทำให้ต้องย้ายแอปจากที่ระบายแบตเตอรี่ไปยังหมวดหมู่ที่มีพฤติกรรมที่ดี!

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

แม้ว่าคุณจะไม่ค่อยใช้ข้อมูลนี้ แต่โปรดทราบว่า DDMS อาศัยสแต็ก Android Debug Bridge (ADB) เพื่อส่งข้อมูลกลับ/จากอุปกรณ์ หาก DDMS ไม่แสดงแอปของคุณ หรือค้างระหว่างเซสชัน DDMS ทางออกที่ดีที่สุดของคุณคือเปิดคอนโซลและพิมพ์:

 adb devices

เพื่อให้แน่ใจว่าอุปกรณ์ของคุณสามารถเข้าถึงได้และได้รับอนุญาตจาก ADB หากไม่เป็นเช่นนั้น ในหลาย ๆ กรณี การรีสตาร์ทเซิร์ฟเวอร์ ADB ในพื้นที่ของคุณควรแก้ปัญหาได้:

 adb kill-server adb devices # restarts the adb server and displays all detected devices

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

ตัวอย่างการใช้งาน DDMS ในชีวิตจริง: แอปหยุดทำงาน (ไม่ขัดข้อง เพียงหยุดชั่วคราว) ผู้ใช้รีบไปที่เวิร์กสเตชันใกล้เคียงทันที เชื่อมต่อกับ USB และเปิด DDMS ในมุมมองเธรดเพื่อค้นหาเธรดสแต็ก » เธรดที่ล้มเหลว » การติดตามสแต็ก ในกรณีของฉันเนื่องจากการหยุดชะงักของการซิงโครไนซ์ซึ่งเมื่อตรวจพบแล้ว แก้ไขได้อย่างง่ายดายโดยการสลับ

เคล็ดลับ: หากหน่วยความจำ RAM มาตรฐานที่ Android จัดสรรให้กับแอปของคุณไม่เพียงพอ เช่น แอปที่เน้นสื่อ โปรดทราบว่าคุณสามารถเพิ่มหน่วยความจำเพิ่มเติม 15-20% บนอุปกรณ์ส่วนใหญ่ได้โดยการเพิ่มแฟล็กรายการ _ largeHeap : https://developer.android.com/guide/topics/manifest/application-element.html_

การจำลองสถานะอุปกรณ์ใน Android DDMS

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

ตัวอย่างเล็กๆ น้อยๆ สำหรับอย่างหลังคือแอป GPS พวกเราส่วนใหญ่ไม่พัฒนาแอพดังกล่าว (แต่ตลาดยังไม่ใหญ่พอ…) แต่ในหลายกรณี เราปรับใช้ลอจิก ซึ่งขึ้นอยู่กับตำแหน่ง ไม่ว่าจะเป็นมุมมองแผนที่อย่างง่ายของตำแหน่งปัจจุบันของผู้ใช้ การติดตามเส้นทาง หรือการแสดงข้อมูลตามตำแหน่ง

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

แต่กระนั้น—เราจะจัดการกับอินสแตนซ์อีมูเลเตอร์อย่างไร? เราจะทดสอบการเปลี่ยนแปลงเหล่านี้ได้อย่างไร

DDMS เข้าช่วยเหลืออีกครั้ง หนึ่งในคุณสมบัติที่แข็งแกร่งกว่าแต่มักถูกมองข้ามของ DDMS คือความสามารถในการสร้างเหตุการณ์จำลอง (“การปลอมแปลง”) ลงในอินสแตนซ์ของโปรแกรมจำลองที่ทำงานอยู่ DDMS สามารถโทรออกจากหมายเลขเฉพาะไปยังโปรแกรมจำลอง ส่ง SMS เปลี่ยนข้อมูลสถานะโทรศัพท์ และอื่นๆ

เมื่อมาถึงอีมูเลเตอร์แล้ว เหตุการณ์ที่ปลอมแปลงเหล่านี้จะไม่สามารถแยกแยะจากเหตุการณ์ "จริง" ได้อีกต่อไป กล่าวคือ ราวกับว่าได้รับจากเซ็นเซอร์ฮาร์ดแวร์ที่อยู่เบื้องล่าง โดยเฉพาะอย่างยิ่ง ตัวรับสัญญาณของแอปที่เกี่ยวข้องทั้งหมดจะเปิดใช้งานในลักษณะเดียวกับที่เกิดขึ้นเมื่อรับสาย/ข้อความ SMS จริง

การเปิดใช้งานสถานะโทรศัพท์และการดำเนินการค่อนข้างตรงไปตรงมา:

หากต้องการทดสอบแอปของคุณสำหรับกรณีที่มีการเชื่อมต่อเครือข่ายต่ำ (ซึ่งคุณควรทำในแอปที่เน้นเครือข่าย) ให้ไปที่ส่วนสถานะโทรศัพท์และตั้งค่าความเร็วและเวลาแฝงเป็นค่าที่ต้องการ ฉันมักจะใช้ค่า GPRS สำหรับทั้งคู่เป็นวิธีที่มีประสิทธิภาพในการเลียนแบบการเชื่อมต่อต่ำ แต่คุณสามารถตั้งค่าของคุณเองได้ตามสบาย

ในการจำลองการโทรหรือ SMS ให้ไปที่ส่วนการดำเนินการทางโทรศัพท์ ตั้งค่าหมายเลขโทรศัพท์ต้นทาง เพิ่มข้อความตัวอักษรหากจำเป็น และยิงออกไป เครื่องมือนี้มีประสิทธิภาพโดยเฉพาะอย่างยิ่งเมื่อคุณกำหนดเส้นทางรหัสเฉพาะสำหรับการโทรจากต่างประเทศและต้องการทดสอบด้วยงบประมาณ

สิ่งต่าง ๆ น่าสนใจยิ่งขึ้นเมื่อพูดถึงการเยาะเย้ยสถานที่ใหม่

หากเป้าหมายทั้งหมดของคุณคือการตั้งค่าตำแหน่งใหม่สำหรับอินสแตนซ์อีมูเลเตอร์ของคุณ ให้เลือก กำหนดเอง ตั้งค่าละติจูด/ลองจิจูดที่ต้องการ แล้วกด ส่ง

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

สำหรับสิ่งนี้ เราจะใช้รูปแบบพิเศษที่เรียกว่า KML ซึ่งได้รับการพัฒนาโดยเฉพาะเพื่อใช้กับ Google Earth และแสดงเส้นทางหรือเส้นทางเป็นชุดของจุดที่เชื่อมต่อกันในอวกาศ ซึ่งสามารถมาจากอุปกรณ์ที่เปิดใช้งาน GPS ได้

GPX เป็นรูปแบบพาธทางเลือกที่ DDMS รองรับ สำหรับวัตถุประสงค์ในทางปฏิบัติทั้งหมด ทั้งสองควรพิจารณาใช้แทนกันได้เมื่อใช้สำหรับการปลอมแปลงตำแหน่งบนอุปกรณ์เคลื่อนที่

ตอนนี้ให้เราเดินผ่านขั้นตอนของการตั้งค่าเส้นทางจำลองในโปรแกรมจำลอง

1. สร้างเส้นทาง วิธีที่ง่ายที่สุดคือการใช้ตัวเลือกทิศทางของ Google Maps เพื่อกำหนดต้นทางและปลายทางที่เหมาะสม

1. เมื่อเส้นทางแสดงบนแผนที่ ไปที่บรรทัดที่อยู่และคัดลอก URL

2. ด้วย URL ในคลิปบอร์ด ให้ไปที่ GPS Visualizer วางลงในช่องข้อความ "ระบุ URL" แล้วคลิกปุ่มแปลง:

และคลิกเพื่อดาวน์โหลดไฟล์ GPX ที่เป็นผลลัพธ์ (ด้วยชื่อที่ค่อนข้างยุ่ง เช่น 20170520030103-22192-data.gpx)

1. กลับไปที่การควบคุมตำแหน่ง DDMS เปิดแท็บ GPX คลิกโหลด GPX และเลือกไฟล์ที่ดาวน์โหลดใหม่

1. เสร็จแล้ว! ขณะนี้คุณสามารถนำทางไปมาระหว่างตำแหน่งเส้นทางต่างๆ ได้โดยคลิกปุ่มย้อนกลับและไปข้างหน้า หรือโดยคลิกปุ่มเล่นเพื่อไปยังเส้นทางโดยอัตโนมัติด้วยความเร็วที่ตั้งไว้

คุณไม่จำเป็นต้องสร้างเส้นทางของคุณเอง มีเส้นทางมากมายให้ดาวน์โหลดจากเว็บไซต์ เช่น OpenStreetMap (ดูหัวข้อ 'GPS Traces')

สุดท้ายนี้ โปรดทราบว่าไม่เหมือนกับ DDMS เวอร์ชันเก่า ที่การโหลดไฟล์เส้นทางเป็นเรื่องง่าย เวอร์ชันที่ใหม่กว่าอาจต้องมีการลองผิดลองถูกเมื่อโหลดเส้นทางเฉพาะ

ตัวอย่างเช่น ปรากฏว่า DDMS รองรับเฉพาะ GPX 1.1 เท่านั้น GPX เวอร์ชันใหม่อาจต้องมีการปรับเปลี่ยนด้วยตนเอง

นอกจากนี้ ไม่รองรับรูปแบบจุดอ้างอิง GPX อีกต่อไป ให้ใช้รูปแบบการติดตาม GPX แทน:

 <trk> <name /> <cmt /> <trkseg> <trkpt lat="27.0512" lon="-80.4324"> <ele>0</ele> <time>2017-02-02T08:01:41Z</time> </trkpt> </trkseg> </trk>

การดีบัก Android: หนึ่งชั่วโมงต่อสัปดาห์สร้างความแตกต่าง!

ทฤษฎีพอ! ตอนนี้ได้เวลาฝึกฝนแล้ว ฉันขอแนะนำ สมมติว่าคุณเป็นนักพัฒนา Android ที่เริ่มต้นในโปรเจ็กต์ถัดไป คุณจะต้อง ใช้เวลาเพียงหนึ่งชั่วโมงต่อสัปดาห์ ในการทบทวนประสิทธิภาพของแอปผ่าน DDMS

คุณจะประหลาดใจกับปริมาณ ข้อมูลที่มีคุณภาพ (เช่น ข้อมูลที่อาจนำไปใช้ในการปรับปรุงสถานะแอปของคุณทันที) ซึ่งจะให้ข้อมูลนี้แก่คุณ!

Android DDMS ตามที่ฉันได้เห็นมาครั้งแล้วครั้งเล่ากับนักพัฒนามือใหม่ เป็นเครื่องมือที่สามารถปรับปรุงความสามารถของนักพัฒนาได้อย่างมาก หากมันเชี่ยวชาญและใช้งานอย่างเหมาะสม ความสามารถของนักพัฒนา Android ในการนำเสนอระบบระดับแนวหน้าจะเพิ่มขึ้นหนึ่งหรือสองอย่างแท้จริงเมื่อพวกเขาแตะศักยภาพของ DDMS ในการพัฒนา Android อย่างเต็มที่ ดังนั้น การสละเวลาสักสองสามชั่วโมงเพื่อใช้ประโยชน์จาก DDMS ให้เป็นประโยชน์จึงดูเหมือนเป็นการลงทุนที่ฉลาด เนื่องจากสามารถปรับปรุงประสิทธิภาพและประสิทธิภาพของ Android ได้อย่างมาก

เป็นหนึ่งในคนฉลาด ใช้มัน.