"ไม่ต้องมีเวทมนตร์ ไม่ต้องไปหาแม่มด แค่คุณทำสิ่งที่โลกระลึกถึงตลอดกาล แค่นั้นคุณก็เป็นอมตะแล้ว"
4 สิ่งที่แตกต่างของโปรเจคแอนดรอยด์บน Eclipse + ADT และ Android Studio
10 Dec 2014 02:46   [17473 views]

Android Studio 1.0 ตัวเต็มออกมาแล้ว คนก็เริ่มย้ายจาก Eclipse มา Android Studio กันบ้างแล้ว (เป็นเรื่องดี)

แต่คนที่ใช้ Eclipse มาตลอด ตอนย้ายมา Android Studio รับประกันความ "งง" ครับ เพราะแนวคิดของโปรเจคบน Eclipse และบน Android Studio นั้นต่างกันมากทีเดียว ด้วยการที่ Eclipse ใช้คุณสมบัติของความเป็น Eclipse พ่วงด้วย Plugin เข้าไปเพื่อ "ฝืน" ทำเป็น IDE สำหรับ Android App Development ส่งผลให้หลายๆส่วนไม่ลงตัว และดูไม่เหมาะกับงานเท่าไหร่ ในขณะเดียวกัน Android Studio ถูกสร้างมาเพื่อพัฒนาแอพฯแอนดรอยด์โดยเฉพาะ ทำให้ทุกอย่างถูกออกแบบมาอย่างดีเพื่อการทำแอพฯแอนดรอยด์อย่างมีประสิทธิภาพ

วันนี้เราเลยขอสรุป 4 ข้อใหญ่ๆที่แตกต่างระหว่าง Eclipse Project และ Android Studio Project มาเพื่อเป็นแนวทางสำหรับคนที่คิดจะ Migrate กันครับ

1) หนึ่งหน้าจอของ Android Studio คือ 1 โปรเจคเท่านั้น แต่สามารถเพิ่ม Module ข้างในได้

ตอนเป็น Eclipse เราสามารถเพิ่มโปรเจคเข้าใน Workspace เท่าไหร่ก็ได้ ผลคือเราสามารถเปิดโปรเจคไว้จำนวนมากใน Workspace เดียว แค่เลือกจะคอมไพล์อะไร แล้วเวลาจะดึง Library ที่มาในรูปแบบ Source Code เข้ามา ก็ต้อง Import เข้ามาเป็นโปรเจค แล้วลิงค์ผ่านระบบ Library เอา

แต่กับ Android Studio เค้าบังคับให้ 1 หน้าจอที่เราเปิดคือ 1 โปรเจคเท่านั้น (ซึ่งเป็นสิ่งที่ดี ทำให้เราไม่สับสน ควรจะเป็นแบบนี้มานานแล้ว) และหากจะเอา Library แบบ Source Code เข้ามา (เช่น Facebook SDK) เราก็จะเอาเข้ามาในรูปแบบของ Module (ตอน New Project มา เราจะมี Module หลักโผล่ขึ้นมา 1 ตัว มีชื่อว่า app)

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

สบายยยย

อย่างไรก็ตาม ... ความจริงอย่างนึงที่จะอยากจะบอกคือ ... แอพฯส่วนใหญ่ก็มีแค่โมดูล app ตัวเดียวแหละ น้อยนักที่จะมีแตกโมดูลที่สองออกมา ฮ่าๆๆๆๆ (แต่ถ้าใช้ Facebook SDK ในแอพฯด้วย ก็เตรียมตัวได้ ต้องใช้ท่า Module นี่แหละ เพื่อดึงมันเข้ามาใช้ในโปรเจค)

จริงๆแนวคิดนี้พอจะสามารถทำบน Eclipse ได้แหละ หากมอง Workspace เป็นโปรเจค แต่ก็จะติดเรื่องแนวคิดอยู่ดี ส่งผลให้ฟังก์ชั่นต่างๆมีปัญหาจนไม่สามารถ Implement บน Eclipse ได้ ในขณะเดียวกัน การรวบทุกอย่างเข้าเป็นโปรเจคเดียวกันอยู่ภายใต้ร่มคันเดียวกันของ Android Studio ก็ทำให้ควบคุมทุกอย่างได้ดีขึ้น จะทำอะไรก็ทำได้ละเพราะทุกโปรเจคไปในทางเดียวกันหมด และเป็นจุดที่ทำให้สิ่งที่เรียกว่า Dependency เกิดขึ้นได้ (จะไปพูดข้อสุดท้ายนะ)

