中译英，专业报告。　　　　才涉及相关翻译，时效性强，26页，大约15000个字左右（中文），头儿要求当天翻译完，我，我，实在是觉得mission impossible啊～～　　不知道是自己太菜还是的确不太可能？　　　　大家来交流下吧～～～～～～　　
楼主发言：1次 发图：0张 | 更多
　　估计到极限了。潘太史曾经一日12000字日翻中，法律文件，比较容易。
　　他说的一天是 24 小时还是 8 小时啊？不可能完成的吧？
　　你们头儿懂的是哪国语言啊？让他试试。
　　什么公司？要人命啊！
　　　　啊，听大家这样说，我感觉好多了，　　　　昨天头儿问我翻完了没有，我说没有。她皱眉头，怎么这么慢？　　　　我已经跟我们头儿反馈了下目前进度，并建议为了最佳工作效果，如果有时效性强的文章需要翻译，最好挑简短的文章。或者以摘要形式发送。　　
　　才15000个字????/太容易,主要是机电自动化　　
　　这个量还是可以一拼的
　　这还得看翻译质量吧。。
　　大家都这么牛啊，佩服佩服。
　　a horrible task！　　15000字/24h＝625字/h　　625字/60m＝10字/m！　　
　　我做法律英翻中，正常一天（指保证8小时睡眠和留出正常吃饭时间）6000字，最少的时候就是2000字，最多的时候10000左右。最关键是看内容，碰到别扭的，一段话要两个小时才能搞定；碰到熟悉的，就很快！
　　你们头也太过分了　　我曾经用了1个周才翻译完这么多的关于城市交通布局设置的稿子，不过是在下班时间，都快疯了，那些崩溃的句子与词汇！呵呵
　　MSN：ma_　　有意相互交流切磋者，请加偶！
　　英译中
我一天能翻译 字，一般字，包括打字整理
　　要看这15000是不是全相关内容的了。
　　那就看专业是否自己十分熟悉和文章的难易程度了.
　　5000----6000
　　比较标准的量了
　　2000英语单词/3000中文是正常速度。有的客户或翻译公司要求每天做五六千字，那是不合理的。不过，国内对翻译质量的要求确实比较低，很多情况下可以蒙混过关。　　
　　怨念一下，手头正做的一个稿，本来是有所谓的参考资料（某公司以前翻的资料），可那资料错误百出，根本无法当作参考，却还堂而皇之地贴在公司网页上，假如真有洋鬼子来看，不知会作何感想。　　
　　内容熟悉的话，两三个工作日，要是不熟悉的话，五个工作日
　　不熟悉的内容，一天翻3000个字也算挺快了。我翻不熟悉的内容时，基本每个名词都要查，而且往往要查好几次（字典、译典、谷歌、百度、客户提供的参考资料），一小时只能翻200字上下。我真的很好奇，每天翻3000字（或以上）不熟悉的中英，究竟是怎样办到的？【前提是稿件中没有大段重复】　　
　　先用软件翻，再自己对照进行润色
　　工作时间包括上论坛溜溜和上QQ的时间.
　　作者：sky9890
回复日期： 12:32:00
　　　　　　先用软件翻，再自己对照进行润色　　－－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　　　这也太不现实了。即便是人工翻译出来的稿件，如果初译者水平不行，也得重新翻一遍；软件翻的只会更差，根本不可能“润色”。假如只需要看个大意，倒也罢了；可是笔译对准确率的要求在99％以上，因此每个词都得较真，你用软件翻完了，还是得挨个词查清楚。除非稿件里有自己或他人用手工翻过的完整段落，且已经存在翻译辅助软件里，这时软件才派得上用场。　　
　　是啊，头儿不懂的话，给她解释一下。在这么短的时间，我完成不了。
　　最狠一次是，上午六点到中午十二点，英译中，7000个中文字。　　　　不过是一个系列的最后一个文件，内容非常熟悉，而且使用CAT。　　
　　其实也不难, 建议你用口译的速度去译, 口译要不了半天的时间.当然这样是没有质量的,既然讲速度,那肯定顾全不了质量.
　　不用通读文章，看一句译一句，真的译不下去再看下文，第一反应怎么译就怎么打出来。拿不准的先根据感觉随便翻译出来，然后做上记号，全文翻译完了回来检查。　　中途休息下，以便更有效率地工作。另外得沉住气。　　本人在中新社巴黎分设做翻译，新闻注重时效性，一般情况下我就是用这种方式工作的。　　辛苦是肯定的，但是不可能的事未必就是常常有的。关键还是看个人吧。你有时间来网上发帖子，就没时间做翻译？
　　明白了。怪不得人家说，要读地道优美的中文，只能在书上看，找报纸看是不行的。怪不得我读参考消息这样的报纸，都不止一次发现有意思错误，而且是光看中译文就能发现错误。　　
　　还有，通读文章很费时间吗？如果是经常翻译新闻，每分钟读相当于300汉字的内容，应该没问题吧？用得着在这上面省时间？　　
　　呵呵，如果你翻译像楼主这样26页的东东，而又要在一天完成，你倒是先把东西通读一边试试
　　另外其实我讲的只是工作效率问题，而XIAOWENSAN朋友讲的则是一种工作责任心问题，如果翻译有错，一方面可能与译者水平翻译状态有关，另一方面也与他的责任心有关，我觉得倒未必是与这种工作方法有关。
　　我也觉得不可能,我最快的速度一天也才五千,当然工作时间除外啦~
　　要看稿子内容如何，有些内容精巧需要精雕细琢需要时间长点，我接稿最喜欢时间充裕一点的，这样有时间充分检查推敲，这样其实也能节省他们审查的时间:)
　　呵呵，如果你翻译像楼主这样26页的东东，而又要在一天完成，你倒是先把东西通读一边试试　　-----------------------------------------------------------　　　　很简单啊，我从不接这种活，因为这样的要求本身就是无理要求。有翻译的时间，没通读的时间？呵呵，唬谁啊？　　　　态度决定一切。　　
　　怪不得我读参考消息这样的报纸，都不止一次发现有意思错误，而且是光看中译文就能发现错误。　　---------------------&&参考消息&&的翻译腔到处都是!
　　本人最高纪录10个小时12000字英翻汉。最低纪录1个小时20字。
　　比较正常的是 一个工作日　　我得记录是10000 十个小时　　我一天的翻译时间不会超过 10个小时的　　才能保证体力和质量　　加一句 是英到中的
　　先用软件翻，再自己对照进行润色　　－－－－－－－－－－－－－－－－－－－－－－－－－－－－　　这也太不现实了。即便是人工翻译出来的稿件，如果初译者水平不行，也得重新翻一遍；软件翻的只会更差，根本不可能“润色”。假如只需要看个大意，倒也罢了；可是笔译对准确率的要求在99％以上，因此每个词都得较真，你用软件翻完了，还是得挨个词查清楚。除非稿件里有自己或他人用手工翻过的完整段落，且已经存在翻译辅助软件里，这时软件才派得上用场。　　_________________________________________________　　非常赞同！　　建议初为翻译者，千万不可用软件。　　我去年帮一个师弟做评职称的翻译，但我当时太忙了，就让他先翻译我再润色。结果，他用的是某个最为流行的软件，我最后修改润色得差点吐血！　　这样的修改，是我翻译同样内容的正常工作量的1.5倍甚至2倍。　　这是我的体会。　　我自己翻译从来不敢用什么翻译软件。不过，金山词霸倒是很有用。
　　我最近一次的记录是，从早上8：00起床到晚上12：00睡觉，除去三餐饭，4900字中文（翻译成英文）。　　专业性技术性很强的文件。　　用金山词霸和牛津高阶手用得都软了。
请遵守言论规则，不得违反国家法律法规回复(Ctrl+Enter)「译」Android最佳实践指南----GitHub Star 7000+ - 简书
「译」Android最佳实践指南----GitHub Star 7000+
Updated on
更新Stetho 相关，简书markdown不支持锚 -_-||||||||||||Updated on
表明谷歌对ADT的废弃态度，新增段落：对于非发布版本的构建使用不同的包名不定时同步更新欢迎转载，但请保留译注者链接：
Lessons learned from Android developers in . Avoid reinventing the wheel by following these guidelines. If you are interested in iOS or Windows Phone development, be sure to check also our
documents.
Summary 概要
使用Gradle和它推荐的项目结构
将密码和敏感数据放在gradle.properties中
不要自己写Http客户端，使用Volley或OkHttp
使用Jackson来解析JSON
由于65k方法数限制，避免使用Guava并维持数量较少的库引用
使用Fragment呈现UI
Activity仅用于管理Fragment
Layout XML同样也是代码，好好组织它们
使用style来避免Layout XML中的重复属性
使用多个style文件避免生成一个庞然大物
保持colors.xml简短并谨记DRY，只在其中定义基础色彩
同样保持dimens.xml DRY，仅定义一般常量
不要制造过深的ViewGroup层级
避免WebView的客户端侧处理，并知晓它可能导致内存泄漏
使用Robolectric做单元测试，Robotium做UI测试
模拟器使用Genymotion
总是使用 ProGuard 或 DexGuard
简单的数据持久化使用SharedPreferences，其他的使用ContentProvider
使用Stetho进行应用debug
Android SDK
放在你的home目录或是其他应用无关的位置。某些IDE***的时候就包含了SDK，并且会将其放置在与IDE相同的目录下。当你需要升级（或重装，或改变）IDE时这就成了一件坏事。同时还要避免将SDK放在另一个系统级别的目录下，那样很可能会让你在使用user权限运行IDE时需要用到sudo权限。
Build system 构建系统
你的默认选择应该是 。Ant的限制要多并且语句还更冗长。使用Gradle，能够简单做到：
使用不同的flavours或variants来构建你的app
制作简单的script-like的tasks
管理并下载依赖
自定义keystores
Android's Gradle plugin同时在被Google做为新标准构建系统积极开发中
Project structure 项目结构
有两种广泛使用的选择：旧式的Ant & Eclipse ADT project structure,和新式的Gradle & Android Studio project structure。你应该选择新式，如果你还在使用旧式，考虑将之做为宝贵遗产并转向新式吧。
Old structure:
old-structure
├─ assets
└─ com/futurice/project
├─ AndroidManifest.xml
├─ build.gradle
├─ project.properties
└─ proguard-rules.pro
New structure:
new-structure
├─ library-foobar
├─ androidTest
└─ com/futurice/project
└─ com/futurice/project
└─ AndroidManifest.xml
├─ build.gradle
└─ proguard-rules.pro
├─ build.gradle
└─ settings.gradle
主要不同点在于新式使用了来自Gradle的概念，更清晰地分开了'source sets' (main, androidTest)。举个例子，你可以添加source sets 'paid' 和 'free' 到 src中作为构建 paid 版本 和 free 版本的代码目录。使用一个top-level app对于将你的app从那些需要引用的 库项目 (e.g., library-foobar) 中区分开来很有效。settings.gradle中写着那些 能被app/build.gradle引用的 库项目 的引用。
Gradle configuration Gradle配置
General structure. Follow
Small tasks. 与这些 (shell, Python, Perl, etc) 脚本不同，你能用Gradle来安排tasks。Just follow
for more details.
Passwords.在app的 build.gradle中你需要为release版本的构建定义signingConfigs，以下为需要避免的事项：
不要这样做。这些信息会出现在版本控制系统中。
signingConfigs {
storeFile file("myapp.keystore")
storePassword "password123"
keyAlias "thekey"
keyPassword "password789"
与之对应，通过一个不会包含在版本控制系统中的gradle.properties这样做：
KEYSTORE_PASSWORD=password123
KEY_PASSWORD=password789
这个文件将会被gradle自动载入，所以你能在build.gradle中像这样来使用它：
signingConfigs {
storeFile file("myapp.keystore")
storePassword KEYSTORE_PASSWORD
keyAlias "thekey"
keyPassword KEY_PASSWORD
catch (ex) {
throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")
使用 Maven 解决依赖而非导入 jar
如果你明确地在项目中包含特定版本的 jar（比如说 2.1.1），下载与处理 jars 的更新将会是一件笨重累赘的事，这个问题在 Maven 中被解决得很好，这也是 Android Gradle builds 所鼓励的方式。看下面这个例子：
dependencies {
compile 'com.squareup.okhttp:okhttp:2.2.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.2.0'
避免 Maven 的动态依赖避免使用动态依赖的库版本, 像是 2.1.+ ，因为这可能会导致不同的、不稳定的构建，或是在数次构建之间表现出细微的、不可追踪的差异行为。使用静态版本像是2.1.1会创建更稳定的、可预期的和可重复的开发环境。
对于非发布版本的构建使用不同的包名为debug使用applicationIdSuffix ，这能够让debug还有release版本的apk同时***在同一部设备上（如果你有任何需要的话，还能将此技巧应用于自定义的 build 类型）。对于一个 app 的生命周期来说，当它被发布到市场之后，这一特性将变得非常有价值。
buildTypes {
applicationIdSuffix '.debug'
versionNameSuffix '-DEBUG'
使用不同的icons来区分***在设备上的不同构建版本app----比如说使用不同的色彩或是使用一个覆盖的"debug"标签。对于Gradle来说，这非常容易，你只需要将debugicon 放在app/src/debug/res，而release icon 放在 app/src/release/res。你还可以针对不同的构建版本更改应用名，versionName也可以改变（就像上面这个例子做的那样）。
IDEs and text editors IDE和文本编辑器
无论使用什么编辑器，它必须能针对项目结构让人愉快地使用文本编辑器是一个很个人的选择，依据项目结构和构建系统来让编辑器起到作用同时也是你的责任。
目前最推荐的IDE是 ，因为它由Google开发，与Gradle关系最紧密，默认使用新式项目结构，针对Android开发量身定做。
来进行Android开发不再是一个好的选择。2015年，谷歌终止了对ADT的支持，并催促开发者尽快向Android Studio迁徙。and urges users toas soon as possible.你也可以继续使用它，但是需要一番配置，因为它采用旧式项目结构与Ant构建。如果 Eclipse 的 Gradle 集成令你使用得不愉快，你的选择只有使用命令行来构建。
你也能只使用一个单纯的文本编辑器像是Vim,Sublime Text, 或 Emacs。在这种情况下，你需要在命令行环境下使用 Gradle 和 adb 。
无论你使用什么，总得确保使用 Gradle 和新式项目结构 来构建应用，注意不要将编辑器相关的配置文件加到版本控制系统中。比如，避免添加Ant 的 build.xml 文件。如果你在 Ant 中更改配置， 一定不要忘记让build.gradle保持 up-to-date 和 functioning 。
还有，善待其他的开发者，不要强迫他们改变他们个性化的工具配置。
Libraries 库
是一个用于 Object 与 JSON 间相互转换的Java库。 也是一个作为解决此问题广受欢迎的存在。然而我们发现 Jackson 表现更好，因为它提供了可选择的方式来处理 JSON : streaming, in-memory tree model, and traditional JSON-POJO data binding。所以Jackson 的体积会比 GSON 要大。取决于你的实际情况，你可能倾向于选择 GSON 以避免 65k
方法数限制。其他选项还有:
网络，缓存和图像.这儿有好几种经过实战检验的用于后端服务器请求的解决方案，你将使用哪一种取决于你自己将要实现的客户端。使用
或 . Volley 额外提供了 helpers 以解决 载入和缓存图像。要是你选择 Retrofit, 考虑用
来做这些, 同时用
来完成高效 HTTP 请求。Retrofit, Picasso 和 OkHttp
这三个工具由同一家公司开发，所以他们能完美地补足彼此。 .
RxJava 是一个响应式编程框架，换句话说，处理异步事件。 它是一种强大并有前途的范例，可能从可读性上讲不是那么理想因为它是如此的不同。我们推荐你在使用这个库来构筑整个应用之前抱持着足够的警惕。有一些项目通过使用 RxJava 构筑， 如果你需要帮助可以和他们之中的人交谈: Timo Tuominen, Olli Salonen, Andre Medeiros, Mark Voit, Antti Lammi, Vera Izrailit, Juha Ristolainen. 我们写了一些博文发表在这上面: , , , .
如果你从前没有运用 Rx 的经历，只需要从将它作为对 API 的回应开始即可。你也可以选择从作为简单 UI 事件处理开始，像是 search field 上的点击或者输入事件。如果你对自己的 Rx 技能足够自信并决定将它应用到整个应用构筑中，一定要针对所有不易理解的部分写Javadoc。用心记住其他不熟悉 Rx 的程序员可能会对维护项目感到无比头大。尽你的全力来帮助他们理解你的代码还有 Rx 。
是一个用来让 JDK8 之前的 Android 或是其他平台支持Lambda表达式语法的库。它用于保持你的代码紧凑并可读，特别是当你使用函数式风格编写代码比如说 RxJava 。为了使用它, 你需要*** JDK8, 在 Android Studio 的 Project Structure dialog 设置它作为你的 SDK Location , 然后设置环境变量 J***A8_HOME 和 J***A7_HOME , 接着在项目根目录的 build.gradle 引用依赖:
dependencies {
classpath 'me.tatarka:gradle-retrolambda:2.4.1'
并在每一个模块的 build.gradle 中添加
apply plugin: 'retrolambda'
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
retrolambda {
jdk System.getenv("J***A8_HOME")
oldJdk System.getenv("J***A7_HOME")
javaVersion JavaVersion.VERSION_1_7
Android Studio 提供了对于 Java8 lambda 的代码协助支持，如果你是 lambda 的新手，只需从以下建议中开始：
任何只有一个方法的接口都是 "lambda friendly" 的，亦即能被收缩成更紧凑的语法格式
如果对 参数 或其他 的什么拿不准，那么就写一个普通的匿名内部类并让 Android Studio 为你将它收缩成 lambda 格式
注意 dex 方法数限制，避免使用过多库Android apps 当被打包成 dex file 时, 有一个固定的引用方法数限制：65536
. 如果你超出了这一限制，就会在编译时遇见一个致命错误。出于这个理由，使用尽可能少的库，并且使用这个工具
来决定使用哪些库集合来保证低于这一限制。特别要避免使用 Guava library, 因为它包含超过 13k 方法.
Activities and Fragments
针对怎样最佳地通过 Fragments 和 Activities 来组织 Android 架构尚无统一结论，这一点不论在社区还是在 Futurice 的开发者中都是一样。Square 甚至开发了一个库用来最大化地通过View来构筑应用架构 ，以此绕过对于 Fragment 的依赖，但这在社区中仍未被作为广泛推荐的方案。
出于Android API的历史，你能自然地想到将Fragments作为屏幕上的UI碎片。换句话说，Fragments通常与UI相关联。Activities能被自然地想到作为控制器，从生命周期和状态管理上的重要性来说。然而，你很可能遇见角色产生变化的情况：activities可能被作为UI角色()，而fragments能被单独作为控制器 。我们推荐谨慎启航，获知尽可能多的消息然后作出决定，因为无论是选择fragments-only、activities-only还是views-only架构，都存在着其缺陷。这里对于需要小心些什么有一些建议，但你需要持保留态度吸收它们：
避免广泛使用嵌套fragments
, 这可能会发生
。 要么在有意义的时候使用嵌套fragments (举个例子, 在一个screen-like 的fragment中需要一些 fragments 放在一个水平方向滑动的 ViewPager 中) ,要么就确保这是一个深思熟虑后的决定。
避免放太多代码在activities中。任何情况下只要可能，让它们作为轻量containers，其存在意义首要在于应用的生命周期循环以及其他重要的Android-interfacing APIs。采用单fragment的activity而不是一个单纯的activity，这样可以将UI代码放在fragment中。当你需要改变它以重新放置到一个标签布局或是一个多fragment表格屏幕中去的时候，这使得它能够被复用。避免持有一个无对应fragment的activity，除非你完全知晓这样做的后果。
不要让你的应用的内部工作滥用Android-level APIs，像是重度依赖于Intent。这可能会影响到Android OS或是其他应用，制造bugs或者延迟。举个例子，如果你的应用使用Intent作为内部通信手段，可能会招致多秒延迟----如果它在OS启动后紧接着被用户打开的话。
Java packages architecture Java分包架构
在Java分包架构方面，Android只能算是粗略接近MVC模型。在Android中，Fragment和Activity是实际上的控制器类。从另一方面来说，它们又明显是用户接口的部分，所以同时也是视图。
出于这一理由，无法将fragments (or activities)严格划分为控制器或是视图。让它们保持自己的fragments package更好一些。Activities能放在最高级package中只要你遵循之前部分的建议。如果你计划超过两个或三个Activities，那么再加一个 activities package。
另外，也可以像经典的MVC那样来进行分包架构，通过使用一个models package包含POJOs（这些POJOs由JSON解析器解析API responses转化生成），和一个views package包含你的自定义Views，notifications, action bar views, widgets, etc。Adapters算是一个麻烦，存在于数据和视图之间。然而，典型情况是它们会通过getView()方法输出一些视图，因此你可以把adapters subpackage将在views里面。
一些application-wide的和接近于Android系统的控制器类可以放置在一个managers package中。混杂的数据处理类，像是"DateUtils"，放在utils package中。那些用于与后端交互的类则放在network package中。
总的来说，序列是从 closest-to-backend 到 closest-to-the-user:
com.futurice.project
├─ network
├─ models
├─ managers
├─ utils
├─ fragments
└─ views
├─ adapters
├─ actionbar
├─ widgets
└─ notifications
Resources 资源
命名 遵循类型前缀惯例，像是 type_foo_bar.xml. Examples: fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
组织 layout XMLs. 如果你不确定如何格式化 layout XML, 以下惯例会有所帮助：
一个属性一行，4 空格缩进
android:id 总是作为第一个属性
android:layout_**** 这类属性放在最上面
style 属性放在最下面
Tag closer /& 拥有自己的一行, 以使顺序清晰和添加属性变得容易
与其使用硬编码 android:text, 不如考虑使用设计时属性
，其受 Android Studio支持.
&?xml version="1.0" encoding="utf-8"?&
&LinearLayout
xmlns:android="/apk/res/android"
xmlns:tools="/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:id="@+id/name"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:text="@string/name"
style="@style/FancyText"
&include layout="@layout/reusable_part" /&
&/LinearLayout&
作为一个经验法则，android:layout_****应该在layout XML中定义，同时其他的属性android:****应该放在style XML中。这条法则会有例外，但总体而言工作得很好。这个想法是为了仅将layout (positioning, margin, sizing)和content属性放在layout files中，而外观详情 (colors, padding, font) 放在 styles files中。
那些例外是:
android:id 明显应该放在 layout files 中
android:orientation 属性对于 LinearLayout 来说一般 放在 layout files 中更有意义
android:text 应该放在 layout files 中因为它定义了 content
有些情况下让 style 来定义 android:layout_width 和 android:layout_height 常量会很有用，但默认情况下它们应该出现在 layout files 中
使用 styles. 几乎每一个项目都需要适当地使用 style，因为对于 view 来说有着重复的外观是非常常见的事，看下面这个例子:
&style name="ContentText"&
&item name="android:textSize"&@dimen/font_normal&/item&
&item name="android:textColor"&@color/basic_black&/item&
该 style 被用于 TextViews:
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/price"
style="@style/ContentText"
你很可能需要为buttons做一些相同的事，不要在这里停下。从宏观角度上提炼出一组相关联的、重复的android:****属性到一个公共的 style 中去。
把一个大的 style 文件分割成多个你无须拘泥于单个 styles.xml 文件。 Android SDK 支持其他不符合这一命名规则的文件，关于文件名 styles什么魔法也没有，起效果的是文件中的 XML tags &style& 。因此你能拥有这样命名的style文件 styles.xml, styles_home.xml, styles_item_details.xml, styles_forms.xml。 不像 resource 目录那样命名对构建系统具有意义， res/values 目录下的文件命名完全可以随意。注：是的，你可以在strings.xml中放color资源，ResourceManager通过映射可以找到它。
colors.xml 是一个颜色调色板 你的colors.xml中不要放其他事物，只需要映射颜色名到一个RGBA值。不要为不同类型的buttons定义RGBA值。
Don't do this:
&resources&
&color name="button_foreground"&#FFFFFF&/color&
&color name="button_background"A91BD&/color&
&color name="comment_background_inactive"F5F5F&/color&
&color name="comment_background_active"󥖁&/color&
&color name="comment_foreground"&#FFFFFF&/color&
&color name="comment_foreground_important"&#FF9D2F&/color&
&color name="comment_shadow"񎺠&/color&
你只是简单地采用重复RGBA值来格式化，但这会使得在需要改变基础颜色的时候变得操作复杂。同时，这些定义与上下文紧密关联，像是"button" or "comment"，它们应该放置于一个button style 中，而非colors.xml。
Instead, do this:
&resources&
&!-- grayscale --&
&color name="white"
&#FFFFFF&/color&
&color name="gray_light"&#DBDBDB&/color&
&color name="gray"
󥖁&/color&
&color name="gray_dark" F5F5F&/color&
&color name="black"
񎺠&/color&
&!-- basic colors --&
&color name="green"D34D&/color&
&color name="blue"A91BD&/color&
&color name="orange"&#FF9D2F&/color&
&color name="red"&#FF432F&/color&
&/resources&
向应用设计者询问调色板。命名无须全都是颜色名像是"green", "blue", etc.这样的命名也是完全可以接受的："brand_primary", "brand_secondary", "brand_negative"。像这样格式化颜色会让改变和重定义颜色变得容易，还能让人看出一共有多少种不同的颜色被使用。通常对漂亮的UI设计来说，减少所使用颜色的多样性是一件重要的事。
好好对待 dimens.xml ，正如对待 colors.xml.你也应该定义典型的间距和字号大小的“调色板”，像对于色彩的基本意图那样。一个好的 dimens 文件的例子像是这样:
&resources&
&!-- font sizes --&
&dimen name="font_larger"&22sp&/dimen&
&dimen name="font_large"&18sp&/dimen&
&dimen name="font_normal"&15sp&/dimen&
&dimen name="font_small"&12sp&/dimen&
&!-- typical spacing between two views --&
&dimen name="spacing_huge"&40dp&/dimen&
&dimen name="spacing_large"&24dp&/dimen&
&dimen name="spacing_normal"&14dp&/dimen&
&dimen name="spacing_small"&10dp&/dimen&
&dimen name="spacing_tiny"&4dp&/dimen&
&!-- typical sizes of views --&
&dimen name="button_height_tall"&60dp&/dimen&
&dimen name="button_height_normal"&40dp&/dimen&
&dimen name="button_height_short"&32dp&/dimen&
&/resources&
像通常对待strings那样，你应该使用spacing_**** dimensions 来设置 layouting, margins 和 paddings，而不是使用硬编码值。这会带来一致的观感，同时让组织和改变styles及layouts变得简单。
strings.xml
使用类似的命名空间来命名你的strings的keys，不要害怕在两个或多个keys中重复某一个值。语言是很复杂的，所以命名空间是有必要的，它能用于提供上下文信息还有打破模糊。
&string name="network_error"&Network error&/string&
&string name="call_failed"&Call failed&/string&
&string name="map_failed"&Map loading failed&/string&
&string name="error.message.network"&Network error&/string&
&string name="error.message.call"&Call failed&/string&
&string name="error.message.map"&Map loading failed&/string&
不要写全大写的string值。遵循一般的文本惯例(e.g., capitalize first character)。如果你需要将整句string大写显示，那么针对实例使用TextView中的这个属性 。
&string name="error.message.call"&CALL FAILED&/string&
&string name="error.message.call"&Call failed&/string&
避免深层级的 views. 有时候你只是想要再加一个LinearLayout，用于完成一些views的布置。但这种情况却可能会发生:
&LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
&RelativeLayout
&LinearLayout
&LinearLayout
&LinearLayout
&/LinearLayout&
&/LinearLayout&
&/LinearLayout&
&/RelativeLayout&
&/LinearLayout&
尽管你没有在layout文件中直接目击到这样的景象，但这最终有可能发生，如果你填充(in Java) views到其他views中。
一些问题可能会发生。你也许遇见过性能问题，因为这样会生成一棵复杂的UI树来让处理器解析。另一个更严重的问题则是可能带来栈溢出错误： .
因此，试着让你的views层级尽可能的扁平：学习如何使用, 如何优化你的布局
还有如何使用 .
清楚与 WebView 相关的问题 当你必须要显示一个web页面的时候，比如说一篇文章，避免客户端侧的对于HTML的清理处理，更好的方式是从后端程序中直接获取一段 "纯粹的" HTML 。当持有Activity的引用而非ApplicationContext时，WebView还可能导致内存泄漏 when they keep a reference to their Activity, instead of being bound to the ApplicationContext。避免用 WebView 来做一些简单的文本或按钮， 更好的选择是 TextViews 或 Buttons。
Test frameworks 测试框架
Android SDK's testing framework尚不完善，特别是有关于UI 测试。Android Gradle实现了一个命名为的测试任务，它能运行你创造的JUnit test，参考.这意味着你需要连接实机或模拟器来运行测试，参考官方测试的指南
作为 unit tests, 而不要做 views tests 这是一个致力于提高开发速度的无须连接设备的测试框架，特别适用于针对models 和 view models的单元测试。然而，Robolectric对于UI tests是不完全并且错误的。在测试以下相关UI元素时会有问题：animations, dialogs, etc,而且当你“行走于黑暗中”（没法看到屏幕正被控制着操作）时，实际情况究竟怎样也是非常难以理解的。
让写 UI tests 变得简单 你可能不需要用Robotium来连接实机跑UI case，但你仍会通过它获取好处，因为它提供了许多helpers用于获取及分析views以及控制屏幕。Test cases 将看起来很简单像是这样:
solo.sendKey(Solo.MENU);
solo.clickOnText("More"); // searches for the first occurence of "More" and clicks on it
solo.clickOnText("Preferences");
solo.clickOnText("Edit File Extensions");
Assert.assertTrue(solo.searchText("rtf"));
Emulators 模拟器
如果你是专业的Android apps开发者，买一个专业版 吧。Genymotion比原生模拟器运行起来有着更高的帧速。它拥有一些工具用于调试你的应用，像是模拟网络连接质量，GPS位置等。用于连接着进行UI test它也很理想。你还能获取许多（不是全部）不同的虚拟设备，与购买许多实机相比Genymotion专业版的花费实在是十分便宜。
警告：Genymotion emulators不支持所有的Google服务像是Google Play Store and Maps.要是你想要测试三星特征的APIs，仍旧有必要拥有一台三星实机。
Proguard configuration Proguard配置
常作为Android项目中缩减体积、混淆代码的工具。
是否使用ProGuard取决于你的项目配置。通常你可以在gradle中像这样配置以在构建正式apk时使用ProGuard。
buildTypes {
minifyEnabled false
signingConfig signingConfigs.release
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
为了决定某些代码是需要保持原样还是丢弃（注：即未实际使用，不打包，这也就是为什么使用ProGuard会减少应用体积）还是混淆，你需要在代码中指出一个或多个关键点。这些关键点区分出这些典型的类：with main methods, applets, midlets, activities, etc.Android framework使用的默认混淆配置能在这里找到：SDK_HOME/tools/proguard/proguard-android.txt，使用这个配置，再加上你自己在这里定义的项目限定的配置：my-project/app/proguard-rules.pro，将会共同构成最终的ProGuard混淆规则。
使用ProGuard经常遇见的一个问题是应用启动时闪退，错误信息则为ClassNotFoundException or NoSuchFieldException or similar,尽管运行构建命令成功 (i.e. assembleRelease) 且无警告。这意味着以下一到两件事：
ProGuard移除了类、枚举、方法、域或注解，检查一下哪些是不需要移除的部分。
ProGuard混淆（重命名）了类、枚举、域，但这些都在代码中被直接使用了它们原本的命名， i.e. through Java reflection.
检查app/build/outputs/proguard/release/usage.txt看是否有存疑对象被移除掉了。检查 app/build/outputs/proguard/release/mapping.txt 看是否有存疑对象被混淆了。
防止ProGuard丢弃一些需要的类或类成员，在你的ProGuard配置中加入keep options：
-keep class com.futurice.project.MyClass { *; }
防止ProGuard混淆一些需要的类或类成员，添加keepnames:
-keepnames class com.futurice.project.MyClass { *; }
for some examples.Read more at
for examples.
尽早地在你的项目中提供一个正式版本构建 用来检查ProGuard是否执行正确符合预期是十分重要的事。当你引用了新库的时候，记得构建一个正式 版本在实机上测试一下。不要等到你的应用要发布"1.0"版本了再来构建正式版本，你可能会遭遇一些令人不愉快的惊喜，而你没有剩下的时间去修正它们。
建议 保存好每一个你发布给你用户的正式版本的mapping.txt file 。通过持有这些文件，你才能够debug一些问题，当你的用户遇见bug并提交了一份带有混淆的stack trace.
DexGuard. 如要你需要一个 hard-core tools 来优化并混淆正式版本代码, 可以考虑 , 制作 ProGuard 的团队推出的商用软件. 它还能轻松地分割 Dex files 以解决65k方法数限制.
Data storage 数据存储
SharedPreferences
如果你只需持久化简单的标志位并且你的应用只在单进程环境下运行。SharedPreferences对你来说很可能已经足够了。它是不错的默认选项。
这儿有两个原因会让你不想要使用SharedPreferences：
性能: 你拥有大量数据或者数据本身非常复杂
多进程获取数据: 你拥有运行在各自进程中的组件或是远程服务，它们需要同步数据
ContentProviders
在SharedPreferences不够满足你的需求的情况下，你应该使用作为平台标准的ContentProvider，它快速并且进程安全。
关于ContentProvider的问题则在于你在使用它之前需要写大量的样板似的代码，还有就是低质量的学习指南。如果可能的话，使用自动库来生成ContentProvider，这样会显著减少劳力。such as .
你仍然需要靠你自己来写一些解析代码用于从Sqlite列中读取出Object数据，反之亦然。你可以序列化数据对象，像是使用Gson，并且只持有结果字串。通过这种方式你会损失一些性能，但另一方面你将不需要为数据类中的每一个域都声明列。
Using an ORM
我们通常不推荐使用对象关系映射库Object-Relation Mapping library，除非你有着不寻常的复杂数据和迫切的需要。它们趋向复杂并需要时间去学习。如果你决定使用ORM了，要是你的应用对 进程安全 process safe 有需求的话就要注意所使用的库是否支持 这一特性，许多现存的ORM解决方案令人惊讶地不支持。
Use Stetho
，一款来自于Facebook 的Android applications debug bridge，与Chrome 开发者工具集成在一起。使用它你很轻易就能检查应用，尤其是网络通信。它还能让你简单地检查和编辑SQLite 数据库、shared preferences。但是，你应用确保Stetho 仅在debug版本中可用，release版本中不可用。
Antti Lammi, Joni Karppinen, Peter Tackage, Timo Tuominen, Vera Izrailit, Vihtori M?ntyl?, Mark Voit, Andre Medeiros, Paul Houghton and other Futurice developers for sharing their knowledge on Android development.
Creative Commons Attribution 4.0 International (CC BY 4.0)
译者推荐阅读
软件工程师
思想第一 代码第二