眼角

模拟器使用Genymotion

故自己每每问自己,为什么女孩子的眼角要大哉。如果送小孩的食指无是诈骗者,而你正好怀念只要一个孩童都以得不交,收生了并且产生啊不针对为。

使用Fragment呈现UI

奇葩说有同等可望的辩题是无钱而无使生子女。反方一员产生心理学背景的辩手介绍了“未成功愿望的魔咒”,即先的要求远非满足会针对君生潜移默化。小时候极端短的,长大后会化您无比怀念使的。所以如果没钱虽老儿女,长大之后孩子会转换得对金格外执着。

动Robolectric做单元测试,Robotium做UI测试

老人说之“眼角要后来居上有”,无非是寄希望于将来时有发生一致上,你出高尚能力的时,不要显得如此不一般配。可是还要生小人口,一辈子才是以往返事先的人生,没有发家,没有越好,只是平凡地,如同昨天一律地了完每一个明罢了。父母善意的期盼成为一生之求而不得。

Java packages architecture Java分包架构

每当Java分包架构方面,Android只能算是粗略接近MVC模型Model-View-Controller。在Android中,Fragment和Activity是实在的主宰器类Fragment
and Activity are actually controller
classes。从单向来说,它们而显而易见是用户接口的片段,所以还要也是视图。

由这等同理由,无法拿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

永不忘记了,欲望使未跟落实欲望之能力相称,那即便是百转千回的忿忿不一致。不要让每个灰姑娘都举行在公主的梦境,这样当她于蒙满灰尘的地下室擦地经常,只能想起亮闪闪的钻石以及皇冠,未免也最凶残。

行使多只style文件避免大成一个巨大

小学起一个同校,她说每天出门前,妈妈还见面吃它简单片钱打早餐,然后同她说,妈妈从不呀钱,工资一个月份只有生两千块,让它们好好学习,以后好多赚钱。后来生平等天,她于街道上遇到一个第三者,对方送它同样就小,她纵然差点就人家走了,后来警力跑过去将她拉扯已才没有出事。妈妈将其对接回家后,打了扳平刹车,妈妈边从边哭,理由是“女孩子眼角要大一些,你怎么如此好糊弄。”她跟本身说之早晚,眼里还透露正在困惑与委屈。她无明白“眼角要后来居上一些”是怎个高法,每天让妈妈教育“家里没有钱”的它,一一味可以小足够大了眼角,进入其底视线了。不知情为何,看到程羽蒙,我就爆冷想到了特别同学。

无须自己写Http客户端,使用Volley或OkHttp

小时侯,家里人常说之言语是“女孩子眼角要高有”。古说富有养女,意思是女孩要高雅、要优雅,要尊重。对于做不至“富养女”的门,“眼角要大一点”成为了经言语来落实之代表。

使Gradle和她推荐的路组织

《等风来》的开场,程羽蒙就算是这样一个关押起“眼角很高”的女孩。她装模作样地点评了高档餐厅的菜色,谢绝了丰裕家小姐朋友送它回家的特约,闪身钻进了那部唬人的“公派”商务车。直到车子上路,才彻底放松下来,说了一样句“师傅,再开始十块钱之吧。”后来于尼泊尔,井柏然拆过它“成天爽”的名下,程羽蒙崩溃了,她将好的不愿、委屈、不平一道脑倒以头里是无辜的富二代身上,撕下伪装下,真实的程天爽以尚未更换得可爱起来。

Using an ORM

我们通常不引进应用对象关系映射库Object-Relation Mapping
library,除非你具备不平庸的复杂性数据与亟待解决的待。它们趋向复杂并需要时错开学学。如果您控制以ORM了,要是你的应用对
进程安全 process safe 有求的说话虽使顾所运用的仓库是否支持
这同样特点,许多现存的ORM解决方案令人惊异地不支持。

求而得无交之,程羽蒙选择用租来的商务车假装自己会获取。而能博取的人,不需要伪装,她说“我未思要”,我虽见面信任。

