2017/10/23 11:11:50

目前这小半年都在用PHP做一些爬虫类的活儿,回想起来PHP强大的web内容处理让我工作的很高效,可以在目前业界没有通用方案可以参考的前提下很快摸索出合适的方案。我也对PHP的一些优缺点有了进一步的看法,这些观点我可能在别的社区阐述过,这里就稍微整理一下加深我对PHP的理解。

"#"缺点

  1. PHP最大的缺点就是没有连接池,因为不是常驻内存。虽然可以选择第三方的连接池(一般来说这些连接池也兼有读写分离的功能),不过应用级别的连接池真的很方便,也可以拿来做缓存,当然了PHP有基于共享内存的缓存方案比如:apc(最新的是apcu了)和yac(无锁高速缓存,但是数据可能破坏)可以一定程度缓解这个问题,SwooleReactPHP等异步常驻内存方案抛弃了PHP易于部署的特性而且不太成熟也很难采用。
  2. 异常和warning/error混在一起,就算PHP 7也没有完全解决这个问题。框架为了解决这个问题可能会去设置error_handler或者shutdown_handler之类的来做自己的异常抛出处理,我写的最大4k行级别的代码大量使用异常机制倒是没遇到坑,但是果然还是希望能把所有的warning/error抛出成异常。
  3. 运行时还不够强大,包括垃圾回收和没有jit,很多时候需要靠重启进程来解决垃圾回收问题,当然了脚本语言有jit的不多。而PHP的第二次jit尝试提高也很少。
  4. 社区对Laravel这种过度设计+速度慢,连单步调试都做不到的框架(谁能用xdebug能跳进那些充满闭包回调的总线/命令呢)的追捧。
  5. 一些扩展只支持linux,比如pcntlswoole,这就导致了习惯win下开发的我很难采用这些扩展。
  6. 扩展对多线程支持的不稳定,导致不敢用多线程。
2017/10/08 14:08:50


zendAPI 是对 Zend Engine 的 C 接口使用 C++ 的最新标准 C++11 进行而面向对象的封装,从而屏蔽了底层 Zend Engine API 的接口复杂性,加快开发 PHP 扩展的效率。从而让 PHP 的扩展开发成为一种享受,不用再考虑不同 PHP 版本带来的差异性,彻底将开发者从 Zend Engine 底层接口的细节中解放出来,让开发者专注于自身的业务逻辑。

"#"项目的使命:

让 PHP 扩展开发成为一种享受

2017/09/14 17:38:27

zendapi项目的爱好者大家好,谢谢大家对项目的关注,经过大概3个月的紧张开发,现在咱们的项目正式进入了一个小小的里程碑,正式进入主流平台的编译测试,详细计划如下:

第一期测试我们的目标操作系统如下:(架构都为x86_64,不支持32位操作系统)

  1. openSUSE-Leap 42.3
  2. CentOS 7.0
  3. ubuntu 16.04.3-desktop-amd64
  4. debian-9.0.1-amd64
  5. macOS Sierra 10.12.6
2017/07/26 10:07:08

记得去年的这个时候,我刚来奇虎的时候,在研究 PHP 的时候无意之中发现了 PHP—CPP 这个项目,立刻就被她吸引了,原来 PHP 的扩展居然还可以这样去实现,以一种面向对象的方式去开发,我感觉这个是个很好的开头。中间辗转反侧,我也尝试了两个项目,一个是 TOPJS 现在暂时停止了,另一个是 qingeditor,同样暂停开发,折腾最终我也是觉得在 PHP 领域做点东西,所以开始构思 zendAPI。

我现在的情况是:

  1. 我从未开发过 c++ 项目
  2. 我从来没有开发过 PHP 扩展
  3. 我需要一个由我控制的项目,实施自己的想法,可能不成熟
2017/07/21 10:43:47

因为时间有限,开发在每天的上午6点到9点,晚上9点到12点以及周末,所以项目周期可能比正常的要长一点,我的计划如下:

"#"7月到8月完成对 zend engine 的一些核心数据库的封装

这个阶段主要针对 zend engine 一些常用的数据接口做一些面向对象的封装,比如用的最多的 HashTable, zendAPI 会为其提供一个STL风格的迭代器进行数据访问,常见的 HashTable 的访问语义接口,方面开发者的日常调用, 避免用到类型不安全的宏调用。