直接执行这两个命令即可：
sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 100
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 150
如果要切换到Python2，执行：
作者：大兵_小将
来源：CSDN
原文：https://blog.csdn.net/sinat_39886323/article/details/78288997
版权声明：本文为博主原创文章，转载请附上博文链接！
目前我国政府高度重视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网络的部署已经启动。
过去的三十多年，移动网络经历了一次又一次革新，几乎每十年就会有一代全新的移动技术诞生，从而带来效率和体验上的飞跃。1G时代，人们从固定电话中解放出来，2G又解决了1G的各种局限，3G第一次引入了移动宽带，而4G带来了更快更稳定的移动宽带。 那么5G，又会带给我们什么惊喜呢？
我们需要先弄清一个简单的含义，4G、5G等数字背后的G代表的是英文单词“Generation”，也就是“代”，5G就是第五代通信技术。从第一代到第五代，是人为划分的代别。它的定义主要取决于在速率、业务类型、传输时延以及各种切换成功率等方面具体实现的不同技术。
随着AR、VR、物联网等技术的诞生和普及，对于移动网络的要求也正越来越高。
5G 应用场景分为移动互联网和物联网，除能解决移动互联网的发展之外，5G 的毫秒级延迟还将解决机器之间的无线通信需求，有效促进车联网、工业互联网等领域的发展。随着5G 技术的普及，未来也将诞生更多有趣的应用，带来更多全新的移动体验！
基于互联网TCP/IP协议的基本技术原理，当网络容量是应用流量的4~5倍时，网络的拥塞和延时趋近于零。也就是说，5G的G比特级接入速率，已经超越互联网接入，以及视频通信应用流量的基本速率，终端用户体验开始发生本质变化，进入“无限网络容量”的体验时代，即终端用户感受就像网络有无限的容量。
与4G网络一样，5G网络是原生的安全业务平台。5G网络采用强化的加密算法，接入认证一体化的能力。核心网确保用户认证和用户隐私。随着越来越多的生态合作伙伴参与到构建5G端到端服务中来，物联网服务也正变得越来越复杂，提供安全的端到端服务，需要从网络到用户的整个过程中对安全性进行管理。5G网络确保只有经过认证的设备才能联网，网络自动化的安全规范和入侵防御功能也得到进一步普及和增加。由此，进而确保企业业务的安全正常运行，大规模的安全规范自动化不仅能帮助管理海量的设备，还能保证这些设备整个生命周期里的安全。
具有超级连接能力的5G网络，将承载10亿个场所的连接、50亿人的连接、500亿物的连接，把数字世界带入每个人、每个家庭、每个组织，构建万物互联的智能世界。
具有超级连接能力的5G网络，将与数字化驱动技术、实时大数据、云技术、人工智能融为一体，带来产业的革命性变化：也就是，连接平台化、万物在线化、全云化、万物即插即慧。
到2024年，联网设备的数量预计将超过220亿台，人们已经无法手动管理数量如此庞大的连接设备，因此，网络自动化是必由之路。
5G的业务模式和定价模式的创新将发生巨大转变， 越来越多的企业将改变自身的业务模式，从单一的产品销售转变到销售增值服务。
5G+AI 智能家居迎来深度变革
欧瑞博抢滩智能家居领跑智慧地产
5G启领未来，构建万物互联的智能世界
5G时代，智能家居产业的变革将超乎想象
无线移动通信是物联网（IoT）的重要赋能者。特别是5G将赋能新的物联网用例（例如低时延和高可靠性需求的用例），以及其他无线通信系统尚未涉足的经济领域。
你需要有一个苹果开发者账号,还没有的话申请一个或者借用。
上架App Store之前是先安装到苹果手机测试调试好，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