2016这些Android技术可能会很火
Android热更新实现原理- http://blog.csdn.net/lzyzsd/article/details/49843581
热点技术的原理分析及四大组件原理分析- http://blog.csdn.net/yueqian_scut/article/category/2152617
SharedPreference的读写原理分析，apply是异步，commit是同步，在主线程中使用commit可能会影响性能，因为同步IO操作的耗时可能会比较长，两个方法都能保证value被正确的保存到磁盘上。
> 2016年技术
在Android开发中，新技术不断涌现。对于GitHub上如此众多的项目，有人不断Mark，有人分享自己的经验，不管怎么样，如果能让你真的有所学习有所收获，我们的目的也就达到了。
1、DataBinding
今年的 Google IO 大会上，Android 团队发布了一个数据绑定框架（Data Binding Library）。Data Binding Library 是一个 support 库，支持 Android 2.1+ 版本 (API level 7+)。
在2015年，它还是beta版本，但是就 Android Studio 2 的 Preview 版本发展来看，Google 在这个库上还是很花心思的，我们有理由相信，在2016年 DataBinding 将会迎来第一个正式版。
2、MVP模式
MVVM 与 MVP 模式，正在 Android 开发中越来越流行。在这里为大家强烈推荐我的：TheMVP 项目，可以直接引入项目作为 module 依赖。(详情请在 github 搜索 TheMVP )
3、热修复
热修复动态加载技术：HotFix、Nuwa、DroidFix、AndFix 等
插件化技术：DroidPlugin、DynamicAPK DynamicLoadApk
腾讯QQ空间的超级补丁技术和微信的Tinker
阿里AndFix以及.阿里巴巴的AndFix、Dexposed，
百度的DynamicLoadApk
360手机助手的 DroidPlugin
热修复，比较著名的有阿里巴巴的HotFix(AndFix)、Dexposed，腾讯QQ空间的超级补丁技术和微信的Tinker。
QQ空间超级补丁技术，超级补丁技术基于DEX分包方案，使用了多DEX加载的原理，大致的过程就是：把BUG方法修复以后，放到一个单独的DEX里，插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。
微信Tinker，微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包，整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同，区别在于不再将patch.dex增加到elements数组中，而是差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并，然后整体替换掉旧的DEX，达到修复的目的。
阿里百川推出的热修复HotFix服务，相对于QQ空间超级补丁技术和微信Tinker来说，定位于紧急bug修复的场景下，能够最及时的修复bug，下拉补丁立即生效无需等待。（BUG修复的即时性）
AndFix不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案，提供了一种运行时在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的。
对于修复紧急BUG这个场景，阿里百川HotFix的更为合适，它更加轻量，可以在不重启的情况下生效，且对性能几乎没有影响。微信Tinker、QQ空间超级补丁技术更多地把场景定位在发布小的新功能上，采用ClassLoader的模式，牺牲较高的性能代价去实现类、资源新增或替换的功能。阿里百川HotFix对应用本身做到无侵入，无性能损耗。
插件化：百度的任玉刚
插件化：一个程序划分为不同的部分，以插件的形式加载到应用中去，本质上它使用的技术还是热修复技术，只是加入了更多工程实践，让它支持大规模的代码更新以及资源和SO包的更新。
热修复：当线上应用出现紧急BUG，为了避免重新发版，并且保证修复的及时性而进行的一项在线推送补丁的修复方案。
QQ空间超级补丁技术和微信Tinker 支持新增类和资源的替换，在一些功能化的更新上更为强大，但对应用的性能和稳定会有的一定的影响；阿里百川HotFix虽然暂时不支持新增类和资源的替换，对新功能的发布也有所限制，但是作为一项定位为线上紧急BUG的热修复的服务来说，能够真正做到BUG即时修复用户无感知，同时保证对应用性能不产生不必要的损耗，在热修复方面不失为一个好的选择。
在2015年，涌现出了一大批热修复动态加载技术：HotFix、Nuwa、DroidFix、AndFix 等等，以及同样原理的插件化技术：DroidPlugin、DynamicAPK。就连 Android Studio 2 的 Preview 版本中体现的 Instant Run 功能，本质上也是一种热修复技术。
无论是dexposed还是AndFix，都利用了Java hook的技术来替换要修复的方法，这就需要我们理解dalvik虚拟机加载、运行java方法的机制，并要掌握libdvm中一些关键的数据结构和函数的使用。
我猜想，在2016年一定会有基于 Instant Run 思想做出的热修复技术涌现。
Android 热补丁动态修复框架小结- http://blog.csdn.net/lmj623565791/article/details/49883661/
4、RxJava
优雅(也许仅体现在lambda表达式)的链式表达，轻松的线程切换，让 RxJava 在 2015 年已然得以如日中天。如果此时你还不了解 RxJava 究竟是什么的话，我建议你一定要仔细反思一下自己是否已与世界脱轨。
(Android开发中，强烈推荐使用retrolambda这个gradle插件，这样你就可以在你的代码中使用lambda了。
gradle-retrolambda-- https://github.com/evant/gradle-retrolambda
RxJava
RxJava最核心的两个东西是Observables（被观察者，事件源）和Subscribers（观察者）。Observables发出一系列事件，Subscribers处理这些事件。这里的事件可以是任何你感兴趣的东西（触摸事件，web接口调用返回的数据。。。）
一个Observable可以发出零个或者多个事件，知道结束或者出错。每发出一个事件，就会调用它的Subscriber的onNext方法，最后调用Subscriber.onNext()或者Subscriber.onError()结束。
Rxjava的看起来很想设计模式中的观察者模式，但是有一点明显不同，那就是如果一个Observerble没有任何的的Subscriber，那么这个Observable是不会发出任何事件的。
1.Observable和Subscriber可以做任何事情
Observable可以是一个数据库查询，Subscriber用来显示查询结果；Observable可以是屏幕上的点击事件，Subscriber用来响应点击事件；Observable可以是一个网络请求，Subscriber用来显示请求结果。
2.Observable和Subscriber是独立于中间的变换过程的。
在Observable和Subscriber中间可以增减任何数量的map。整个系统是高度可组合的，操作数据是一个很简单的过程。)
https://github.com/ReactiveX/RxJava ——RxJava核心库
https://github.com/ReactiveX/RxAndroid ——RxJava在Android中使用的扩展库
https://github.com/JakeWharton/RxBinding ——Android控件对RxJava的支持库
https://github.com/f2prateek/rx-preferences ——使SharedPreferences支持 RxJava
https://github.com/trello/RxLifecycle ——帮助RxJava在Android中生命周期的控制，避免内存溢出等问题
https://github.com/square/retrofit ——Retrofit
https://github.com/pushtorefresh/storio ——数据库对RxJava的支持
https://github.com/cn-ljb/rxjava_for_android -- rxjava_for_android
5、RxVolley
RxVolley，让 Volley 支持了 RxJava 后，让你的代码很轻松的脱离了回调地狱。同时移除掉了复杂的 HttpClient ，以及可选支持 OkHttp 与 ImageLoader，让你使用自己习惯编码风格的同时极大缩减了项目体积。
6、RxBus、RxBinding
得益于 RxJava 繁多的操作符与特性，结合此类基于 RxJava 的库，将使你的代码更加简洁，开发效率大大提高。
RxBus，值得一提的是 RxBus 并不是一个库，而是一种设计思维，它可以巧妙利用 RxJava 的特性，完美替换掉了原事件总线类库(EventBus/Otto等)
RxBinding， RxJava 封装的 View 事件处理，事件的改变以流的形式进行传递。
7、Kotlin 语言
作为 Android 阵营的 Swift ，在2015年也迎来了它的正式版。Kotlin 拥有很多 Java 所不具备的特性， 比如空指针安全，函数默认参数，默认包含模板类，对 lambda 的原生支持(在 Android 开发中, 常常使用 RxKotlin )等特性。
最后补上 React Native Android；插件化；热修复；VR；直播；VR开发、智能硬件开发等
[人工智能技术发展及机器人、无人驾驶汽车领域]
-------------------------------------
React Native是从 Web 前端开发框架 React 延伸出来的解决方案，主要解决的问题是 Web 页面在移动端性能低的问题，React Native 让开发者可以像开发 Web 页面那样用 React 的方式开发功能，同时框架会通过 JavaScript 与 Objective-C 的通信让界面使用原生组件渲染，让开发出来的功能拥有原生APP的性能和体验。
这里会有一个学习成本的问题，大部分 iOS 开发者并不熟悉 Web 前端开发，当他们需要一个动态化的方案去开发一个功能模块时，若使用 React Native，就意味着他需要学习 Web 前端的一整套开发技能，学习成本很高。所以目前一些使用 React Native 的团队里，这部分功能的开发是由前端开发者负责，而非终端开发者。
但前端开发者负责这部分功能也会有一些学习成本的问题，因为 React Native 还未十分成熟，出了 Bug 或有性能问题需要深入 React Native 客户端代码去排查和优化。也就是说 React Native 是跨 Web 前端开发和终端开发的技术，要求使用者同时有这两方面能力才能使用得当，这不可避免地带来学习成本的提高。
跨平台典型的适用场景是电商活动页面，以展示为主，重开发效率轻交互体验，但不适用于功能性的模块。对 Android 来说目前热更新方案十分成熟，Android 十分自由，可以直接用原生开发后生成 diff 包下发运行，这种无论是开发效率和效果都是最好的。所以若是重体验的功能模块，Android 使用原生的热更新方案，iOS 使用 JSPatch 开发，会更适合。
JSPatch Demo--https://github.com/bang590/JSPatch/tree/master/Demo/DribbbleDemo
iOS 动态更新方案上，我们跟进了对 JSPatch 和 React Native.
Android 热补丁技术——资源的热修复- http://blog.csdn.net/sbsujjbcy/article/details/52541803
----------------------------------
> 直播（H5直播，Android/iOS原生直播）
直播技术- http://lib.csdn.net/base/liveplay
【Dev Club 分享第五期】H5 视频直播那些事-- http://dev.qq.com/topic/57a42ee6503dfcb22007ede8
H5视频直播扫盲-- http://www.nihaoshijie.com.cn/index.php/archives/615
移动直播技术秒开优化经验（含PPT）-- http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547042&idx=1&sn=26d8728548a6b5b657079eeab121e283&scene=23&srcid=0428msEitG9LJ3JaKGaRCEjg#rd
Android 超级补丁包技术 http://www.infoq.com/cn/presentations/android-super-patch-pack-technology?utm_source=infoq&utm_medium=videos_homepage&utm_campaign=videos_row1
直播面临的核心问题是网站稳定可用、视频流畅清晰、弹幕互动效果稳定。
端:Web页、iOS、Android、各种Pad端、网吧弹窗合作、电视盒子合作App、游戏主机合作App，从各个渠道扩展业务。
负责短链接、微博Card对象、网游页游平台业务。
需要满足用户登录注册、关注主播、看视频、发弹幕、加房管、领任务、送免费竹子等核心功能，采用了复用模块＋主业务全新开发的策略。
复用模块得益于团队的前360技术背景，根据直播秀场类项目上的技术积累，利用PHP框架Pylon、发版工具Rigger，在老战友的帮助下，重新搭建了一套QBus消息组件，长连接系统，改进的Redis、MongoDB和MySQL集群，视频云服务，敏感词服务，搜索服务
视频模块——从新搭建视频云，RTMP推流拉流，接入三家CDN作为互备。这其中需要自己实现统一调用接口和服务，方便切换CDN： 推流地址、拉流地址、转码规定、开播断流回调、一键断流、连接数查询、流截图、直播时长查询。基本上每个接口都很重要！例如一键断流万一失效，则可能面临停业整顿风险；人数不准，主播挂人气刷榜，则可能导致不公平竞争而影响平台的体验与口碑。
分布式基本组件：复用Syslog-ng日志收集系统、Kafka消息队列QBus、MySQL主从库、Redis主从库、MongoDB、SSDB大容量存储。
长连消息：单机百万长连，支持千万用户同时在线，性能够用，保证聊天弹幕稳定性。
图床：很重要的一环，房间截图，用户头像。
CMS系统：配置各种推荐位，直播间的CDN调度
熊猫TV架构第一原则是高可用
网络：需要应对国内复杂的网络环境，使用内网光纤互联的多IDC来覆盖多运营商。
资源：DB和缓存都是集群化，配置Virtual IP方便切换。
隔离性：不同业务不同机器，防止雪崩效应；核心和非核心业务隔离，流量扛不住情况保重点业务。
降级：从Nginx和API层设置接口开关、Cache开关、DB开关，出问题一键切换。
超时控制：主站每个依赖业务设置5秒超时，并有报警和错误日志。
异步：用户不关心实时结果的大写入量业务使用异步方式更新，提高核心服务性能。
监控：服务器错误设置log监控、接口监控报警，随时处理线上异常。
架构选型
Web层：Nginx＋PHP-FPM，开发迅速，适合团队技术现状，但需要针对服务器，做一定的调优配置。
缓存层：Redis主从库、SSDB大容量存储，会在各个业务块儿使用，增加系统性能。
存储层：MySQL主从库存储重要业务数据，属性变化不大。MongoDB数据库存储字段不固定变更较多的数值明细记录。SSDB存储观看记录关注等列表较长，且性能要求较高的数据。分表分库上考虑用户注册量和主播播放频率，用户中心、主播播放时长采用了按用户ID Sharding和 按年Sharding两种策略。业务初期暂时没有分库需求。
消息队列：实现业务解耦，使用当前较流行的Kafka队列。
安全性上：所有80接口做XSS校验，CSRF token防范，对接口做几十道安全检测，防止被拖库，防止Cookie被盗用；反垃圾反盗号反外挂：含敏感词聊天信息过滤，垃圾IP封禁；注册和任务都增加图片验证码，识别机器刷用户刷竹子；房间人气值采用复杂策略，用算法综合判断确认合理性，防刷防挂；主播审核更加严格，身份证银行卡姓名等信息都要求录入，可以追究责任到真人，甚至有视频验证，严防色情内容。
功能上：建立游戏娱乐户外等分类模块，运营自助增加分类；部署并自行运维第三方搜索服务，支持主播昵称、标题、房间号等维度搜索，过滤直播状态、主播地区、封禁状态等条件；礼物系统抽奖投票等系统上线，增加主播收益渠道，增加互动。
优化效果：全年未出现过白页、首页不可访问情况，支撑千万级PV，百万级日活，单房间最高达到百万级在线，视频流量近TB级；接口平均响应时间20ms左右，99.9%在1s内；各个系统数据存储量破千万，MongoDB、SSDB等大容量库很好地支持了业务。
熊猫TV架构改进思路是应对峰值流量高度集中的直播需求，总结几条经验：
不能依赖单个CDN。可自建，可用第三方，但中国网络环境太复杂，必须高度重视容灾。海外推拉流也需要十分关注。
弹幕消息一定要做策略优化。广播蝴蝶效应明显，峰值可能将机房整体带宽打满。区分弹幕优先级，做好降级预案。
提高金钱敏感度。直播网站由于有很清晰的变现模式，要严防褥羊毛，严防色情内容，火速响应监管，支付礼物交互一定是高可用、严监控。
N个大主播 ＝ 半个网站峰值。必须考虑某些特殊主播的火爆人气，做好视频弹幕房间信息上的峰值应对。
未来我们会在以下方面继续努力：
自助式运营处理：帮助运营自助处理问题，直接和CDN对接，帮助技术人员从简单重复问题处理中脱身。
反作弊：基于大数据处理体系的用户画像、设备画像、IP画像、内容画像，多维度构建反垃圾反盗号功能 。
长连优化：支撑千万用户在线的高并发实时弹幕和聊天。
礼物商城：优化计数对账，幂等处理整个支付到特效抽奖、弹幕消息、消费记录、统计等流程。
Golang、NodeJS服务化：替代性能较差需要各种优化的PHP，服务端接口全面Golang化，前端也在合适的场景使用NodeJS提高服务性能。此外需针对KV存储做value压缩，节省流量，提高接口速度。
数据挖掘和机器学习：渠道分析、用户分析等便于产品和高层决策，甚至开发出机器人主播互动。
推荐：在综艺化娱乐化多元化的内容基础上，个性化推荐用户感兴趣的直播内容。
搜索：自建搜索，从用户维度、聊天维度更好服务用户。
日志收集分析：高性能日志方案探索，更快更迅速发现业务问题，分析流量变化。
广告系统：友好娱乐化的广告展现，精准推送，严禁的计费系统。
支付：国际化支持，多种银行卡信用卡接入，多种货币支持。
NewSQL：引入TiDB等新SQL技术到某些业务，替换Redis、MongoDB、MySQL，更方便友好地进行技术开发。
客户端编译、采集、推流、拉流、美化特效、水印、延时优化、音视频同步、p2p等等。当然还可能包括一些信号处理的知识，比如滤波，傅里叶变换（FFT）。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
直播技术（从服务端到客户端）-- http://blog.csdn.net/xwl198937/article/details/52371726
nginx下载地址：
官方release：http://nginx.org/en/download.html
gitHub地址：https://github.com/nginx/nginx
ffmpeg下载地址：
官方release：https://ffmpeg.org/download.html
nginx-rtmp-module下载地址：https://github.com/arut/nginx-rtmp-module
在部署服务端环境其实包含很多东西的，最常用的web服务nginx，数据库Mysql、Nosql，api开发最多的三种选择：
java环境，需要jdk，tomcat/jboss
php环境，需要安装php，odp
lua环境，需要安装lua、luajit
考虑使用缓存技术，则主要包含redis和memcached。如果还要其他的日志统计（kafka什么的）需求则还需要更多的环境
1、ffmpeg源码、处理音视频编码
2、gpuimage源码、处理美颜功能
3、ffmpeg、gpuimage只提供sdk集成，不提供源码
4、ios使用oc原生开发，android使用java原生开发，后端采用php+mysql+redis
5、消息推送走第三方推送平台
视频流压缩传输
程序首先会对接收到的视频流进行压缩及转换，让视频流更适合网络传输，减少直播传输所需要的带宽。当然程序是可以根据自己的要求来修改压缩比例以及视频播放的分辨率。
视频直播的传输协议是rtmp，视频编码是x264，音频编码是aac。
标清的码率在300~400kb，高清的码率在500kb~800kb。
视频分发走CDN加速。
聊天： 聊天走自己的聊天服务，支持Websocket传输协议。单台服务并发1万路以上。
网站：网站逻辑基于php、mysql、redis。
均衡负载功能<很强大的功能>
此功能可以无限添加FMS直播服务器，来分摊视频流的带宽负担。
首先，程序完全可以将网站程序与FMS视频流来分开，也就是说，网站可以单独使用一台服务器或者虚拟主机，FMS则使用另外一台独立的服务器，这样就不会因为视频直播流量大影响网站的访问速度。
。
一个完整的直播过程，包括采集、处理、编码、封包、推流、传输、转码、分发、拉流、解码、播放，从推流到播放，再经过中间转发环节，延迟越低，用户体验越好。
RTMP推流模式.HLS/RTMP视频服务器 —— HLS/RTMP拉流模式.
基于 React Native 的 58 同城 App 开发实践-- http://geek.csdn.net/news/detail/105028
对直播的后台来说，用户管理、礼物管理、充值提现管理、房间管理、运营策略和数据，这几个功能是必不可少的。在用户管理上，有些用户可能在管理员巡查时发现存在问题，系统可以对他进行禁言和封禁。还有就是礼物的管理。直播平台礼物分大礼物和小礼物，大礼物是一出来之后有一个大动画，比如我们看映客中的飞机、法拉利、保时捷，这些属于大礼物，很贵，甚至有一些平台有土豪套装，比如说帝王套，一个要花费几千人民币。还有小礼物，一毛两毛这样的礼物，可以连发，一发 99 个或者 520 个。
互动直播的基本产品架构， 分为视频系统、互动系统、用户系统，包括管理后台。视频系统包括直播和点播 2 大块；互动系统，就是在直播间里的一些消息，包括评论、弹幕、点亮、礼物、对主播的关注和粉丝的关注，还有就是把当前的直播分享出去；用户系统包括用户资料（头像、性别、年龄）、充值、好友关系等。
Android热修复技术选型——三大流派解析-https://yq.aliyun.com/articles/62685?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&utm_content=m_7565
不同的解决方案，如QQ空间补丁方案、阿里AndFix以及微信Tinker.阿里巴巴的AndFix、Dexposed，腾讯QQ空间的超级补丁技术和微信的Tinker。
1.QQ空间超级补丁技术
超级补丁技术基于DEX分包方案，使用了多DEX加载的原理，大致的过程就是：把BUG方法修复以后，放到一个单独的DEX里，插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。
热修复和插件化
插件化：一个程序划分为不同的部分，以插件的形式加载到应用中去，本质上它使用的技术还是热修复技术，只是加入了更多工程实践，让它支持大规模的代码更新以及资源和SO包的更新。
热修复：当线上应用出现紧急BUG，为了避免重新发版，并且保证修复的及时性而进行的一项在线推送补丁的修复方案。
接入三种热修复服务，根据腾讯提供超级补丁技术和Tinker的数据，那么会变成以下的场景：
阿里百川HotFix:启动时间几乎无增加，不增加运行期额外的磁盘消耗。
QQ空间超级补丁技术：如果应用有700个类，启动耗时增加超过2.5s，达到5.5s以上。
微信Tinker：假设应用有5个DEX文件，分别修改了这5个DEX，产生5个patch.dex文件，就要进行5次的patch合并动作，假设每个补丁1M，那么就要多占用7.5M的磁盘空间。
QQ空间超级补丁技术和微信Tinker 支持新增类和资源的替换，在一些功能化的更新上更为强大，但对应用的性能和稳定会有的一定的影响；阿里百川HotFix虽然暂时不支持新增类和资源的替换，对新功能的发布也有所限制，但是作为一项定位为线上紧急BUG的热修复的服务来说，能够真正做到BUG即时修复用户无感知，同时保证对应用性能不产生不必要的损耗，在热修复方面不失为一个好的选择。
VirtualAPK：滴滴 Android 插件化的实践之路- http://geek.csdn.net/news/detail/130917