目前我国政府高度重视5G发展，在第一届全球5G大会上，工信部部长苗圩表示“十三五”规划纲要明确提出要积极推进5G发展，2020年5G商用将正式启动，中国制造2025、国家信息化发展战略纲要、信息通信行业“十三五”规划等文件，也对5G技术研发、标准和产业化布局等做出了相关部署。

5G的出现极大地促进智能家居中智能家电、家庭安防数据传输，加快产业亲民化步伐，使“智能化”概念得以大力推广，对智能家居的影响将是颠覆性。

目前，全球运营商正在紧锣密鼓进行5G商用部署。据媒体报道，截至2018年11月，全球已有182个运营商在78个国家进行了5G试验、部署和投资。“4G改变生活，5G改变社会”已成为业内共识。2017年中国智能家居市场规模为3254.7亿元，预计未来三年内市场将保持21.4%的年复合增长率。而5G时代的来临及其技术带来的信息传输效率，将使万物互联的智能家居生活逐渐成为现实。

全球移动通信系统协会的CEO洪曜庄曾表示：预计2025年后，5G将覆盖全球40%人口，中国有望成为未来最大的5G市场。在全球移动通信系统协会GSMA大中华区战略合作总经理葛颀看来，从1G到4G，主要解决的是人与人之间的沟通，而5G将解决人与物、物与物之间的沟通，并将成为网络时代重要的基础设施。

如果说3G开启了移动端流量的大门，那么4G则开启了移动视听时代。而与3G、4G技术升级主要为手机等移动设备服务的目的不同，5G的技术本质并不是让我们可以获得更快的网络，而是通过低时延、高稳定性、海量设备接入等一系列性能提升让我们得到以往3G、4G所不具备的能力。

据介绍，5G的意义不仅仅是更快的网络，更代表着智能手机和平板以外的移动网络。5G具有高速率、大容量、低时延的特性，这使得5G技术在物联网、智慧家居、远程服务、外场支援、虚拟现实、增强现实等领域有了新的应用。更高的速率和更好的业务体验，为各行各业的数字化转型提供技术前提，5G将真正实现移动信息化与社会各行各业的深度融合。

2019年是5G产业进入全面商用的关键一年，全球5G网络的部署已经启动。

1. 5G是什麽? 要解决什么问题?

过去的三十多年，移动网络经历了一次又一次革新，几乎每十年就会有一代全新的移动技术诞生，从而带来效率和体验上的飞跃。1G时代，人们从固定电话中解放出来，2G又解决了1G的各种局限，3G第一次引入了移动宽带，而4G带来了更快更稳定的移动宽带。 那么5G，又会带给我们什么惊喜呢？

从 1G 到 5G

我们需要先弄清一个简单的含义，4G、5G等数字背后的G代表的是英文单词“Generation”，也就是“代”，5G就是第五代通信技术。从第一代到第五代，是人为划分的代别。它的定义主要取决于在速率、业务类型、传输时延以及各种切换成功率等方面具体实现的不同技术。

• 沟通的起源：1G
• 网络的开始：2G
• 通讯新纪元：3G
• 速度的革命：4G
• 物联的决心：5G

随着AR、VR、物联网等技术的诞生和普及，对于移动网络的要求也正越来越高。

5G 应用场景分为移动互联网和物联网，除能解决移动互联网的发展之外，5G 的毫秒级延迟还将解决机器之间的无线通信需求，有效促进车联网、工业互联网等领域的发展。随着5G 技术的普及，未来也将诞生更多有趣的应用，带来更多全新的移动体验！

从1G到5G

5G 的特点

• 超高的可靠性
• 极低的时延
• 超大范围的覆盖
• 超高的网络承载力
• 5G支持优先级, QoS（服务质量协议），在传递实时数据的时候，不容易丢包
• 1-20Gbps的峰值速率
• 10-100Mbps的用户体验
• 1-10毫秒的端到端延时
• 1-100倍的网络能耗效率提升

5G 时代的特点

5G 的典型应用场景有哪些? 5G 应用场景

