android实践

① 基于android系统的手机游戏的开发

如果你有兴趣为Android平台开发游戏，有很多你需要了解的东西。如果你有过游戏开发经验，那么转移到移动平台上来将不是特别困难。你主要只需学习其架构以及API就行了。如果你是一名游戏开发新手，我总结了一张列表，上面有你必需知道的东西，供你起步用。这些知识适用于很多类型的游戏，包括动作类、策略类、模拟类和益智类。Android是一个基于java的环境。这对初学者来说是个好消息，因为相对于C，Java被广泛认为是一门更容易上手的语言，它是移动开发的规范。Google也做了一件出色的工作，它将API文档化并提供示例代码供使用。其中有个叫做APIDemos的示例几乎展示了所有API的功能。如果你熟悉Java并且用过Eclipse，要让你的第一个应用跑起来那是相当简单。如果你以前从没写过代码，在你前进路上还要学习很多，但别气馁。

获取SDK

新手上路的第一步便是获取AndroidSDK（软件开发工具包）。SDK里有一个核心类库，一个模拟器，一些工具和示例代码。我强烈建议使用Eclipse和AndroidEclipse插件。如果你玩Android的话，EclipseIDE对Java开发者来说很好用。如果这是你第一次开发Java项目，你可能会需要下载全套JDK，它里面包括签名和部署你的应用程序的一些工具。

学习应用程序架构

别急着一头扎进开发的海洋里，理解Android应用程序架构是很重要的。如果你不学一下，你设计出来的游戏在线下将很难调试。你将需要理解、Activities、Intents以及它们怎样相互联系。Google提供了很多有用的架构信息。真正重要的是要理解为什么你的游戏需要多于一个的Activity，以及什么才是设计一个有良好用户体验的游戏。要理解这些，首先要了解什么是Activity生命周期。

学习Activity生命周期

Activity生命周期由Android操作系统来管理。你的activity创建、恢复、暂停、销毁都受操作系统的支配。正确处理这些事件是很重要的，这样应用程序才能表现良好，做用户认为正确的事。在你设计你的游戏之前了解所有这些是如何工作的是件好事，因为以后你可以为自己节省调试时间和昂贵的重新设计时间。对大多数应用来说，默认的设置将工作正常，但对于游戏，你可能需要考虑将标志打开。当设置为默认时，Android在它认为合适时会创建activity的新实例。对于游戏来说，你可森余能只需要一个游戏activity的实例。这对于你要怎样管理事务的状态有些影响，但对于我来说，这解决了一些资源管理的问题，应予以考虑。

主循环

根据你写的游戏的类型敏春卖，你可能需要也可能不需要一个主循环。如果你的游戏不依赖于时间或者它仅仅对用户所做的加以回应，并且不做任何视觉上的改变，永远等待着用户的输入，那么你就不需要主循环。如果你写的是动作类游戏或者带有动画、定时器或任何自动操作的游戏，你应该认真考虑下使用主循环。

游戏的主循环以一个特定的顺序通常尽可能多的在每秒钟内“滴答”提醒子系统运行。你的主循环需要在它自己的线程里运行，原因是Android有一个主用户界面线程，如果你不运行自己的线程，用户界面线程将会被你的游戏所阻塞，这会导致Android操作系统无法正常的更新任务。执行的顺序通常如下：状态，输入，人工智能，物理，动画，声音，录像。

更新状态意思是管理状态转换，例如游戏的结束、人物的选择或下一个级别。很多桥逗时候你需要在某个状态上等上几秒钟，而状态管理应该处理这种延迟，并且在时间过了之后设置成下一个状态。

输入是指用户按下的任何键、对于滚动条的移动或者用户的触摸。在处理物理之前处理这些是很重要的，因为很多时候输入会影响到物理层，因而首先处理输入将会使游戏的反应更加良好。在Android里，输入事件从主用户界面线程而来，因此你必须写代码将输入放入缓冲区，这样你的主循环可以在需要的时刻就从缓冲区里取到它。这并非难事。首先为下一个用户输入定义一个域，然后将或函数设为接到一个用户动作就放到那个域里，有这两步就够了。如果对于给定游戏的状态，这是一个合法的输入操作，那么所有输入需要在那一刻做的更新操作都已经定下来了，剩下来就让物理去关心怎样响应输入吧。

人工智能所做的类似于用户在决定下一个要“按”哪个按钮。学习怎样写人工智能程序超出了这篇文章的范围，但大体的意思是人工智能会按照用户的意图来按按钮。这些也有待物理去处理和响应吧。

