php中文网站

小程序多端框架到底应该选哪个？

最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？

作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。

那么，当我们在讨论多端框架时，我们在谈论什么：

多端

笔者以为，现在流行的多端框架可以大致分为三类：

1. 全包型

这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。

这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。

2. Web 技术型

这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有：

开发迅速复用前端生态易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS缺点有：

交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 JS 和 Native 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。3. JavaScript 编译型

这类框架就是我们这篇文章的主角们：

Taro

、

WePY

、

uni-app

、

mpvue

、

chameleon

，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。

这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有

react-native-web

, Weex 原生支持)

另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。

但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。

那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。

如果不管什么 DSL 都能接受，那就可以进入下一个环节：

生态

以下内容均以各框架现在（2019 年 3 月 11日）已发布稳定版为标准进行讨论。

开发工具

就开发工具而言

uni-app

应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。

其它的框架都是使用 CLI 命令行工具，但值得注意的是

chameleon

有独立的语法检查工具，

Taro

则单独写了 ESLint 规则和规则集。

在语法支持方面，

mpvue

、

uni-app

、

Taro

、

WePY

均支持 TypeScript，四者也都能通过

typing

实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。

CSS 方面，所有框架均支持

SASS

、

LESS

、

Stylus

，Taro 则多一个

CSS Modules

的支持。

所以这一轮比拼的结果应该是：

uni-app

>

Taro

>

chameleon

>

WePY

、

mpvue

多端支持度

只从支持端的数量来看，

Taro

和

uni-app

以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），

chameleon

少了头条小程序紧随其后。

但值得一提的是

chameleon

有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。

uni-app

则有一套独立的条件编译语法，这套语法能同时作用于

js

、样式和模板文件。

Taro

可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。

在移动端方面，

uni-app

基于

weex

定制了一套

nvue

方案 弥补

weex

API 的不足；

Taro

则是暂时基于

expo

达到同样的效果；

chameleon

在移动端则有一套 SDK 配合多端协议与原生语言通信。

H5 方面，

chameleon

同样是由多态协议实现支持，

uni-app

和

Taro

则是都在 H5 实现了一套兼容的组件库和 API。

mpvue

和

WePY

都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。

所以最后一轮对比的结果是：

chameleon

>

Taro

、

uni-app

>

mpvue

、

WePY

组件库/工具库/demo

作为开源时间最长的框架，

WePY

不管从 Demo，组件库数量 ，工具库来看都占有一定优势。

uni-app

则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起

WePy

也是完全不遑多让的。

Taro

也有官方维护的跨端 UI 库

taro-ui

，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但

Taro

有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。

而

mpvue

没有官方维护的 UI 库，

chameleon

第三方的 demo 和工具库也还基本没有。

所以这轮的排序是：

WePY

>

uni-app

、

taro

>

mpvue

>

chameleon

接入成本

接入成本有两个方面：

第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如

wxparse

、

echart

、

zan-ui

等）多是基于原生微信小程序框架语法写成的。目前看来

uni-app

、

Taro

、

mpvue

均有文档或 demo 在框架中直接使用原生小程序组件/库，

WePY

由于运行机制的问题，很多情况需要小改一下目标库的源码，

chameleon

则是提供了一个按步骤大改目标库源码的迁移方式。

第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。

而对于两种接入方式 Taro 都提供了

taro convert

功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。

所以这轮的排序是：

Taro

>

mpvue

、

uni-app

>

WePY

>

chameleon

流行度

从 GitHub 的 star 来看，

mpvue

、

Taro

、

WePY

的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。

uni-app

则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是

uni-app

领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。

所以从流行程度来看应该是：

uni-app

>

Taro

、

WePY

、

mpvue

>

chameleon

开源建设

一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。

从第三方贡献者数量来看，

Taro

在这一方面领先，并且

Taro

的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的

omi

框架小程序部分也是基于 Taro 完成的。

WePY

在腾讯开源计划的加持下在这一方面也有不错的表现；

mpvue

由于停滞开发了很久就比较落后了；可能是产品策略的原因，

uni-app

在开源建设上并不热心，甚至有些部分代码都没有开源；

chameleon

刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。

那么这一轮的对比结果是：

Taro

>

WePY

>

mpvue

>

chameleon

>

uni-app

最后补一个总的生态对比图表：

未来

从各框架已经公布的规划来看：

WePY

已经发布了

v2.0.alpha

版本，虽然没有公开的文档可以查阅到

2.0

版本有什么新功能/特性，但据其作者介绍，

WePY 2.0

会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后

WePY

的表现。

mpvue

已经发布了

2.0

的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，

mpvue

要想在未来有作为首先要打消社区对于

mpvue

不管不顾不更新的质疑。

uni-app

已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果

uni-app

能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。

chameleon

的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有：

快应用和端拓展协议通用组件库和垂直类组件库面向研发的图形化开发工具面向非研发的图形化页面搭建工具如果

chameleon

把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来

chameleon

将大有可为。

Taro

的未来也一样值得憧憬。Taro 即将要发布的

1.3

版本就会支持以下功能：

快应用支持Taro Doctor，自动化检查项目配置和代码合法性更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 只能用 map 创造循环组件 一条H5 打包体积大幅精简同时