• 增强型移动宽带(eMBB, 即enhanced Mobile BroadBand)
• 高可靠低时延连接(URLLC，即Ultra-Reliable Low Latency Connection)
• 海量物联网(Massive IoT)

2. 5G什么时候到来?

5G 新闻事件

• 三大运营商 5G 时间表：都是在2019年预商用，2020年正式商用。 5G 商用时间表
• 2018年12月22日: 中央发文：明年要加快5G商用步伐 中央发文,加快5G步伐
• 1月24日，华为召开5G发布会暨MWC2019与沟通会，正式面向全球发布了5G多模终端芯片
• 2018年6月，5G独立组网标准冻结，5G完成了第一阶段全功能eMBB（增强移动宽带）标准化工作
• 2018年12月6日, 中国三大运营商获得全国范围5G中低频段试验频率使用许可
• 2019年1月10日，工信部宣布发放5G临时牌照，拉开我国5G商用建网的大幕。

3. 5G 将对我们的生活带来怎样的改变? 华为报告

1. 普及移动互联网极致的用户体验

基于互联网TCP/IP协议的基本技术原理，当网络容量是应用流量的4~5倍时，网络的拥塞和延时趋近于零。也就是说，5G的G比特级接入速率，已经超越互联网接入，以及视频通信应用流量的基本速率，终端用户体验开始发生本质变化，进入“无限网络容量”的体验时代，即终端用户感受就像网络有无限的容量。

1. 安全可信的网络架构

与4G网络一样，5G网络是原生的安全业务平台。5G网络采用强化的加密算法，接入认证一体化的能力。核心网确保用户认证和用户隐私。随着越来越多的生态合作伙伴参与到构建5G端到端服务中来，物联网服务也正变得越来越复杂，提供安全的端到端服务，需要从网络到用户的整个过程中对安全性进行管理。5G网络确保只有经过认证的设备才能联网，网络自动化的安全规范和入侵防御功能也得到进一步普及和增加。由此，进而确保企业业务的安全正常运行，大规模的安全规范自动化不仅能帮助管理海量的设备，还能保证这些设备整个生命周期里的安全。

具有超级连接能力的5G网络，将承载10亿个场所的连接、50亿人的连接、500亿物的连接，把数字世界带入每个人、每个家庭、每个组织，构建万物互联的智能世界。

具有超级连接能力的5G网络，将与数字化驱动技术、实时大数据、云技术、人工智能融为一体，带来产业的革命性变化：也就是，连接平台化、万物在线化、全云化、万物即插即慧。

1. 海量连接与网络自动化
   5G网络是原生的海量连接平台，随着5G技术可用性的成熟和升级，将加速万物互联，万物在线化，即万物默认在线。

到2024年，联网设备的数量预计将超过220亿台，人们已经无法手动管理数量如此庞大的连接设备，因此，网络自动化是必由之路。

5G的业务模式和定价模式的创新将发生巨大转变， 越来越多的企业将改变自身的业务模式，从单一的产品销售转变到销售增值服务。

3. 5G对智能家居行业会产生怎样的影响?

5G+AI 智能家居迎来深度变革
欧瑞博抢滩智能家居领跑智慧地产
5G启领未来，构建万物互联的智能世界
5G时代，智能家居产业的变革将超乎想象

无线移动通信是物联网（IoT）的重要赋能者。特别是5G将赋能新的物联网用例（例如低时延和高可靠性需求的用例），以及其他无线通信系统尚未涉足的经济领域。

物联网和5G的关系
智能家居，2019风口正盛

4. 展望与规划

一、整体流程如下：

前提条件

你需要有一个苹果开发者账号,还没有的话申请一个或者借用。

上架App Store之前是先安装到苹果手机测试调试好，app能正常运行再上架

上架流程

上架过程分六个详细步骤，按步骤一步步来，新手也能快速掌握上架流程。

仔细看这个流程，少走很多弯路，不用一步步去试错，节省时间。

