Panduan yang Terlalu Menyeluruh Untuk Perpustakaan Android yang Kurang Digunakan
Diterbitkan: 2022-03-11Pengembang berpengalaman mana pun akan memberi tahu Anda bahwa kode terbaik mereka bukanlah kode yang mereka tulis. Itu kode yang mereka ambil dari pekerjaan orang lain.
Ya, kami pengembang adalah pemecah masalah yang inovatif, tetapi banyak masalah yang kami hadapi telah dipecahkan—dan solusi yang dikemas ke dalam perpustakaan tersedia bagi siapa saja. Mengapa menemukan kembali roda ketika roda bebas ada di mana-mana?
Android tidak terkecuali. Sumber utama untuk penggunaan kembali kode adalah Android SDK itu sendiri, yang hadir dengan konstruksi dan layanan hebat yang akan melakukan banyak pekerjaan untuk Anda.
Tetapi ketika SDK berjalan singkat, komunitas Android telah membuat beberapa pustaka top-of-the-line yang dapat menghemat banyak pekerjaan pengkodean, menggantinya dengan implementasi yang sangat disetel, diperiksa, dan diuji. Saya tidak berbicara tentang perpustakaan yang jelas—Pustaka Dukungan Android, Pustaka Dukungan Desain Android, Gson. Saya mengacu pada alat yang mungkin tidak Anda ketahui. Dan bahkan jika Anda melakukannya, Anda mungkin belum menggunakannya.
Saya telah mengembangkan, membimbing, dan memimpin tim Android selama bertahun-tahun, dan saya telah mempelajari dan menggunakan lusinan alat dan pustaka eksternal. (Saya bahkan diketahui membaca kode implementasi mereka dan mendiskusikan internal mereka dengan pengembang.) Banyak yang sangat efektif dalam membantu saya menyelesaikan pekerjaan, tetapi kenyataannya, sebagian besar tidak.
Itu sebabnya saya menyusun panduan ini. Bersandar pada pengalaman saya, serta pengalaman pengembang seluler lainnya, untuk memastikan Anda menggunakan perpustakaan terbaik. Saya telah memilih tujuh. Saya menduga mereka akan menjadi favorit Anda segera juga.
Memilih Perpustakaan Android yang Tepat
Saat memilih perpustakaan, saya mencari empat fitur utama:
- Ini memberikan solusi yang konsisten dan berkualitas tinggi untuk masalah nyata dan non-sepele.
- Ini menggunakan API sesederhana mungkin.
- Itu tidak memaksa perubahan apa pun dalam keseluruhan arsitektur saya.
- Ini memiliki basis pengguna yang besar dan, lebih disukai, komunitas pengembang yang aktif.
Tiga fitur pertama adalah pemecah kesepakatan. Jika mereka tidak ada, saya melanjutkan atau memulai pengkodean tangan.
Pustaka yang saya bahas di bawah lulus keempat tes. Mereka juga memecahkan beberapa aspek pengembangan seluler yang paling menantang.
- Dua perpustakaan untuk injeksi ketergantungan, pengikatan layout-ke-Java, objek tiruan.
- Model perpesanan pub/sub dalam aplikasi.
- Lapisan komunikasi HTTP yang aman, efisien, dan pulih sendiri.
- Manipulasi gambar: mengunduh, menyimpan, mengubah ukuran, dan memuat ke dalam RAM.
- Streaming video waktu nyata.
- Deteksi kebocoran memori.
ButterKnife: Alat Injeksi Ketergantungan Utama
Ini adalah perpustakaan injeksi ketergantungan utama untuk Android. Sederhana, kuat, super cepat (tanpa refleksi!), dan mampu menghilangkan banyak kode boilerplate aplikasi Anda.
Tidak perlu lagi mengikat setiap tampilan Anda secara langsung melalui panggilan ke findViewById()
; sebagai gantinya, ada tampilan beranotasi yang memberi Anda akses langsung ke kode.ButterKnife juga menghilangkan kebutuhan untuk peristiwa UI boilerplate seperti onClick
, onTouch
, dan seterusnya, dan menggantinya dengan kode yang disuntikkan secara otomatis.
Tapi cukup mengobrol, mari kita lihat kodenya.
Lihat pengikatan bidang:
class MyButterKnifeActivity extends Activity { @BindView(R.id.name) TextView name; @BindView(R.id.address) TextView address; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.simple_activity); ButterKnife.bind(this); // MUST BE CALLED BEFORE ACCESSING UI FIELDS name.setText(“etc etc”); } }
Pengikatan sumber daya:
class ExampleActivity extends Activity { @BindString(R.string.username) String username; @BindDrawable(R.drawable.graphic) Drawable graphic; @BindColor(R.color.bg_color) int bgColor; @BindDimen(R.dimen.lower_padding) Float lowerPadding; // and no need for getResources().getString()/getDrawable/getColor() }
pengikatan acara UI:
@OnClick(R.id.my_button) public void clickHandler(View view) { // onClick logic goes here }
AndroidAnnotations: Membawa Injeksi Ketergantungan ke Tingkat Selanjutnya
Hampir sedetik dari ButterKnife dalam hal injeksi ketergantungan, AndroidAnnotations menggunakan pendekatan yang sedikit berbeda: kelas yang dibuat secara otomatis, yang, setelah Anda menguasainya, sangat sederhana. Yang lebih berguna adalah memungkinkan Anda injeksi ketergantungan "berbasis nama". Misalnya, @ViewById ListView myUserList;
menginstruksikan perpustakaan untuk menetapkan bidang ini dengan layoutListView
dengan nama yang sama.
AndroidAnnotations juga sangat cepat, tetapi mencapainya dengan cara yang agak berbeda dari ButterKnife. Alih-alih injeksi ketergantungan pengikatan waktu proses, AndroidAnnotations membuat duplikasi waktu pembuatan dari semua aktivitas yang terpengaruh dan mendorong logika koneksinya ke dalamnya, sehingga memungkinkan Anda mendapatkan kinerja yang sama dengan logika kode tangan.
Namun kemampuan injeksi AndroidAnnotations lebih jauh dari itu. Anda dapat memasukkan status dan tata letak ke dalam aktivitas.
Implementasi AndroidAnnotations:
@NoTitle @Fullscreen @EActivity(R.layout.my_layout) public class MyActivity extends Activity { @ViewById ListView customerList; // auto-binded to R.id.customerList @App MyApplication app; // auto-binded to app object @AminationRes Animation fadeoutAnimation; @UiThread void updateUI() { // main thread action } }
Anotasi terakhir memerlukan sedikit penjelasan lebih lanjut: Tugas umum untuk aplikasi Android multi-utas adalah beralih dari utas latar belakang (atau pekerja) ke utas maju (atau utama atau UI), yang merupakan satu-satunya yang memungkinkan akses ke komponen UI . Tugas ini, meskipun tidak rumit, sering kali diperlukan dan melibatkan beberapa pengkodean yang berantakan:
new Handler(Looper.getMainLooper()).post(new Runnable() { logic goes here } ); // NO ANNOTATIONS
Di AndroidAnnotations, yang perlu Anda lakukan hanyalah membubuhi keterangan fungsi Anda dengan @UiThread, dan sekarang dijamin untuk selalu dijalankan:
@UiThread void updateUI() {..} // WITH ANNOTATIONS
Perhatikan bahwa anotasi ini berlaku untuk kelas komponen Android standar (aktivitas, layanan, dan sebagainya). Tapi apa yang terjadi ketika saya juga ingin membubuhi keterangan kelas saya sendiri?
Di sini, AndroidAnnotations hadir dengan konsep baru, yaitu EBean
. Yang harus Anda lakukan adalah menandai kelas Anda menggunakan @EBean
, dan Anda siap melakukannya:
@EBean public class MyNonComponentClass { @SystemService NotificationManager notifManager; @Bean MyOtherClass dependency; @UiThread void updateUI() { // main thread work goes here } }
EventBus: Komunikasi Lintas Komponen Menjadi Mudah
Perpustakaan EventBus mengubah masalah yang menghantui pengembang Android selama bertahun-tahun menjadi berjalan-jalan di taman. Komunikasi lintas komponen tidak pernah semudah ini—gunakan model pub/sub sederhana untuk berkomunikasi antara dua bagian mana pun dari sistem Anda.
Layanan polling latar belakang Anda tidak lagi perlu mengetahui fragmen Anda untuk memberi mereka makan dengan peristiwa perubahan.
Penggunaan EventBus sangat mudah.
Sebuah. Buat kelas acara. Bekerja dengan POJO di sini adalah yang terbaik:
class NewUserEvent { String fullname; String address; String role; // add getters and setters }
B. Buat metode penanganan peristiwa di kelas—kelas apa pun yang ingin Anda langgani untuk peristiwa ini:
class MySubscriber { @Subscribe public void newUserHandler(NewUserEvent event) { // handle NewUserEvent } @Subscribe public void newUserHandler(AnotherEvent event) { // handle AnotherEvent } }
Tapi hei, pengembang Android yang setengah berpengalaman akan berhenti dan bertanya pada titik ini: Apa model threading dari penangan ini? Dan bisakah saya memaksa pawang untuk menjalankan utas utama jika, katakanlah, itu melibatkan akses komponen UI? Pertanyaan bagus…
Secara default, semua metode penangan berjalan pada utas pekerja yang diambil dari kumpulan utas yang dialokasikan dan dikelola oleh EventBus itu sendiri. Jika Anda memerlukan metode penangan untuk dijalankan di utas utama, perluas anotasi langganan Anda sebagai berikut:
@Subscribe(threadMode = ThreadMode.MAIN) public void runOnMainThreadHandler(AnotherEvent event) { … }
Peringatan: Jangan terlalu sering menggunakan fitur ini! Operasi yang berjalan lama tidak boleh dijalankan pada utas utama , dan bahkan dengan operasi cepat, berhati-hatilah. Membanjiri utas utama adalah cara paling pasti untuk membuat aplikasi Anda lambat, gelisah, dan pada dasarnya kurang menyenangkan bagi pengguna Anda.
C. Kelola siklus hidup pendaftaran EventBus dari kelas pelanggan Anda—yaitu, kapan terhubung dan kapan terputus dari bus? Alur pendaftaran yang wajar untuk suatu aktivitas adalah:
class MySubscriberActivity extends Activity { @Override public void onStart() { super.onStart(); EventBus.getDefault().register(this); // START RECEIVING EVENTS HERE } @Override public void onStop() { EventBus.getDefault().unregister(this); // NO MORE EVENTS super.onStop(); } }
Hal di atas, tentu saja, hanyalah sebuah contoh. Anda dapat melakukan (un)registrasi di mana saja yang Anda pilih.
D. Dan akhirnya, benar-benar menjalankan sebuah acara:
EventBus.getDefault().post(new MyEvent(“I'm here”));
Masih banyak lagi yang perlu diketahui tentang menggunakan EventBus: peristiwa multicasting (perilaku default), menggunakan peristiwa tempel, utas pengiriman, prioritas, dan banyak lagi. Tetapi hal di atas sudah cukup bagi Anda untuk memulai dengan teknologi yang sederhana namun kuat ini.
OkHttp: HttpClient Android pada Steroid
Ini adalah cara HttpClient Android seharusnya ditulis. Sangat sederhana, sangat cerdas. Pustaka OkHttp secara internal menangani pengulangan percobaan, kompresi otomatis muatan, dukungan Http/2, penyatuan koneksi, dan cache respons sehingga Anda dapat menghindari akses jaringan yang tidak perlu.
Penggunaan OkHttp tidak perlu dipikirkan lagi.
Http POSTING:
OkHttpClient client = new OkHttpClient(); MediaType JSON = MediaType.parse("application/json; charset=utf-8"); RequestBody body = RequestBody.create(JSON, json_str); Request request = new Request.Builder() .url(url) .post(body) .build(); Response response = client.newCall(request).execute(); return response.body().string();
Http DAPATKAN:
OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url(urls[0]) .build(); Response responses = client.newCall(request).execute(); String jsonData = responses.body().string();
OkHttp juga mendukung fitur berguna seperti jaringan asinkron, permintaan rute pengalihan permintaan, kueri cache lokal, dan banyak lagi. Jangan ragu untuk menggunakannya jika diperlukan. Sebagian besar pengembang menggunakan OkHttp sebagai pengganti yang lebih cerdas untuk klien HTTP default Android, HttpURLConnection. Faktanya, seluruh proyek ini dimulai sebagai garpu pribadi untuk HttpURLConnection.
Saya suka kekokohannya—segera ditambahkan ke lapisan jaringan Anda.
Picasso: Ada Alasan Bagus Google Menggunakannya Juga!
Picasso adalah cara paling sederhana dan paling andal untuk mengelola unduhan gambar, caching, pengubahan ukuran, dan pemotongan.
Pernyataan ini:
Picasso.with(context).load(url).resize(50,50).centerCrop().into(imageView)
Akan melakukan ini untuk Anda:
- Hubungkan ke URL jarak jauh.
- Unduh gambar.
- Simpan di cache LRU lokal yang juga akan dikelola untuk Anda.
- Ubah ukuran gambar asli sebelum memuatnya ke dalam memori.
- Jalankan semua hal di atas pada kumpulan utas yang dikelola oleh Picasso.
- Gunakan gambar yang diubah ukurannya untuk mengisi imageView Anda.
- Sebelum menjalankan apa pun di masa mendatang, periksa cache lokal untuk memastikan perjalanan pulang pergi jaringan benar-benar diperlukan.
Membangun rangkaian tugas di atas akan membutuhkan banyak jam kerja, bahkan untuk pengembang master. Dan itu mengasumsikan Anda mengingat semuanya. Bagaimana jika Anda lupa, katakanlah, bagian pengubahan ukuran?

Nah, pada rata-rata perangkat Android, sebuah aplikasi mendapatkan tidak lebih dari 50 hingga 60 Megabyte RAM, dan faktor piksel-ke-byte untuk sebagian besar perangkat Android adalah 4. Ini berarti mencoba memuat gambar 13 megapiksel dari kartu SD akan membutuhkan 52 Megabyte RAM. Dengan kata lain, aplikasi Anda akan langsung mogok.
Ini hanyalah salah satu contoh kekuatan Picasso. Salah satu hal pertama yang saya lakukan saat mengoptimalkan/men-debug proyek lama yang menggunakan media intensif adalah mengalihkan semua pemuatan gambar ke Picasso. Anda akan terkejut dengan dampak satu langkah sederhana ini terhadap kualitas aplikasi.
Salah satu bukti terkuat tentang kekuatan perpustakaan ini: Banyak contoh kode Android Google sendiri dari dua tahun terakhir menggunakan Picasso untuk memuat gambar.
ActiveAndroid: Overhead Kinerja ORM Sans
ORM, kependekan dari pemetaan relasional objek, dipopulerkan pada masa J2EE. Ini memungkinkan Anda untuk menyimpan POJO Anda, dan mengambilnya dari, database tanpa harus mengubahnya menjadi bidang terpisah.
Apakah itu membantu? Sangat banyak, karena memungkinkan Anda untuk menulis sebagian besar aplikasi Anda tanpa mengkodekan pernyataan SQL apa pun.
Ini juga sangat efisien. Di masa lalu, platform ORM sangat mengandalkan refleksi dan terkenal lambat. Platform modern, termasuk ActiveAndroid, jauh lebih cepat dan untuk sebagian besar persyaratan praktis, tidak akan mengalami overhead kinerja dibandingkan pengkodean SQL mentah.
Penggunaan:
Sebuah. Inisialisasi dalam objek aplikasi dengan memperluas kelas Aplikasi khusus:
public class MyApplication extends extends com.activeandroid.app.Application { … }
B. Buat POJO, diturunkan untuk kelas model, dengan kelas untuk setiap catatan yang Anda rencanakan untuk disimpan dalam database. Setiap POJO tersebut dapat berada di tabelnya sendiri. Anotasi harus digunakan untuk menentukan nama bidang DB untuk setiap anggota yang disimpan:
@Table(name = "Categories") public class UserDetails extends Model { @Column(name = "Name") public String name; @Column(name = "Address") public String address; @Column(name = "Age") public int age; }
Jika Anda ingin menetapkan indeks untuk anggota, gunakan anotasi berikut:
@Column(name = "ID", index = true) public String userID;
C. Untuk mencegah perpustakaan mengulangi semua waktu startup paling klasik Anda, yang merupakan perilaku default, sangat disarankan Anda menentukan semua kelas model Anda di bagian manifes berikut:
<meta-data android:name="AA_MODELS" android:value=“com.myapp.MyModelA, com.myapp.MyModelB" />
Catatan: Kelas model yang tidak muncul dalam daftar ini tidak akan dikenali oleh ActiveAndroid.
D. Tulis ke database:
UserDetails usr = new UserDetails(); usr.save(); // RUNS ON A BACKGROUND THREAD
Jika beberapa penulisan diperlukan, cara yang lebih efisien adalah dengan mengelompokkannya dalam satu transaksi:
ActiveAndroid.beginTransaction(); try { for (UserDetails u: userList) item.save(); ActiveAndroid.setTransactionSuccessful(); } finally { ActiveAndroid.endTransaction(); }
e. Baca POJO dari database:
new Select() .from(UserDetails.class) .where("name = ?", usr.getName()) .orderBy("Age") .executeSingle();
ORM adalah alat yang harus dimiliki selama hari-hari saya sebagai pengembang sisi server. Itu agak terlambat masuk ke domain Android. Tapi, akhirnya, ini dia: pemrograman database sesederhana yang didapat. Bersenang senang lah.
LibStreaming: Streaming Video Tanpa Rasa Sakit
Streaming video real-time dulunya merupakan masalah besar karena API yang tidak didokumentasikan, perbedaan versi lintas-SDK, penggunaan refleksi, dan banyak lagi.
Untungnya, libStreaming mengubah semua ini dengan merangkum sebagian besar kompleksitas streaming dan mengekspos API sederhana dan ramah yang memungkinkan Anda menulis aplikasi streaming dasar dalam hitungan jam.
Untuk menggunakannya untuk H.264 dan AAC, Anda perlu melakukan hal berikut:
Sebuah. Inisialisasi objek sesi pada metode onCreate aktivitas utama Anda. Objek sesi mewakili streaming media ke peer:
protected void onCreate(Bundle savedInstanceState) { mSession = SessionBuilder.getInstance() .setCallback(this) .setSurfaceView(mSurfaceView) .setPreviewOrientation(90) .setContext(getApplicationContext()) .setAudioEncoder(SessionBuilder.AUDIO_NONE) .setAudioQuality(new AudioQuality(16000, 32000)) .setVideoEncoder(SessionBuilder.VIDEO_H264) .setVideoQuality(new VideoQuality(320,240,20,500000)) .build(); mSurfaceView.getHolder().addCallback(this); }
B. Sebenarnya memulai sesi:
mSession.setDestination(destination_server_url); mSession.start();
C. Hentikan sesi setelah selesai:
mSession.stop();
Sekarang, tolong jangan salah paham. Streaming real-time pada dasarnya berantakan dan libStreaming tidak menghilangkan kerumitan ini. Namun, itu melakukan pekerjaan yang sangat baik menyembunyikannya dari Anda sebagian besar waktu. Dalam beberapa kasus, Anda perlu menangani kerumitannya, seperti saat memilih kebijakan pensinyalan rekan, memilih penyandian kamera (biasanya Anda ingin menggunakan MediaCodec/surface-to-buffer), atau menangani paket.
Namun, Anda akan menemukan bahwa orang-orang baik di balik libStreaming bekerja lebih keras dalam menggabungkan kompleksitas ini dengan lancar ke dalam API yang mudah digunakan.
LibStreaming mendukung sebagian besar encoder yang digunakan oleh aplikasi Android, termasuk H.264, H.263, AAC, dan AMR.
Saya telah menuai hasil yang bagus dengan perpustakaan ini. Beberapa aplikasi streaming paling populer menggunakannya sebagai bagian dari infrastrukturnya. Jika Anda pernah mengalami kebutuhan, saya yakin itu akan membuat pengalaman streaming media Anda jauh lebih lancar.
LeakCanary: Mendeteksi Kebocoran Memori di Baris Kode
Mari kita mulai dengan motivasi di balik perpustakaan ini: kebocoran memori . Aplikasi Android rentan terhadapnya, terutama jika Anda tidak berhati-hati dengan pengkodean Anda. Sebenarnya, membuat kebocoran memori sangat sederhana. Yang perlu Anda lakukan adalah menyimpan referensi aktivitas di luar konteksnya. Faktanya, bahkan menyimpan referensi ke objek tampilan tunggal di luar konteks aktivitasnya akan membuat kebocoran.
Mengapa? Karena tampilan—semua tampilan, pada kenyataannya—secara internal menyimpan referensi konteks ke aktivitas yang memuatnya. Selama referensi ke tampilan disimpan, aktivitas yang memuatnya—bersama dengan apa yang ada di dalamnya, termasuk sumber daya yang dapat digambar, hierarki tampilan, dan sumber daya—tidak dapat diklaim kembali oleh pengumpul sampah.
Menjaga referensi ke aktivitas bocor tidak selalu jelas sebagai parameter statis. Setiap kali Anda membuat kelas dalam atau menelurkan utas di dalam aktivitas, referensi ke aktivitas tersebut akan dibuat dan aktivitas tidak dapat diklaim kembali hingga kelas atau utas dalam tersebut selesai.
Membocorkan referensi ke satu aktivitas intensif sumber daya terkadang cukup untuk membuat aplikasi Anda mogok dengan pengecualian “ Memori habis ”.
Bagaimana Anda bisa melindungi dari mereka? Mulailah dengan praktik pengkodean yang ketat , tentu saja. Namun tidak semua dari kita adalah developer Android berpengalaman, dan bahkan developer berpengalaman pun terkadang lupa aturannya.
Tinjauan kode berkala dengan penekanan pada kebocoran memori mungkin membantu, tetapi membutuhkan waktu. Juga, beberapa kebocoran benar-benar licik dan sulit dideteksi hanya dengan meninjau kode.
Menggunakan alat memori DDMS adalah cara yang bagus untuk mengetahui, dari waktu ke waktu, jika aplikasi Anda bocor. Anda pasti harus menggunakannya. Namun, itu tidak akan memberi tahu Anda apa yang menyebabkan kebocoran.
Di sinilah leakCanary untuk menyelamatkan. Ini adalah pendeteksi kebocoran memori terbaik di luar sana, dan menyediakan deteksi kebocoran otomatis — seperti dalam satu atau dua baris kode — untuk semua aktivitas Anda.
Untuk menggunakannya cukup inisialisasi leakCanary dengan objek aplikasi Anda onCreate()
:
public class MyApp extends Application { @Override public void onCreate() { super.onCreate(); LeakCanary.install(this); // more initialisations } }
Dan Anda sudah selesai. LeakCanary akan memantau kebocoran memori, dan mengirim pemberitahuan jika terdeteksi.
LeakCanary mencapai keajaiban ini dengan otomatis menginjeksi objek yang disebut ActivityRefWatcher
ke dalam semua aktivitas Anda dan memantau jumlah referensi mereka setelah onDestroy()
dipanggil. A > 0 hitungan ref pada aktivitas yang dihancurkan hanya bisa berarti kebocoran.
Penting: Deteksi kebocoran hanya berfungsi untuk aplikasi mode debug. Jangan pernah menguji kebocoran (yah, tidak dengan LeakCanary) dalam APK mode rilis.
Tetapi bagaimana jika saya ingin menguji bagian lain dari sistem saya untuk mengetahui kebocoran? Di sini, LeakCanary menawarkan objek yang disebut refWatcher, yang sebenarnya merupakan nilai balik dari panggilan inisialisasi:
refWatcher = LeakCanary.install(this);
Hal ini dapat digunakan untuk melihat nilai-nilai yang akan segera direklamasi. Lebih tepatnya, nilai-nilai yang menurut saya akan segera direklamasi. Untuk melakukannya, hubungi:
refWatcher.watch(my_soon_to_be_reclaimed_obj);
Pustaka akan memberi tahu Anda jika objek ini belum dirilis dalam waktu singkat setelah panggilan menonton.
Saya tidak dapat menemukan nilai dari "waktu singkat" ini di mana pun, tetapi mungkin itu tidak terlalu penting. Dengan leakCanary, semuanya berfungsi. Sangat berharga.
Ringkasan
Pengembang berpengalaman memotong berhari-hari dan berminggu-minggu dari fase pengkodean dan debugging mereka menggunakan perpustakaan ini, jadi tidak ada alasan Anda tidak dapat melakukan hal yang sama.
Singkatnya, inilah yang dapat dilakukan oleh perpustakaan Android pilihan saya untuk Anda:
ButterKnife – Kode yang disuntikkan secara otomatis akan membantu Anda menghilangkan banyak kode boilerplate aplikasi Anda. Ini adalah injeksi kode utama untuk Android. Perlu saya katakan lebih?
AndroidAnnotations – Gunakan kelas yang dibuat secara otomatis dan injeksi kode berbasis nama yang sangat cepat untuk menghemat waktu tanpa penalti kinerja dibandingkan logika kode tangan.
EventBus – Memisahkan komponen untuk kode yang lebih kuat, komunikasi lintas komponen tidak pernah semudah ini.
OkHttp – Pengganti cerdas untuk HttpURLConnection, dengan dukungan untuk jaringan asinkron, permintaan rute pengalihan permintaan, permintaan cache lokal, dan banyak lagi.
Picasso – Manipulasi gambar yang disederhanakan yang sangat bagus sekarang digunakan oleh Google. Ini adalah penghemat waktu utama dalam proyek media berat dan proyek warisan tertentu.
ActiveAndroid – ORM menjadi mudah tanpa overhead kinerja.
LibStreaming – Streaming video real-time, digunakan oleh aplikasi streaming utama.
Apakah ini satu-satunya perpustakaan Android yang sepadan dengan waktu Anda? Tentu tidak. Tapi saya berjanji ini kepada Anda: Menggunakan salah satu dari mereka pada proyek Anda berikutnya akan membuat Anda menjadi pengembang yang jauh lebih baik. Jika Anda ingin melihat mereka beraksi, lihat GitHub saya.
Jika Anda sudah menggunakan beberapa atau semuanya, atau jika Anda menggunakan perpustakaan alternatif, saya mendorong Anda untuk membagikan pengalaman Anda di komentar di bawah.