Taro

也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。

又到一年一度的跳槽求职高峰季，很多人问我，你们公司还需要人么，你们用的技术栈是哪些，有哪些是你们比较关注技术重点？

没错，作为负责技术面试的我，面对数十甚至上百封简历，肯定要做一轮筛选。究竟哪些技术点或方向在我筛选或面试时，留下深刻印象呢？

我觉得优秀的，有潜质的程序员可以从下面几点体现。

1. 性能调优

几乎每个JAVA后端开发程序员，都会在面试时碰到诸如如何性能调优的问题，如何回答好这个问题，不仅仅是对JVM，内存模型等的理解，更重要的是碰到性能问题时，排查问题的方法论和思路。

典型的一个场景是：在压力测试时，发现FullGC频率很高，如何解决？

此类问题一般从以下几点入手：

1. 观察GC日志，判断是否有内存泄漏，或者存在的内部不合理点。此处要求能熟悉各种linux命令，可以快速查看和定位。

2. 调整JVM 参数，如新生代，年老代大小，S0和S1大小比例，不同垃圾回收器的采用。并结合业务特点做进一步分析。这里不但要求扎实的JVM内存模型和理论，还要求对JVM的各种参数设置耳熟能详，并能实践操作。

3. Dump内存，做进一步的对象分析。

4. 压测脚本的编写，性能问题解决前可以发现问题，并能在问题解决后真实的验证。

此类优化不仅仅是照本宣科式的回答，面试官一定会喜欢问实际中操作的场景，和解决问题的思路。因为性能问题的原因是多种多样的，但是解决问题的思路和方法论是可以明确的。

网易十几年的互联网开发和几乎囊括了互联网的各个产品和业务场景，在性能优化和调优这块积累了丰富和独到的实践经验，很有代表和可参考性。

2. 网络框架的理解和使用

大家一定都听过或使用过网络异步框架Netty，甚至使用netty框架开发过一些应用和功能。

但是大部分人仅限于对Netty的使用，甚至仅仅知道其他一些开源框架使用了Netty，但是在资深面试官眼里，Netty有很多值得学习和借鉴的地方，使用过Netty并且能对Netty的一些原理有一定的了解且能学以致用的Java程序员格外受欢迎。

一般来说，要求较高的面试官和技术经理喜欢从Netty的设计模式角度深入的考察技术人员对网络开发和相关理论的理解如：

1. Netty的Reactor模型如何设计，反应在应用里的模型是如何（见下图）。

2. Netty的pipeline 责任链如何使用，业务场景中是否有类似的实践经验。

3. 项目中有无使用Netty，并利用Netty进行私有化协议设计。

同学们不仅要求能使用Netty，通过阅读其源码，理解其中的精髓，并能应用在自己的实践项目中，这个才是亮点和加分项。

3. 开源服务化RPC框架的理解和使用

互联网经过十几年的发展，早已经从单体应用发展为服务化应用，大厂里系统和服务尤其如此。

拿经典的dubbo 服务化框架举例，当前市面上有很多dubbo相关的文章和介绍，这里撇开不谈，从技术负责人的角度来，我会更关心下面有关几个dubbo相关的问题。

1. 技术选型：为什么选择dubbo，而不选择其他如spring cloud框架?

我认为可以从如下考虑：

A）业务的特点以及可预见的后续的发展。作为高级技术人员，必须需要对业务的的发展做预计和规划。

B）可用性要求，是否需要达到4个99（99.99%），需要支撑的峰值QPS，是否有业务的集中爆发点，如电商大促

C）团队的成熟度，一个成熟的团队可以很好的hold住复杂的开源框架，甚至做定制化开发。

技术选型话题虽然宽泛，但是最能体现体现技术人员的综合能力，尤其结合业务特点后对技术框架深度和广度的驾驭能力。

2. Dubbo底层走的是什么协议，如何处理异步转同步？

大部分的Java开发都会直接使用dubbo，而不会去关心其底层一些技术细节，但是一些细节，如dubbo如何对对象进行序列化，用了哪些序列化方式，这些在分布式项目中对提高应用的处理速度，减少网络开销，都很大帮助。

同时RPC框架里如何将异步转同步，也是需要技术人员非常关注的一面，里面相关的设计模式，多线程程高并发场景都是很多业务系统里真实需要和借鉴的。

3. Dubbo在高并发高可用等实践场景需要认真考虑的其他问题

使用了dubbo后，很多人觉得万事大吉，其实并不是这样，下面几点还需要关心，并且这些就是体现你价值的地方

A) dubbo依赖了zooKeeper，但是万一ZooKeeper宕机了怎么办

B) 如果ZooKeeper假死，客户端对服务端的调用是否会全部下线，如果是该如何避免

C) 如何监控duubo的调用，并做到优雅的客户端无感发布

同学们可以自行思考，答案不是唯一，网易有很多类似的项目，设计的很好，非常值得思考和借鉴。

自身多年的面试体会

1.项目中尽量多思考，迎难而上，如碰到复杂的性能，内存泄露等问题的问题，往往是提升自己的机会，千万要仔细研究解决，可以参考其他解决类似问题的文章和实践经验，对技术深度的提升是很大的，关键时候可以让你的面试官突然觉得面耳目一新。