Activities and Fragments

对如何最佳地经 Fragments 和 Activities 来集团 Android
架构尚无统一结论,这等同沾不论在社区还是在 Futurice
的开发者中都是同等。Square
甚至开了一个库用来最大化地由此View来修建以架构 a library for
building architectures mostly with
Views,以这个绕了对
Fragment 的借助,但就在社区中按未受看成大推荐的方案。

出于Android
API的史,你可知当地想到用Fragments作为屏幕及之UI碎片。换句话说,Fragments通常与UI相关联。Activities能给当地想到作为控制器,从生命周期和状态管理及的机要来说。然而,你非常可能遭遇见角色来变化的情:activities可能吃看做UI角色(delivering
transitions between
screens),而fragments能于单独作为控制器
fragments might be used solely as
controllers。我们引进谨慎启航,获知尽可能多的信然后作出决定,因为任选择fragments-only、activities-only还是views-only架构,都存在在该短。这里对用小心把什么来局部建议,但你需要持保留态度吸收她:

  • 避大采取嵌套fragments nested
    fragments
    , 这可能会见生 matryoshka
    bugs
    。 要么在发出义的时刻用嵌套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启动后接着被用户打开的言辞。

高中的时光,和班里一个女生一从失去到同一涂鸦中学生沙龙。当时其都当拟英语准备出国。沙龙最终一个环是发微博抽奖,发之微博越多滑坡到的票房价值越充分,奖品是如出一辙令拍立得。我乐意地将出手机一下子犯了五六条,她只是说了同样词“可自有些用微博诶”,就拖了手机。后来抽奖抽了了,没有抽到自,我一头埋怨在好心疼,一边删微博,而它们以自己旁边,一直维系着微笑。我说“你刚好干嘛不作什么,好心疼哟。”她说“我莫思量发嘛,我怀念要之话语可好请什么。”我愣住了同一秒钟,然后尴尬地笑笑了笑笑,再没领取抽奖的事。后来每次抽奖看到大家狂热与兴奋的范,我都见面想起那个女孩,也会见无自觉地按一点。我无觉得嫉妒,也未看生气,我只是隐隐有些激动,原来人和人真的匪平等。

Lessons learned from Android developers in
Futurice. Avoid
reinventing the wheel by following these guidelines. If you are
interested in iOS or Windows Phone development, be sure to check also
our iOS Good
Practices

and Windows App Development Best
Practices

documents.

眼角都非常高,前者有点讨人厌,后者则显得那么当。

用style来避免Layout XML中之又属性

水平和眼角其实都差不多,它们来一个一同之近义词叫价位。《世界文学名著百统》一法要4800,而平不成欧洲实践平均消费在15000左右。当与情侣等以在合谈谈去欧洲朝拜文艺复兴的时候,你家的水电单也未会见无故消失的。

Project structure 项目结构

发生个别种常见应用的选取:旧式的Ant & Eclipse ADT project
structure,和新颖的Gradle & Android Studio project
structure。你该选时,如果您还当动旧式,考虑用之做吧珍贵遗产并转发时吧。

Old structure:

old-structure
├─ assets
├─ libs
├─ res
├─ src
│  └─ com/futurice/project
├─ AndroidManifest.xml
├─ build.gradle
├─ project.properties
└─ proguard-rules.pro

New structure:

new-structure
├─ library-foobar
├─ app
│  ├─ libs
│  ├─ src
│  │  ├─ androidTest
│  │  │  └─ java
│  │  │     └─ com/futurice/project
│  │  └─ main
│  │     ├─ java
│  │     │  └─ com/futurice/project
│  │     ├─ res
│  │     └─ 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引用的 库项目 的引用。

实质上自重很爱,但管温馨推广得无比重,最后往往变成嘴硬和装。从小受感化“眼角要高一点”的丫头,既错了什么样平凡的和和谐彼此配合的甜,也未曾道将虚幻的设想成现实。

