JSPatch成长之路.pptx

JSPatch 成长之路 大纲 • • • 起步 发展 下一步 起步 App 线上 bug 修复周期长，成本高 (测试-打包-发布-审核-用户下载) 问题 waxPatch 业界解决方案 线程不安全 停止开发 不支持Block 不支持64位 没有文档 没有测试用例 难以调试 审核风险 lua语言陌生 JavaScript 原生JavaScriptCore引擎 JS 语言终端应用广泛 符合审核规则 更好的解决方案 有没有人试过？ JavaScriptBridge 需要编译前定义所有接口 臃肿 实用性低 更好的解决方案 Rollout 非开源 写法复杂 更好的解决方案 UIView.alloc() JavaScriptCore className “UIView” methodName “alloc” ObjC Runtime Call [UIView alloc] 核心问题 期望的效果: 核心问题 语言规则：必须已经是对象成员函数 OC 遍历UIView方法 JS 构建UIView对象 UIView.alloc() 调用 • • 方法太多 (NSObject 实例方法830个 类方法118个) 占用内存高 (NSObject 1.3M, UIView 2M) 核心问题 每一个类和方法都要事先定义好： 优化？ • • 去除私有方法 JS构建继承链公用基类方法 ✕ 占用内存依旧很高 思维定势 必须遵守语言规则 核心问题 UIView.alloc() UIView.__c(“alloc”)() • • 正则替换代码 __c() 函数：模拟 Ruby/Lua 元方法机制 效果: • • 简洁 高效 内存占用 ↓99% UIView.__c(“alloc” )() UIView.alloc() 调用OC方法 调用JS方法 UIView是OC对象 是 否 核心问题 预编译 • • • • • 调用/替换OC方法 支持64位 支持block 完整参数类型支持 (C指针 / Class / id* / struct) 支持C函数调用 …… 完善功能 /bang590/JSPatch/wiki 发展 降低使用门槛 提高使用效率 如何做得更好？ Keep it simple and tiny 保持精巧，保持好用 易用性 安全问题 权限大，第三方攻击危害大 方案一：对称加密脚本，固定密钥 • • 优点：简单 缺点：密钥存客户端，易被破解 安全策略 方案二：https传输 • • 优点：安全性高 缺点：门槛高，部署繁琐 方案三：RSA签名验证 安全策略 私钥 脚本文件 MD5值 加密 MD5值 MD5值 解密 公钥 加密MD5值 脚本文件 加密MD5值 服务端 脚本文件 客户端 校验 1 2 3 4 5 6 优点：门槛低，通用性高，部署简单，安全性高 JPLoader 安全策略 后台搭建麻烦 JSPatch 平台 问题：如何支撑高并发？ JSPatch平台 JSPatch平台 平台用户 APP客户端 平台服务端 平台数据库 … App请求 App接收 服务端CGI 处理请求参数 读取DB数据 组装数据返回 JSPatch平台 静态资源服务器 平台用户 平台服务端 返回json App请求 静态资源服务器 {v:10} App接收 ① … APP客户端 ① 文件名：{appKey} 内容：{v:10} 转换代码效率低 人工翻译整个方法内容 JSPatch Convertor 提高使用效率 • • • • 保证易用性 JSPatch 安全方案 (JPLoader) JSPatch 平台 完善的文档 / 原理解析文章 • • JSPatch Convertor Extensions 总结 降低使用门槛 超过 2500 个 APP 已接入使用 下一步 React Native / Weex • • • 前端 - 终端 (学习成本) 大型(环境配置，包大小) 组件 坑 JSPatch • • • 学习成本低 微型 复用所有 OC 组件，坑少 使用JSPatch开发功能模块 开发效率 运行效率 问题 开发效率 JSPatchX 代码补全 开发效率 PlayGround 即时刷新 运行效率 确定瓶颈 进入 __c 调用 JS 方法 转换参数 callSelector 字符串转 Class Selector 调用 JPForwardInvocation 包装/转换参数 转换返回值类型 JS拿到返回值 调用结束 运行效率 进入 __c 调用 JS 方法 转换参数 callSelector 字符串转 Class Selector 调用 JPForwardInvocation 包