快应用之开发体验纪要

（点击上方公众号，可快速关注）

来源：静晴轩别苑

https://nice.lovejade.cn/zh/article/develop-quick-app-experience-notes.html

何谓「快应用」呢？它是基于手机硬件平台的新型应用形态，标准是由主流手机厂商组成的快应用联盟联合制定。其标准的诞生将在研发接口、能力接入、开发者服务等层面建设标准平台，以平台化的生态模式对个人开发者和企业开发者全品类开放。快应用具备传统 APP 完整的应用体验，无需安装、即点即用； 覆盖 10 亿设备，与操作系统深度集成，探索新型应用场景。快应用 ──复杂生活的简单答案，让生活更顺畅 ── 来自 快应用官方网站 | 倾城之链。

快应用特点

下面列出些关于「快应用」特点，这将有助于对它有更深刻的理解；

• 基于手机硬件平台，标准由主流手机厂商组成的快应用联盟制定;

• 无需安装、即点即用，且具备传统 APP 完整的应用体验;

• 与操作系统深度集成，一键直达;

• 更新直接推送，新版本直接更新到后台，用户无感知快应用的技术实现;

• 基于前端技术栈开发、可快速迭代;

• 通过全新的引擎，将系统原生的渲染机制和接口能力提供给上层应用;

• 运行在框架应用进程中，对每个快应用会开一个 Launcher 进程快应用的开发、发布和使用流程;

• 开发者需要在快应用官网注册，上传至快应用官网，测试并通过审核后即可进行分发;

• 使用前端技术栈进行开发，经过编译、签名后最终产出 rpk 文件;

• 开发者需登录快应用官网进行上传和发布，发布前会经过审核快应用与小程序的对比;

• 快应用使用 native 渲染，性能体验会比较好，而小程序是使用 webview 渲染 ;

• 快应用的系统级能力更强，能调用更多系统级 API;

与小程序对比

以上这些比对，皆是从两者的出生角度而言；可以肯定的是，「快应用」得益于其与生俱来的优势，将在更多应用场景发挥作用，它的崛起，将会给 Android 用户带来更多的便捷。同时作为后起之秀，其开发体验上，是明显优于小程序的；但目前的小程序，已经有长足的发展，而「快应用」才处于刚起步阶段，在经验累积、应用数量、分发传播、社区建设等方面，两者之间还存在些差距；后续故事将会如何，让我们将拭目以待。

开发 & 调试

环境搭建

• 鉴于「快应用」基于前端技术栈来开发，因此需要安装 Node.js (>= 6.0)；yarn （推荐使用）。

• 安装 hap-toolkit ；它是针对「快应用」衍生出的开发者工具；

yarn global add hap-toolkit

// 检测是否成功安装 hap-toolkit

hap -V

• 手机安装「快应用」调试器 ── 一个 Android 应用程序，它可以连接到手机系统内的快应用执行环境，包含扫码安装、本地安装、在线更新、开始调试、等功能；

扫码安装：配置 HTTP 服务器地址，下载 rpk 包，并唤起平台运行 rpk 包；

本地安装：选择手机文件系统中的 rpk 包，并唤起平台运行 rpk 包；

在线更新：重新发送 HTTP 请求，更新 rpk 包，并唤起平台运行 rpk 包；

开始调试：唤起平台运行 rpk 包，并启动远程调试工具；

备注：当您的手机系统尚未内置快应用运行平台，或您想在开发过程中体验快应用尚未正式发布的新功能、新特性，您可以安装 快应用预览版,这是一个包含了快应用基础功能的 Android 应用程序。下载安装成功后，通过快应用调试器可以选择在快应用预览版运行 rpk包，开发测试对应平台的 api 和功能。更详细的叙述，请参见快应用开发文档 | 环境搭建 。

开发环境

在「快应用」中，对代码编辑配置做了说明；你可以使用 VsCode、Sublime Text、WebStorm 等工具来开发。鉴于官方针对 VsCode 推出了 Hap Extension 扩展，这里推荐使用 VsCode 来编写快应用代码（据悉，专门用于开发「快应用」的编辑器，尚在开发中 18-08-15）。