由于65k方法数限制,避免使Guava并保障数比少之堆栈引用

Layout XML同样也是代码,好好组织她

使用Jackson来解析JSON

以密码和伶俐数据在gradle.properties中

连天以 ProGuard 或 DexGuard

Data storage 数据存储

Activity仅用于管理Fragment

使Stetho进行利用debug


一样保持dimens.xml DRY,仅定义一般常量

License

Futurice Oy
Creative Commons Attribution 4.0 International (CC BY 4.0)

Test frameworks 测试框架

Android SDK’s testing framework尚非周全,特别是关于于UI 测试。Android
Gradle实现了一个命名吧connectedAndroidTest的测试任务,它亦可运作而创造的JUnit
test,参考extension of JUnit with helpers for
Android.这象征你用连接实机或模拟器来运转测试,参考官方测试的指南[1]
[2]

使用 Robolectric
作为 unit tests, 而毫无做 views tests

这是一个事为加强支付速度的永不连接装置的测试框架,特别适用于对models
和 view models的单元测试。然而,Robolectric对于UI
tests是未净而错误的。在测试以下相关UI元素时见面发出问题:animations,
dialogs,
etc,而且当你“行走于黑暗中”(没法看屏幕正被决定正在操作)时,实际情形到底怎么样为是深不便理解的。

Robotium
让写 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"));

Thanks to

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.

Summary 概要

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, 不如考虑以计划时属性 Designtime
    attributes
    ,其受 Android Studio支持.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >

    <TextView
        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>

该 style 被用于 TextViews:

<TextView
    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">#2A91BD</color>
    <color name="comment_background_inactive">#5F5F5F</color>
    <color name="comment_background_active">#939393</color>
    <color name="comment_foreground">#FFFFFF</color>
    <color name="comment_foreground_important">#FF9D2F</color>
    ...
    <color name="comment_shadow">#323232</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"      >#939393</color>
    <color name="gray_dark" >#5F5F5F</color>
    <color name="black"     >#323232</color>

    <!-- basic colors -->
    <color name="green">#27D34D</color>
    <color name="blue">#2A91BD</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中重复某个一个价。语言是非常复杂的,所以命名空间是发生必不可少之,它能够用于提供上下文信息还有打破模糊。

Bad

<string name="network_error">Network error</string>
<string name="call_failed">Call failed</string>
<string name="map_failed">Map loading failed</string>

Good

<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中之之特性textAllCaps

Bad

<string name="error.message.call">CALL FAILED</string>

Good

<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树来让电脑解析。另一个重复重的问题则是可能带来栈溢出左:
StackOverflowError.

故,试着受您的views层级尽可能的扁平:学习怎样使RelativeLayout,
如何优化你的布局 optimize your
layouts
还有哪些使用 <merge>
tag.

明白与 WebView 相关的题目
当你必须使显得一个web页面的时节,比如说一首文章,避免客户端侧的于HTML的清理处理,更好的主意是打后端程序中一直得到一段子
纯粹的” HTML
。当所有Activity的援而未ApplicationContext时,WebView还可能造成内存泄漏WebViews
can also leak
memory
when they keep a reference to their Activity, instead of being bound to
the ApplicationContext。避免用 WebView 来做有概括的文本或按钮,
更好之挑选是 TextViews 或 Buttons。

简易的多少持久化使用SharedPreferences,其他的用ContentProvider

Android SDK

将 Android
SDK
放在公的home目录或是其他使用无关的职。某些IDE安装之早晚就是富含了SDK,并且会将该放置在和IDE相同的目下。当你得提升(或重装,或改)IDE时及时就算成为了同码坏事。同时还要避免以SDK放在另一个系统级别的目下,那样挺可能会见让您以采取user权限运行IDE时需要为此到sudo权限。

Emulators 模拟器

