由于计算机软件的非法复制，通信的泄密、数据安全受到威胁，解密及盗版问题日益严重，甚至引发国际争端，所以在信息安全技术中，加密技术占有不可替代的位置，因此对信息加密技术和加密手段的研究与开发，受到各国计算机界的重视，发展日新月异。现在我们就几种常用的加密算法给大家比较一下。
DES加密算法是一种分组密码，以64位为分组对数据加密，它的密钥长度是56位，加密解密用同一算法。DES加密算法是对密钥进行保密，而公开算法，包括加密和解密算法。这样，只有掌握了和发送方相同密钥的人才能解读由DES加密算法加密的密文数据。因此，破译DES加密算法实际上就是搜索密钥的编码。对于56位长度的密钥来说，如果用穷举法来进行搜索的话，其运算次数为256。
随着计算机系统能力的不断发展，DES的安全性比它刚出现时会弱得多，然而从非关键性质的实际出发，仍可以认为它是足够的。不过，DES现在仅用于旧系统的鉴定，而更多地选择新的加密标准。
我们都知道使用SQLite来存储数据却存在着一个安全问题，就如微信之前数据库也是没加密的，后来才进行了加密。大多数的Android手机都是Root过的，而Root过的手机都可以进入到/data/data/<package_name>/databases目录下面，在这里就可以查看到数据库中存储的所有数据。如果是一般的数据还好，但是当涉及到一些账号密码，或者聊天内容的时候，我们的程序就会面临严重的安全漏洞隐患。那么今天，就让我们一起研究一下如何借助SQLCipher来解决这个安全性问题。
SQLCipher是一个在SQLite基础之上进行扩展的开源数据库，它主要是在SQLite的基础之上增加了数据加密功能，如果我们在项目中使用它来存储数据的话，就可以大大提高程序的安全性。SQLCipher支持很多种不同的平台，这里我们要学习的自然是Android中SQLCipher的用法了。
添加以下项进行dependencies到app/build.gradle文件：
冷启动时间是指当用户点击你的app那一刻到系统调用Activity.onCreate()之间的时间段。在这个时间段内，WindowManager会先加载app主题样式中的windowBackground做为app的预览元素，然后再真正去加载activity的layout布局。
知道了Android冷启动时间的原理之后，就可以通过一些小技巧来对冷启动时间进行优化，从而让你app加载变得”快“一些（视觉体验上的快）。我们可制作一个启动Activity的背景样式的.9图片，然后把这个.9图片做为windowBackground。
这里推荐使用 MaterialColdStart 这个库来制作我们.9图片。
红外遥控的发射电路是采用红外发光二极管来发出经过调制的红外光波；红外接收电路由红外接收二极管、三极管或硅光电池组成，它们将红外发射器发射的红外光转换为相应的电信号，再送后置放大器。
发射机一般由指令键(或操作杆)、指令编码系统、调制电路、驱动电路、发射电路等几部分组成。当按下指令键或推动操作杆时，指令编码电路产生所需的指令编码信号，指令编码信号对载波进行调制，再由驱动电路进行功率放大后由发射电路向外发射经调制定的指令编码信号。
接收电路一般由接收电路、放大电路、调制电路、指令译码电路、驱动电路、执行电路(机构)等几部分组成。接收电路将发射器发出的已调制的编码指令信号接收下来，并进行放大后送解调电路，解调电路将已调制的指令编码信号解调出来，即还原为编码信号。指令译码器将编码指令信号进行译码，最后由驱动电路来驱动执行电路实现各种指令的操作控制（机构）。
不说那么多废话了，看代码吧。。。
要为安卓应用找到一个好的架构不是一件容易的事情。谷歌似乎不太在乎这个事情，因此在设计模式上，除了Activity 生命周期管理之外，再也没有官方的推荐。
但是，为你的应用打造一个架构是非常重要的。不管你是否喜欢，任何应用最终都会有一个架构。因此你最好是成为一个架构的奠基人，而不是等着它出现。
目前的趋势是采用Uncle Bob在2012年对web应用提出的建议： Clean Architecture。
但是我发现Clean Architecture对于绝大多数安卓应用来说都有点过度设计了。
通常移动应用要比web应用的生命短。移动端技术的发展太快，以至于今天发行的app可能在一年后已经完全过时。
移动应用所做的事情很少。绝大多数的用例都只是数据信息流的消费。从API获取数据，显示数据给用户，很少有输入与写入。
所以它的业务逻辑并不复杂。至少不如后端一样的复杂。虽然你要处理很多平台上的问题：内存，存储，暂停，恢复，网络，定位等等，但是这些都不是业务逻辑。所有app都有这些东西。
因此，绝大多数app似乎都无法从类似于复杂的分层或者工作执行优先级队列中获益。
他们也许只是需要一种组织代码的简单方式，能高效的一起工作，更容易的发现bug。
一个好的软件架构可以降低软件耦合度、提高可复用性、增强软件稳健性、提高代码的阅读美感等等。那么我们接下来就介绍下Android平台下常用的MVC、 MVP和MVVM软件架构。
即Model View Controller，MVC设计模式将应用程序分为三个主要方面：即Model，View和Controller。
使用Canvas的drawText绘制文本是不会自动换行的，即使一个很长很长的字符串，drawText也只显示一行，超出部分被隐藏在屏幕之外。可以逐个计算每个字符的宽度，通过一定的算法将字符串分割成多个部分，然后分别调用drawText一部分一部分的显示， 但是这种显示效率会很低。
这里介绍下TextView的基本渲染原理，总的来说，TextView中负责渲染文字的主要是这三个类：
主要负责显示单行文本，并提供了isBoring方法来判断是否满足单行文本的条件。
当文本为Spannable的时候，TextView就会使用它来负责文本的显示，在内部设置了SpanWatcher，当检测到span改变的时候，会进行reflow，重新计算布局。
当文本为非单行文本，且非Spannable的时候，就会使用StaticLayout，内部并不会监听span的变化，因此效率上会比DynamicLayout高，只需一次布局的创建即可，但其实内部也能显示SpannableString，只是不能在span变化之后重新进行布局而已。
以上三个类都继承于Layout类，在此类中统一负责文本的具体绘制，在Layout.draw方法中，会对文本一行一行的进行渲染。
国内常见公开的直播协议有几个：RTMP、HLS、HDL（HTTP-FLV）、RTP，我们来逐一介绍。
即Real Time Messaging Protocol，是Adobe的专利协议，现在大部分国外的CDN已不支持。在国内流行度很高。原因有几个方面：
1、开源软件和开源库的支持稳定完整。如斗鱼主播常用的OBS软件，开源的librtmp库，服务端有nginx-rtmp插件。
2、播放端安装率高。只要浏览器支持FlashPlayer就能非常简易的播放RTMP的直播，协议详解可以Google了解。相对其他协议而言，RTMP协议初次建立连接的时候握手过程过于复杂（底层基于TCP，这里说的是RTMP协议本身的交互），视不同的网络状况会带来给首开带来100ms以上的延迟。基于RTMP的直播一般内容延迟在2~5秒。
即使用HTTP协议流式的传输媒体内容。相对于RTMP，HTTP更简单和广为人知，而且不担心被Adobe的专利绑架。内容延迟同样可以做到2~5秒，打开速度更快，因为HTTP本身没有复杂的状态交互。所以从延迟角度来看，HDL（HTTP-FLV）要优于RTMP。
HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
超文本传输协议 (HTTP-Hypertext transfer protocol) 是一种详细规定了浏览器和万维网服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。
HTTPS协议需要到ca申请证书，一般免费证书很少，需要交费。
HTTP是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的ssl加密传输协议。
HTTP和HTTPS使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
HTTP的连接很简单,是无状态的。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全
HTTPS解决的问题：信任主机的问题、通讯过程中的数据的泄密和被窜改问题。
前段时间XcodeGhost闹的沸沸扬扬，意外发现迅雷下载真的是可以被污染的，这个很有意思，详情见对迅雷下载进行投毒的简单尝试，也提醒了开发者不要随意从非官方渠道下载开发工具。
我们都知道Android SDK由于国内网络环境的原因，下载速度很慢，有很多国内搭建的镜像，但镜像服务器下载带宽肯定有一定限制，并且内网一般也会限制下载速度。所以在内网搭建一个Android SDK镜像服务器很有必要，一方面可以保证速度，几兆每秒肯定不成问题，另一方面大家从内网下载，也可以保证安全性。貌似有的团队用FTP存储SDK，还是太Low了，用起来肯定不如镜像方便。
搭建Android SDK镜像服务器，有两个现成的开源解决方案，苏州GDG和中科院开源镜像小组，苏州GDG牛皮吹的很响，貌似还在某个会议上发表过演讲，但估计是个人作品，东西不够完善，更新缓慢。中科院开源镜像小组开源的方案非常不错，并且也对外开放了镜像服务，一直运行良好，Github上还有定时同步和Nginx的配置信息。
花了一个下午的时间，搞定了内网Android SDK镜像服务器，下载速度平均5M/s，效果杠杠的。