• 1、创建APP身份证（App IDs）
• 2、申请iOS发布证书
• 3、申请iOS发布描述文件
• 4、上传ios证书编译打包IPA
• 5、上传iTunes Connect
• 6、上传好IPA回到iTunes Connect填写APP信息并提交审核

我们常见的 OLTP 类型的 web 应用，性能瓶颈往往是数据库查询，因为应用服务器层面可以水平扩展，但是数据库是单点的，很难水平扩展，当数据库服务器发生磁盘IO，往往无法有效提高性能，因此如何有效降低数据库查询频率，减轻数据库磁盘IO压力，是web应用性能问题的根源。

OLTP:联机事务处理（on-line transaction processing）

对象缓存是所有缓存技术当中适用场景最广泛的，任何 OLTP 应用，即使实时性要求很高，你也可以使用对象缓存，而且好的ORM实现，对象缓存是完全透明的，完全不需要你的程序代码进行硬编码。

用不用对象缓存，怎么用对象缓存，不是一个简单的代码调优技巧，而是整个应用的架构问题。在你开发一个应用之前，你就要想清楚，这个应用最终的场景是什么？会有多大的用户量和数据量?你将采用什么方式来架构这个应用?

也许你偏好对SQL语句级别的优化，数据库设计当大表有很多冗余字段，会尽量消除大表之间的关联关系，当数据量很大以后，选择分库分表的优化方式，这是目前业界常规做法。但是也可以选择使用 ORM 的对象缓存优化方式：数据库设计避免出现大表，比较多的表关联关系，通过 ORM 以对象化方式操作，利用对象缓存提升性能。

举个例子：

论坛的列表页面，需要显示 topic 的分页列表，topic 作者的名字，topic 最后回复帖子的作者，常规做法：

select ... from topic left join user left join post .....    

你需要通过 join user 表来取得 topic 作者的名字，然后你还需要 join post 表取得最后回复的帖子，post 再 join user 表取得最后回贴作者名字。也许你说，我可以设计表冗余，在 topic 里面增加 username，在 post 里面增加username，所以通过大表冗余字段，消除了复杂的表关联:

select ... from topic left join post...   

且不说冗余字段的维护问题，现在仍然是两张大表的关联查询。

然后让我们看看ORM怎么做

select * from topic where ... -- 分页条件  

就这么一条SQL搞定，比上面的关联查询对数据库的压力小多了。

也许你说，不对阿，作者信息呢？回贴作者信息呢？

这些难道不会发送SQL吗？如果发送SQL，这不就是臭名昭著的n+1条问题吗？

你说的对，最坏情况下，会有很多条SQL：

select * from user where id = topic_id...;  
....  
select * from user where id = topic_id...;  

select * from post where id = last_topic_id...;  
....  
select * from post where id = last_topic_id...;  
  
select * from user where id = post_id...;  
....  
select * from user where id = post_id...;  

事实上何止 n+1，根本就是 3n+1 条SQL了。

那你怎么还说ORM性能高呢？ 因为对象缓存在起作用，你可以观察到后面的 3n 条 SQL 语句全部都是基于主键的单表查询，这 3n条语句在理想状况下(比较繁忙的web网站的热点数据)，全部都可以命中缓存。

所以事实上只有一条SQL，就是：

select * from topic where ...--分页条件   

这条单表的条件查询和直接使用 join 查询 SQL 通过字段冗余简化过后的大表关联查询相比，当数据量大到一定程度以后对数据库磁盘IO的压力很小，这就是对象缓存的真正威力！

更进一步分析，使用ORM，我们不考虑缓存的情况，那么就是 3n+1 条 SQL。

但是这 3n+1 条 SQL 的执行速度一定比SQL的大表关联查询慢吗？

不一定！因为使用ORM的情况下，第一条SQL是单表的条件查询，在有索引的情况下，速度很快，后面的3n条SQL都是单表的主键查询，在繁忙的数据库系统当中，3n 条 SQL几乎可以全部命中数据库的data buffer。

但是使用SQL的大表关联查询，很可能会造成大范围的表扫描，造成频繁的数据库服务器磁盘IO，性能有可能是非常差的。