假若你是业内的Android apps开发者,买一个业内版 Genymotion
emulator吧。Genymotion比原生模拟器运行起来有更强的帧速。它有一些器用于调试你的采用,像是仿照网络连接质量,GPS位置等。用于连接在开展UI
test它呢颇出彩。你还能得到许多(不是周)不同的虚构设备,与市多实机相比Genymotion专业版的花实在是非常造福。

告诫:Genymotion emulators不支持具有的Google服务如是Google Play Store
and Maps.要是你想要测试三星星特征的APIs,仍旧有必不可少有同等令三星实机。

避WebView的客户端侧处理,并掌握她或许导致内存泄漏

ContentProviders

于SharedPreferences不足够满足你的急需的情景下,你应有运用作为平台标准的ContentProvider,它很快并且经过安全。

有关ContentProvider的问题则在你以采取它之前需要写大量的指南似的代码,还有就是是没有质量的学习指南。如果可能吧,使用自动库来生成ContentProvider,这样见面明确减少劳力。such
as
Schematic.

卿仍需要负你自己来形容有解析代码用于从Sqlite列中读取出Object数据,反之亦然。你可序列化数据对象,像是行使Gson,并且只是持有结果字串。通过这种方法若见面损失有属性,但一头你将未待吗数据类中的各一个域都声明列。

Gradle configuration Gradle配置

General structure. Follow Google’s guide on Gradle for
Android

Small tasks. 与这些 (shell, Python, Perl, etc)
脚本不同,你会为此Gradle来配置tasks。Just follow Gradle’s
documentation
for more details.

Passwords.
在app的
build.gradle遭遇而用呢release版本的构建定义signingConfigs,以下也需要避免的事项:

绝不这么做。这些消息会油然而生于版本控制系统面临。

signingConfigs {
    release {
        storeFile file("myapp.keystore")
        storePassword "password123"
        keyAlias "thekey"
        keyPassword "password789"
    }
}

暨之相应,通过一个不会含有在版本控制系统被的gradle.properties这样做:

KEYSTORE_PASSWORD=password123
KEY_PASSWORD=password789

斯文件拿会受gradle自动载入,所以若能够在build.gradle中像这样来利用其:

