注：本文为极客公园观察家 UC优视总裁何小鹏对近日流行的轻应用概念的解读系列的第三篇。

今年，招商银行信用卡中心配合腾讯力推自己的微信公众帐号，取得了不错的效果。很多朋友告诉我，他们都知道招商银行在微信上有个公众帐号能缴信用卡账单，但对推出更久的招商银行 App 却没什麽印象。

这个例子能说明，现在新进入移动互联网的创业者或传统企业，也许更应该考虑的是怎么合理利用超级 App、生成轻应用来导入和激活用户，而不是从零开始建设“基础设施”。

这篇文章就从产品层面出发，与各位探讨一下轻应用的开发。

老兵增值，新兵突击

我在《轻应用，不只是Web App》中提到，轻应用能提供立体高效的分发体系，并大幅降低开发成本。所以理论上说，除了对系统底层能力要求极高的应用（例如 3D 动画制作），其他的都应该考虑布局轻应用——它是已经占据移动互联网山头的 Apps 另一个重要增量渠道，新进者、长尾应用则可以把轻应用作为主打产品形态。

前者属于原有品牌基础上的二次增值。而长远来看，我认为后者会是轻应用生态的规模主体，包括传统企业的移动信息化（轻企业应用）、HTML5游戏（轻游戏）以及中小 PC 互联网服务商的迁移，建议大家多关注。

先说轻企业应用

照现在形势来看，传统企业针对各式各样的硬件开发 Native App，然后自己做发行和活跃，真的很不容易，也没必要。

举个例子，假设某个著名旅游景点需要做个移动应用，供用户查询信息、订门票。如果做 Native App，之前的思路是“研发——推广营销——获取用户（安装）——提升活跃度——盈利”，整个链条节点是串联的，前者是后者的必要前提，每个环节用户和效益都会出现流失。

但如果做的是轻应用，就能让其中几个环节的关系转化为“并行”。例如这个景点的 Web App 开发完成后，可以接入 UC 浏览器的网页应用中心免费推广，也可以付费到搜索引擎、门户网站、流量联盟或导航站推广，用户点击链接就能访问到相应的服务界面（所点即所得），有进一步需求的用户形成付费购买行为（盈利）。而不管付费与否，这个轻应用都可以通过 UC+ 应用书签等方式，提示用户保存，方便二次使用（用户获取、活跃度提升）。

以上例子中， “盈利”和“获取用户”、“提升活跃度”就是并行关系——你的流量推广，不必先获取到用户后再进行盈利，而是在需求产生时立刻就能获得收益，并将这个用户转化为你的长期活跃用户。

未来，UC 会推出更成熟的基于浏览器的企业移动信息化方案，提供更多更透明的开放接口，可以很傻瓜式地定制一个轻应用，包含程序图标、启动画面、首页和菜单等元素。同时，我们会不断提升安全等级来保障用户和服务之间的交互安全，例如针对开放性的 Wi-Fi 热点进行数据加密、大量内核级别的数据安全优化（防止恶意存储等）、与支付宝及银联合作的安全支付等，未来还会在 U3 内核基础上推出更多的安全特性。这样一来，不管是大型传统企业还是路边的小商店，都有机会低成本、高效地拥抱移动互联网。

再说轻游戏

我认为明年是创业团队进入 HTML5 游戏最好时间点，原因有 4 个：

性能大幅提升。这主要得益于超级 App 对手机硬件调用能力的提升，例如 UC 浏览器从 9.3 版本起，后面 3 个版本都会加强对 HTML5 的支持，通过硬件能力和算法优化，很快可以将整体执行的效率提升为现在的 3～5 倍，超过 Chrome 等浏览器；

开发与发行环境成熟。各大巨头甚至创业企业都已经开始推出成型的HTML5游戏开发调试工具，超级App则强化了发行渠道；

产业起步阶段，厂商和项目还比较少，马上就要进入抢滩期；

多屏互动会在明年初步崛起，游戏在 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 的开放接口和适用场景，针对性地设计某种交互提醒方式，精确地去影响用户，这样才算得上是“平滑的需求-消费路径”。

例如，以后用浏览器打开一个日文网站，可能就会弹出一个翻译插件的提醒，问用户是否需要使用，或者“双十一”马上要到了，用户打开一个电商产品页面，就会推荐一个智能比价用的插件。这些例子中，超级 App 的信息浏览主需求与插件的特定场景调用是紧密结合的上下游关系，符合精确触发的原则，就是一种比较理想的激活流程。

Web App：活用能力

而针对 Web App，我建议开发者在开发过程中关注以下几点：

1. 采用响应式的基础设计

简而言之，就是同样一个应用，在用不同终端访问时，能根据屏幕比例等环境自适应，展现不同的交互界面。因为将来的互联网服务必是跨屏的，涵盖的终端包括 PC、手机、平板和电视等，最近小米力推智能电视民生信用卡中心营销岗，遵循的就是这个大趋势。采用响应式设计后，一能降低部署、运营成本，二能让用户在不同设备之间无缝迁移服务，试想一下：用户用手机浏览网站时，无意中进入到一个商品购买页，然后就能很简单地同步到电视或者平板上，切换终端的成本几乎为零。开发者不用再为每种屏幕都重启灶炉做个新版本，只需要简单地“同步一下”。

2. 增强离线能力

这一点主要针对 Web App，利用 App Cache、Local Storage 等技术，将主体框架离线缓存至本地，同时采取一定的联网更新策略，这样基本上就能很好地解决访问速度和体验上的很多问题。目前这方面做得比较成熟的当属 Google，Gmail、Google Docs 等应用在移动端都有很好的体验。

3. 合理使用推送能力

Web App、插件、公众帐号如果获得系统级的推送能力，就能具备与 Native App 基本一致的能力和体验，增大运营空间，理论上所有的轻应用都应该考虑整合这种能力，包括前文中提到的智能推

来源【写作训练营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！