2.重视解决问题的思路和方法，很多时候技术人员可以快速设计一个系统或解决一个问题，但是在资深工程师或面试官眼里可能并不是最优方案。如何解决？

很多技术人员的项目和技术相对单一，长久以往，容易造成技术思路和视野的狭窄，接触不到行业最新思路和动态或者当前疑难问题的最佳解决方案。

总结：想成为进阶架构师，那么资源肯定也是少不了的，如果你对技术提升很感兴趣，小编在这里提供了一份针对架构进阶视频资料，资源分享包括但不限于（分布式架构、高可扩展、高性能、高并 发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql 、Zookeeper、Tomcat、Docker、Dubbo、Nginx）。

作者：程序猿院长链接：https://juejin.im/post/5cc15490e51d456e2446fcd2来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

前言

对于大部分程序员来说，主要工作都是进行编码以及一些简单的中间件安装，这就导致了很多人对于“运维”相关的工作会比较生疏。例如当我们拥有一台自己的服务器以后，可能会在上面跑一跑自己blog程序，mysql，nginx等等。当程序越来越多了没有一个统一的入口管理启停，也可能会遇到一些特殊的原因导致程序被kill掉了，这时候又没装相关的监控程序或者脚本（太麻烦了懒得装，机器配置差不想装），所以只能当我们访问自己程序发现异常的时候才会登上服务器查找原因。

这些状况对我们来说是比较麻烦的，那么这就需要一个“神器”来解放我们的双手，铛铛铛！！Supervisor 就来了。

正文

Supervisor 介绍

Supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启。它是通过fork/exec的方式把这些被管理的进程当作supervisor的子进程来启动，这样只要在supervisor的配置文件中，把要管理的进程的可执行文件的路径写进去即可。也实现当子进程挂掉的时候，父进程可以准确获取子进程挂掉的信息的，可以选择是否自己启动和报警。

supervisor 安装

简单粗暴

yum install supervisor -y

supervisor 配置说明

通过这种形式安装的supervisor，其配置文件的目录位于：/etc/supervisord.conf (主配置文件，下面会详细介绍)/etc/supervisor.d/ (默认子进程配置文件，也就是需要我们根据程序配置的地方)

supervisord.conf 基本配置项说明，由于其参数比较多，这些只贴出一些常用的配置项，详细内容可参阅官网。温馨提示 “;” 符号是表示该行配置被注释。

[unix_http_server]file=/home/supervisor/supervisor.sock ; supervisorctl使用的 socket文件的路径;chmod=0700 ; 默认的socket文件权限0700;chown=nobody:nogroup ; socket文件的拥有者[inet_http_server]; 提供web管理后台管理相关配置port=0.0.0.0:9001 ; web管理后台运行的ip地址及端口，绑定外网需考虑安全性 ;username=root ; web管理后台登录用户名密码;password=root[supervisord]logfile=/var/log/supervisord.log ; 日志文件，默认在$CWD/supervisord.loglogfile_maxbytes=50MB ; 日志限制大小，超过会生成新文件，0表示不限制logfile_backups=10 ; 日志备份数量默认10，0表示不备份loglevel=info ; 日志级别pidfile=/home/supervisor/supervisord.pid ; supervisord pidfile; default supervisord.pid ; pid文件nodaemon=false ; 是否在前台启动，默认后台启动falseminfds=1024 ; 可以打开文件描述符最小值minprocs=200 ; 可以打开的进程最小值[supervisorctl]serverurl=unix:///home/supervisor/supervisor.sock ; 通过socket连接supervisord,路径与unix_http_server->file配置的一致[include]files = supervisor.d/*.conf ;指定了在当前目录supervisor.d文件夹下配置多个配置文件

准备测试项目

这里我打包了一个简单的spring-boot程序，存放与“/opt/project/”下。

在这个程序中我们只是简单的定义了一个rest接口，主要用于演示作用。

@RestControllerpublicclassHelloController{ @RequestMapping("/hello") public String hello(){ return"hello world"; }}

如果不用supervisor的话，我们启动程序一般用一下命令

nohup java -jar springboot-hello-sample.jar &

这是以后台的方式启动jar包，程序运行相关输出会在nohup.out中，我们我们就不再赘述了，那么我们来看一下，切换到supervisor的方式，我们是怎么配置项目，以及管理的呢？

定义supervisor管理进程配置文件

从上面的配置文件[include]->files配置项我们可以知道，supervisor会把supervisor.d/下以conf结尾的配置文件都加载进来，那么我们在这个目录下面新建一个sboot.conf,内容如下：

[program:sboot];[program:xxx] 这里的xxx是指的项目名字directory = /opt/project ;程序所在目录command = java -jar springboot-hello-sample.jar ;程序启动命令autostart=true ;是否跟随supervisord的启动而启动autorestart=true; 程序退出后自动重启,可选值：[unexpected,true,false]，默认为unexpected，表示进程意外杀死后才重启stopasgroup=true;进程被杀死时，是否向这个进程组发送stop信号，包括子进程killasgroup=true;向进程组发送kill信号，包括子进程stdout_logfile=/var/log/sboot/supervisor.log;该程序日志输出文件，目录需要手动创建stdout_logfile_maxbytes = 50MB;日志大小stdout_logfile_backups = 100;备份数