开发调试

在开发文档调试工具一节，对此有详细说明；从一般性开发角度总结而言，只需运行以下两个命令: npm run server 和 npm run watch；前者会在终端会输出一个二维码，用手机上启动快应用调试器，点击扫码安装扫描，即可下载安装 apk 包，并运行之；而后者将会启动文件监视器，每次修改工程文件时，会自动编译并在手机端刷新，速度蛮快；至于日志查看，可利用 devtools 调试界面 console 输出，也可利用 adb 工具，在终端进行查看：

adb logcat -s JsConsole

快应用示例

在安装 Toolkit 工具后，可通过全局 hap 命令创建一个项目模板，如下所示：

hap init <YourProjectName>

鉴于其内置的 Demo 项目示例，尚处于入门级项目设定(@18-08)，不便于用户着手开发，且不利于高效编写、维护；因此，有将编写的快应用 nicelinks-quick-app 开源，借此以探索新型应用设计；此外，也是在探索如何构建优质快应用，希望可以在此事儿上提供些参考。其代码组织结构如下：

有必要谈及的是，此项目秉承在高效开发 Web 单页应用解决方案中所传递的理念：为高效开发而设计；相比于内置 Demo，她具有以下诸多优点：

• 对项目结构进行优化；如上组织结构所示，将各资源模块，更专业的分门别类，使之可以便捷的去编写、维护、查找，同时也是基于前端开发既定共识去设计，更容易为初接触者所理解 & 上手；

• 更优雅的处理数据请求；采用 Promise 对系统内置请求 @system.fetch 进行封装，并抛出至全局，使得可以极简的进行链式调用，同时便捷地处理返回数据；

• 内置了样式处理方案；「快应用」支持 less, sass 的预编译；这里采取 less 方案，并内置了部分变量，以及常用混合方法，使得可以轻松开启样式编写、复用、修改等；

• 优化本地开发端口设定；「快应用」默认端口为 12306，虽说可自定义端口，但使用体验却不够友好；此处参考 creat-react-app 设定，对本地开发地址端口使用进行优化：如果?️定端口(默认: 8080)被占用，则向上递增寻找新的可用端口(如：8081 / 8082 / … )；

• 浏览器打开调试主页二维码；运行 npm run server，会启动 HTTP 调试服务器，并将该地址在命令行终端显示，手机端用快应用调试器扫码，即可下载并运行 rpk 包；当终端积累的信息流多了，就造成扫码不便；故增设在浏览器打开调试主页二维码；如想不使用此功能，在 command/server.js 文件中，将 autoOpenBrowser 设置为 false 即可；

• 会持续探究，逐步将更多好用姿势集成 ……

关于快应用の发布

关于快应用发布，有必要谈下的理由是，其发布流程说简单却也复杂，说快也慢；这是因为涉及多家厂商，且有着不同规则，导致变数横生；倘若经历过之后，这个流程就可以描述为：说复杂也简单，说慢也快；就以个人开发者来聊下相关经验：

• 首先需要开发一款快应用；务必确认好 minPlatformVersion 版本，应用命名称也该有所考究，最好都是中文(利推广)；

• 快应用官网注册，完善相关资料之后(须手持身份证反面照片，需清晰)，即可创建 & 提交你的快应用（有些资料要填写）；

• 厂商审核；对于华为、OPPO、小米等厂商，必须先绑定其开放者账号才可以（Vivo 无需），所以得先到厂商注册，并绑定账号；

• 绑定账号，应用提交之后，接下来就是坐等；不同平台审核结果许有不同：如华为还需上传免责函签名至版权处等等；

• 修正审核提到的问题，如指出应用提交分类错误(HuaWei)、应用界面单一、功能过于简单(OPPO)等，继续提交，坐等即可(速度还行)；

