Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

มาดูกันว่า 4 ปีที่ผ่านมาของการพัฒนา Instagram Android App เป็นอย่างไรบ้าง ?

$
0
0

instagram-00

instagram-00 เคยนำบทความต่าง ๆ ของการพัฒนาระบบ Instagram มาแปลและสรุป ในครั้งนี้เป็นเรื่องราวสำหรับการพัฒนา Android app ว่าในช่วง 4 ปีที่ผ่านมานั้น ได้ทำอะไรมาบ้าง ? ผ่านร้อนผ่านหนาวอะไรมาบ้าง ? ตั้งแต่ version แรกที่พัฒนาด้วย engineer 2 คน ใช้เวลาไป 4 เดือน จนตอนนี้ทีมมีจำนวน 30 คนแล้ว ทำการแปลและสรุปจากบทความเรื่อง Instagram + Android: Four Years Later มาไว้นิดหน่อย น่าจะเป็นประโยชน์ต่อนักพัฒนากันบ้าง ทั้งการรับมือเรื่องขยายทีม ทั้งการรับมือเรื่องการดูแลรักษาระบบ ทั้งการเพิ่มความสามารถต่าง ๆ ทั้งการดูเรื่องขนาดของ APK ทั้งการดูเรื่อง performance ที่ขึ้นชื่อว่าเร็วมาก ๆ

เริ่มต้นด้วยข้อมูลและสถิติต่าง ๆ ก่อน

  • 30 คือ จำนวนสมาชิกของทีม Android
  • 19.3 MB คือ ขนาดของ APK แบบ raw size (ใช้ข้อมูลล่าสุดวันที่ 20 กันยายน 2556)
  • 15.4 MB คือ ขนาดของ APK แบบที่ผู้ใช้งานต้อง download และ ติดตั้ง
  • ถูกติดตั้งมากกว่า 1 พันล้านครั้ง
  • 4.5 คือคะแนนของการ review บน Google Play
  • 38 ล้านคือจำนวนคน review
สิ่งที่น่าสนใจมาก ๆ คือ การดูแลรักษา value หรือคุณค่าในสิ่งที่กำลังสร้าง นั่นหมายถึง feature บน Android app มันจะต้องมีคุณค่าเพิ่มขึ้น ตามขนาดของทีมที่โตขึ้นเสมอ

จาก Core Value ของทีมพัฒนา Instagram คือ Do the Simple Thing First

โดยจะทำการสร้าง feature ที่คนใช้ต้องการใช้ หรือ ใช้อยู่แล้วก่อนเสมอ รวมทั้งให้ความสนใจในเรื่อง performance ของระบบอย่างมาก ซึ่งจะแยกส่วนการทำงานต่าง ๆ ออกจากกันอย่างชัดเจน (Component) เพื่อทำให้สามารถแก้ไขและปรับปรุงระบบได้ง่าย ตัวอย่างเช่น Android app ทำหน้าที่ render ข้อมูลที่ได้รับจาก server ทำหน้าที่เหมือน Web browser การประมวลผล business logic ที่ซับซ้อนทำงานที่ server side ทำให้ง่ายต่อการแก้ไข bug และ เพิ่ม feature ใหม่ ในฝั่ง server จะต้องทำการส่งข้อมูลที่จำเป็นต่าง ๆ ให้ครบ ดังนั้นจึงต้องมีระบบ Continuous Integration Testing เพื่อทำให้มั่นใจว่าสิ่งที่สร้างทำงานดังที่หวัง และ feature เก่า ๆ ยังคงทำงานได้เหมือนเดิม ผลที่ตามมาก็คือ ฝั่ง Android app แทบจะไม่ต้อง ทำการตรวจสอบค่าว่าเป็น Null หรือไม่ ? ทำการตรวจสอบว่าข้อมูลใช้ได้หรือไม่ ? เนื่องจาก Android app ส่วนใหญ่ที่ crash ก็มาจากเรื่องเหล่านี้แหละนะ ดังนั้นจึงทำการแก้ไขปัญหาที่ต้นเหตุกันดีกว่า ยังไม่พอนะ ยังมีระบบ Automated Crash Report ให้อีก ซึ่งจะแจ้งสาเหตุของการ crash มาให้ แน่นอนว่ามี stack trace มาให้ เพื่อช่วยทำให้การแก้ไขง่ายขึ้น จะได้ช่วยลด ละ เลิก การ debug app !!