因此，即使不使用对象缓存，ORM 的 n+1 条 SQL 性能仍然很有可能超过 SQL 的大表关联查询，而且对数据库磁盘 IO 造成的压力要小很多。

这个结论貌似令人难以置信，但经过我的实践证明，就是事实。前提是数据量和访问量都要比较大，否则看不出来这种效果。

应用场景

是 OLTP 还是 OLAP 应用，即使是 OLTP，也要看访问的频度，一个极少被访问到的缓存等于没有什么效果。一般来说，互联网网站是非常适合缓存应用的场景。

缓存的粒度

毫无疑问，缓存的粒度越小，命中率就越高，对象缓存是目前缓存粒度最小的，因此被命中的几率更高。

举个例子来说吧：你访问当前这个页面，浏览帖子，那么对于 ORM 来说，需要发送 n 条 SQL，取各自帖子 user 的对象。很显然，如果这个 user 在其他帖子里面也跟贴了，那么在访问那个帖子的时候，就可以直接从缓存里面取这个 user 对象了。

架构的设计

架构的设计对于缓存命中率也有至关重要的影响。

例如你应该如何去尽量避免缓存失效的问题，如何尽量提供频繁访问数据的缓存问题，这些都是考验架构师水平的地方。

再举个例子来说，对于论坛，需要记录每个topic的浏览次数，所以每次有人访问这个topic，那么topic表就要update一次，这意味着什么呢？

对于topic的对象缓存是无效的，每次访问都要更新缓存。那么可以想一些办法，例如增加一个中间变量记录点击次数，每累计一定的点击，才更新一次数据库，从而减低缓存失效的频率。

缓存的容量和缓存的有效期

缓存太小，造成频繁的 LRU，也会降低命中率，缓存的有效期太短也会造成缓存命中率下降。

所以缓存命中率问题不能一概而论，一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通，有意识的去调整应用的架构，去分解缓存的粒度，总是会带来很高的命中率的。

文章作者: robbin, 转载自 csdn

网络环境

• DNS
• CDN
• BGP机房

系统优化

• gzip cache
• linux nginx mysql php-fpm
• web前端加速

站点级别

• robots.txt
• url规划
• 链接结构
• 面包屑导航

页面级别

• title description
• heading alt
• canonical nofollow

提交收录

• 主动推送
• 自动推送
• Sitemap
• Ping

移动适配

• 跳转适配
• 代码适配
• 自适应

我们都知道浏览器会缓存访问过网站的网页，浏览器通过URL地址访问一个网页，显示网页内容的同时会在电脑上面缓存网页内容。如果网页没有更新的话，浏览器再次访问这个URL地址的时候，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页。

[size=medium]一、什么是HTTP Cache[/size]

对于浏览器的这种网页缓存机制大家已经耳熟能详了，举个例子来说，JavaEye的新闻订阅地址：http://www.iteye.com/rss/news ， 当浏览器或者订阅程序访问这个URL地址的时候，JavaEye的服务器在response的header里面会发送给浏览器如下状态标识：

Etag "427fe7b6442f2096dff4f92339305444"
Last-Modified Fri, 04 Sep 2009 05:55:43 GMT

这就是告诉浏览器，新闻订阅这个网络资源的最后修改时间和Etag。于是浏览器把这两个状态信息连同网页内容在本地进行缓存，当浏览器再次访问JavaEye新闻订阅地址的时候，浏览器会发送如下两个状态标识给JavaEye服务器：

If-None-Match "427fe7b6442f2096dff4f92339305444"
If-Modified-Since Fri, 04 Sep 2009 05:55:43 GMT

就是告诉服务器，我本地缓存的网页最后修改时间和Etag是什么，请问你服务器的资源有没有在我上次访问之后有更新啊？于是JavaEye服务器会核对一下，如果该用户上次访问之后没有更新过新闻，那么根本就不必生成这个RSS了，直接告诉浏览器：“没什么新东西，你还是看自己缓存的网页吧”，于是服务器就发送一个304 Not Modified的消息，其他什么都不用干了。

