Oracle America, Inc. v. Google Inc.
Filing
509
DECLARATION of RUCHIKA AGRAWAL in Opposition to #496 MOTION in Limine No. 5, #494 MOTION in Limine No. 3, #492 MOTION in Limine No. 1, #493 MOTION in Limine NO. 2, #495 MOTION in Limine No. 4 filed byGoogle Inc.. (Attachments: #1 Exhibit 1-1, #2 Exhibit 1-2, #3 Exhibit 1-3, #4 Exhibit 1-4, #5 Exhibit 1-5, #6 Exhibit 1-6, #7 Exhibit 1-7, #8 Exhibit 1-8, #9 Exhibit 1-9, #10 Exhibit 1-10, #11 Exhibit 1-11, #12 Exhibit 1-12, #13 Exhibit 2-1, #14 Exhibit 2-2, #15 Exhibit 2-3, #16 Exhibit 2-4, #17 Exhibit 2-5, #18 Exhibit 2-6, #19 Exhibit 2-7, #20 Exhibit 2-8, #21 Exhibit 2-9, #22 Exhibit 2-10, #23 Exhibit 2-11, #24 Exhibit 2-12, #25 Exhibit 2-13, #26 Exhibit 2-14, #27 Exhibit 2-15, #28 Exhibit 2-16, #29 Exhibit 2-17, #30 Exhibit 3-1, #31 Exhibit 3-2, #32 Exhibit 3-3, #33 Exhibit 3-4, #34 Exhibit 3-5, #35 Exhibit 3-6, #36 Exhibit 3-7, #37 Exhibit 3-8, #38 Exhibit 3-9, #39 Exhibit 3-10, #40 Exhibit 3-11, #41 Exhibit 4-1, #42 Exhibit 4-2, #43 Exhibit 4-3, #44 Exhibit 5-1, #45 Exhibit 5-2, #46 Exhibit 5-3, #47 Supplement 5-4)(Related document(s) #496 , #494 , #492 , #493 , #495 ) (Kamber, Matthias) (Filed on 10/7/2011)
EXHIBIT 2-1
Designing for Performance | Android Developers
Page 1 of 6
Designing for Performance
An Android application will run on a mobile device with limited computing
power and storage, and constrained battery life. Because of this, it should
be efficient. Battery life is one reason you might want to optimize your app
even if it already seems to run "fast enough". Battery life is important to
users, and Android's battery usage breakdown means users will know if
your app is responsible draining their battery.
Note that although this document primarily covers micro-optimizations,
these will almost never make or break your software. Choosing the right
algorithms and data structures should always be your priority, but is
outside the scope of this document.
In this document
Introduction
Optimize Judiciously
Avoid Creating Unnecessary Objects
Performance Myths
Prefer Static Over Virtual
Avoid Internal Getters/Setters
Use Static Final For Constants
Use Enhanced For Loop Syntax
Consider Package Instead of Private Access with
Inner Classes
Use Floating-Point Judiciously
Know And Use The Libraries
Use Native Methods Judiciously
Closing Notes
Introduction
There are two basic rules for writing efficient code:
• Don't do work that you don't need to do.
• Don't allocate memory if you can avoid it.
Optimize Judiciously
This document is about Android-specific micro-optimization, so it assumes that you've already used profiling to work out exactly what
code needs to be optimized, and that you already have a way to measure the effect (good or bad) of any changes you make. You only
have so much engineering time to invest, so it's important to know you're spending it wisely.
(See Closing Notes for more on profiling and writing effective benchmarks.)
This document also assumes that you made the best decisions about data structures and algorithms, and that you've also considered
the future performance consequences of your API decisions. Using the right data structures and algorithms will make more difference
than any of the advice here, and considering the performance consequences of your API decisions will make it easier to switch to
better implementations later (this is more important for library code than for application code).
(If you need that kind of advice, see Josh Bloch's Effective Java, item 47.)
One of the trickiest problems you'll face when micro-optimizing an Android app is that your app is pretty much guaranteed to be running
on multiple hardware platforms. Different versions of the VM running on different processors running at different speeds. It's not even
generally the case that you can simply say "device X is a factor F faster/slower than device Y", and scale your results from one device
to others. In particular, measurement on the emulator tells you very little about performance on any device. There are also huge
differences between devices with and without a JIT: the "best" code for a device with a JIT is not always the best code for a device
without.
If you want to know how your app performs on a given device, you need to test on that device.
http://developer.android.com/guide/practices/design/performance.html
EXHIBIT 2-1
9/1/2011