可以看到，在配置文件里面已经有配置该程序名，启动路径等，这样一来，supervisor就可以完全的掌管程序的生死了。接着我们执行

service supervisord restart

重启supervisord。

观察效果

浏览器输入:服务器ip:9001 （这里的web管理页面端口是在配置文件配置好的。）

如图所示，我们可以可以观察到springboot程序已经是running状态了，pid是27517，我们可以点击Tail -f拉力观察输出日志，它的作用跟我们在服务器直接“tail -f”是类似的。

这里我们为了方便延时就没有添加验证了，如果大家是在公网的使用环境，需要配置文件里面的用户名密码验证注释打开。不然别人扫出你的后台管理页面就可以随意控制程序了。

除了web管理页面，还有一些简单的命令也是需要我们掌握的。

直接在命令行输入supervisorctl会展示当前已配置好的项目信息。

[root@wangzh supervisor.d]# supervisorctlsbootRUNNINGpid 27517, uptime 0:18:04supervisor>

然后可以执行

start/stop/restart sboot 来简单控制项目的启停等

supervisorctl update #更新配置文件supervisorctl reload #重新启动配置的程序supervisorctl stop all #停止全部管理进程

结语

只需要一点简单的配置，就可以统一的管理我们的程序了，同时也可以在进程意外死掉的时候自动重启，这些工作以后就交给supervisor了，我们只要掌握一点简单的命令就可以“为所欲为”。

HTTP和FTP之间有哪些区别？本篇文章就给大家介绍HTTP和FTP是什么？让大家了解HTTP和FTP之间的区别，希望对你们有所帮助。

HTTP和FTP都是用于在客户端和服务器之间传输数据的文件传输协议，但它们之间还是存在差异的。在介绍HTTP和FTP之间的区别之前，我们首先来了解一下HTTP和FTP。

什么是HTTP？

HTTP是超文本传输协议，是用于在万维网上传输文件（文本，图形图像，声音，视频和其他多媒体文件）的规则集。它是互联网中数据通信的基础，数据通信以客户端发送的请求开始，并以从Web服务器接收的响应结束。

只要Web用户打开Web 浏览器，就会间接的使用HTTP。HTTP是一种在TCP / IP协议套件（Internet的基础协议）之上运行的应用程序协议。

什么是FTP？

FTP是文件传输协议，用于使用TCP在FTP服务器和网络中的客户端计算机之间上传和下载文件，可以将文件从一个主机复制到另一个主机。

FTP使用TCP的服务在客户端和服务器之间传输文件，会建立两个连接，一个用于TCP端口号20上的数据传输，另一个用于TCP端口号21上的控制信息（命令和响应）。

HTTP和FTP之间的区别

1、功能上的区别

HTTP用于访问Internet上的不同网站，将网页内容从Web服务器传输到客户端的Web浏览器，被称为单向系统。

FTP用于在FTP服务器和FTP客户端之间上传和下载文件，可以将文件从一个主机传输到另一个主机，被称为双向系统。

2、连接上的区别的区别

HTTP仅建立一个链接：数据连接。

FTP建立两个链接：数据连接和控制连接。

3、使用端口的区别

HTTP使用TCP的80端口，而FTP使用TCP的20和21端口。

4、传输的文件大小的区别

HTTP可以有效地传输较小的文件，如网页；而FTP则可以有效地传输大文件。

5、验证区别

HTTP不需要身份验证；而FTP使用密码进行身份验证。

6、数据储存的区别

使用HTTP传输到设备的网页或数据内容不会保存在该设备的内存中，而使用FTP传送到设备的数据会保存在该设备的内存中。

7、显示的区别

如果用户使用HTTP，http将显示在网站的URL中；如果用户使用的是FTP，则会在URL中显示ftp。

总结：以上就是本篇文的全部内容，希望能对大家的学习有所帮助。

以上就是HTTP和FTP之间有哪些区别的详细内容，更多请关注php中文网其它相关文章！

PHP 7是PHP编程语言的一个主要版本，它被认为是web应用程序开发方式的一场革命。这个版本被认为是继2004年PHP 5发布之后对PHP最重要的更改。

新功能

PHP 7增加了许多特性，其中最重要的特性如下所述

性能改进——在PHP7中合并了PHPNG代码，速度是PHP 5的两倍。

较低的内存消耗——优化的PHP 7使用较少的资源。

标量类型声明——现在可以强制执行参数和返回类型。

64位支持——对64位体系结构计算机的一致支持。

异常层次结构——异常层次结构得到改进。

许多致命错误转换为异常——异常范围增加，包括许多作为异常转换的致命错误。

安全随机数生成器——添加新的安全随机数生成器API。

已删除不推荐使用的SAPI和扩展 ——各种旧的和不支持的SAPI和扩展被从最新版本中删除。

空合并运算符(??)——添加了新的空合并运算符。

返回类型和标量类型声明——支持添加返回类型和参数类型。

匿名类——支持添加匿名。

Zero cost asserts——支持添加Zero cost asserts。

PHP 7使用新的Zend Engine 3.0来改进应用程序性能，其性能几乎是PHP 5.6的两倍，内存消耗也提高了50%。它允许在不需要任何额外硬件的情况下为更多并发用户提供服务。PHP 7是根据当前的工作负载设计和重构的。