เมื่อ Android app มีขนาดใหญ่ขึ้น

แน่นอนว่า จำนวน source code ต้องเยอะขึ้น ดังนั้นสิ่งที่ต้องดูแลรักษาอย่างหนักก็คือ
  • Source code ต้องง่ายและทำความเข้าใจได้ง่าย
  • Source code สามารถอธิบายตัวมันเองได้
  • Source code ต้อง debug ได้ง่าย
  • ทำการ generate source code ให้น้อยที่สุด
  • ลดการใช้ runtime annotation ลงไป
  • รวมทั้งลดการใช้พวก maagic library ต่าง ๆ
โดยรวมแล้วพยายามเขียน code ให้เรียบง่ายที่สุด ไม่ซ่อนความซับซ้อนไว้ข้างหลัง ในการเขียน code นั้นทีมพัฒนา Android ได้เรียนรู้ว่า ช่วงแรกของการพัฒนานั้น ทีมมีขนาดเล็ก รวมทั้งมีความกดดันที่ต้องเสร็จเร็ว ๆ ดังนั้นใน code จึงเต็มไปด้วย inheritance !! แต่เมื่อทีมมีขนาดใหญ่ขึ้นก็พบว่า แนวทางที่ทำอยู่นั้นไม่สามารถ scale ได้ตามขนาดของทีม เนื่องจาก code แต่ละส่วนผูกติดกันอย่างมาก ผลก็คือ มันยากมาก ๆ ต่อการแก้ไข และ เพิ่ม feature ใหม่ ดังนั้นแนวคิดในการพัฒนาจึงเปลี่ยนไปใช้ Composition over inhertiance ซึ่งเหมาะสมกับทีมและสิ่งที่กำลังพัฒนามากกว่า

มาดูการ Optimize App กันบ้าง !!

โดยจะทำการปรับปรุง performance ใน feature ที่มีคนใช้งานเยอะ ๆ เป็นหลัก ตัวอย่างเช่น การจัดการกับข้อมูล JSON โดยใน version ที่ 1 นั้นใช้งาน library Jackson Data Binding ซึ่งพบปัญหาว่า ทำงานช้ามาก ๆ บนมือถือกลุ่ม Low-end (เครื่องที่ CPU และ RAM น้อย ๆ) ดังนั้นจึงทำการเขียน library ขึ้นมาใช้เอง เพื่อให้ตรงกับความต้องการ สามารถอ่านเพิ่มได้ที่ Fast, auto-generated streaming JSON parsing for Android การจัดการกับ Activity Screen โดยใน version แรก ๆ นั้นจะทำการแสดง activity ต่าง ๆ เช่นการ like และ comment ผ่าน App ด้วย WebView !!! เนื่องจากทำให้ง่ายต่อการเพิ่มชนิดของข้อมูลต่าง ๆ แต่กลับพบว่า การใช้งาน WebView นั้นทำให้ App ช้าลงไป 30% ดังนั้นจึงทำการเขียน code ขึ้นมาใหม่ สามารถอ่านเพิ่มได้ที่ Building a better Instagram app for Android
จะเห็นได้ว่า ทีมพัฒนาก็ต้องมีเครื่องมือในการวิเคราะห์ข้อมูลต่าง ๆ ของ App เพื่อทำให้เห็นว่า ส่วนไหนของ App ที่มีปัญหา ทั้ง performance, startup time, data usage รวมทั้งรายงานเกี่ยวกับ bug ต่าง ๆ อีกด้วย
ปล. ลองกลับมาดู App ของเราสิว่า ยังขาดอะไรไปบ้าง ?

มาถึงเรื่อง Effienct UI สรุปสั้น ๆ ได้ว่า

