你这个 project 别人 100%是跑不起来的，因为它依赖了一个特定的 IDE ，而且没有使用任何构建技术，你在 gitignore 中的配置又忽略了.jar ，对于你目前的情况这实际就是忽略了依赖。

先去研究下 maven/gradle ，这样可以保证不管别人是用 eclipse 还是 jb 家的编辑器，甚至 vim/atom 这样的文本编辑器，构建和运行你的项目都是没有任何问题的。

喜马拉雅的还没有看到更新,难道那儿也是非授权转载?

Postman ?

冷藏仓库

@gzxultra /t/178591 用了好久了，以前也发过贴
感觉 retina 屏录出来的效果都是这个样子

@kutata 看样子像是 licecap 录出来的.

@koor
@vibbow
@aisk
并不是，从 native 的角度来说， worklight 的“应用内更新”可以简单理解为应用沙盒内数据的更新，比如某个地图应用的离线地图包，网络游戏的数据 patch ，这些资源文件的更新当然是不需要走 App Store 的，也是符合 apple 政策的；
如果需要客户端的页面一直保持最新，最简单的方式就是通过 webview 去请求一个外部的地址，通俗点就是“内嵌 H5 ”，这个可以参见淘宝，京东 app 的部分页面；
worklight 的 webview ，和淘宝京东的本质不同的一点是，所有 UI 层面的资源文件是已经压缩在应用内的，省去了外部请求>加载资源>渲染页面这个过程， app 端和服务端只有数据的交换。所以当表现层的资源需要更新时，就必须去请求服务器下载新的更新、解压。

这些概念并不是什么新鲜的技术， WL 本身也算是 phonegap 、 cordova 的高级封装， ionic 中也有类似的东西。

@yjxjn 韩国的 lotte

@hewigovens 根据目前的客户群,都是铁*部,**银行,lo**e,全是不差钱的金主
另外,中小企业并不一定适合这套东西.何况目前 hybrid 的选择也挺多

IBM Worklight 的 directUpdate 技术,升级的是 www 目录下的 HTML/JS/CSS 文件(目前的版本中这些资源文件都是经过加密的 zip),考虑到 App Store 的审核周期,这种机制还算比较适合 12306 这种快速迭代的应用,客户端更新是不走应用商店的.
至于 1.7M 这个文件大小,我们之前的 WL 应用确实也发现好多次是这个数值...特别是当需要更新的静态文件比较大的时候,应该是一个 WL 内部压缩文件算法的问题

@Perry MD101 还特么这么贵啊。