物理可能是也可能不是真正的物理。对于动作类游戏来说，关键点是要考虑到上一次更新的时间、正在更新的当前时间、用户输入以及人工智能，并且决定它们朝着什么方向发展和是否会发生冲突。对于一个你可视化地抓取一些部件并滑动它们的游戏来说，物理就是这个游戏中滑动部件或者使之放入合适的位置的部分。对于一个小游戏来说，物理即使这个游戏中决定答案是错还是对的部分。你可能将其命名为其他东西，但每个游戏都有一个作为游戏引擎的红肉部分（译者注：可能是主体部分的意思），在这篇文章里，我把这部分称为物理。

动画并非像在游戏里放入会动的gif图片那样简单。你需要使得游戏能在恰当的时间画出每一帧。这并没有听起来那么困难。保留一些像isDancing、danceFrame和那样的状态域，那样动画更新便能决定是否可以切换到下一帧去了。动画更新真正做的事就那么多。真正来显示动画的变化是由录像更新来处理的。

声音更新要处理触发声音、停止声音、音量变化以及音调变化。正常情况下当写游戏的时候，声音更新会产生一些传往声音缓冲区的字节流，但是Android能够管理自己的声音，因而你的选择将是使用SoundPool或者MediaPlayer。它们都需要小心处理以免出错，但你要知道，因为一些底层实现细节，小型、低比特率的声音文件将带来最佳的性能和稳定性。

录像更新要考虑游戏的状态、角色的位置、分数、状态等等，并将一切画到屏幕上。如果使用主循环，你可能需要使用SurfaceView，并做一个“推”绘制。对于其他视图，视图本身能够调用绘制操作，主循环不必处理。SurfaceView每秒产生的帧数最多，最适合于一些有动画或屏幕上有运动部件的游戏。录像更新所要做的工作是获取游戏的状态，并及时地为这个状态绘制图像。其他的自动化操作最好由不同的更新任务来处理。

3D还是2D？

在开始写游戏之前，你要决定是做3D的还是2D的。2D游戏有一个低得多的学习曲线，一般更容易获得良好的性能。3D游戏需要更深入的数学技能，并且如果你不在意的话会有性能问题产生。如果你打算画比方框和圆圈更复杂的图形，还需要会使用3DStudio和Maya那样的建模工具。Android支持OpenGL用来3D编程，并且在OpenGL方面有很多很好的教程可供学习。

建立简单、高质量的方法

上手时，要确保你整个游戏不要就用一个庞大而冗长的方法。如果你遵循我上面描述的主循环模式，这将相当简单。每个你写的方法应当完成一个非常特定的任务，并且它就应该无差错地那样做。举例来说，如果你需要洗一副纸牌，你应该写一个“”的方法，并且该方法就应该只做这一件事。

这是一个适用于任何软件开发的编码实践，但对于游戏开发来说这尤为重要。在一个有状态的、实时的系统里，调试将变得非常困难。使你的方法尽量的小，一般的经验法则是每个方法有且仅有一个目的（译者注：完成且仅完成一个功能）。如果你要为一个场景用编程方式画一个背景，你可能需要一个叫做“”的方法。诸如此类的任务能够很快完成，因而你可以按照搭积木的方法来开发你的游戏，而你能够继续添加你要的功能，并且不会使得这一切难以理解。

最重要的是效率！

性能是任何游戏的主要问题。我们的目标是使得游戏的反应越快越好，看起来越流畅越好。某些方法如Canvas.drawLine比较慢。并且要将屏幕大小的位图画到主画布上，每一帧都是代价昂贵的。如何权衡对于达到最佳性能很有必要。确保管理好你的资源，使用技巧来以最少量的CPU资源完成你的任务。如果性能不好的话，即使是最好的游戏玩起来也没劲。人们一般对于游戏卡或者响应慢几乎难以容忍。

提示和技巧

看一下SDK中的示例LunarLander。它使用SurfaceView，这对于一个每秒需要处理最多帧的游戏来说是合适的。如果你要做3D，示例中有GLView可以处理3D显示的很多初始化工作。对LightRacer来说，我不得不优化把所有东西都画出来这种方法，否则帧率将会大大地降低。我只在视图初始化的时候把背景画进一个位图里一次。路径放在它们自己的位图里，随着车手的前进而更新。这两个位图在每一帧里都被画进主画布中去，车手画在顶端，到最后会有一个爆炸。这种技术使得游戏运行在一个可以玩的程度。

如果适用的话，使得你的位图的大小精确等于你打算画到屏幕上的大小，这也是个好的实践。这么做了以后就需要缩放，可以节省CPU资源。

在游戏中始终一致的位图配置（如RGBA8888）。这将会通过减少不同格式之间转换的时间来节省图形库的CPU时间。

