深入探索Android应用性能优化

5星 · 超过95%的资源需积分: 0 83 浏览量更新于2024-07-23 8 收藏 2.63MB PDF 举报

"Android应用性能优化(完整版）带书签" 在移动开发领域，特别是在Android平台上，应用性能优化是一项至关重要的任务。本书《Android应用性能优化》由Hervé Guihot撰写，全面探讨了如何提升Android应用程序的性能，使其运行更加流畅、高效。以下是对该书部分内容的详细解析： 1. **内存管理优化** - 内存泄漏：书中会详细介绍如何检测和避免内存泄漏，这对于保持应用的稳定性和延长设备电池寿命至关重要。 - 对象生命周期：深入理解Activity、Service、BroadcastReceiver和ContentProvider等组件的生命周期，以及如何正确管理它们，可以防止不必要的资源消耗。 - 垃圾回收（GC）：了解GC的工作原理，以及如何避免触发不必要的GC周期，能显著提升应用性能。 2. **UI性能优化** - 视图层次结构：优化视图层次结构可以减少绘制时间和CPU使用率。书中可能包含关于减少嵌套布局、使用Merge标签和ViewStub的建议。 - 动画与过渡：高效使用动画系统，如使用Property Animation替代View Animation，以及适时使用硬件加速，能提高用户体验。 - RecyclerView和ListView的优化：学习如何有效地复用视图，减少滚动时的卡顿。 3. **代码性能优化** - 编程最佳实践：遵循Android编码规范，例如避免使用大量全局变量，减少冗余计算，优化算法等。 - 使用编译器优化：理解ProGuard和R8工具如何进行代码混淆、优化和压缩，以减小程序大小并提高运行效率。 - 并发与多线程：掌握并发编程的基本概念，合理利用线程池，避免主线程阻塞。 4. **资源优化** - 图片压缩与优化：了解如何选择合适的图片格式，压缩图片大小，以及使用Nine-Patch图片以适应不同屏幕尺寸。 - 资源加载策略：动态加载资源可以减少启动时间和内存占用，比如延迟加载、按需加载等方法。 - 字体和字符串优化：合理使用字符串资源，避免硬编码，同时注意字体文件的大小和数量。 5. **电池寿命优化** - 电源管理：学习如何降低应用的功耗，例如限制后台活动，减少唤醒锁的使用，及时关闭传感器等。 - 能耗分析：使用工具如Battery Historian来监控应用的能耗，找出潜在的问题。 6. **测试与调试** - 性能测试工具：如Systrace、Traceview、Android Profiler等，用于识别性能瓶颈。 - 代码分析：利用Lint和其他静态代码分析工具，找出潜在的性能问题和代码缺陷。 - 用户反馈：结合用户反馈进行性能优化，不断迭代和改进。 7. **App启动优化** - 了解应用启动过程，优化初始化逻辑，减少启动时间，提升用户第一印象。《Android应用性能优化》提供了全面的指南，帮助开发者提升应用的性能、响应速度和用户体验，是Android开发者必备的参考资料。通过实践书中的方法，开发者可以创建出更加高效、流畅的应用，满足用户对高质量软件的需求。

CHAPTER 1: Optimizing Java Code

002564: 7110 3d00 0000 |0006: invoke-static {v0},

Lcom/apress/proandroid/Fibonacci;.computeRecursively:(I)J

00256a: 0b00 |0009: move-result-wide v0

00256c: 9102 0402 |000a: sub-int v2, v4, v2

002570: 7110 3d00 0200 |000c: invoke-static {v2},

Lcom/apress/proandroid/Fibonacci;.computeRecursively:(I)J

002576: 0b02 |000f: move-result-wide v2

002578: bb20 |0010: add-long/2addr v0, v2

00257a: 1000 |0011: return-wide v0

00257c: 8140 |0012: int-to-long v0, v4

00257e: 28fe |0013: goto 0011 // -0002

The first number on each line specifies the absolute position of the code within the file.

Except on the very first line (which shows the method name), it is then followed by one

or more 16-bit bytecode units, followed by the position of the code within the method

