当前位置：首页 > 范文大全 > 实用文>如何编写高效的Android代码

如何编写高效的Android代码

2022-11-13 08:22:44 收藏本文下载本文

“子乐找”通过精心收集，向本站投稿了6篇如何编写高效的Android代码，下面是小编精心整理后的如何编写高效的Android代码，希望能够帮助到大家。

如何编写高效的Android代码

篇1：如何编写高效的Android代码

虽然如此说，但似乎并没有什么好的办法：Android设备是嵌入式设备，现代的手持设备，与其说是电话，更像一台拿在手中的电脑。但是，即使是“最快”的手持设备，其性能也赶不上一台普通的台式电脑。

这就是为什么我们在书写Android应用程序的时候要格外关注效率。这些设备并没有那么快，并且受电池电量的制约。这意味着，设备没有更多的能力，我们必须把程序写的尽量有效。

本章讨论了很多能让开发者使他们的程序运行更有效的方法，遵照这些方法，你可以使你的程序发挥最大的效力。

简介

对于占用资源的系统，有两条基本原则：

不要做不必要的事

不要分配不必要的内存

所有下面的内容都遵照这两个原则。

有些人可能马上会跳出来，把本节的大部分内容归于“草率的优化”(xing:参见[The Root of All Evil])，不可否认微优化(micro-optimization。xing: 代码优化，相对于结构优化)的确会带来很多问题，诸如无法使用更有效的数据结构和算法。但是在手持设备上，你别无选择。假如你认为Android虚拟机的性能与台式机相当，你的程序很有可能一开始就占用了系统的全部内存(xing:内存很小)，这会让你的程序慢得像蜗牛一样，更遑论做其他的操作了。

Android的成功依赖于你的程序提供的用户体验。而这种用户体验，部分依赖于你的程序是响应快速而灵活的，还是响应缓慢而僵化的。因为所有的程序都运行在同一个设备之上，都在一起，这就如果在同一条路上行驶的汽车。而这篇文档就相当于你在取得驾照之前必须要学习的交通规则。如果大家都按照这些规则去做，驾驶就会很顺畅，但是如果你不这样做，你可能会车毁人亡。这就是为什么这些原则十分重要。

当我们开门见山、直击主题之前，还必须要提醒大家一点：不管VM是否支持实时(JIT)编译器 (xing:它允许实时地将Java解释型程序自动编译成本机机器语言，以使程序执行的速度更快。有些JVM包含JIT编译器。)，下面提到的这些原则都是成立的。假如我们有目标完全相同的两个方法，在解释执行时foo比bar()快，那么编译之后，foo()依然会比bar()快。所以不要寄希望于编译器可以拯救你的程序。

避免建立对象

世界上没有免费的对象。虽然GC为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。

如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。

所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则：

当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。

如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个StringBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。

一个更极端的例子是，把多维数组分成多个一维数组。

int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。

如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]数组和Bar[]数组，一定比(Foo,Bar)数组效率更高。(也有例外的情况，就是当你建立一个API，让别人调用它的时候。这时候你要注重对API借口的设计而牺牲一点儿速度。当然在API的内部，你仍要尽可能的提高代码的效率)

总体来说，就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集，进而减少对用户体验的影响。

使用本地方法

当你在处理字串的时候，不要吝惜使用String.indexOf(), String.lastIndexOf()等特殊实现的方法(specialty methods)。这些方法都是使用C/C++实现的，比起Java循环快10到100倍。

使用实类比接口好

假设你有一个HashMap对象，你可以将它声明为HashMap或者Map:

Map myMap1 = new HashMap();

HashMap myMap2 = new HashMap();

哪个更好呢?

按照传统的观点Map会更好些，因为这样你可以改变他的具体实现类，只要这个类继承自Map接口。传统的观点对于传统的程序是正确的，但是它并不适合嵌入式系统。调用一个接口的引用会比调用实体类的引用多花费一倍的时间。

如果HashMap完全适合你的程序，那么使用Map就没有什么价值。如果有些地方你不能确定，先避免使用Map，剩下的交给IDE提供的重构功能好了。(当然公共API是一个例外：一个好的API常常会牺牲一些性能)

用静态方法比虚方法好

如果你不需要访问一个对象的成员变量，那么请把方法声明成static。虚方法执行的更快，因为它可以被直接调用而不需要一个虚函数表。另外你也可以通过声明体现出这个函数的调用不会改变对象的状态。