2) Android Studio แยกส่วนของโค้ดออกจากกันอย่างชัดเจน ไม่กองรวมกัน ไม่ปนกันมั่ว

บน Eclipse เราจะกองทุกอย่างไว้ด้วยกัน ไม่ว่าจะเป็น Library, Test ฯลฯ ซึ่งทำให้ทุกอย่างดูรกไปหมด ยิ่งพอโปรเจคใหญ่ขึ้นแล้ว ชีวิตจะลำบากมาก

บน Android Studio ก็มีการเรียง Project Structure ใหม่หมด (และนี่คือสิ่งที่คนย้ายจาก Eclipse มาใหม่ๆรู้สึกกลัว) โดยแยกเอาส่วนที่เราใช้พิมพ์โค้ดออกจากส่วนอื่นๆทั้งหมด ดังนี้

ถ้าสังเกตดูจะพบว่า ตอนเราแก้โปรเจค เราก็แค่ไปแก้ในโฟลเดอร์ java, res และ AndroidManifest.xml เท่านั้น ส่วนอื่นๆจะถูกรวบไว้ที่อื่นให้ดูง่าย (แล้วมันง่ายมั้ยเนี่ย)

ตอนแรกก็อาจจะดูงงๆว่าทำไมแค่จะแก้ไฟล์จาวาถึงต้องเข้าไปลึกขนาดนั้น แต่มันมีเหตุผลของมันแบบนี้แล

3) Android Studio เน้นดึง Library ภายนอกมาใช้ด้วยระบบ Dependency แทนการก็อปไฟล์ .jar มาแปะเอง

ตอนเราทำโปรเจคบน Eclipse ถ้าต้องการดึง Library ภายนอกเข้ามาใช้ เราก็ต้องดิ้นรนวิ่งไปหา .jar มาแปะใส่ในโฟลเดอร์ libs กันเอง

ผลคือถ้ามีเวอร์ชั่นใหม่ที่แก้บั๊กออกมา เราก็ไม่รู้ ปล่อยใช้ตัวเก่าที่อุดมไปด้วยบั๊กต่อไป หรือถ้ามีการดึงหลายๆโปรเจคมาคอมไพล์ด้วยกัน แล้วเจอ libs ซ้ำกัน ก็จะเกิดการ Conflict คอมไพล์เป็น apk ไม่ผ่าน เพราะ Compiler ไม่รู้ว่าจะเอา .jar ตัวไหนไปใช้ (ต้องไปติ๊กออกเอาเอง)

เรียกว่าปัญหาสารพัดเลยหละ ซึ่งบน Android Studio สิ่งเหล่านี้ไม่ใช่ปัญหาอีกต่อไป ด้วยระบบ Dependency อันแสนฉลาดดดดดดด ด้วยการใส่เพียงบรรทัดเดียวใน build.gradle เราก็สามารถดึง Library นั้นๆมาใช้ได้แล้ว

พูดเลยว่าระบบ Dependency เป็นตัวช่วยชีวิตนักพัฒนาแอพฯแอนดรอยด์ได้ดีมากๆ จะทำโปรเจคอะไรใหม่ก็แค่ก็อปมาบรรทัดเดียว จบ ! ที่เหลือเดี๋ยวมันดึงเข้ามาให้ ไม่ต้องไปนั่งสับสนกับไฟล์ .jar อีกต่อไป (เป็นเหตุผลหลักๆที่พยายามดึงคนมาใช้ Android Studio ก่อนหน้านี้มาโดยตลอด)

