前言

这几天在研究部门内部的自定义协议，因此去了解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给用户分配的带宽不是固定吗？

大家好，我是光源。

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

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

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

Android 中一共有三类动画：

• View Animation
  又称补间动画，在 android.view.animation.Animation 类之下衍生了五个子类。

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

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

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

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

前言

大家好，我是光源。

从 Android6.0 开始Android的权限模式有了一番更改，从安装时一股脑列给用户，到运行时动态申请权限。对于 Android开发者而言，这是一个重要的变更。

讨论这个问题之前，我们得先检查一下项目的 target version。如果是 23及以上，则必须得适配新权限模式；如果是 23之下，则还是统一在安装时全部申请权限——即便如此，使用Android 6.0及以上系统的用户还是可以在设置中去关闭你的某些权限。当权限被关闭时，不会导致你的应用直接崩溃，但是会导致你获取到的返回值为null 或者 0，这个是需要注意的地方。

以下是 Android 官网给出的最佳实践，草草翻译，有不妥之处还请斧正。

正文

app很容易用海量的权限请求淹没用户。如果用户发现 app 影响使用或者担忧 app 滥用用户个人信息，他们可能不再使用或者完全删除这个app。以下最佳实践能帮助你避免这种糟糕的用户体验。

前言

今天逛稀土时偶然看到hanks分享的一篇英文文章，粗略浏览便已觉得不错，因此翻译成中文，与君分享。

原文地址：Android Performance Patterns: Rescue tips

正文

现在的app到处都充斥着华丽的动画、复杂的转化还有自定义View，然而用户体验必须尽可能直观且类似。以下这些范例将会帮助你做出一个流畅的、快速响应的、甚至可能减少电量损耗的app，这些范例由一些可以提升整体应用表现的微优化组成。

起因

今天在做一个“WebView内部跳转”的小需求时，发现了一件比较诡异的事：项目中没有在 shouldOverrideUrlLoading中主动去用view.loadUrl逻辑处理，为何能够实现WebView内部跳转呢？

带着这个小疑惑，我去问了一个厉害的同事，他说道，只要shouldOverrideUrlLoading返回值为false，即可实现内部跳转。

听到这个我有些困扰，因为记忆中一直是需要手动去load新的url才能实现，否则就跳浏览器的。然后google了下，就搜到以下两个：

[shouldOverrideUrlLoading return method]

[WebViewClient shouldOverrideUrlLoading 常见错误用法]

我的内心是崩溃的。。

分析原因

我之所以会记错技术点，小原因有三：
1，我之前使用WebView都比较简单，没有去设置WebViewClient，所以会有链接跳转都交由系统处理的惯性思维；
2，在之前的项目中，接触到了系统对webView中的以http协议开头的处理，更加加深了“系统会主动去处理链接”的想法；
3，然后就是之前包括刚刚搜索了几次“webView 内部跳转”，都是说需要手动去调用view.loadUrl处理的博客。