移动开发中的Web：WebView、WebKit、JSCore、Web 优化、热修复、跨平台……

随着 App 业务的不断发展，单纯的 Web 加载与渲染无法满足复杂的交互逻辑，如拍照、音视频、蓝牙、定位等，同时 App 内也需要统一的登录态、统一的分享逻辑以及支付逻辑等，所以针对第三方的 Web 页面，Native 需要注册相应的 JavaScript 接口供 Web 使用。

对于 Api 需要提供的能力、接口设计和文档规范，不同的业务逻辑和团队代码风格会有不同的定义，微信 JS-SDK 说明文档就是一个很好的例子。而脱离 JavaScript Open Api 对外的接口设计和封装，在内部的实现上也有一些通用的关键因素，这里简单列举几个：

注入方式和时机

对于 JavaScript 文件的注入，最简单的就是将 JS 文件打包到项目中，使用 WKWebView 提供的系统函数进行注入。这种方式无需网络加载，可以合理地选择注入时机，但是无法动态地进行修改和调整。而对于这部分业务需求需要经常调整的 App 来说，也可以把文件存储到 CDN，通过模板替换或者和 Web 合作者约定，在 Web 的 HTML 中通过 URL 的方式进行加载，这种方式虽然动态化程度较高，但是需要合作方的配合，同时对于 JS Api 也不能做到拆分地注入。

针对上面的两种方式的不足，一个较为合理的方式是 JavaScript 文件采用本地注入的方式，同时建立资源的动态更新系统(上文)。这样一方面支持了动态更新，同时也无需合作方的配合，对于不同的业务场景也可以拆分不同的 Api 进行注入，保证安全。

安全控制

JavaScript Open Api 设计实现的另一个重要方面，就是安全性的控制。由于完整的 Api 需要支持 Native 登录、Cookies 等较为敏感的信息获取，同时也支持一些对 UI 和体验影响较多的功能，如页面跳转、分享等，所以 App 需要一套权限分级的逻辑控制 Web 相关的接口调用，保证体验和安全。

常规的做法就是对 JavaScript Open Api 建立分级的管理，不同权限的 Web 页面只能调用各自权限内的接口。客户端通过 Domain 进行分级，同时支持动态拉取权限 Domain 白名单，灵活地配置 Web 页面的权限。在此基础上 App 内部也可以通过业务逻辑划分，在 Native 层面使用不同的容器加载页面，而容器根据业务逻辑的不同，注入不同的 JS 文件进行 Api 权限控制。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!