不用getter和setter

在很多本地语言如C++中，都会使用getter(比如：i = getCount())来避免直接访问成员变量(i = mCount)。在C++中这是一个非常好的习惯，因为编译器能够内联访问，如果你需要约束或调试变量，你可以在任何时候添加代码。

在Android上，这就不是个好主意了。虚方法的开销比直接访问成员变量大得多。在通用的接口定义中，可以依照OO的方式定义getters和setters，但是在一般的类中，你应该直接访问变量。

将成员变量缓存到本地

访问成员变量比访问本地变量慢得多，下面一段代码：

for (int i = 0; i < this.mCount; i++)

dumpItem(this.mItems[i]);

再好改成这样：

int count = this.mCount;

Item[] items = this.mItems;

for (int i = 0; i < count; i++)

dumpItems(items[i]);

(使用“this”是为了表明这些是成员变量)

另一个相似的原则是：永远不要在for的第二个条件中调用任何方法，

如下面方法所示，在每次循环的时候都会调用getCount()方法，这样做比你在一个int先把结果保存起来开销大很多。

for (int i = 0; i < this.getCount(); i++)

dumpItems(this.getItem(i));

同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：

protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {

if (isHorizontalScrollBarEnabled()) {

int size = mScrollBar.getSize(false);

if (size <= 0) {

size = mScrollBarSize;

}

mScrollBar.setBounds(0, height - size, width, height);

mScrollBar.setParams(

computeHorizontalScrollRange(),

computeHorizontalScrollOffset(),

computeHorizontalScrollExtent(), false);

mScrollBar.draw(canvas);

}

这里有4次访问成员变量mScrollBar，如果将它缓存到本地，4次成员变量访问就会变成4次效率更高的栈变量访问。

另外就是方法的参数与本地变量的效率相同。

使用常量

让我们来看看这两段在类前面的声明：

static int intVal = 42;

static String strVal = “Hello, world!”;

必以其会生成一个叫做的初始化类的方法，当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal，然后把一个指向类中常量表的引用赋给strVal。当以后要用到这些值的时候，会在成员变量表中查找到他们。下面我们做些改进，使用“final“关键字：

static final int intVal = 42;

static final String strVal = ”Hello, world!“;

现在，类不再需要方法，因为在成员变量初始化的时候，会将常量直接保存到类文件中。用到intVal的代码被直接替换成42，而使用strVal的会指向一个字符串常量，而不是使用成员变量。

将一个方法或类声明为”final“不会带来性能的提升，但是会帮助编译器优化代码。举例说，如果编译器知道一个”getter“方法不会被重载，那么编译器会对其采用内联调用。

你也可以将本地变量声明为”final“，同样，这也不会带来性能的提升。使用”final“只能使本地变量看起来更清晰些(但是也有些时候这是必须的，比如在使用匿名内部类的时候)(xing:原文是 or you have to, e.g. for use in an anonymous inner class)

谨慎使用foreach

foreach可以用在实现了Iterable接口的集合类型上。foreach会给这些对象分配一个iterator，然后调用 hasNext()和next()方法。你最好使用foreach处理ArrayList对象，但是对其他集合对象，foreach相当于使用 iterator。

下面展示了foreach一种可接受的用法：

public class Foo {

int mSplat;

static Foo mArray[] = new Foo[27];

public static void zero() {

int sum = 0;

for (int i = 0; i < mArray.length; i++) {

sum += mArray[i].mSplat;

}

public static void one() {

int sum = 0;

Foo[] localArray = mArray;

int len = localArray.length;

for (int i = 0; i < len; i++) {

sum += localArray[i].mSplat;

}

public static void two() {

int sum = 0;

for (Foo a: mArray) {

sum += a.mSplat;

篇2：编写可读的代码

代码最重要的读者不再是编译器、解释器或者电脑，而是人，写出的代码能让人易于理解、轻松维护、容易扩展的程序员才是专业的程序员。

代码应当易于理解

在过去的五年里，我们收集了上百个“坏代码”的例子（其中很大一部分是我们自己写的），并且分析是什么原因使它们变坏，使用什么样的原则和技术可以让它们变好。我们发现所有的原则都源自同一个主题思想。

关键思想：代码应当易于理解

我们相信这是当你考虑要如何写代码时可以使用的最重要的指导原则。我们会展示如何把这条原则应用于你每天编码工作的各个不同方面。但在开始之前，我们会详细地介绍这条原则并证明它为什么这么重要。

是什么让代码变得“更好”

大多数程序员（包括两位作者）依靠直觉和灵感来决定如何编程。我们都知道这样的代码：

for (Node* node = list->head; node != NULL; node = node->next)

Print(node->data);

比下面的代码好：

Node* node = list->head;

if (node == NULL) return;

while (node->next != NULL) {

Print(node->data);

node = node->next;

}

if (node != NULL) Print(node->data);

（尽管两个例子的行为完全相同。）但很多时候这个选择会更艰难。例如，这段代码：

return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

它比下面这段要好些还是差些？

if (exponent >= 0) {

return mantissa * (1 << exponent);

} else {

return mantissa / (1 << -exponent);

}

第一个版本更紧凑，但第二个版本更直白。哪个标准更重要呢？一般情况下，在写代码时你如何来选择？

可读性基本定理

在对很多这样的例子进行研究后，我们总结出，有一种对可读性的度量比其他任何的度量都要重要，

管理资料

因为它是如此重要，我们把它叫做“可读性基本定理”。

关键思想：代码的写法应当使别人理解它所需的时间最小化。

这是什么意思？其实很直接，如果你叫一个普通的同事过来，测算一下他通读你的代码并理解它所需的时间，这个“理解代码时间”就是你要最小化的理论度量。

并且当我们说“理解”时，我们对这个词有个很高的标准。如果有人真的完全理解了你的代码，他就应该能改动它、找出缺陷并且明白它是如何与你代码的其他部分交互的。

现在，你可能会想：“谁会关心是不是有人能理解它？我是唯一使用这段代码的人！”就算你从事只有一个人的项目，这个目标也是值得的。那个“其他人”可能就是6个月的你自己，那时你自己的代码看上去已经很陌生了。而且你永远也不会知道——说不定别人会加入你的项目，或者你“丢弃的代码”会在其他项目里重用。

总是越小越好吗

一般来讲，你解决问题所用的代码越少就越好。很可能理解行代码写成的类所需的时间比5000行的类要短。但少的代码并不总是更好！很多时候，像下面这样的一行表达式：

assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

理解起来要比两行代码花更多时间：

bucket = FindBucket(key);

if (bucket != NULL) assert(!bucket->IsOccupied());

类似地，一条注释可以让你更快地理解代码，尽管它给代码增加了长度：

// Fast version of “hash = (65599 * hash) + c”

hash = (hash << 6) + (hash << 16) – hash + c;

因此尽管减少代码行数是一个好目标，但把理解代码所需的时间最小化是一个更好的目标。

理解代码所需的时间是否与其他目标有冲突

你可能在想：“那么其他约束呢？像是使代码更有效率，或者有好的架构，或者容易测试等？这些不会在有些时候与使代码容易理解这个目标冲突吗？”我们发现这些其他目标根本就不会互相影响。就算是在需要高度优化代码的领域，还是有办法能让代码同时可读性更高。并且让你的代码容易理解往往会把它引向好的架构且容易测试。有些程序员对于任何没有完美地分解的代码都不自觉地想要修正它。这时很重要的是要停下来并且想一下：“这段代码容易理解吗？”如果容易，可能转而关注其他代码是没有问题的。

最难的部分

是的，要经常地想一想其他人是不是会觉得你的代码容易理解，这需要额外的时间。这样做就需要你打开大脑中从前在编码时可能没有打开的那部分功能。但如果你接受了这个目标（像我们一样），我们可以肯定你会成为一个更好的程序员，会产生更少的缺陷，从工作中获得更多的自豪，并且编写出你周围人都爱用的代码。

本文节选自《编写可读代码的艺术》一书，Dustin Boswell、Trevor Foucher著，尹哲、郑秀雯译，由机械工业出版社出版。

篇3：Android任意时刻、任意代码处全屏

public void toggleFullscreen(boolean fullScreen) { //fullScreen为true时全屏，否则相反 WindowManager.LayoutParams attrs = getWindow.getAttributes(); if (fullScreen) { attrs.flags |= WindowManager.LayoutParams.FLAG_FULLSCREEN; } else { attrs.flags &= ~WindowManager.LayoutParams.FLAG_FULLSCREEN; } getWindow().setAttributes(attrs); }