23
Little Networks Stacy Devino Big Android BBQ 2015

Big Trouble in Little Networks

Embed Size (px)

Citation preview

Page 1: Big Trouble in Little Networks

Little Networks

Stacy Devino Big Android BBQ 2015

Page 2: Big Trouble in Little Networks

• Senior Android Innovator at The Home Depot

Dallas Technology Center

• Works on Consumer Mobile App and Internal

Product Innovation

• WTM Lead, SixSigma BlackBelt, Intel Innovator,

DMS Member, Vintage game collector/restorer

STACY DEVINO

WEBSITES www.stacydevino.com www.ledgoes.com www.openbrite.com

EMAIL [email protected]

G+ https://plus.google.com/+StacyDevino

TWITTER @DoesitPew

Page 3: Big Trouble in Little Networks

● 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

Biggest Issues

Page 4: Big Trouble in Little Networks

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)

Tracking Your Application Data

Page 5: Big Trouble in Little Networks

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"

Capturing a PCAP

Page 6: Big Trouble in Little Networks

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+

Download + InstalL ARO

Page 7: Big Trouble in Little Networks

Quick, Valuable insight to major issues which may be occurring.

Track Image sizes and downloaded resources

Cached Resources

Duplicated APIs

Areas of Improvement

ARO Main Summary

Page 8: Big Trouble in Little Networks

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.

ARO Main Summary (Competitor)

Page 9: Big Trouble in Little Networks

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! $$$$$

ARO Main Summary (Competitor)

Page 10: Big Trouble in Little Networks

ARO Main Summary (Competitor)

Page 11: Big Trouble in Little Networks

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!)

ARO Profiles

Page 12: Big Trouble in Little Networks

ARO Overview

Page 13: Big Trouble in Little Networks

ARO Diagnostics (similar to Network Monitor)

Page 14: Big Trouble in Little Networks

Overall Score Sheet

How did Yah do?

Eh, not bad

But, we can DO BETTER!

ARO Stats

Page 15: Big Trouble in Little Networks

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

Filtering your Images

Page 16: Big Trouble in Little Networks

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

Page 17: Big Trouble in Little Networks

1. JPEG (or WebP) whenever possible (no Transparency needed)

2. ARGB_4444 for Iconography assets pulled from the network

3. Compress all your images (once)

4. Compress all your images (twice)

5. Compress all your images (three times a …)

6. Don’t be afraid to compress Lossy (especially with large images like 5MP+ Camera captured images, Google Photos does it!)

7. Compression on the Network != Compression in your Heap (do both)

8. Design your APIs to work with Screens of Many sizes

TL:DR Image Filtering

Page 18: Big Trouble in Little Networks

ADJUST YOUR ASSETS BASED ON YOUR NETWORK TYPE!!!!!

Very Simple, just use the BroadcastReceiver class I have posted here:

https://github.com/childofthehorn/BABBQNetworkTracker/blob/master/app/src/main/java/com/stacydevino/networktracker/ConnectivityChangeReceiver.java

That way you can dynamically adjust your API requests for quality

because SPEED MATTERS.

Tracking Your Network Type

Page 19: Big Trouble in Little Networks

● 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

Structuring Images for Speed

Page 20: Big Trouble in Little Networks

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, Samsung Galaxy Centura , ZTE, Alcatel OneTouch phones (Prepaid smartphones less than $100)),

HIGH Width : 1536 Height : 1904 MEDIUM Width : 1050 Height : 1400 LOW Width : 640 Height : 800

Tracking your network type

Page 21: Big Trouble in Little Networks

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 (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

Bundle Together : GCMNetworkManager makes it easy to do this (https://goo.gl/ThFuyo)

Data Batching

Page 22: Big Trouble in Little Networks

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. Batching your individual application data together and offload to high speed networks when possible

6. Bundle as a system with GcmNetworkManager

TL:DR API Structure

Page 23: Big Trouble in Little Networks

The Home Depot DTC Google Developers

Android Performance Patterns ATT and WireShark

Big Android BBQ Team / IDEAA

THANKS !