本篇文章就是关于PHP7的介绍，希望对需要的朋友有所帮助！

以上就是PHP 7是什么？的详细内容，更多请关注php中文网其它相关文章！

前端现正处于一个高速发展的时代。我们站在2019年的节点上，回望前端的发展，在过去十年中，前端从最初的HTML，CSS，JavaScript三把刷子做出来静态网页的时代，发展到现在视觉效果酷炫，适用于多种终端，开发手段丰富多样的前所未有的黄金时代。

越来越多的开发者涌入前端行业，那么就有一种说法流传出来，“前端开发已经饱和了”，“前端开发要找不到工作了”。这是不是在危言耸听，真相是什么样的呢？

在多个招聘网站搜索“前端工程师”职位就会发现，在每个一线城市均可找到10000+以上前端工程师招聘职位。这说明在2019年，对前端开发需求量依然可以保证你找到一门工作，不存在饱和这样的说法。

但如果你再仔细留意，你会发现招聘量最大的3-5年的中高级前端乃至前端架构师，而不是初级前端。所以再回过头来说前端饱不饱和这个问题，需求肯定是不饱和，但留给初级前端的机会确实少了。

所以，如果你是一个实力很弱的前端小菜鸟，找到一份心仪的前端工作是有些困难的，初级前端就只能失业了吗？不，除了熬年限、熬经验，实力才是最为重要的。高水平的开发也是从初级水平成长起来的，你也是可以成长为一名高级前端开发的。

初级开发怎么才能成长为一名高级前端？前端的知识体系庞杂，框架、库、插件数不胜数，API迭代飞速，怎么才能在如此混乱的局面中抓住正确的道路？下面介绍3点关键点：

夯实基础

无论是做什么样的专业技术工作，专业基础都是十分重要的。基础不牢固，上层建筑建的再华丽，都是岌岌可危的。

前端的基础是什么？是HTML、CSS，JavaScript。特别是JavaScript，我们对前端基础的掌握程度，极大程度上体现在对JavaScript的掌握程度上。所有的浏览器引擎运行的脚本语言都是JavaScript，我们使用的框架也是用JavaScript开发的。即使最近非常流行的typescript，其实底层也是JavaScript，是需要编译为JavaScript后才能在浏览器运行的。

即使是高级前端工程师的面试中，对于JavaScript知识的考核也是必不可少的。不仅体现在JavaScript语法，API，也很大一部分包含着最新的ES6的知识。

洞悉原理

我们需要知道的原理不仅体现在框架的原理上，也体现在JavaScript语言和浏览器引擎的原理上。高级前端工程师对于框架和语言的理解绝不会停留于了解API的层面上，需要深入到了解内部原理和运行机制的层面上。

JavaScript引擎运行各种数据类型的方法的操作细节，各个JavaScript runtime在运行JavaScript的差异细节，各个框架的设计原理，使用的设计模式，核心算法，比如拼接字符串时+方法和join方法，在不同浏览器因为引擎操作不同而有着截然不同的性能差异；又比如Vue响应式的原理，Virtual DOM生成真实DOM和Diff的算法，运用到的发布订阅设计模式，自定义指令，插件挂载等等，即便不懂这些，写起业务逻辑来完全不耽误，但是不懂这些在前端市场上完全没有竞争力。

能完全弄懂这些原理的人的确相对很少，但是会写JavaScript、会用Vue之类框架的人却很多，此时如果企业看到你是了解原理的高级开发者，你的竞争力必然是陡然上升。另一方面高级前端作为初级前端的引领者，要能够帮助初级前端工程师解决棘手的问题。如果不懂得原理，如何能够快速的定位和解决问题，如何履行高级前端的职责？如何能够对于不断变化的框架API迅速地理解和深入运用？

主动学习

一名优秀的程序员绝对不是一个被别人牵着鼻子或者被人用鞭子赶着才会去学习的人，他一定是一个主动学习的人。

优秀的程序员之所以优秀，是因为他有深厚的知识积累，而这些知识的来源，是因为他在不断地学习。所以才能够在工作中解决棘手的问题，在面试中回答出刁钻的难题，因此而获得丰厚的薪水。一个被动学习的人，我想是很难达到这种地步的。

作为前端要主动学习，方向必须是能够具有针对性的提升自身竞争力的内容，而且是轻易不会过时的稳定的知识。比如就像语言内部机制和框架原理，设计模式这种知识。学了这种知识，其实就有能力自己做一些简单的框架，工具和库了，心中有底气，就可以摆脱被不断更新的应用型，API型知识牵着鼻子走的局面。

2019年的前端依然是一个很有前途的职业，如果目前还只是一名初级前端的话，一定还要努力尽快成为一名高级前端开发者。在夯实基础的前提下，向纵深出挖掘，在做好工作的同时，利用平时点滴零碎时间，追根朔源式的学习，不断积累前端知识。同时也建议多看些前端最新新闻，前端前沿技术之类的博客文章，多尝试最新的技术功能更新，紧跟技术发展，才能不被飞速发展的前端圈落下。

