Criticue of “library” approachin developing for android

ILLYA RODINLead Android Engineer

Agenda● Origin● Greedy ORM● “Fast” communication with EventBus● “Rapid” Mortar● RxAndroid: real solution for unreal problems● Everything else…● Q&A

Out of topic● Image download managers (UIL, Glide, Picasso, e.t.c.)

○ DownloadManager, Volley● Integration libraries (Facebook SDK, Twitter Kit, Google Play Service, e.t.c )● Analytic, advertising, debug, loggers, test, memory profiling, e.t.c.● Custom UI components

”Android Performance Workshop” Romain Guy and Chet HaaseDevoxx 2013“External libraries:

● Not necessarily written for Android● Potentially large expensive for small benefits”

“Do not multiply own mistakes by the other people's mistakes”©Good sense

Origin

“Commandments”● Be careful with resources

○ RAM (especially!)○ Battery○ CPU/GPU○ Device memory○ Network

©”The Art of War” Sun-tzu

● Be respectful to platform○ Components life cycle○ Cooperation with environment○ Fragmentation

● Do everything faster ● “Good things - simple things”

Every Device is a Village

“... which means that everybody has to cooperate to make the user experience on that device work. You can all make it suck together, or you could make it nice together.

Chet HaaseUdi CohenPerformanceDemo

Greedy ORM

Why not?! *Almost

Galligan's War

Kevin GalliganBlog

Droidcon 2015 London

“Generally we (touchlab) use ORMlite to build an app without too much concern for performance, then test and improve as needed.”

“I’d say if you have serious problems managing raw SQL, you shouldn’t be using SQLite at all.…So, my opinion is that you shouldn’t pick an ORM because its the fastest, but because of its features. However, I would encourage ORM authors to improve their performance where reasonable.”

“This also kind of turned into a big talk about Realm, which wasn’t the goal. Outside of the medical study framework, I don’t think we’d be likely to use it in a production app, but we have a lot more sqlite experience in house.”

https://github.com/touchlab/android-orm-benchmark-updated

Let's check?!

Input:

● OS versions: 4.2.2 and 5.1 (Genymotion)

● Device: Nexus 4● 10 subscribers x 10 events● 5 experiments● 2000 Users● 20000 Messages

Kevin’s My

GreenDAO 2.0.0 2.1.0

ORMLite 4.48 4.48

DBFlow 2.0.0 3.0.0-beta5

Squeaky 0.4.0 0.4.0.2

Realm 0.84.1 0.88.0

OS Write (ms) Read(ms) W/R (slower)

Write (ms)In memory

Read(ms)In memory

W/R (slower)

SQLite4.2.2 2741 647 2202 532

5.1 1248 365 1153 378

SQLiteX4.2.2 901 474 867 446

5.1 734 373 721 342

DBFlow4.2.2 1297 740 1036 640

5.1 1001 514 1101 546

GreenDAO4.2.2 1256 670 1159 775

5.1 1243 563 956 516

ORMLite4.2.2 1792 914 1750 902

5.1 1673 621 1560 654

Squidb4.2.2 1012 454 1015 479

5.1 948 386 780 404

OS Write (ms) Read(ms) W/R (slower) Write (ms)In memory

Read(ms)In memory W/R (slower)

Realm4.2.2 1257 552 39%/17% 1347 670 55%/50%

5.1 1598 814 117%/118% 1552 803 115%/134%

Using the NDK Performantly (Big Android BBQ 2015)

What can really help?

The Definitive Guide to SQLite

Grokking Android

URI

Next?!

“Fast” communication with EventBus

http://greenrobot.org/eventbus/

What is EventBus? It…

● simplifies the communication between components● decouples event senders and receivers● performs well with Activities, Fragments, and background threads● avoids complex and error-prone dependencies and life cycle issues● makes your code simpler● is fast● is tiny (<50k jar)● is proven in practice by apps with 100,000,000+ installs● has advanced features like delivery threads, subscriber priorities, etc.

*Almost

Let's check?! EventBus Vs LocalBroadcastManager (LBM)

Input:

● OS versions: 4.2.2 and 5.1 (Genymotion)● Device: Nexus 4● Event Bus 3.0● LocalBroadcastManager 23.2.1● Subscriber thread: UI thread● Sender thread: Worker Thread (IntentService)● 10 subscribers x 10 events● 5 experiments*

OS Avr. Time (ms)

EventBus4.2.2 1878.8

5.1 540.4

LBM4.2.2 1508 ~24% faster

5.1 381.6 ~41% faster

Who next?

“Rapid” Mortar

A little history...

Spring of 2010...

Results...

+2 projects at Google play market

He was “surprised” ....

Next developer...

I think so...

Why this can't work good?!

● Inconvenient to support changes in API and backward compatibility● Lose all benefits for to control on Task stack● Unreasonable consuming memory● Lose some cool features (e.g. Android Transition Framework)● e.t.c.