个人开发的倾城之链-快应用版(https://github.com/nicejade/nicelinks-quick-app)已于 09-05 日，发布上架；目前在 Vivo 厂商已审核通过，可在支持快应用手机的负一屏、浏览器等搜索倾城之链即可率先体验，之后将持续迭代升级，敬请期待。

快应用存在的缺陷

从上面快应用特点，应该对其优点有所感受；接下来不妨‘揣测’下它或将是缺陷的存在（当然，在年与时驰间，随着版本的不断迭代升级，某些现在看来是缺陷，日后兴许就荡然无存，也说不定）。

• 若要运行「快应用」，须要手机出厂时在底层支持；否则就须要先安装平台预览版;

• 使用前端技术栈开发，native 渲染，标签、样式、功能等都需要一一映射处理，目前来看支持不够完善；长期迭代情况将会好转；

• 暂不支持使用主流前端框架（Eg: vue、react）进行开发，且很多功能需要填补；长期迭代情况将会好转；

• 相比于其他‘竞品’而言，文档、周围生态系统、等都需要亟待完善；长期迭代情况将会好转；

• 由国内 Android 手机厂商联合推出的，不支持 IOS 操作系统，目测以后也无法给予支持；

• 社交：「快应用」缺乏微信的社交场景能力和传播手段，推广拉新，成本不低；再有上一条先天不足，现在来看，不容乐观。

• ……

如何看待「快应用」?

就目前来看，在移动设备市场，充盈各种类型的应用，大有“诸子百家争鸣”之基础；以技术栈来分，有原生型、混合型、Web 型、小程序、「快应用」…… 百花齐放；从类别上看，有支付宝这般丰富的超级 App，亦有许多精品级小众应用；就用户而言，不仅能享受其便捷性，同时也能体验市场的多元化；而各种不同类型应用间良性竞争，对更一步改善用户体验也是大有裨益。如此，看来「快应用」的诞生，从外部环境来看，有其成长的土壤；而具有体量的公司都参与的事情（如闪充、全面屏），便是不错的趋势，至少不会输，受影响的是旧的模式 ── 原生应用。

出于业务需求以及用户拉新等方面诉求，Native VS Web 这个由来已久之争，如今愈发向前端技术栈倾斜，且已占上风；虽然说，技术的发展，同时有给 Native 和 Web 两种模式，都提供了利好（对 Web，硬件提升使得体验越来越好；于 Native，越来越大的存储空间使得用户装 APP 成本下降），但“即点即用”这种快捷模式的横空出世，附带以前端技术栈开发的低成本，将打破固有局面，修改用户原有习惯，从而渐变整个格局。

谈及「快应用」，微信小程序是无法绕过的点；两者肯定存在竞争关系，同时也可算是伙伴：如同两部同时上映的电影，虽有竞争，也会是彼此之助力，共同把盘子做大，吸引更多的用户倾斜，从而变更未来的应用格局。再有，都是基于前端技术栈，如能有互转工具给予铺成，对于开发者而言，即可实现一次编写，多平台运行；将会为这种模式提升更多竞争力。

上面已经从出生层面，对「快应用」和小程序做了对比；「快应用」使用 Native 渲染，而非小程序基于 Webview 渲染，再加上硬件资源扶持，体验上则能更上一层楼。况且，对于已经司空见惯的事物，新鲜感在如今看来，也极具诱惑，如子弹短信的出现；就小程序而言目前火热程度，已有百万应用，渐成垄断之势，从过往历史来看，这对于用户来讲，绝不都是好事；而对于开发商来说，也尽是受制于人(腾讯有绝对控制权)，无法主导自己命运，多个渠道，则多份活路；况且，兵无常势，水无常形，在大时代的拉锯之下，微信又岂会是永恒的王者？独立的才是自己的，而小程序并不提供这方面红利；对于个人开发者来讲，加入「快应用」阵营，借助厂商流量扶持，为自己独立平台倒量，不失为更明智的抉择；现在来看「快应用」，机遇与挑战并存，未来它将如何，朋友你怎么看？

【关于投稿】

如果大家有原创好文投稿，请直接给公号发送留言。

① 留言格式：
【投稿】+《 文章标题》+ 文章链接

② 示例：
【投稿】《不要自称是程序员，我十多年的 IT 职场总结》：http://blog.jobbole.com/94148/

③ 最后请附上您的个人简介哈~

觉得本文对你有帮助？请分享给更多人

关注「前端大全」，提升前端技能