除非你一直生活在一块石头下，或者生活在过去，否则你会意识到JIT正在进入PHP 8：投票今天悄然结束，绝大多数人赞成合并到PHP8，所以，这是正式的，本文全方位解读php8.0版本优化与改进。

PHP8 官宣《PHP8首个版本 Alpha1 发布！》

现在，坐下来阅读下面这篇颠覆神话的文章，我们将澄清一些关于JIT是什么、它将带来什么好处的困惑，并深入研究它是如何工作的（但只是一点点，因为我不想让你感到无聊）。

因为我不知道我在和谁说话，所以我会从简单的问题开始，一直到复杂的问题，如果你已经确定你知道标题中问题的答案，你可以跳过那部分。。。

什么是JIT？

PHP实现了一个虚拟机，一种虚拟处理器，我们称之为Zend VM。PHP将人类可读的脚本编译成虚拟机能够理解的指令（我们称之为操作码），这个执行阶段就是我们所说的“编译时”。在执行的“运行时”阶段，虚拟机（Zend VM）执行代码的指令（操作码）。

这一切工作得很好，像APC（过去）和OPCache（现在）这样的工具可以缓存代码的指令（操作码），以便“编译时”只在必须的时候发生。

首先，有一行代码解释了什么是JIT：

Just-in-time 是一种编译器策略，它接受代码的中间表示形式，并在运行时将其转换为依赖于体系结构的机器代码，以便及时执行。

在PHP中，这意味着JIT将为Zend VM生成的指令作为中间表示，并发出依赖于体系结构的机器代码，因此代码的宿主不再是ZendVM，而是CPU。

为什么PHP需要JIT？

在PHP 7.0之前，PHP内部社区关注的焦点是性能，这是由Facebook的HHVM项目带来的良性竞争带来的。PHP 7.0中的大部分核心更改都包含在PHPNG补丁中，这大大改进了PHP在其核心上利用内存和CPU的方式，从那时起，我们每个人都被迫关注性能。

自PHP 7.0以来，已经有了一些性能改进，HashTable （PHP的核心数据结构）的优化，某些操作码的Zend VM的专门化，某些序列的编译器的专门化，以及对OPCache的优化器组件的不断改进。。。除此之外还有很多其他的，太无聊了。

这是一个残酷的事实，这些优化只能带我们到目前为止，我们正在迅速接近，或可能已经遇到了砖墙，在我们的能力，以进一步改善它。

注意：当我们说“我们不能再改进了”时，我们真正的意思是，“我们必须做出取舍，以进一步改进它不再看起来有吸引力”。。。每当我们讨论性能优化时，我们都在讨论权衡。通常，在简单性和性能之间进行权衡。我们都想认为最简单的代码是最快的代码，但在现代的C编程世界中，情况并非如此。最快的代码通常是准备利用依赖于体系结构的内部函数或依赖于平台（编译器）的内部函数的代码。简单并不能保证最好的性能。。。

此时，PHP的JIT功能似乎是从PHP获得更多性能的最佳方法。

JIT会让我的网站更快吗？

很有可能，并不明显。

也许不是您期望的答案：在一般情况下，用PHP编写的应用程序是I/O绑定的，JIT在CPU绑定的代码上工作得最好。

“I/O和CPU绑定”到底是什么意思？

当我们想要描述一段代码或一个应用程序的一般性能特征时，我们使用术语I/O绑定和CPU绑定。

最简单的说法是：

如果我们能够改进（减少、优化）它所做的I/O，那么一段I/O绑定的代码将会运行得更快。如果我们能够改进（减少、优化）CPU正在执行的指令，或者（神奇地）提高CPU的时钟速度，那么一段CPU限制的代码就会运行得更快：）一段代码或一个应用程序可以是I/O绑定、CPU绑定，或者与CPU和I/O同等绑定。一般来说，PHP应用程序往往是I/O绑定的——减慢它们速度的是它们正在执行的I/O——连接、读取和写入数据库、缓存、文件、套接字等等。CPU绑定的PHP是什么样子的？

由于大多数PHP应用程序的性质，许多PHP程序员并不熟悉CPU绑定代码——他们的工作往往是连接到某个数据库，或者可能是一个缓存，做一些轻量级的工作，并输出html/json/xml响应。

您可能会环顾代码库，发现许多与I/O无关的代码，甚至调用与I/O完全断开连接的函数的代码，并且会感到困惑，我似乎是在暗示这并没有使您的应用程序CPU受到限制，即使处理非I/O的代码行数可能比I/O多。

PHP实际上相当快，它是世界上解释速度最快的语言之一。Zend VM调用与I/O无关的函数和在机器代码中进行相同的调用之间没有显著的区别。

这显然是有区别的，但事实是，机器代码有一个调用约定，Zend VM有一个调用约定，机器代码有一个序言，Zend VM有一个序言：在Zend操作码中调用某个c_level_function（）还是机器代码对调用应用程序的性能没有显著影响-尽管这似乎对那个电话有很大的影响。

注意：调用约定大致是指在进入另一个函数之前执行的一系列指令，序言是指在进入另一个函数时执行的一系列指令：在这两种情况下，调用约定都将参数推送到堆栈上，序言将它们从堆栈中弹出。

