View this presentation here on Android Developers:
https://www.youtube.com/watch?v=PxQl56aJ09A&
This is a rehashed version of:
http://www.slideshare.net/StacyWylie/big-trouble-in-little-networks with NEW content and merged example code!
2. STACY DEVINO
•Senior Android Innovator at The Home
Depot Dallas Technology Center
•Works on Consumer Mobile App and
Internal Product Innovation
•WTM Lead DFW, SixSigma BlackBelt,
Intel Innovator, DMS Member, Vintage
game collector/restorer
2
WEBSITES
www.stacydevino.com
www.ledgoes.com
www.openbrite.com
EMAIL
childofthehorn@gmail.com
G+
https://plus.google.com/
+StacyDevino
TWITTER
@DoesitPew
3. Biggest Issues
● Large, Unfiltered Images
● Untracked Data Usage (Does that API really
need to be active right now? )
● Non-optimized Network handling (Batching)
● Not Using the Android tools to help you
● Bad API designs
● Doubled / Badly Handled API calls
3
4. Tracking Your Application Data
Using the Android Tools
Network Monitor in Android Studio
TrafficStats API in Android (http://goo.gl/9cu59J)
Watching your APIs and responses
Charles Proxy (not free, but worth the money)
Detailed Tracking of Network Data (with Forensics)
Application Resource Optimizer (ARO) by ATT (easiest)
Wireshark
Shark for Root (locally on the device)
4
5. Capturing a PCAP
PCAP files are used to track network communications and data
Rooted Phones (see http://goo.gl/uMFv2N for non-rooted phones)
1. Grab a copy of tcpdump from http://goo.gl/YbyaA2
2. Go to Settings > Apps > Running Apps and Force Stop any services that are not part of the Android
System (or use Development options > Background process limit > At most 2 processes )
3. Now open just the app you want to test
4. Open a Terminal and type “adb push tcpdump /sdcard”, "adb shell", "su", “cp /sdcard/tcpdump /
system/xbin”, and then “chmod 755 tcpdump”
If using Wifi:
1. "tcpdump -i wlan0 -s 65535 -w /sdcard/networktrace.pcap"
If using Cellular (rmnetusb0 is also possible, look at “ip addr”):
1. "tcpdump -i rmnet0 -s 65535 -w /sdcard/networktrace.pcap"
5
6. Download + InstalL ARO
1.Download the appropriate version for your OS and
Mobile Platform here : https://goo.gl/gTIvwt
2.Download the DiffTool utility for doing side by side
comparisons of before and after a change https://
goo.gl/f1ai6M
3.Source for ARO : https://github.com/
attdevsupport/ARO
4.Install Dependencies : WinPCAP and JRE 6.0+
6
7. ARO Main Summary
▪ Quick, Valuable
insight to major
issues which may be
occurring.
▪ Track Image sizes and
downloaded
resources
▪ Cached Resources
▪ Duplicated APIs
▪ Areas of Improvement
7
8. ARO Main Summary (Competitor)
You can track your
app’s performance
just as well as you can
track your competitor.
It can be a great way
to see how your app
performance in that
market compares as
well as be able to find
valuable insight to
things they may be
doing right where you
are not.
8
9. ARO Main Summary (Competitor)
▪ Gives you the reasons
for your failures
▪ No cache headers?
▪ That could be a problem
for reused web
resources, making the
device re-download
(using more data).
▪ Cache is King! $$$$$
9
11. ARO Profiles
▪ Define your own WIN
parameters
▪ Allows you to track your
performance against your
user defined values.
▪ Very useful if you have
made new Cellular
performance characteristics
to your APIs and need to
verify it is within the desired
performance (and getting
correct values!)
11
15. ▪ Compression is your FRIEND
▪ PNG vs JPEG vs WebP
▪ 85% Quality JPEG with Smoothing can reduce a 42MB PNG image to 185kb in the Real
World with virtually no loss in Visible Quality
▪ JPEG does not support Transparency
▪ Lossy Compression for Network pulled resources is the way to go for everything that is not
a Photo app (Ok, even a Photo Gallery... maybe not an editor)
▪ Saves MEMORY so you don’t get the dreaded OOME (OutofMemoryError)
▪ WebP is a Combo of the best of JPEG and PNG since it supports Transparency and High
Compression, but does not work for iPhones or universal Mobile Web (so, not a great
possibility for converged APIs)
▪ You can compress PNG lossy and losslessly, but it never quite gets to JPEG
15
Filtering your Images
16. 16
ARGB_8888 ARGB_4444 RGB_565
Transparency X X
Number of Bits 32 16 16
Full Color
(nice
Gradients)
X X
Space on
Image Memory
Load (def.)
SAME SAME SAME
● ARGB_4444 and RGB_565 will be about the same in size (Data in Transit)
● ARGB_4444 is ideal for web icon assets with minimal color gradients and
needing Transparency
● No need of Transparency? RGB_565 is always ideal.
● Android will always load images into the same amount of memory,
regardless of compression, so use the Bitmap Options tools to save
Memory too
Types of Images
17. JPEG (or WebP) whenever possible (no Transparency needed)
ARGB_4444 for Iconography assets pulled from the network
Compress all your images (once)
Compress all your images (twice)
Compress all your images (three times a …) even PNGcrush!
Don’t be afraid to compress Lossy (especially with large images like
5MP+ Camera captured images, Google Photos does it!)
Compression on the Network != Compression in your Heap (do both)
Design your APIs to work with Screens of Many sizes
17
TL:DR Image Filtering
18. ▪ ADJUST YOUR ASSETS BASED ON YOUR NETWORK TYPE!!!!!
▪ Very Simple, just use the BroadcastReceiver class I have
posted here: https://goo.gl/A5P1U3
▪ AND Facebook has an awesome DYNAMIC downstream
bandwidth connection class library that you can use here :
https://goo.gl/I7YLOE which can also be combined with their
YEARCLASS library here: https://goo.gl/Ztgxik
▪ That way you can dynamically adjust your API requests
for quality because SPEED MATTERS.
18
Tracking Your Network Type
20. ● Allows you to account for
Multiple Screen sizes without
skewing
● Dynamic Quality adjustment
based on networks (Bigger
screens can go down)
● Never get larger images than
what you need
● Build based off of the devices
you want to support.
● iPhones can also be
accounted for in the Android
sizing
20
Structuring Images for Speed
21. 21
Ratio : 0.56:1 (16:9)
Devices : iPhone 5/6/6+,
Samsung 3/4/5/6
(Android Devices with
Hardware buttons)
HIGH
Width : 1440
Height : 2560
MEDIUM
Width : 1080
Height : 1920
LOW
Width : 720
Height : 1280
Ratio : 0.63:1
Devices : iPhone 4,
OnePlus 1/2, Nexus 5/5x/
6/6p/7(2013)/7(2014),
Moto X, G, E (2013-2015)
(Android devices with
software buttons)
HIGH
Width : 1440
Height : 2268
MEDIUM
Width : 1080
Height : 1701
LOW
Width : 720
Height : 1134
Ratio : 0.81:1
Devices : Nexus 9,
Samsung Tab S2, ZTE,
Alcatel OneTouch phones
(Prepaid smartphones
less than $100)),
HIGH
Width : 1536
Height : 1904
MEDIUM
Width : 1050
Height : 1400
LOW
Width : 640
Height : 800
Qualities BY network type
22. Serialized data types
JSON
• Most popular, most APIs are formatted like this
• Easy to use libraries like RetroFit and Android Volley
• Still somewhat human-readable
XML
• Very Human-readable and alterable
• LOTS of type-casting overhead, LEAST EFFICIENT
PROTOBUFFERS
• Natively Supported on Android, but totally platform neutral (use with any Language or Platform,
even iOS, Web, and Socket connections)
• Most efficient, but still popular way
• OMG Retrofit works here too now, so try for a combo when you can
• Must have formatted data that meets the expected format almost exactly, not a lot of error
handling here, but Square has provided a tool for easy Conversion and generating code : https://
github.com/square/wire
22
23. Batching your Data is one of the easiest ways to optimize your usage
of Cellular data.
Bundle Yourself
• Wait to offload large datasets ’til the user is on Wifi and hopefully
charging as well (metrics and user behavior)
• JSON is not very efficient (XML is way worse), see if it is possible to
switch to buffered data or binary files. Even CSV is more efficient...I
know, right?
• Bundle your requests and waits together (promotional notifications and
asset updates) this will give your user up to date data before they even
launch the app without using more battery or network data!
Bundle Together
▪ GCMNetworkManager makes it easy to do this
(https://goo.gl/ThFuyo)
23
Data Batching
24. 1. Use lower quality images in low quality networks
2. Time to User matters (you only have a few hundred milliseconds)
3. Allow users to dictate resources and run in a low-usage network mode
(best performance vs. best quality)
4. You can handle virtually all resources with just 3 aspect ratios for all of
Android and iOS, as well as mobile web (Spiffy!)
5. Change your API requests to ProtoBuffers (Best) and JSON if possible
6. Batching your individual application data together and offload to high
speed networks when possible
7. Bundle as a system with GcmNetworkManager
24
TL:DR API Structure
25. THANKS
▪ The Home Depot DTC
▪ Google Developers
▪ Dallas Android Developers
▪ Android Performance Patterns
▪ ATT
▪ WireShark
▪ Big Android BBQ Team / IDEAA
25