The document criticizes the "library" approach to Android development and advocates for a more minimal and performant approach. It discusses several common libraries used in Android development such as ORMs, EventBus, and RxAndroid. It argues that many libraries are not optimized for Android, can have performance issues, and promote coupling between components. The document recommends choosing libraries carefully based on your needs, testing library performance, and favoring simpler solutions over complex libraries when possible to follow Android development best practices around performance and resource usage.

1. Criticue of “library” approach
in developing for android
ILLYA RODIN
Lead Android Engineer

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

3. 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 Haase
Devoxx 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

4. Origin

5. “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”

6. 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 Haase
Udi Cohen
PerformanceDemo

7. Greedy ORM

8. Why not?!
*Almost

9. Galligan's War
Kevin Galligan
Blog
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

10. 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

11. OS Write (ms) Read(ms)
W/R
(slower)
Write (ms)
In memory
Read(ms)
In memory
W/R
(slower)
SQLite
4.2.2 2741 647 2202 532
5.1 1248 365 1153 378
SQLiteX
4.2.2 901 474 867 446
5.1 734 373 721 342
DBFlow
4.2.2 1297 740 1036 640
5.1 1001 514 1101 546
GreenDAO
4.2.2 1256 670 1159 775
5.1 1243 563 956 516
ORMLite
4.2.2 1792 914 1750 902
5.1 1673 621 1560 654
Squidb
4.2.2 1012 454 1015 479
5.1 948 386 780 404

12. OS Write (ms) Read(ms) W/R (slower)
Write (ms)
In memory
Read(ms)
In memory
W/R (slower)
Realm
4.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)

13. What can really help?
The Definitive Guide to SQLite
Grokking Android

14. URI

15. Next?!

16. “Fast” communication with EventBus

17. 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

18. 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)
EventBus
4.2.2 1878.8
5.1 540.4
LBM
4.2.2 1508 ~24% faster
5.1 381.6 ~41% faster

19. Who next?

20. “Rapid” Mortar

21. A little history...
Spring of 2010...

22. Results...
+2 projects at Google play market
He was “surprised” ....
Next developer...
I think so...

23. 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.

25. One more?

26. RxAndroid: real solution for
unreal problems

27. 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.

28. Where the place for RxAndroid?
https://github.com/googlesamples/android-testing-templates.git

29. “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

30. Everything else…

31. DI
facebook engineering

32. TTD
Erik 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

33. 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.”

35. 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

36. Meanwhile…
Somewhere…

37. “Programming is not a science. Programming is a craft.”
- Richard Stallman

38. Q&A

39. Thanks you for
attention!