itself (relative position, or label), the opcode mnemonic and finally the opcode’s

parameter(s). For example, the two bytecode units 3724 1100 at address 0x00255a

translate to “if-le v4, v2, 0012 // +0011”, which basically means “if content of virtual

by skipping 17 bytecode units” (17

equals 11

). The term “virtual register” refers to the

fact that these are not actual hardware registers but instead the registers used by the

Dalvik virtual machine.

Typically, you would not need to look at your application’s bytecode. This is especially

true with Android 2.2 (codename Froyo) and later versions since a Just-In-Time (JIT)

compiler was introduced in Android 2.2. The Dalvik JIT compiler compiles the Dalvik

bytecode into native code, which can execute significantly faster. A JIT compiler

(sometimes referred to simply as a JIT) improves performance dramatically because:

 Native code is directly executed by the CPU without having to be

interpreted by a virtual machine.

 Native code can be optimized for a specific architecture.

Benchmarks done by Google showed code executes 2 to 5 times faster with

Android 2.2 than Android 2.1. While the results may vary depending on what

your code does, you can expect a significant increase in speed when using

Android 2.2 and later versions.

The absence of a JIT compiler in Android 2.1 and earlier versions may affect

your optimization strategy significantly. If you intend to target devices running

Android 1.5 (codename Cupcake), 1.6 (codename Donut), or 2.1 (codename

Éclair), most likely you will need to review more carefully what you want or

need to provide in your application. Moreover, devices running these earlier

Android versions are older devices, which are less powerful than newer ones.

While the market share of Android 2.1 and earlier devices is shrinking, they still

represent about 12% as of December 2011). Possible strategies are:

 Don’t optimize at all. Your application could be quite slow on these

older devices.

CHAPTER 1: Optimizing Java Code

 Require minimum API level 8 in your application, which can then be

installed only on Android 2.2 or later versions.

 Optimize for older devices to offer a good user experience even

when no JIT compiler is present. This could mean disabling features

that are too CPU-heavy.

TIP: Use android:vmSafeMode in your application’s manifest to enable or disable the JIT

compiler. It is enabled by default (if it is available on the platform). This attribute was introduced

in Android 2.2.

Now it is time to run the code on an actual platform and see how it performs. If you are

familiar with recursion and the Fibonacci series, you might guess that it is going to be

slow. And you would be right. On a Samsung Galaxy Tab 10.1, computing the thirtieth

Fibonacci number takes about 370 milliseconds. With the JIT compiler disabled, it takes

about 440 milliseconds. If you decide to include that function in a Calculator application,

users will become frustrated because the results cannot be computed “immediately.”

From a user’s point of view, results appear instantaneous if they can be computed in

100 milliseconds or less. Such a response time guarantees a very good user experience,

so this is what we are going to target.

Optimizing Fibonacci

The first optimization we are going to perform eliminates a method call, as

shown in Listing 1–3. As this implementation is recursive, removing a single

call in the method dramatically reduces the total number of calls. For example,

computeRecursively(30) generated 2,692,537 calls while

computeRecursivelyWithLoop(30) generated “only” 1,346,269. However, the

performance of this method is still not acceptable considering the response-

time criteria defined above, 100 milliseconds or less, as

computeRecursivelyWithLoop(30) takes about 270 milliseconds to complete.

Listing 1–3. Optimized Recursive Implementation of Fibonacci Series