如果你决定开发3D游戏但没有3D方面的知识，你需要挑选一两本3D游戏编程方面的书并学习线性代数。你最少要理解点积、叉积、向量、单元向量、法线、矩阵和变换。这方面我遇到的最好的书是叫《3D游戏编程和计算机图形学数学》。

声音文件要小而且低比特率。需要加载的越少，加载速度越快，游戏所需内存越少。

声音使用OGG文件，图片使用PNG文件。

确保释放所有媒体播放器，当Activity销毁时空出所有的资源。这能保证垃圾收集器清除了所有东西，也能保证在两次游戏开始之间没有内存泄露。

加入Android谷歌小组，寻求社区支持。这里有人可以在开发过程中给你帮助。

最重要的是，花时间测试再测试，确保每一小部分都如你所愿地工作。改善游戏是整个开发中最耗时最困难的部分。如果你匆匆将其推向市场，你很可能会使用户们失望，你会感到你的努力都白费了。你不可能使所有人都喜欢你写的东西，但你至少要尽量发布你最高质量的作品。

② 【译】Android材质组件的动手实践：Dialogs

Android MDC 系列文章：

这篇文章将介绍 Dialogs 组件的功能和API。要了解如何处理Android的Material Components的初始设置（包括Gradle依赖关系和创建应用程序主题），请参阅我的原始文章：

为Android设置Material Components主题

对话框是组件，通常带有模式窗口，显示在应用程序内容的前面。它们用于告知用户可能包含关键信息和/或需要做出决定的任务。它们有目的地打断电流，并一直显示在屏幕上，直到被解散或采取措施为止，因此应谨慎使用。

从设计的角度来看，可以在不同的场景中使用三种主要类型的对话框：

上面所有这些都具有共同的特征：遮盖应用程序内容的背景稀松布（可以选择轻按以关闭对话框）和表面容器。

注意：存在第四种类型： 全屏对话框 。为此， 官方文档 建议使用 *DialogFragment* 和资源限定符一起确定其显示方式。这不在本文的讨论范围之内，因此不会涉及。

可以使用来实现所有上述对话框类型 MaterialAlertDialogBuilder 。该构建器类 AlertDialog 使用Material Design规范和主题来配置和实例化。

显示对话框的基本方法如下：

配置更改（例如设备旋转）后，上述方法将不会保留对话框。为了实现这一点，我们需要花一段 DialogFragment 时间使用 MaterialAlertDialogBuilder 来提供 Dialog ：

DialogFragment 可以使用 导航体系结构组件 显示，也可以通过 Fragment 或 Activity 通过以下方式手动显示：

可以通过将参数传递给来实现上面（和更多）三种对话框中列出的所有特征 MaterialAlertDialogBuilder 。下面列出了其中一些。

注意：在以下大多数情况下，将使用硬编码值。该构建器还提供资源ID的重载。

注意：对话框的中间区域可以被支持文本或一组特定类型的项目占用。这些不能合并。

存在几个主题叠加层，用于更改对话框的总体布局。这些主题覆盖变体继承自 ThemeOverlay.MaterialComponents.MaterialAlertDialog ，每个都有一个可选的后缀：

实施全局自定义Material AlertDialog 主题叠加层时，请在您的应用程序主题中使用 materialAlertDialogTheme 属性引用它。

另外，还有一个辅助 MaterialAlertDialogBuilder 构造函数，它接受覆盖的主题资源ID：

可以使用三个“材料主题”子系统为主题设置“材料警报”对话框： 颜色 ， 版式 和 形状 。我们已经在上面的 “选择主题叠加层” 部分中显示了要使用 的主题叠加层 。除此之外， AlertDialog 可以通过扩展样式并使用属性 在 主题叠加层中引用自定义样式。 MaterialAlertDialog.MaterialComponents``alertDialogStyle

有没有具体的属性自定义在一个对话框中使用的颜色，但 colorPrimary ， colorSecondary ， colorSurface 和各自的“关于”在您的应用程序使用的主题会自动调整对话框颜色颜色改变时。

对话框文本元素将采用 fontFamily 您在应用程序主题中定义的属性。操作按钮的样式将根据 textAppearanceButton 您在应用主题中设置的样式进行设置。

在主题叠加层中，您还可以使用 属性为正文文本专门设置样式。

可以使用该 shapeAppearance 属性自定义对话框背景的形状。默认为 。

我希望这篇文章对对话框以及如何在您的Android应用中使用对话框提供了一些见识。如果您有任何疑问，想法或建议，那么我很乐意收到您的来信！

在Twitter上找到我 @ricknout

③ Android性能优化－大分辨率图片最佳实践

