大幅提高Android开发效率之Android项目模板化(下)

大家好,我是光源。

《大幅提高Android开发效率之Android项目模板化(上)》中我们了解了如何用 Android Studio Template 大幅减少写业务代码前的工作量,同时也稍微提了下用 Live Template 减少写业务代码过程中的“样板式代码”。

可能有朋友会问,我们这么紧张这点效率真的必要么?

这个问题我先不回答,我们先来看看一个场景:写一个单例。

单例模式应该是开发过程中最常见的设计模式之一了。写单例前总得先纠结一下吧,单例模式这么多种实现方式该用哪种好呢?选定了实现方式后,老老实实写一堆代码,然后你会突然发现除了类名不一样外,其他代码都是一模一样,这时你心里会不会隐隐约约觉得这是可以优化的?

我不知道你完成单例模式的实现需要多长时间,但我告诉你,我们可以用一秒来搞定,你会不会觉得老老实实写代码的自己很傻?

这就是 Live Template 的第一个作用,提高编码效率

再接着上面的话题,又有人吐槽另一个细节了,一般有点年头的程序员对于单例模式都有自己的一个默认实现方式,不需要花时间去纠结吧?

这话不假,像我就默认使用内部静态类的方式实现单例。但是你有没有想过,项目开发是一个团队协作的过程,就算个人不纠结,但多人开发情况下,要么每个人用自己的一套实现方式造成代码风格不统一,要么同事还是得事先通气、询问用哪种好。(编码规范文档也不会事无巨细把这类问题也事先规定好的)

再思考一下,很多有多方案且不属于编码规范的场景,我们又要怎么去统一呢?

答案还是用 Live Template。例如,Android 开发中,我们应该使 Message.obtain() 来获取一个 Message 实例,而不是去 new 一个,那么我们完全可以定一个 getMsg 的 Live Template,大家只要是用 getMsg 的,可以严格保证统一性——这就是 Live Template 的另一个作用了,保持项目中非编码性质的代码风格统一。(编码性质的代码风格统一果断用编码规范文档来实现了)

大家看到这里一定已经对 Live Template 有了一定的重视与好奇了吧,别着急,下面上正餐。

大幅提高Android开发效率之Android项目模板化(上)

一、两个场景的思考

大家好,我是光源。

首先思考一个最普通的场景:创建一个 Activity。你需要做的是:

1、 创建 Activity 类文件;
2、 创建对应的 Layout 布局文件;
3、 在 AndroidManifest.xml 注册;

当然现在 MVP 模式(mvp 模式有多种实现方式,这里选择一种普遍的)基本成为标配,所以你还需要接着:

4、 对应的 View interface;
5、 对应的 Presenter interface
6、对应的 View 实现;
7、对应的 Presenter 实现;
8、对应的 Model 类;

当你气喘吁吁地做好以上工作后,你又想起这个页面你需要用 RecyclerView 实现,所以你继续:
9、在布局中加入 RecyclerView;
10、设置 LayoutManager
11、创建 RecyclerView Adapter
······
终于,你可以开始写具体的业务代码了,而此刻距刚开始已经过去了 N 首歌的时间。

开始写代码后,我们再思考一下这样的场景:显示一个 Dialog
这时一般有两种情况,一种是你需要从零开始构造一个对话框、设置样式、编写逻辑等等,这与上面一个场景一样,一大堆的样板式代码;另一种情况是部门内已经对 Dialog 的设置样式、构造等代码做了封装,比较常见的方式会像这样:

1
DialogUtil.show(...);

那么你直接调用就行。但这同样存在“无脑写代码”的问题,以及对于部门内的新人来说,可能不一定会遵循这种使用封装好的代码的约定。

看到这里,假如你有一点点感同身受的话,那么恭喜你,本文将教你如何解决这些问题。如果没有共鸣也没关系,看完本文,你也会有一定的收获——实际上对于所有还不知道 Android 模板相关内容的开发者而言,看完本文都能大幅提升项目开发效率,这也是本文标题的由来。

写给Android开发者的混淆使用手册

写在前面

大家好,我是光源。

本文首发于我的个人公众账号,同时会在个人博客上同步。假如有任何建议还请移步博客点评,同时如果博客本身有修改或勘误,也会在博客更新。

综述

毫无疑问,混淆是打包过程中最重要的流程之一,在没有特殊原因的情况下,所有 app 都应该开启混淆。

首先,这里说的的混淆其实是包括了代码压缩、代码混淆以及资源压缩等的优化过程。依靠 ProGuard,混淆流程将主项目以及依赖库中未被使用的类、类成员、方法、属性移除,这有助于规避64K方法数的瓶颈;同时,将类、类成员、方法重命名为无意义的简短名称,增加了逆向工程的难度。而依靠 Gradle 的 Android 插件,我们将移除未被使用的资源,可以有效减小 apk 安装包大小。

