เคยนำบทความต่าง ๆ ของการพัฒนาระบบ 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
แสดงดังรูป
สุดท้ายแล้ว
ประโยคที่ผมชอบมาก ๆ ก็คือ
The average engineer spends 20–40% of her day on various code review and mentorship activities.
