具体形态方面，我建议新进入者最好使用

 Web App 这种模式，成本更低。对于那些已

经做了

 App 的开发商，则可以考虑结合自己的产品特性，与 UC、微信、微博等超级 App 形

成基于需求链条上下游的互动，例如将

 Native App 转为 UC+ 中的插件，基于用户浏览网

页行为提供服务，获得更多的被调用场景；如果碍于产品特性无法进行这种互动，且用户
规模发展缓慢的，也建议转为

 Web App。

另外需要提一下

 Web App 的开发语言。过去说到 Web App 会是取代 Native App 的未来，

大家提的都是

 HTML5，似乎整个行业都在期待一场彻底的大革命。但如今其实通过

 

HTML4+JavaScript 的技术，再加上浏览器等超级 App 对于硬件调用能力的增强，也能够做
出能力非常出色的

 Web App，完全能够满足用户的需求。所以，开发者们不必太过拘泥于

 

HTML5 还是 HTML4（现阶段可能后者比较实际一些）。

插件：场景式触发

确定好产品大方向，就进入正式的开发阶段。因为

 UC+ 轻应用平台分为插件与 Web 

App 两大形态，所以我也分成两部分来谈一些做轻应用的具体建议。

首先对于插件，其实质就是一种

“基于超级 App 的 Native App”。与现在的封闭式 Native 

Apps 相比，我认为在设计上的最大不同点在于特定使用场景下的触发机制，包含从需求产
生，到内容、服务消费的完整路径，应该是完全贯通的，存在一种互动关系，其中涉及到轻
应用与超级

 App 的纵向调用，甚至不同轻应用之间的横向配合。

Super App+Light App 的扩展式架构能把用户的个性化选择权最大化，但开发者不能完

全指望用户完全主动地去勾选你的应用

——事实上大部分用户都不会这么做，因此轻应用

在开发过程中就应该充分利用超级

 App 的开放接口和适用场景，针对性地设计某种交互提

醒方式，精确地去影响用户，这样才算得上是

“平滑的需求-消费路径”。