นอกจากนั้น หากโมดูลเรียกใช้ Library เดียวกัน ก็จะไม่เกิดปัญหา Conflict อีกต่อไป เพราะพอดึงจาก Dependency มันก็จะมองว่าเป็นตัวเดียวกันโดยอัตโนมัติ ต่างจากตอนเป็น .jar คราวนี้ก็จะคอมไพล์ผ่านอย่างฉลุยแล้ว

อย่างไรก็ตาม หาก Library นั้นๆยังไม่เข้าร่วมในระบบ Repository เราก็ต้องไปหา .jar มาใช้อยู่ดี แล้วยัดใส่ในโฟลเดอร์ libs

แต่ข่าวดีคือ ... กูเกิ้ลให้เวลานักพัฒนามาพอสมควร จนเรียกได้ว่า Library ดังๆล้วนเข้าสู่ Repository หมดแล้ว ถ้า Library ไหนยังไม่เข้าร่วม ก็อนุมานได้ว่า Library นั้นกากเกินจะใช้จริงได้ ขอให้หาทางเลือกอื่นก่อน

4) ใช้ Gradle ชักใยโปรเจคอีกที

ตอนเราทำโปรเจคบน Eclipse เราจะแก้เฉพาะ AndroidManifest.xml ไฟล์จาวาและ Resources ที่เหลือไม่ค่อยได้ไปยุ่งกับมัน

กับ Android Studio ไฟล์เหล่านั้นก็ยังต้องแก้อยู่ แต่จะมีไฟล์ตระกูล .gradle (build.gradle และ settings.gradle) ที่คอยชักใยโปรเจคโดยรวมอีกที

ดังนั้นจงทำตัวคุ้นชินกับไฟล์ Gradle Build Script ด้วยครับ ต้องแก้มันเรื่อยๆ หลักๆในตอนแรกก็คือไฟล์ build.gradle ในโมดูล app นั่นเอง โดยบางส่วนถูกดึงออกไปจาก AndroidManifest.xml แล้วถูกเอาไปใส่ใน build.gradle แทน เช่นพวก versionCode, versionName ใครย้ายมาจาก Eclipse แล้วสงสัยว่ามันหายไปไหน มันย้ายมาอยู่นี่แหละ (ซึ่งตอนคอมไพล์มันจะรวมใส่ใน Manifest ให้เอง)

apply plugin: 'com.android.application'android {    compileSdkVersion 21    buildToolsVersion "21.1.1"    defaultConfig {        applicationId "com.example.app"        minSdkVersion 14        targetSdkVersion 21        versionCode 1        versionName "1.0"    }    buildTypes {        release {            minifyEnabled false            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }    }}dependencies {    compile fileTree(dir: 'libs', include: ['*.jar'])    compile 'com.android.support:support-v4:21.0.2'    compile 'com.android.support:appcompat-v7:21.0.2'    compile 'com.squareup.picasso:picasso:2.3.3'    compile 'com.squareup:otto:1.3.5'    compile 'com.squareup.okhttp:okhttp:2.0.0'    compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.0'    compile 'com.google.code.gson:gson:1.7.2'    compile 'commons-codec:commons-codec:1.5'}

ไฟล์อื่นๆมีโอกาสถูกแก้บ้าง แต่ก็แล้วแต่โอกาสครับ (เช่นไฟล์ build.gradle ที่อยู่ข้างนอก เราต้องคอยแก้ gradle version ของโปรเจคให้เปลี่ยนไปตามเวอร์ชั่นของ Android Studio ด้วย ตัวล่าสุดคือ com.android.tools.build:gradle:1.0.0)

ส่วนไฟล์อื่นๆ ถ้าถึงจุดที่ต้องแก้แล้ว ก็คือโปรเจคใหญ่ระดับหนึ่งและคงเชี่ยวชาญแล้วระดับหนึ่ง ไม่น่าจะมีปัญหาครับ ^_^

บทความที่เกี่ยวข้อง

Feb 20, 2015, 00:27
6888 views
ทดลองตั้งระบบ Crash Tracking สำหรับ Android เองด้วย ACRA
Jan 20, 2015, 23:56
13123 views
รู้จักกับ mipmap ในวันที่ Android Studio 1.1 ย้ายไอคอนใน Template จาก drawable ไป mipmap
0 Comment(s)
Loading