One more?

RxAndroid: real solution for unreal problems

Problems:● CPU intensive tasks● connection to network● work with files● long-running activity● e.t.c

Tools:● Java Threads + concurrency

framework● HaMeR● AsyncTask● Loaders● Services● JobScheduler● AlarmManager● DownloadManager● e.t.c.

Where the place for RxAndroid?

https://github.com/googlesamples/android-testing-templates.git

“I’m aware of retrolambda, and I think I love the idea. I think it’s wonderful. Before using it, I would go decompile the result of retrolambda to see what exactly happens. Because with lambda, I’m sure you could have nasty surprises. I’m pretty sure it turns into anonymous classes somewhere, so you might end up with tons of allocations depending on how they’re invoked. For instance, if I pass a lambda in a loop, what happens in terms of allocations? So, I would just go look at the disassembly and see what’s going on before I would decide. You know, the anonymous class could be cached, or it could be reallocated every time, I don’t know. I would have to look at it. It’s one of those cases where it’s important, as software engineers, to try to understand what is going on under the hood before making a decision about how to use it, because you can end up with nasty surprises down the road. And of course, in some cases like if you just using that lambda when you click on a button, that really doesn’t matter, right? Performance is not that big of an issue when you click on a button.

Romain Guy

Everything else…

DI

facebook engineering

TTDErik Meijer is Dutch computer scientist, the founder of Applied Duality, one of the creators of modern programming languages such as C#.…Unsurprisingly, Meijer has a take on how the development work should be organized and executed. He states that test-driven development should die out – it can’t predict the bugs anyway.

– Just push it to production. It will fail, but testing is only about writing tests, not real code. If it breaks, fix it! TDD is for pussies!

https://reaktor.com/blog/erik-meijer-software-eating-world/

Android Application Testing Guide

compile "com.raizlabs.android:DBFlow-Core:2.2.1" compile "com.raizlabs.android:DBFlow:2.2.1" compile 'com.google.dagger:dagger:2.0' compile 'javax.annotation:jsr250-api:1.0' compile 'com.squareup.retrofit:retrofit:2.0.0-beta2' compile 'com.squareup.retrofit:converter-jackson:2.0.0-beta2' compile 'de.greenrobot:eventbus:2.4.0' compile 'com.birbit:android-priority-jobqueue:1.3.5' compile 'org.apache.commons:commons-lang3:3.4' compile 'com.fasterxml.jackson:jackson-parent:2.6.2' compile 'joda-time:joda-time:2.9.1' apt 'com.raizlabs.android:DBFlow-Compiler:2.2.1' apt 'com.google.dagger:dagger-compiler:2.0' androidTestApt 'com.google.dagger:dagger-compiler:2.0' androidTestCompile 'com.android.support.test:runner:0.4' // Set this dependency to use JUnit 4 rules androidTestCompile 'com.android.support.test:rules:0.4' // Set this dependency to build and run Espresso tests androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1' // Set this dependency to build and run UI Automator tests androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2' androidTestCompile 'com.android.support:support-annotations:23.1.1' androidTestCompile 'org.mockito:mockito-core:2.0.2-beta' androidTestCompile ('com.android.support.test.espresso:espresso-contrib:2.2.1') { exclude module: 'support-annotations' exclude module: 'support-v4' exclude module: 'support-v13' exclude module: 'recyclerview-v7'

https://github.com/yigit/dev-summit-architecture-demo.git

“This is not an official Google product.● The sample app uses many public open source

projects. You should not take these as suggestions to use in your app. This demo application is written in a short time and we've used many libraries to make it a complete app as fast as possible. Since this is a demo app, we did not care much about performance characteristics of these libraries. As always, do your due diligence before using any library.

● The models do not cache anything in memory. A real app should.

● There is moderate testing for the project. They are not state of the art testing examples but show how different use cases can be tested.”

compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.github.bumptech.glide:glide:3.5.2' compile 'com.android.support:support-annotations:22.2.0' compile 'com.android.support:gridlayout-v7:22.2.0' compile 'com.android.support:cardview-v7:22.2.0' compile 'com.android.support:appcompat-v7:22.2.0' compile 'com.android.support:design:22.2.0' compile 'com.android.support:recyclerview-v7:22.2.0' compile 'com.google.android.apps.muzei:muzei-api:2.0' compile 'com.google.android.gms:play-services-gcm:8.3.0' compile 'com.google.android.gms:play-services-location:8.3.0'

https://github.com/sorinpanduru/sunshine.git

https://github.com/googlesamples/android-BasicSyncAdapter.git

https://github.com/googlesamples/android-testing-templates.git

https://github.com/googlesamples/android-architecture

Meanwhile… Somewhere…

“Programming is not a science. Programming is a craft.”

- Richard Stallman

Q&A

Thanks you for attention!