signingConfigs {
    release {
        try {
            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见面创造更平稳之、可预料的及而又的支出环境。

对此非发布版本的构建利用不同的包名
debugbuild
type运applicationIdSuffix
,这能给debug还有release本的apk同时设置在同等部配备及(如果你来其他需要来说,还能以此技运用被由定义之
build 类型)。对于一个 app
的生命周期来说,当它吃宣告到市场下,这同一特性将更换得要命有价。

android {
    buildTypes {
        debug {
            applicationIdSuffix '.debug'
            versionNameSuffix '-DEBUG'
        }

        release {
            // ...
        }
    }
}

应用不同的icons来区分安装于配备及之不等构建版本app——比如说使用不同的情调或是使用一个蒙面的”debug”标签。对于Gradle来说,这非常容易,你只待用debugicon
放在app/src/debug/res,而release icon 放在
app/src/release/res。你还得本着不同之构建版本更改应用名叫change app
name,versionName也堪改(就像面是事例做的那样)。

Libraries 库

Jackson
是一个用来 Object 与 JSON
间相互转换的Java库。Gson
也是一个看作化解这问题大于欢迎之有。然而我们发现 Jackson
表现又好,因为它们提供了但选取的法子来处理 JSON : streaming, in-memory
tree model, and traditional JSON-POJO data binding。所以Jackson
的体积会比 GSON 要十分。取决于你的实在情形,你也许支持被选择 GSON 以避免
65k 方法数限制。其他选择还有:
Json-smart
and Boon
JSON

纱,缓存和图像.
这来少数种经过实战检验的用于后端服务器请求的解决方案,你将运用啊一样种在你自己快要实现之客户端。使用
Volley

Retrofit.
Volley 额外提供了 helpers 以化解 载入和缓存图像。要是你选
Retrofit, 考虑用
Picasso
来做这些, 同时用
OkHttp
来完成快速 HTTP 请求。Retrofit, Picasso 和 OkHttp
这三独器由同家企业开发,所以她们力所能及圆满地补足彼此。 OkHttp can also
be used in connection with
Volley.

RxJava 是一个响应式编程框架,换句话说,处理异步事件。
它是一模一样栽强大并起前景的范例,可能从可读性上说不是那精彩因为她是如此的不同。我们引进你以利用是库房来修整个应用之前抱持着足够的小心。有一些种经下
RxJava 构筑, 如果你待帮忙可以跟她们其中的人数交谈: Timo Tuominen, Olli
Salonen, Andre Medeiros, Mark Voit, Antti Lammi, Vera Izrailit, Juha
Ristolainen. 我们写了有些博文发表在当下点:
[1],
[2],
[3],
[4].

假若你过去未曾采用 Rx 的经历,只待打以其作为针对 API
的应对开始即可。你呢得以选取于作为简单 UI 事件处理开始,像是 search
field 上之点击或者输入事件。如果你针对协调的 Rx
技能足够自信并操纵将它使用到任何应用构筑中,一定要对准具有对理解的一部分写Javadoc。用心记住其他不熟识
Rx
的程序员可能会见对保护项目发无比头大。尽你的奋力来援助他们掌握您的代码还有
Rx 。

Retrolambda
是一个据此来为 JDK8 之前的 Android
或是其他平台支撑Lambda表达式语法的库。它用于维持君的代码紧凑并不过读,特别是当你下函数式风格编写代码比如说
RxJava 。为了采取她, 你待安装 JDK8, 在 Android Studio 的 Project
Structure dialog 设置它当你的 SDK Location , 然后安装环境变量
JAVA8_HOMEJAVA7_HOME , 接着以列根本目录的 build.gradle 引用依赖:

dependencies {
    classpath 'me.tatarka:gradle-retrolambda:2.4.1'
}

并以各级一个模块的 build.gradle 中补充加

apply plugin: 'retrolambda'

android {
    compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

retrolambda {
    jdk System.getenv("JAVA8_HOME")
    oldJdk System.getenv("JAVA7_HOME")
    javaVersion JavaVersion.VERSION_1_7
}

Android Studio 提供了于 Java8 lambda 的代码协助支持,如果您是 lambda
的初手,只需要从以下建议被初露:

  • 其他只来一个道的接口都是 “lambda friendly”
    的,亦即能于抽成重紧密的语法格式
  • 苟对 参数 或另 的啊用不按,那么即便形容一个家常的匿名内部类并受
    Android Studio 为汝将它收缩成 lambda 格式

在意 dex 方法数限制,避免采用过多库
Android apps 当让由包改成 dex file 时, 有一个定位的援方法数限制:65536
[1]
[2]
[3].
如果您过了当下同一范围,就见面以编译时碰到一个致命错误。出于此理由,使用尽可能少的库,并且以此工具
dex-method-counts
来决定下什么库集合来保证低于这等同克。特别要避免以 Guava library,
因为它们涵盖超过 13k 方法.

保持colors.xml简短并谨记DRY,只于里边定义基础色彩

IDEs and text editors IDE和文本编辑器

管采取什么编辑器,它必须能够针对项目布局为丁快地使
文本编辑器是一个杀个人的选,依据项目布局与构建系统来给编辑器起及意向而为是若的权责。

现阶段极度推荐的IDE是 Android
Studio,因为其由Google开发,与Gradle关系最紧密,默认使用时项目组织,针对Android开发量身定做。

使用 Eclipse
ADT
来进展Android开发不再是一个吓的挑三拣四。2015年,谷歌已了针对ADT的支持,并催促开发者尽快向Android
Studio迁徙。Google ended ADT support at the end of
2015and
urges users tomigrate to Android
Studioas
soon as
possible.你呢得以延续以其,但是得一番布置,因为它们采取旧式项目结构以及Ant构建。如果
Eclipse 的 Gradle 集成令你下得无喜欢,你的挑只有应用命令执行来构建。

公吧能够仅仅以一个独的文本编辑器像是Vim,Sublime Text, 或
Emacs。在这种景象下,你用以指令行环境下采取 Gradle 和 adb

随便你用啊,总得确保下 Gradle 和时项目组织
来构建利用,注意不要用编辑器相关的配备文件加到版本控制系统受到。比如,避免添加Ant
build.xml 文件。
要是你在 Ant 中改变配置, 一定不要遗忘给build.gradle保持 up-to-date 和
functioning 。

还有,善待其他的开发者,不要强求他们转移他们个性化的工具配置。

甭打了特别的ViewGroup层级

Use Stetho

Stetho,一慢性来自于Facebook
的Android applications debug bridge,与Chrome
开发者工具并在并。使用它们而老随意就能够检查采取,尤其是网络通信。它还能被你简单地反省以及编排SQLite
数据库、shared preferences。但是,你使用确保Stetho
仅于debug版本中可用,release版本中无可用。

翻译推荐阅读

  • dex分包
  • 「打造和谐之Library」SharedPreferences篇
  • 动用Chrome来调节你的Android
    App

Build system 构建系统

卿的默认选项相应是
Gradle。Ant的范围而多而告诉句还更没完没了。使用Gradle,能够简单得:

  • 使用不同的flavours或variants来构建而的app
  • 打造简单的script-like的tasks
  • 治本并下载依赖
  • 自定义keystores
  • 还有更多

Android’s Gradle plugin同时在受Google做吗新专业构建系统积极开发中

Updated on 2016/2/14 更新Stetho 相关,简书markdown不支持锚
-_-||||||||||||
Updated on 2016/1/15
表明谷歌对ADT的废态度,新增段落:对非发布版本的构建利用不同的包名
不定时一并创新原文
迎接转载,但要保留译注者链接:http://www.jianshu.com/p/613d28a3c8a0

SharedPreferences

假如您才待持久化简单的标志位并且你的行使只于单进程环境下运作。SharedPreferences对而吧特别可能曾经够用了。它是不易的默认选项项。

此刻来一定量独由会给你无思只要运用SharedPreferences:

  • 性能: 你具备大量数要数额我非常复杂
  • 差不多进程获取数据:
    你抱有运行于各自进程中之组件或是远程服务,它们需一块数据

Proguard configuration Proguard配置

ProGuard
常作为Android项目受到裁减体积、混淆代码的工具。

是不是采取ProGuard取决于你的种类布局。通常你得在gradle中像这么安排为当构建规范apk时以ProGuard。

buildTypes {
    debug {
        minifyEnabled false
    }
    release {
        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) 且无警告。
就代表以下一到一定量起事:

  1. ProGuard移除了类似、枚举、方法、域或注解,检查一下哪些是不需要移除的有些。
  2. 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 { *; }

Check this template’s ProGuard
config
for some examples.
Read more at
Proguard
for examples.

及早地于公的类型受到提供一个标准版本构建
用来检查ProGuard是否推行不利符合预期是老重要的从事。当你引用了初仓库的当儿,记得构建一个业内
版本于实机上测试一下。不要赶你的利用要发布”1.0″版本了再也来构建标准版本,你也许会见蒙一些教人非快活的大悲大喜,而而莫剩余的流年错开匡正它们。

建议 保存好每一个您发表于你用户的专业版本的mapping.txt file
。通过装有这些文件,你才能够debug一些题材,当您的用户遇见bug并提交了平卖包含混淆的stack
trace.

DexGuard. 如要你需要一个 hard-core tools 来优化并混淆正式版本代码,
可以设想
DexGuard,
制作 ProGuard 的集体推出的商用软件. 它还能够轻松地划分 Dex files
以化解65k术数限制.

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图