ระหว่างทำงานมาหลาย ๆ ปีนี้ feature เราก็งอกเงยขึ้นเรื่อย ๆ เป็นดอกเห็ด ทำให้ การ build code กินเวลานาน ยิ่งมีใครดีลกับพวกโฆษณาเข้ามาด้วยนี้ library ครอบจักรวาล หรือเอาจริง ๆ implement google-playservice มันก็เริ่มกินเวลา build นานขึ้นแล้ว จากกดปุ๊บมาปั๊บ เดี๋ยวนี้กดไปรอ 4 นาทีบ้างหรือหนักหน่อยก็ 7 นาที ตามรูป
// insert image so long builing
ล้อเล่นนะ มันบัคไปแล้วแต่เลขยังวิ่งอยู่เฉย ๆ
ปัญหา build time งอกแบบนี้ เป็นการเผา resource ไปโดยเปล่าๆ เราเลยหาวิธีแก้ไขมันอยู่พักใหญ่ ๆ ล้มลุกคลุกคลานและเผาเวลาของเราไปพักนึงแล้ว เลยได้ข้อสรุปประมาณนี้ สิ่งที่ช่วยให้ build ได้เร็วขึ้นหลัก ๆ เลยคือ
1.Remove Unused Resource
2.Fix Min SDK, Fix Resource and Disable multiple CPU build
3.Cache Gradle
4.Instant Run
5.Fix Warning Comment and Remove Unused Import Class
#Unused Resource
Unused resource ลบ ๆ มันไปบ้างไฟล์ไหนไม่จำเป็นก็ลบมันออกไป APK size มหึมา install ทีเสียเวลาชิบ ใครไม่ใช้อะไรก็ลบ ๆ ทิ้งมันไปเถอะ เตือนนิด ก่อนลบคุยกับเพื่อนก่อนนะ เดี๋ยวไปลบไฟล์ที่เตรียมจะเอาไปทำ feature ไม่รู้ด้วย
หรือให้ Android Studio ช่วยก็ได้ Refector -> Remove Unused Resource
# Fix Min SDK, Fix Resource and Disable Multiple CPU Build
อันนี้ทีเด็ดเลยใส่เข้าไปที speed พุ่งเพราะมันทำให้ไม่ต้องไปกวาดหา SDK เก่า ๆ มา build ให้แอพเรา แต่ระวังมีปัญหาเรื่อง method บางตัวมันใช้ได้แค่เวอร์ชันใหม่นะดูดี ๆ แนะนำให้เขียน API พื้น ๆอย่าเล่นท่าพิศดารเยอะ อยากเติมอะไรค่อยมาลงตอน feature เสร็จ “แล้วไงต้องมานั่งแก้ไปแก้มาเหรอ เวลาจะ release ทีต้องมาแก้กลับที ถ้าลืมแก้นี่ งานงอกนะ” ใจเย็น ๆ ได้ใช้ Skill Gradle Mastery แล้ว คืองี้ มันสามารถตั้งได้ว่าเราจะ build productFlavors อะไรแบบไหน
debugFlavor, release, alpha, internal หรือจะตั้งชื่อเป็น for you จีบ tester ก็ได้นะ
ตัวอย่าง
debugFlavor{
minSdkVersion 27
applicationId 'com.ookbee.joyapp.android'
targetSdkVersion 27
resConfigs (“en”, “xxhdpi”)
}
เอานี่ไปใส่ไว้ใน buildTypes{} ที่ Gradle ของ App ตั้ง min SDK ให้มันเท่ากับเครื่องที่เราจะ build และตั้งให้มัน build ที่ en กับ DPI xxhdpi อย่างเดียว หลัก ๆ มีเท่านี้ก็เร็วและ
config อื่น ๆ search หากันเอาเองมีคนสอนเต็มเลย
แต่ปัญหายังไม่หมดไป คนแบ่ง code ออกเป็น Module ProductFlavor มันก็จะเยอะตาม หรือคนทำหลาย ๆ ProductFlavor ในเน็ตก็มีคนบอกมันทำให้ build ช้า
ไม่เป็นไรเรามีอีกทาง ไม่ต้องใช้ Product Flavor ให้แยก BuildTypes ออกจากกันแล้วเขียน variable ของ Gradle แทนแบบนี้
def computeMinSdkVersionGloble() {
return project.hasProperty('devBuild') ? project.ext.currentMinSDK : 16
}
allprojects {
project.ext{
currentMinSDK = 24
flavorGlobleMinSDK = computeMinSdkVersionGloble()
}
}
เอาไปสร้างใน build.gradle ของตัว Project
จากโค้ดเราสร้าง function ชื่อ computeMinSdkVersionGloble() โดยที่จะอิงกับ property ตัว ‘devBuild’ ซึ่งถ้ามันมีตัวนี้จะเป็น build แบบ debug นั่นเองถ้าเป็น dev จะให้ property flavorGlobleMinSDK เป็น version 24 ถ้าไม่ใช่จะให้เป็น 16 เลขในที่นี้เท่ากับตัวที่จะปล่อยให้ user ของแอพเราใช้หนะ
ส่วนของตัว app-> build.gradle ให้เขียนแบบนี้
defaultConfig {
...
minSdkVersion project.ext.flavorGlobleMinSDK
targetSdkVersion 27
...
}
คือตัว Gradle มันสามารถสร้างตัวแปลหรือเขียน function ลงไปได้ หรืออยากจะเขียน class ลงไปเลยก็ได้นะ ตอนแรกเราว่าจะเขียนให้มันส่ง mail มาหาเราเวลามัน build ตัว relaese เสร็จ แต่ยังไม่สำเร็จ ฮา
#Cache Gradle
ใส่นี่ไว้ใน gradle.propertis ของ project
org.gradle.deamon=true
org.gradle.parallel=true
org.gradle.caching=true
เช่นเดิมส่วนอื่น ๆ ไปหาอ่านเอา blog อื่นๆ มีเขียนให้ค่อนข้างเยอะ
#Instant Run
เปิด Instant Run อันนี้ช่วยได้เยอะ version หลัง ๆ เค้าทำมาดีแล้วหละ
#Fix Warning Comment and Remove Unused Import Class
Comment or Unused Function เผื่ออยากใช้ในอนาคต หน้าที่พวกนี้เป็นของ Source Control เลิก comment โค้ดทิ้งไว้ได้แล้ว หรือพวก Class import ที่ไม่ได้ใช้ลบ ๆ มันไปเถอะ compiler จะได้เลิกฟ้อง warning สักที สงสารมันไม่ต้องคอยมาปริ้น Log แจ้งเรา
หรือคลิกขวาที่ Project -> Optimize Imports
ก่อนจบ Run command ข้างล่างนี้ ดูก่อนก็ได้ จะรู้ว่า task ไหนมันทำงานนาน
./gradlew assembleDebug --profile
เราว่าปัญหานี้มันค่อนข้างใหญ่นะ สมมุติเราทำคนเดียวเลยลดเวลา build จาก 4 นาทีลงไปเหลือ 1 นาทีได้คุณกด build ไป 10 ครั้ง คุณประหยัดเวลาไปแล้ว 30 นาทีนะ ยิ่งพอคุณมีทีมงานอย่างในทีมเราตอนนี้มี 4 คน ประหยัดเวลาในการ build ลงไปเยอะ build ทีนึง อาจเอาเวลา build ไปนั่งคิด logic ต่อไปที่จะเขียนเลยก็ได้นะ แต่ก่อนก็แนะนำให้คนในทีมทำแบบนั้น แต่เอาเข้าจริงการทำแบบนี้อาจทำให้เราลืมสิ่งที่เราจะทดสอบใน build ก่อนหน้านี้ ซึ่งสมัยรุ่น ๆไฟแรงไม่เคยมีปัญหาหลงลืมเลย พอเริ่มมีอายุเยอะขึ้นมันกลับลืม ซึ่งทำให้เราคิดได้ว่ามีโอกาสที่คนอื่นจะเป็นแบบนี้เหมือนกันแหละ ถึงแม้ตั้งใจทำงานแค่ไหนก็ตาม เดี๋ยวนี้เลยต้องหาหนังสือมาจดบ้างแล้ว สุดท้ายมันก็เจองานที่แก้ไม่ได้ มาเจองานจัดแบบ UI มันอาจจะต้องรันบ่อย ๆ เปิดหลายเครื่องหลายจอมาเช็ค การ build นาน ๆ ไม่ใช่ผลดีแน่นอน
สุดท้ายหาเวลามา optimize project ที่เรารักกันเถอะ
เอ๊ะ แต่บางคนบอกไม่มีเวลา แค่ทำงาทำ feature ก็ไม่ทันแล้ว ใช่ครับ หน้าที่ Developer สำหรับผม ผมคิดว่าคุณคิดถูกแล้ว ผมก็นั่งทำงานคนเดียวมาก่อน การ optimize build ไม่ได้ช่วยให้บริษัทมีกำไรมากขึ้นถ้าในทีมมีคุณคนเดียว build feature กับแก้บัคก็พอแล้วครับ แต่อย่าลืมการบริหาร Resource ในการทำ Program เป็นหน้าที่ของ Developer อย่างเรา ๆ นี่แหละ เพราะงั้นอย่างน้อยๆทำข้อ 1 และข้อ 2 สักหน่อยก็ดีนะ
Top comments (0)