เป้าหมายก็คือ สร้าง App ที่ทำงานได้อย่างรวดเร็ว และ สวยงาม แน่นอนว่า อ่านแล้วมันดูขัดแย้งกันพอสมควร ทางทีมพัฒนา App ของ Instragram สรุปไว้ดังนี้ ในช่วง Startup time ของ App ต้องน้อย ๆ ดังนั้นพวกขนาดของรูปต้องลด ทั้งขนาด ทั้ง texture ทั้ง color ที่ไม่จำเป็นออกไป รวมทั้งพวก asset ต่าง ๆ อีก รวมไปถึงเวลาในการเปิดหน้าอื่น ๆ อีกด้วย ส่งผลทำให้ขนาดของ App เล็กลงไปด้วย ซึ่งมีผลอย่างมากต่อผู้ใช้งาน สิ่งที่ต้องใส่ใจอย่างมาก คือ UI ต้องเรียบง่าย นั่นคือง่ายต่อการสร้างมันขึ้นมา และต้องมีการกำหนดมาตรฐานต่าง ๆ ขึ้นมา เพื่อสรุปข้อตกลงในการทำงานร่วมกัน ทำให้เราสามารถสร้าง library กลางเพื่อให้คนอื่น ๆ นำไปใช้ได้ นั่นแสดงว่าทั้ง UI designer และ Developer จำเป็นต้องพูดคุยกัน เพื่อทำให้ App โตไปอย่างยั่งยืน แถมทำให้ทั้ง App มันเข้ากัน ไม่ใช่ว่า แต่ละหน้า แต่ละ feature ไปกันคนละทาง !!

มาถึงเรื่องที่ชอบมาก ๆ ก็คือ เรื่องของ Code

เป้าหมายของทีมพัฒนา คือ พยายามที่จะลด จะตัด dependency ต่าง ๆ ออกไป ให้เหลือเฉพาะสิ่งที่จำเป็นหรือใช้งานเท่านั้น โดยในแต่ละ component จะมีหน้าที่การทำงานเฉพาะเจาะจงตาม use case ทำให้เกิดการเขียน code หรือ library ขึ้นมาใช้เอง เช่น JSON parser ไม่ใช้ Dependency Injection library เนื่องจากทำให้ขนาดของ App ใหญ่ขึ้น แถมซับซ้อนขึ้นอีก และกระทบต่อ performance แน่นอน ยังไม่พอนะ ใน App จะไม่มี Google Play Library อีกด้วย เนื่องจากเขียน code ขึ้นมา เพื่อจัดการกับ GCM เอง สิ่งที่นักพัฒนาต้องเรียนรู้คือ หลีกเลี่ยง MultiDex โดยมันคือปัญหาของ App ขนาดใหญ่ทุก App แน่นอนว่า ส่งผลต่อขนาดและ performance อย่างแรง หนัก ๆ เลยก็คือ เวลาในการ build แต่ละครั้งนานมาก !! ใช้ memory เยอะมาก !! ซึ่งนักพัฒนาทุกคนน่าจะกำลังประสบภัยกันปัญหานี้อยู่ ดังนั้นทีมพัฒนา App ของ Instagram จะใส่ใจเรื่องนี้มาก ๆ จะไม่ให้เกิด multidex ขึ้นมาใน App เลย ดังนั้นสิ่งที่ต้องทำก็คือ ดูแลการใช้งาน dependency library ต่าง ๆ อย่างใกล้ชิด ในแต่ละ library ที่เขียนหรือนำมาใช้ ต้องมีชุดการทดสอบครอบคลุม มิเช่นนั้น จะไม่ยอมรับในการเปลี่ยนแปลงนั้น ๆ รวมทั้งจัดการเรื่องจำนวนของ method count ซึ่งเราต้องทั้งสนใจและใส่ใจในสิ่งที่กำลังสร้างอยู่เสมอ ลองนำไฟล์ APK ของ Instagram App มาเปิดด้วย Analyze APK แสดงดังรูป instagram-01
สุดท้ายแล้ว ประโยคที่ผมชอบมาก ๆ ก็คือ The average engineer spends 20–40% of her day on various code review and mentorship activities.

Viewing all articles
Browse latest Browse all 1997

Trending Articles