好久没更新博客了，借着908公司18周年年会这个普（期）天（待）同（红）庆（包）的日子，来说下安卓中的图片与内存的关系。
大家都知道安卓中图片是占用内存的大户，在日常开发中也免不了用到图片，那么图片占用内存与哪些因素有关呢，先直接给结论：
1）与图片分辨率有关；
2）与开发者放的文件目录有关；
3）与图片大小没有半毛钱关系。
举个例子：
以现在主流1080p手机为例，新建一个空的工程，用一张1080*1080像素图片来测试：

将图片放在xxhdpi目录下，测试内存，效果如下：

大家可以接着尝试将图片放到mhdpi目录 或者xhdpi目录下，看下内存占用情况，上面放xxhdpi从图上看大概占4M左右，那么这个值是怎么计算来的：
放xxhpi下图片内存占用 ＝ 1080 ＊1080 ＊4 ／1024 / 1024 ＝ 4.45M
稍微解释下公式，像素长＊宽＊一个像素占用的字节数，安卓的色彩模式一个像素占用的字节关系如下表：

也就是说，你在布局文件里随便定义一个imageview，加载一个1080*1080的图片，显示的时候，将按一像素4byte计算内存占拆配昌用。

如果你按照上面的步骤尝试了将图片放到mdpi目录或者xhdpi目录，应该知道结论了，图片占用内存成倍数的变大了，看下放mdpi文件夹下的效果：

如果开发者将同样一张1080*1080像素图片放到mdpi目录下，图片占用内存＝（1080＊3）＊（1080＊3）＊4 ／1024 /1024 ＝ 40M，比之前放xxdpi目录下内存高出了9倍，所以：图片不是乱放的，要谨慎。

现在主流手机分辨率1080p以上，建议大图统一放到xxhdpi目录下管理。

高分辨率图片常见的导致性能缺陷的场景包括：
1）放错图片目录卖基，导致占用内存成倍数增长；
2）限定了高宽的imageview组件，加载了超过该尺寸大小的图片；
3）单色值图片、loading过渡图片、对清晰度要求不高的图片等，强上了大分辨率图片。
这些场景都是在实际开发中遇到过的问题，可能出于设计师的疏忽，可能出于程序猿的随意，修复这些缺陷的成本很低，但是对内存降低的帮助是指数级的，投入产出比这么高的事情，只能说到这里了。
对应的修复手段很明确了：
1）建议图片放xxhpdi目录；
2）限定高宽的imageview，图片最大尺寸不超过该imageview最大承载高宽；
3）简单图片直接下掉，或者压缩下吧，也可以结合业务背景用背景色等替换。

如果你的项目比较小，人肉去找都可以知道哪些是大分旅扒辨率图片，那么检查下使用是否正确。如果你的项目是一个大型客户端项目，人工去找就很尴尬了，是的，我想说python大法好，来个脚本吧，无死角搞定所有大分辨率图片可能导致的性能缺陷：

④ Android 开机自启动service实践

Android 设备启动的时候，会发送android.intent.action.BOOT_COMPLETED的广播，监听这个广播来实现开机自启动。

1） 创建需要的service和 BroadcastReceiver
2） 在AndroidManifest.xml 注册service 和BroadcastReceiver

3）申明权限
```
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

}

⑤ ANDROID多渠道快速打包实践

参考资料：
美团Android自动化之旅—生成渠道包
Android批量打包提速
AndroidMultiChannelBuildTool

背景
随着发版需要，每次发版所需渠道包越来越多（现在差不多有一百个左右了），正常gradle打包由于耗时效率过低已无法满足需求，开始了android多渠道快速打包实践。

方法
下面主要介绍两种快速打包的方式：
1、类似美团的方式，在META-INF中写入渠道名的空文件，用于读取空文件。 美团Android自动化之旅—生成渠道包
2、在apk末尾动态写入渠道信息。 一种动态为apk写入信息的方案
其实这两种方式都是同一个原理，替换以前从manifest中读取渠道号的方式，而使用新的获取方式（渠道号如何写入就如何读取）。
所以这首先需要客户端（重要！）：
1、统一应用中获取渠道的方式并替换之前的（最好兼容）。
2、注意第三方SDK渠道号的传入，比如友盟sdk，否则第三方会使用默认从manifest中读取的方式。

下面介绍一种已经测试过的方法（git上开源项目 AndroidMultiChannelBuildTool ）
1、安装环境由于脚本环境是使用python语言，所以需要我们 安装环境 。
2、导入项目导入开源项目 AndroidMultiChannelBuildTool ），并把想要批量打包的apk文件拷贝到PythonTool目录下（与py同级），运行py脚本即可打包完成。

以上基本实现快速打包，经过测试一分钟百十个无压力。另外需要注意这种方式只适用于打包需求一致渠道号不同，不适用特殊定制渠道。

备注：9月21日补充快速打包java版本，详见 AndroidMultiChannelBuildTool-Java-master