本文由两部分构成,第一部分给出混淆的最佳实践,力求让零基础的新手都可以直接使用混淆;第二部分会介绍一下混淆的整体、自定义混淆规则的语法与实践、自定义资源保持的规则等。

一、Android混淆最佳实践

1. 混淆配置

一般情况下,app module 的 build.gradle 文件默认会有如下结构:

1
2
3
4
5
6
7
8
9

android {
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

因为开启混淆会使编译时间变长,所以debug模式下不应该开启。我们需要做的是:

  1. releaseminifyEnabled的值改为true,打开混淆;
  2. 加上shrinkResources true,打开资源压缩。

修改后文件内容如下:

1
2
3
4
5
6
7
8
9
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

2. 自定义混淆规则

app module 下默认生成了项目的自定义混淆规则文件 proguard-rules.pro,多方调研后,一份适用于大部分项目的混淆规则最佳实践如下:

[转]QUIC和TCP

前言

这几天在研究部门内部的自定义协议,因此去了解Google的QUIC协议的特性,下面这篇文章将QUIC协议和TCP协议做了比较,个人比较喜欢作者的阐述,特地转到博客中来。

原文作者:henrystark henrystark@126.com
原文地址:http://blog.chinaunix.net/uid-28387257-id-4335291.html

正文

0.写作目的

QUIC由Google提出,基于UDP,用于加快网络速率。常用来和基于TCP的SPDY比较。Google在传输层、应用层或其他方面做出的提升网络质量的贡献令人佩服。本篇blog将论述QUIC的起源、优缺点,以及TCP存在的问题。

1.引言

Why QUIC is necessary? 每个接触QUIC的programmer总会这样问。答案也很简单:SPDY、TCP不够好!不过这样说太肤浅了,下面我来分析本质原因【引 1】。基于一条TCP连接的SPDY复用连接会面临这样的情况:当有丢包发生时,所有连接都将阻塞,这是由TCP的拥塞控制特性决定的【引 2 3】。丢包必须恢复,而恢复过程中,或早或晚,滑动窗口总有停等的时刻,耗费一个RTT。在广域网上,一个RTT相当于50-100ms。相比较而言,当x条并行HTTP连接中,有一条丢包,只会阻塞一条。

QUIC是和HTTP同一层的应用层协议,其核心是将丢包控制工作转移到应用层【注 1】。由于QUIC基于UDP,可以不理会丢包,快速投递,再用丢包恢复方法保证可靠性。除此之外,基于一条TCP连接的SPDY和多条并行HTTP连接相比,没有优势可言。多条连接中,每个连接都有一个拥塞窗口,不受彼此丢包影响。Google希望通过QUIC更好地处理多条连接下的拥塞状况。

2.TCP的症结

以上所述其实反映了TCP基于窗口的拥塞控制策略的问题。TCP的核心在于“丢包必须恢复”,正是这种丢包恢复导致传输速率降低。而除此之外,TCP拥塞控制也存在粒度不精细等问题。举例而言,往年有一道很好的面试题:早期网络中,为什么蚂蚁等下载器比网页下载快?答案是下载器使用多线程,多连接下载,而网页下载往往使用单连接。也许回答到这种程度,大部分人已经满意了。但往下问,还有更深刻的内涵:为什么多连接比单连接快?ISP给用户分配的带宽不是固定吗?

Android抖动动画的实现与思考

大家好,我是光源。

在日常使用app或者玩游戏的过程中,我们经常可以看到某个view通过抖动来吸引用户注意,今天就来说说怎么实现这个动画。

具体需求是,实现一个抖动动画要求同时对大小、旋转角度进行更改且可定制

要实现动画,我们首先应该想到的是 Android 中动画相关的内容。

Android 中一共有三类动画:

  • View Animation
    又称补间动画,在 android.view.animation.Animation 类之下衍生了五个子类。
类名 作用
AlphaAnimation 渐变透明度
RotateAnimation 旋转
ScaleAnimation 尺寸缩放
TranslateAnimation 位置平移
AnimationSet 动画集合

​通过前四个类,基本可以解决大部分动画需求,再使用 AnimationSet 使动画具有组合的能力。

  • Drawable Animation
    又称逐帧动画,通过设置多个帧在一定时间内不断进行帧的变换形成动画的效果,类似 gif 图。通过 xml 中的 animation-list 标签定义动画,再在 java 代码中用 AnimationDrawable 类来进行控制。

  • Property Animation
    View Animation 虽然可以解决大部分动画,但还是有些无法实现,而 Drawable Animation 则太过费时费力,所以在 Android 3.0(API 11)引入了属性动画,属性动画实现原理就是修改控件的属性值实现的动画。具体实现又分为 ValueAnimator 和 ObjectAnimator,这里不展开。

回到需求本身,从需求上看,三种方式都可以实现(其实对最接近动画本质的逐帧动画而言,还真没有不能实现的动画 ),这里不妨三种方式都尝试一下(为方便代码展示,以下尽量使用java代码实现动画)。

Fork me on GitHub