国内私募机构九鼎控股打造APP，来就送20元现金领取地址：/phone.html
内部邀请码：C8E245J（不写邀请码，没有现金送） 国内私募机构九鼎控股打造，九鼎投资是在全国股份转让系统挂牌的公众公司，股票代码为430719，为“中国PE第一股”，市值超1000亿元。
--------------------------------------------------------
原文地址：/blog//06/26/inside-alipay-plugin.html
昨天看到唐巧分析了支付宝钱包插件的实现原理，今天也趁热打铁研究了一下支付宝插件的结构和代码，很多时候逆向思考也可以为自己积累很多有用的经验（即便实际实现方式和自己所想有出入）。
承接唐巧的上文，本文同样以彩票插件为例，如果你没有下载该插件的压缩包，用如下命令下载。
wget /mobilecsprod/alipay.mobile/0601021432806/xlarge/10000011.amr
并改为 zip 后缀，解压。
根目录
CERT：内容为各文件的特征值，特征值可以是重复 hash 和 salt 多次后 base64 的结果，解压插件后支付宝理应检查文件特征值以确定来源可靠Manifest.xml：插件的描述文件，都有注释，易懂，其中定义了业务包 ID、名称、介绍、版本等信息，也定义了版本兼容性、能力集、依赖关系、入口文件等
res
res：资源文件，仅有图标，奇怪的是代表 Android 尺寸的目录下没有文件，可能因为唐巧抓的包是 iOS 的？
www
www：前端代码，目录结构跟一般 Web 开发相似，其中 demo 下是 HTML 代码
demo
demo：HTML 代码，子目录都是拼音缩写，比如 ssq 代表双色球，根据Manifest.xml描述，index-alipay-native.html为插件入口页面
cp
唐巧打开index-alipay-native.html给大家看过了，你会发现 Cells 都是不能点的，因为页面尚未初始化，代码中可以看到形似<a rel="ssq/ssqbet.html">的代码。显然这代表双色球的子页面，我简单猜测一下用 rel 的原因：
首先，点击 Cell 在客户端触发的必然是 Native 的pushViewController:，用 href 同样可以通过webView:shouldStartLoadWithRequest:navigationType:触发，但这样会在某些意外情况下造成点击后页面直接跳转。此外如果最终是用形如push://10000011/ssq/ssqbet.html的协议来实现 Native 跳转，用 rel 再注入 JS 处理可以防止客户端逻辑的显式暴露（如长按、拷贝，曾经的新浪微博客户端长按评论可以看到类似 comment:// 的协议，不见得有多大危害，但是值得避免）
页面底部有如下代码：
略懂前端开发的话，果断猜测onDeviceReady()是在页面加载完毕后，由设备调用的初始化方法，于是尝试在 Console 中输入onDeviceReady()执行，点击 Cell，报错如下：
onDeviceReady
跟到nav.js里可以看到是在pushWindow中报错的，错误为alipay未定义，粗略判断alipay为客户端注入的变量，这里看到的调用形如alipay.navigation.pushWindow(obj.attr('rel'))用到了上述rel属性，最终应该会触发客户端类似[self pushWebControllerWithURL:url]的代码来推入下一个 VC，这位我们最终尝试实现能跑这个插件的 Demo 提供了一些思路。
用onDeviceReady可以完成大部分页面的初始化工作，如ssq/ssqbet.html，在浏览器里也能响应下拉机选操作，你会发现，这些插件的屏幕尺寸兼容性和浏览器兼容性极佳：
ssqbet
再如jczq/jczqmatch.html，甚至可以读到场次数据并完成数据初始化了
jczq
在这里我们又发现了两个有意思的信息，它们被写在 meta 信息里，根据字面，很容易理解，它们分别定义了navigationBar的title和rightBarButtonItem，以及点击rightBarButtonItem触发的 JS 函数。此时你如果比对着使用客户端就知道这个筛选对应着怎样的表现和交互，这些都为我们写 Demo 提供了线索。
尝试在 Console 输入rightBar（不带括号）查看其定义，又能得到很多有用的线索，比如点击rightBarButtonItem触发的是推入filterpage，这个filterpage则是在js/jczq/jczqmatch.js中定义的。
jczq
此外，结合jczqfilter.html的内容和rightBar函数，可以看到主页面利用 HTML5 的 localStorage 为 filter 页面提供了数据（这为纠结于 UIWebView 如何给 push 进来的下一个 View 提供数据的我，提供了很好的思路，值得借鉴）
不知不觉写了 2 个多小时了，发现通过文字表达出来要比分析本身还费时。不过，至此，支付宝插件的大体框架已经比较清晰了，和 Native Code 的交互方式、数据传递方式也有了一定的思路。
接下来的几天我会尝试写一个 Demo 让这样一个插件基本能跑起来（除了核心的下单、支付环节，这显然不是我力所能及的）。跟着我的分析，相信读者对 WebView + Native Code 的混合编程模式应该也有了一些新的认识。
希望我有足够的动力和时间写 Demo，因为这个 Demo 可以帮助大家更清楚地理解支付宝插件中用到的 WebView + Native Code 的 Hybrid 开发方式。