循环、尾调用和X呢？我听说你问过：PHP实际上非常聪明，启用了OPCache的优化器组件，你的代码就好像被魔法转化成了你能编写的最有效的形式。

现在需要注意的是，JIT不会改变Zend函数的调用约定，而不是VM建立的约定-Zend必须能够在任何时候在JIT和VM模式之间切换，因此决定保留VM建立的调用约定。因此，当JIT运行时，随处可见的那些调用并没有明显地加快速度。

如果您想了解CPU绑定的PHP代码是什么样子的，请查看Zend/bench.php文件... 这显然是一个极限的CPU代码示例，但它应该让我们知道JIT真正的亮点是在数学领域。

PHP是否为加快数学速度做出了最终的权衡？

不，我们这样做是为了扩大PHP的范围，而且相当大。

在这个非常偏颇的PHP开发人员看来，如果你在2019年是一名web程序员，你还没有考虑在下一个项目中使用PHP，那么你做的web是错误的。

在PHP中提高更快地执行数学的能力，乍一看，似乎是一个非常狭窄的范围。

然而，这实际上为机器学习、3d渲染、2d（gui）渲染和数据分析（仅举几个例子）打开了大门。

为什么我们不能在PHP 7.4中使用它呢？

我刚刚把JIT称为“最终的权衡”，我认为它是：它可以说是有史以来最复杂的编译器策略之一，也许是最复杂的。引入JIT就是引入相当的复杂性。

如果你问Dmitry（JIT的作者）他是否让PHP变得复杂，他会说“不，我讨厌复杂性”（这是一个直接的引语）。

归根结底，复杂是我们所不了解的，而目前，真正了解JIT实现的内部开发人员（不到几个）很少。

PHP 7.4的发展很快，合并到php7.4中会给我们留下一个PHP版本，只有不到几个人可以调试、修复或改进（在任何实际意义上）。对于那些对合并到PHP 7.4投反对票的人来说，这种情况是不可接受的。

在从现在到PHP 8的这段时间里，我们中的许多人将在业余时间努力理解JIT：

我们仍然有一些要实现的特性和需要为php8重写的工具，首先我们必须理解JIT。我们需要这一次，并非常感谢大多数选民认为适合把它交给我们。

复杂并不是可怕的同义词：

复杂可以是美丽的，就像星云一样，JIT就是那种复杂。原则上，你可以完全理解某件复杂的事情，并且只在表面上的复杂程度上稍微降低一点。换句话说，即使有20个内部开发人员和Dmitry一样熟悉JIT，它也不会真正改变JIT的复杂性。

PHP的开发速度会减慢吗？

没有理由认为会这样。我们有足够的时间可以满怀信心地说，到PHP 8普遍可用时，我们中已经有足够多的人熟悉JIT，至少在修复bug和推动PHP向前发展方面能够像今天一样发挥作用。

当试图将这一点与JIT本质上是复杂的观点联系起来时，请考虑我们花在引入新特性上的大部分时间实际上是花在讨论该特性上的。对于大多数功能，甚至修复，代码可能需要几分钟或几小时的编写时间，而讨论则需要几周或几个月的时间。在极少数情况下，一个特性的代码可能需要几个小时或几天的时间来编写，但在这些极少数情况下，讨论总是需要更长的时间。

简介：本人17岁，现是一名java开发攻城狮，在学习编程的路上很多小伙伴很迷茫，下面给大家聊一下如何才能学好编程呢？

俗话说人要有目标，学习编程也是一样的道理。朝着自己的目标前进，往往会事半功倍。经常遇到很多人问，现在java好找工作吗？听说Python很厉害，我要不要学Python呢？技术一直在更新，今天可能Python很火，明天可能C#很火，这些都是预料不到的事情。往往自己正确的选择更为重要，选择自己感兴趣的方向，你才肯花时间去学习，因为只有这样你才有前进的方向。

学习目标：首先你要决定你的学习方向，例如我对java感兴趣，我就会把时间全部投入到java的学习过程中，切勿今天学习python,明天又想学习java,没有目标的人注定不能成功！

学习态度：在学习编程的过程中肯定会枯燥乏味，请你一定要坚持住。有很多人说学java开发的人太多了，我怕我找不到工作。其实成功的道路并不拥挤，在于你是否能坚持下来。你坚持住了，下一个开发攻城狮将会是你

学习方法：现在百度、谷歌……浏览器好像你想要的都能搜索到，一个真心想学习的人他会想很多办法来找学习资料，下面我给大家提供一些学习网站。希望对新手有帮助！慕课网、极客学院、腾讯课堂……一些培训机构的视频教程还是非常不错的，大部分网站都有提示你学习的路径，按照流程学习即可！

新手学习编程的时候本人不建议看太多的书籍，看书反而越看越懵逼，可能都会看到你怀疑人生，建议大家是【视频+书】组合，视频看完了，然后看着书回忆一下，加深印象。说到书，java的书籍也是一大堆，在这里推荐一下《Java核心技术 卷1/卷2》。

笔记：学过的知识，建议大家记录下来，方便下次回顾，大脑有限，你不可能什么都记得非常清楚。有道云笔记就不错哦！

代码：编码是重中之重，你就算把一本书或视频全部看完了，或与很多知识点你都能说出来，但是请记住公司给你发工资不是请你去吹流弊的，代码不会写等于0。

