移动互联网下的轻应用的开发应该做些什么 ？
UC优视总裁 何小鹏
今年，招商银行信用卡中心配合腾讯力推自己的微信公众帐号，取得了不错的效果。很多朋友告诉我，他们都知道招商银行在微信上有个公众帐号能缴信用卡账单，但对推出更久的招商银行App却没什麽印象。
这个例子能说明，现在新进入移动互联网的创业者或传统企业，也许更应该考虑的是怎么合理利用超级App、生成轻应用来导入和激活用户，而不是从零开始建设“基础设施”。
这篇文章就从产品层面出发，与各位探讨一下轻应用的开发。
老兵增值，新兵突击
我在《轻应用，不只是Web App》中提到，轻应用能提供立体高效的分发体系，并大幅降低开发成本。所以理论上说，除了对系统...全部
UC优视总裁 何小鹏
今年，招商银行信用卡中心配合腾讯力推自己的微信公众帐号，取得了不错的效果。很多朋友告诉我，他们都知道招商银行在微信上有个公众帐号能缴信用卡账单，但对推出更久的招商银行App却没什麽印象。
这个例子能说明，现在新进入移动互联网的创业者或传统企业，也许更应该考虑的是怎么合理利用超级App、生成轻应用来导入和激活用户，而不是从零开始建设“基础设施”。
这篇文章就从产品层面出发，与各位探讨一下轻应用的开发。
老兵增值，新兵突击
我在《轻应用，不只是Web App》中提到，轻应用能提供立体高效的分发体系，并大幅降低开发成本。所以理论上说，除了对系统底层能力要求极高的应用(例如3D动画制作)，其他的都 应该考虑布局轻应用——它是已经占据移动互联网山头的Apps另一个重要增量渠道，新进者、长尾应用则可以把轻应用作为主打产品形态。
前者属于原有品牌基础上的二次增值。而长远来看，我认为后者会是轻应用生态的规模主体，包括传统企业的移动信息化(轻企业应用)、HTML5游戏(轻游戏)以及中小PC互联网服务商的迁移，建议大家多关注。
先说轻企业应用。照现在形势来看，传统企业针对各式各样的硬件开发Native App，然后自己做发行和活跃，真的很不容易，也没必要。
举个例子，假设某个著名旅游景点需要做个移动应用，供用户查询信息、订门票。
如果做Native App，之前的思路是“研发——推广营销——获取用户(安装)——提升活跃度——盈利”，整个链条节点是串联的，前者是后者的必要前提，每个环节用户和效益都会出现流失。
但如果做的是轻应用，就能让其中几个环节的关系转化为“并行”。
例如这个景点的Web App开发完成后，可以接入UC浏览器的网页应用中心免费推广，也可以付费到搜索引擎、门户网站、流量联盟或导航站推广，用户点击链接就能访问到相应的服 务界面(所点即所得)，有进一步需求的用户形成付费购买行为(盈利)。
而不管付费与否，这个轻应用都可以通过UC+应用书签等方式，提示用户保存，方便二 次使用(用户获取、活跃度提升)。
以上例子中， “盈利”和“获取用户”、“提升活跃度”就是并行关系——你的流量推广，不必先获取到用户后再进行盈利，而是在需求产生时立刻就能获得收益，并将这个用户转化为你的长期活跃用户。
未来，UC会推出更成熟的基于浏览器的企业移动信息化方案，提供更多更透明的开放接口，可以很傻瓜式地定制一个轻应用，包含程序图标、启动画面、首页和 菜单等元素。同时，我们会不断提升安全等级来保障用户和服务之间的交互安全，例如针对开放性的Wi-Fi热点进行数据加密、大量内核级别的数据安全优化 (防止恶意存储等)、与支付宝及银联合作的安全支付等，未来还会在U3内核基础上推出更多的安全特性。
这样一来，不管是大型传统企业还是路边的小商店，都 有机会低成本、高效地拥抱移动互联网。
再说轻游戏。我认为明年是创业团队进入HTML5游戏最好时间点，原因有4个：
1)性能大幅提升。
这主要得益于超级App对手机硬件调用能力的提升，例如UC浏览器从9。3版本起，后面3个版本都会加强对HTML5的支持，通过硬件能力和算法优化，很快可以将整体执行的效率提升为现在的3～5倍，超过Chrome等浏览器；
2)开发与发行环境成熟。
各大巨头甚至创业企业都已经开始推出成型的HTML5游戏开发调试工具，超级App则强化了发行渠道；
3)产业起步阶段，厂商和项目还比较少，马上就要进入抢滩期；
4)多屏互动会在明年初步崛起，游戏在PC、手机、平板甚至电视上的跨平台一定是大趋势。
而HTML5在跨平台快速开发方面，有很大的优势。
最后是PC互联网服务的迁移。大部分中小互联网服务商其实都明白，移动互联网必须要进去，但另一方面Native App已被证明是事倍功半的模式，大家过得都很辛苦。
而轻应用体现的是资源的个体化特性，一本书、一部电视剧、一个自媒体，再小的内容个体都能成为一个轻 应用——换句话说，借助超级App，轻应用剔除了一笔可观的推广、研发费用，帮助开发者回归到最核心的内容层面。
毕竟许多用户最关注的并不是应用本身，而 是好的内容，只要有好的内容和服务，无论开发者处于哪个平台，都会受到用户的支持。很显然，对于众多开支有限的中小PC互联网服务商来说，轻应用是比 Native App更适合拥抱移动互联网的载体。
具体形态方面，我建议新进入者最好使用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的开放接口和适用场景，针对性地设计某种交互提醒方式，精确地去影响用户，这样才算得上是“平滑的需求-消费路径”。
http://www。sarft。net/a/139987。aspx。收起