public class Fibonacci {

public static long computeRecursivelyWithLoop (int n)

{

if (n > 1) {

long result = 1;

do {

result += computeRecursivelyWithLoop(n-2);

n--;

} while (n > 1);

return result;

}

return n;

}

CHAPTER 1: Optimizing Java Code

NOTE: This is not a true tail-recursion optimization.

From Recursive To Iterative

For the second optimization, we switch from a recursive implementation to an iterative

one. Recursive algorithms often have a bad reputation with developers, especially on

embedded systems without much memory, because they tend to consume a lot of stack

space and, as we just saw, can generate too many method calls. Even when

performance is acceptable, a recursive algorithm can cause a stack overflow and crash

an application. An iterative implementation is therefore often preferred whenever

possible. Listing 1–4 shows what is considered a textbook iterative implementation of

the Fibonacci series.

Listing 1–4. Iterative Implementation of Fibonacci Series

public class Fibonacci {

public static long computeIteratively (int n)

{

if (n > 1) {

long a = 0, b = 1;

do {

long tmp = b;

b += a;

a = tmp;

} while (--n > 1);

return b;

}

return n;

}

Because the n

term of the Fibonacci series is simply the sum of the two previous

terms, a simple loop can do the job. Compared to the recursive algorithms, the

complexity of this iterative algorithm is also greatly reduced because it is linear.

Consequently, its performance is also much better, and computeIteratively(30) takes

less than 1 millisecond to complete. Because of its linear nature, you can use such an

algorithm to compute terms beyond the 30

. For example, computeIteratively(50000)

takes only 2 milliseconds to return a result and, by extrapolation, you could guess

computeIteratively(500000) would take between 20 and 30 milliseconds to complete.

While such performance is more than acceptable, it is possible to to achieve even faster

results with a slightly modified version of the same algorithm, as showed in Listing 1–5.

This new version computes two terms per iteration, and the total number of iterations is

halved. Because the number of iterations in the original iterative algorithm could be odd,

the initial values for a and b are modified accordingly: the series starts with a=0 and b=1

when n is odd, and it starts with a=1 and b=1 (Fib(2)=1) when n is even.

CHAPTER 1: Optimizing Java Code

Listing 1–6. BigInteger Version of Fibonacci.computeIterativelyFaster

public class Fibonacci {

public static BigInteger computeIterativelyFasterUsingBigInteger (int n)

{

if (n > 1) {

BigInteger a, b = BigInteger.ONE;

n--;

a = BigInteger.valueOf(n & 1);

n /= 2;

while (n-- > 0) {

a = a.add(b);

b = b.add(a);

}

return b;

}

return (n == 0) ? BigInteger.ZERO : BigInteger.ONE;

}

That implementation guarantees correctness as overflows can no longer occur.

However, it is not without problems because, again, it is quite slow: a call to

computeIterativelyFasterUsingBigInteger(50000) takes about 1.3 seconds to

complete. The lackluster performance can be explained by three things:

 BigInteger is immutable.

 BigInteger is implemented using BigInt and native code.

 The larger the numbers, the longer it takes to add them together.

Since BigInteger is immutable, we have to write “a = a.add(b)” instead of simply

“a.add(b)”. Many would assume “a.add(b)” is the equivalent of “a += b” and many would

be wrong: it is actually the equivalent of “a + b”. Therefore, we have to write “a =

a.add(b)” to assign the result. That small detail is extremely significant as “a.add(b)”

creates a new BigInteger object that holds the result of the addition.

Because of BigInteger’s current internal implementation, an additional BigInt object is

created for every BigInteger object that is allocated. This results in twice as many

objects being allocated during the execution of

computeIterativelyFasterUsingBigInteger: about 100,000 objects are created when

calling computeIterativelyFasterUsingBigInteger (50000) (and all of them but one will

become available for garbage collection almost immediately). Also, BigInt is

implemented using native code and calling native code from Java (using JNI) has a

certain overhead.

The third reason is that very large numbers do not fit in a single, long 64-bit value. For

example, the 50,000

Fibonacci number is 34,7111–bit long.

NOTE: BigInteger’s internal implementation (BigInteger.java) may change in future

Android releases. In fact, internal implementation of any class can change.

剩余277页未读，继续阅读

裤裆有暗器

粉丝: 3
资源: 19

深入探索Android应用性能优化

Android性能优化.pdf

《Android应用性能优化》.(埃尔韦).[PDF]

Android系统性能优化

android app性能优化

android11 性能优化 卡顿

Android系统性能优化的目录？

android 性能优化实战篇 pdf

android系统性能优化

Android 性能优化 赵子健

android 性能优化列表

最新资源

android11 性能优化卡顿

Android 性能优化赵子健