跟好人学好人，跟猫子学咬人。跟一群热爱学习和有目标以及有梦想的人在一起，你会进步很快，否则反之，多认识一些对你学习有帮助的人，因为他们会让你的技术和各方面迅速提升！

本文来自PHP中文网，更多相关知识点请前往PHP中文网视频课程频道！

PHP在默认的情况下是不支持多线程的，通过安装pthreads扩展，让其参数来指定编译PHP的线程安全方式来使其支持多线程，但是使用的过程中要考虑到线程安全的问题

线程是操作系统中进行运算调度的最小单位。它被包含在进程中，是进程中的实际运作单位。今天将要分享的是线程知识是有关于PHP的，具有一定的参考价值，希望对大家有所帮助

多线程的理解

所谓多线程就是在在一个进程中可以并发多个线程，每条线程并行执行不同的任务。多线程大大提高了程序的执行效率，一个多线程比单线程被操作系统调度的概率更大。而且更高效。多个线程可以在多核CPU的多个核心同时运行，加快了运行效率。而且线程间的通信更加简单。

PHP多线程

在默认情况下PHP是不支持多线程的，要使用多线程需要安装 扩展，目前常用的扩展有pcnlt，POSIX ，pthreads，但是用的最多的还是pthreads扩展，它通过使用参数来指定来编译PHP时的线程安全方式，使其支持多线程

在使用线程之前首先要考虑到线程的安全问题，线程安全指的是某个函数或函数库在多线程环境中被调用时，能够正确的处理多线程之间的共享变量，使得程序的功能能够正确完成

例：

在多线程中由于存在共享变量，很有可能会导致出现以下问题：

存在一个全局数组：$arr = array('a');

A 线程获取数组长度为1;

B 线程获取数组长度为1;

A 线程pop出数组元素 $a = array_pop($arr); $a = 'a';

B 线程也pop数组元素 $b = array_pop($arr); $a = null;

但是此时B线程内就出现了错误事件，虽设置了数组长度大于0，但是没有 pop值来

PHP实现线程安全

PHP实现线程安全主要通过 TSRM 机制，通过此机制可以对全局变量和静态变量进行隔离，并且给每个线程都复制了一份全局变量和静态变量。各个线程使用的都是主线程的一个备份。这样就避免了变量冲突，也不会发生线程安全的问题。

PHP 对多线程的封装保证了线程安全，所以开发人员就不需要在考虑读写冲突的问题了，也使得代码更加安全。不过这样做也有不好的地方，例如当子线程开始运行时，主线程便再也无法对子线程运行细节进行调整了，失去了消息传递能力

以上就是php多线程是什么意思的详细内容，更多请关注php中文网其它相关文章！

PHP一直被唱衰，特别是某一些培训机构为了推python、java等语言的培训，总是搞一些编程语言排行榜，误导编程初学者，给初学者造成PHP不行了的印象。是否PHP真的在走下坡路？PHP语言到底市场份额占有多少？

不妨根据 W3Techs 提供的数据和报告，看看 PHP 最新的使用统计和市场定位情况。W3Techs 是国外一个专门调查 Web 技术的网站，提供有关 Web 各种技术的使用情况信息。

来源地址：https://w3techs.com/technologies/overview/programming_language

以上是W3Techs提供的2019年12月6号的统计数据。

是的，你没有看错！PHP在WEB网站服务器端使用的编程语言所占份额高达78.9%，稳居第一！将排在第二位的ASP.NET和第三位的JAVA远远甩在身后。

那有人又开始杠了，你只是统计的一个月的，不具有代表性，那我们再来看看最近一年的情况。

（WEB服务器端编程语言使用情况统计）

（折线图形式）

上图我们可以看到PHP语言在WEB服务器端语言中基本稳定保持在79%，ASP.NET有小幅度下滑，Java小幅上升。

总而言之：

PHP是世界上最好的语言，没有之一！不是梗，也不是空穴来风。PHP是免费开源的、WEB开发全球使用最多、生态最好、维护成本也是最低的一种网站服务端开发语言，所以做网站编程开发首选肯定是PHP，PHP也是学习周期最短，入门最容易的一门编程语言，不像Java、Python、.NET等需要一定的学历，另外也是最好找工作的一门语言。

我们再来看看有哪些知名的网站使用的是PHP语言。

全部使用PHP的网站

php中文网

Smzdm

Asus

Nba

Pulzo

Getpocket

部分使用 PHP 的热门网站

Facebook

Wikipedia

Vk

WordPress

Pinterest

Ettoday

Instructure

腾讯

新浪

百度贴吧

网易

360

宝宝树

那我们学习PHP，要学习哪个版本呢？

我们来看下具体的统计：

从图中可以看出，PHP 5 和 PHP 7 是目前的主流。尤其是 PHP 5，大有还能再战几年的势头，至于 PHP 4 和 3 可以说是已经被抛弃了。

从PHP7开始，性能更是质的提高！最新一个版本PHP7.4也在11月底公布了，具体可参考《PHP 7.4.0刚刚发布！一起看看有哪些新特性》。

PHP8也即将发布，每个新版本都朝着更好的PHP迈出了又一步，届时php会走的更远！