这就是HTTP层的Cache，使用这种基于资源的缓存机制，不但大大节省服务器程序资源，而且还减少了网页下载次数，节约了很多网络带宽。

[size=medium]二、HTTP Cache究竟有什么作用？[/size]

我们通常的动态网站编程，服务器端程序根本就不去处理浏览器发送过来的If-None-Match和If-Modified-Since状态标识，只要有请求就生成网页发送给浏览器。对于一般情况来说，用户不会总是没完没了刷新一个页面，所以大家并不认为这种基于资源的缓存有什么太大的作用，但实际情况并非如此：

[size=medium]1、像Google这种比较智能的网络爬虫可以有效识别资源的状态信息，如果使用这种缓存机制，可以大大减少爬虫的爬取次数。[/size]

比方说Google每天爬JavaEye网站大概15万次左右，但实际上JavaEye每天有更新的内容不会超过1万个网页。因为很多内容更新比较快，因此Google就会反复不停的爬取，这样本身就造成了很多资源的浪费。如果我们使用HTTP Cache，那么只有当网页内容发生改变的时候，才会真正进行爬取，其他时候我们直接告诉Google的爬虫304 Not Modified就可以了。这样不但降低了服务器本身的负载和爬虫造成的网络带宽消耗，实际上也大大提高了Google爬虫的工作效率，岂不是皆大欢喜？

[size=medium]2、很多内容更新不频繁的网页，尽管用户不会频繁的刷新，但是从一个比较长的时间段来看使用HTTP Cache，仍然可以起到很大的缓存作用。[/size]

比方说一些历史讨论帖子，已经过去了几个月了，这些帖子内容很少更新。用户可能通过搜索，收藏链接，文章关联等方式时不时访问到这个页面。那么只要用户访问过一次以后，后续所有访问服务器直接发送304 Not Modified就可以了，不用真正生成页面。

[size=medium]3、对于历史帖子使用HTTP Cache可以避免爬虫反复的爬取。[/size]

比方说JavaEye的论坛帖子列表页面，分页到20页后面的帖子已经很少有人直接访问了，但是从服务器日志去看，每天仍然有大量爬虫反复爬取这些分页到很后面的页面。这些页面由于用户很少去点击，所以基本上没有被应用程序的memcached缓存住，每次访问都会造成很高的资源消耗，爬虫隔一段时间就爬一次，对服务器是很大的负担。如果使用了HTTP Cache，那么只要爬虫爬过一次以后，以后无论爬虫爬多少次，都可以直接返回304 Not Modified了，极大的节省了服务器的负载。

[size=medium]三、如何在应用程序里面使用HTTP Cache[/size]

如果我们要在自己的程序里面实现HTTP Cache，是件非常简单的事情，特别是对Rails来说只需要添加一点点代码，以上面的JavaEye新闻订阅来说，只要添加一行代码：

def news
fresh_when(:last_modified => News.last.created_at, :etag => News.last)
end

用最新新闻文章作为Etag，该文章最后修改时间作为资源的最后修改时间，这样就OK了。如果浏览器发送过来的标识和服务器标识一致，说明内容没有更新，直接发送304 Not Modified；如果不一致，说明内容更新，浏览器本地的缓存太古老了，那么就需要服务器真正生成页面了。

以上只是一个最简单的例子，如果我们需要根据状态做一些更多的工作也是很容易的。比方说JavaEye博客的RSS订阅地址： http://robbin.iteye.com/rss

@blogs = @blog_owner.last_blogs
@hash = @blogs.collect{|b| {b.id => b.post.modified_at.to_i + b.posts_count}}.hash
if stale?(:last_modified => (@blog_owner.last_blog.post.modified_at || @blog_owner.last_blog.post.created_at), :etag => @hash)
render :template => "rss/blog"
end

这个实现稍微复杂一些。我们需要判断博客订阅所有的输出文章是否有更新，所以我们用博客文章内容最后修改时间和博客的评论数量做一个hash，然后用这个hash值作为资源的Etag，那么只要这些博客文章当中任何文章内容被修改，或者有新评论，都会改变Etag值，从而通知浏览器内容有更新了。

