这几年在三家企业都使用 app 內建 web server 的技术方案。效果很好。
该方案顾名思义，就是在 app 中加入一个 embed webserver 组件。组件和app运行于同一进程空间。程序启动时，该嵌入式web服务器即自动启动。程序结束时该web服务器也结束。
该方式具有以下优势：
1.定制性好。最早设计该方案是在 2014 年，当时的公司搞了一堆小游戏，都是网页版的，后来要将其包装为 app。这些网页是公司重要资源，不能泄露源码。所以我将其加密压缩成了一个巨大的资源文件！！静态服务器在接收浏览器请求时，从压缩文件中解压解密得到字节流并输出。这个解密的过程在 app 中完成，用户无从得知其格式。这段代码类似于 tomcat 的 filter，使用 native 实现。
2.支持 ajax。在很多浏览器中，使用 file:/// 打开的网页中 ajax 是无法工作的。该方式下浏览器接触的是 http 协议，故可以正常使用 ajax 功能！！
之前还遇到过一个商品描述为 html 代码的场景，html中含有图片信息，这种情形 webview 没有合适的主机地址，图片资源无法打开。我让人以cgi的方式编写了一个特殊的 /echo 代码：webview 将html post 到该 /echo 网址，echo 原封不动的输出该 html，webview 即获得了合法有效的主机地址。最后通过阅读 webview 文档该问题也得到了解决，不过使用嵌入式 web 服务器也是一个行之有效的办法。
3. 通过转发可以成为 remote webserver 的代理服务器。用户在 webview 中对 embed server 提交表单，embed server 将部分请求转发到真正的 remote server。实现了本地资源和远程资源有机混合。
4. 作为代理服务器可提供cache功能！由于用户不能察觉其请求的是远程资源还是本地资源，有时为了节约用户带宽，可以将远程数据cache到本地，用户从本地即可获取。虽然浏览器自身支持 cache，但浏览器cache不可控，灵活性不如本方案。采用本方案后，像视频等离线下载活动，可以归结为 embed server 的cache，不需要另外编写离线资源存储模块！！之前使用过的一个技巧：不需要cache的远程资源，直接访问远程地址，需要cache的，访问 localhost。
5. 如上， cache 可以加密。
6. 作为代理服务器支持重发！！！有时网络故障等造成请求没有发送到远程服务器，在以往场景需要js处理，但是网页自己也会被关闭，网页关闭后其 js 会不再活动。而在本方案中，请求是提交到嵌入式 web server 的，embed webserver 可以根据情况（可扩充 request header 增加重发注解）决定是否反复提交到成功为止！！
ASK：为何不使用 phonegap 方案？
RE：@_@ 我上面白说了吗？
ASK：是否能形成一个颠覆 phonegap 的产品？
RE：你以为我不想，要是有人愿意欢迎一起干