之前有在群里看到人说，有一些 Swoole 框架启动速度慢，尤其是挂载的网络硬盘下运行尤其的慢。
我想，由于 Swoole 可以让 PHP 应用实现常驻内存，所以启动时候势必要扫描和加载许多文件，这应该是导致启动速度慢的罪魁祸首。
想到 php 还有 phar 包这个东西，我试图用 phar 来解决这个问题。功夫不负有心人，我终于为imi框架实现了 phar 打包的兼容和支持，测试结果表明：
使用 Phar 进行文件枚举、读取、include，无论是在本地硬盘还是 Samba 等网络文件共享挂载，性能都比零散的文件性能更强。
刚刚一个群里有人引出了 PHP 数组和对象占用内存谁多谁少的问题。我想起之前我好像也测试过这个问题，和群里人说的对象比数组节省内存的结论相反，我得出的是数组比对象节省内存。
但今天，我想说，这两种说法都不对！！！
点进去看吧，代码……
先来讲讲目前的场景吧，目前已有的api项目是跑在apache下的，接下来打算新的业务接口上swoole+imi。为了保证不给前端那边造成困扰，打算新老接口，都用同一个域名（api.xxx.com）。
这时候就需要Nginx了，之前说实话没怎么用过，研究了一下，暂时没什么问题。把配置发出来，供大家参考，也是给自己做一个记录。
作为一个开源作者，我开发的类库、框架想要本地开发并测试，一般框架demo是单独一个项目。我demo项目想要通过composer引用框架，一般需要推送到git上才可以。找了半天，终于找到可以引入本地文件夹的办法了。
IMI 是基于 Swoole 开发的协程 PHP 开发框架，拥有常驻内存、协程异步非阻塞IO等优点。
IMI 框架文档丰富，上手容易，致力于让开发者跟使用传统 MVC 框架一样顺手。
IMI 框架底层开发使用了强类型，易维护，性能更强。支持 Aop ，支持使用注解和配置文件注入，完全遵守 PSR-3、4、7、11、15、16 标准规范。
框架的扩展性强，开发者可以根据实际需求，自行开发相关驱动进行扩展。不止于框架本身提供的功能和组件！
我们认为一个框架不仅需要代码健壮、简单易用，文档也是十分重要，所以文档的完善是我们工作的重点，相信一个好的文档能够让你事半功倍！
借助这篇文章，我希望能够把 Swoole 安利给更多人。虽然 Swoole 可能目前定位是一些高级 phper 的玩具，让中低级望而生畏，可能对一些应用场景也一脸懵逼，但其实没这么难的。
在 Swoole 官网的自我介绍是“面向生产环境的 PHP 异步网络通信引擎”，首先 Swoole 它是一个网络应用的开发工具，它支持 Http、TCP、UDP、WebSocket。
Swoole 和我们传统的 PHP 开发差别是有的，需要理解的概念也是有的。使用目前一些基于 Swoole 的框架开发的话，从开发习惯上和传统的TP、LV 框架相差不多。
那为什么要使用 Swoole？
宇润认为有以下几点：
常驻内存，避免重复加载带来的性能损耗，提升海量性能
协程异步，提高对 I/O 密集型场景并发处理能力（如：微信开发、支付、登录等）
方便地开发 Http、WebSocket、TCP、UDP 等应用，可以与硬件通信
PHP 高性能微服务架构成为现实
Composer是PHP界的一个包管理器，一般大家只会用，可能不知道如何制作自己的Composer包。其实很简单，下面的图文教程就教你怎么做自己的Composer包。
“让前端开发简单而友好”是阿里对飞冰的介绍。
今天逛开源中国，看到飞冰的更新日志，第一次了解到飞冰。
下载飞冰安装后，简单使用后，感觉这太美妙了！我们做开发这行的，给公司给客户开发了这么多图形化的系统，提升工作效率，增加效益。但是我们自己日常用的工具，大多数却还是整天命令行命令行的……