除了RSS订阅之外，JavaEye网站还有很多地方适合使用HTTP Cache，比方说JavaEye论坛的版面列表页面，一些经常喜欢泡论坛的用户，可能时不时会上来刷新一下版面， 看看有没有新的帖子，那么我们就不必每次用户请求的时候都去执行程序，生成页面给他。我们判断一下如果没有新帖子的话，直接告诉他304 Not Modified就可以了，在没有使用HTTP Cache之前的版面Action代码：

def board
@topics = @forum.topics.paginate...
@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions => ...
render :action => 'show'
end

添加HTTP Cache以后，代码如下：

def board
@topics = @forum.topics.paginate...
if logged_in? || stale?(:last_modified => @topics[0].last_post.created_at, :etag => @topics.collect{|t| {t.id => t.posts_count}}.hash)

@announcements = (params[:page] || 1).to_i == 1 ? Topic.find :all, :conditions...
render :action => 'show'

end
end

对于登录用户，不使用HTTP Cache，这是因为登录用户需要实时接收站内短信通知和订阅通知，因此我们只能对匿名用户使用HTTP Cache，然后我们使用当前所有帖子id和回帖数构造hash作Etag，这样只要当前分页列表页面有任何帖子发生改变或者有了新回帖，就更新页面，否则就不必重新生成页面。

论坛帖子页面实际上也可以使用HTTP Cache，只不过Etag的hash算法稍微复杂一些，需要保证帖子的任何改动都要引起hash值的改变，示例代码如下：

def show
@topic = Topic.find params[:id]
user_session.update_....... if logged_in?
Topic.increment_counter(...) if ......
@posts = @topic.post_by_page params[:page]
posts_hash = @posts.collect{|p| {p.id => p.modified_at}}.hash
topic_hash = @topic.forum_id + @topic.sys_tag_id.to_i + @topic.title.hash + @topic.status_flag.hash
ad_hash = ... (广告的hash算法，略)
if logged_in? || stale?(:etag => [posts_hash, topic_hash, ad_hash])

render

end
end

要分别根据主题贴，该分页的所有回帖和帖子页面的广告内容进行hash，计算出来一个唯一的Etag值，保证任何改动都会生成新的Etag，这样就搞定了，是不是很简单！这种帖子的缓存非常有效，可以避免Rails去render页面和下载页面，极大的减轻了服务器负载和带宽。

再举一个需求比较特殊的例子：对于知识库搜索相关文章的推荐页面，比方说：http://www.iteye.com/wiki/topic/462476，也就是本文的相关文章推荐内容，我们并不希望用户和爬虫每次访问这个页面都实际执行一遍全文检索，然后构造页面内容，在一个相对不长的时间范围内，这篇文章的相关推荐文章改变的概率不大，因此我们希望比方说5天之内，用户重复访问该页面，就直接返回304 Not Modified，那么Rails没有直接的设施给我们使用，需要我们稍微了解一些Rails的机制，自己编写，代码示例如下：

def topic
@topic = Topic.find(params[:id])
unless logged_in?

if request.not_modified?(5.days.ago)
  head :not_modified
else
  response.last_modified = Time.now
end

end
end

每次用户请求，我们判断用户是否5天之内访问过该页面，如果访问过，直接返回304 Not Modified，如果没有访问过，或者上次访问已经超过了5天，那么设置最近修改时间为当前时间，然后生成页面给用户。是不是很简单？

在给JavaEye网站所有的RSS订阅输出添加了HTTP Cache以后，通过一天的观察发现，超过一半的RSS订阅请求已经被缓存了，直接返回304 Not Modified，所以效果非常明显，由于JavaEye网站每天RSS订阅的动态请求就超过了10万次，因此添加HTTP Cache可以减轻不少服务器的负担和带宽消耗。除此之外，新闻文章页面，整个论坛频道，知识库相关推荐文章页面都可以添加HTTP Cache，粗粗计算下来，JavaEye这些页面统统使用HTTP Cache以后，网站整体性能至少可以提高10%。