小游戏学习–获取已发布微信小游戏源码
最近一直在做微信小游戏的开发，发现了一个好玩的事，在这里记录一下。 这段时间一直在做一些小游戏，小程序的开发，但有的时候会发现性能上总是不那么的尽如人意（毕竟我这小菜鸟水平有限），于是就想到，想要看看别的大神们是怎么处理这些问题的（其实就是想看一下大神们的代码怎么写！）。但是，有一个问题就是小游戏或者小程序和H5、网页不一样，不能直接F12看代码，要怎么才能拿他们的代码呢？ 在经过一...
在这里阅读的是，微信安卓653.980版的反编译后的代码。很清晰的可以看到，小程序在代码中被称为appbrand，主要逻辑放在包com.tencent.mm.plugin.appbrand下面（部门抽出的ui控件除外）；另外引用了3个js资源，均在/assets/wxa_library/下。虽然很大部门代码被混淆过的，然则适当的反编译后，我们照样能看出绝大部门器械。
包整理
依次整理com.tencent.mm.plugin.appbrand下的内容，按包区分:
a：似乎是单例和依赖注入的容器
appcache：微信小程序打包为wxapkg文件，这里处置的是下载解包验证和后续处置逻辑
appstorage：在数据库中存取AppBrandKVData的逻辑
b：在数据库中存取AppBrandLauncherLayoutItem的逻辑，是微信小程序列表缓存
c：通过安卓的canvas实现了一套完整的js的canvasapi，提供应小程序中canvas控件使用
config：小程序模块环境变量治理，其中数据可以通过互联网下发更新
contact：把app添加为微信联系人，似乎和谈天置顶有关
d：InputStream相关工具类
e：录音功效相关工具类
f：周围的人的小程序相关工具类
g：应该是AppBrandNetworkUtil，小程序模块用到的网络部门的工具类
h：权限治理工具类，包罗小程序权限治理和jsapi权限治理，同时也可以通过网络更新
i：小程序sd卡操作工具类
ipc：ipc即历程间通讯。小程序通过新开历程来保障自力运行的，自力历程的启动与微信本体的通讯依赖这个包的代码完成。其中AppBrandMainProcessService是最主要运行服务，而AppBrandProcessProxyUI是小程序历程持有性子activity。
j：AppBrandConversionExtension，似乎是多个小程序切换历程中的辅助类
jsapi：微信小程序通过浏览器露出给js环境的api的入口基本上都在这儿了，包罗组件部门和api部门。最后AppBrandJSInterface把这些入口聚合在一起。
k：似乎是一些零星的工具类
l：js中WebSocketapi的native实现
launching：微信小程序加载逻辑的实现。主要是处置了许多加载准备历程中的逻辑和错误监测
m：微信小程序列表搜索功效相关逻辑
netscene：似乎是对webview提议的特殊请求的处置和中止
page：页面部门，包罗微信小程序列表页等，主要都是各个activity和使用的自界说view。其中l.class值得注重，应该是焦点使用的webview了，h.class是这个webview的容器，也做了许多操作。
report：只是数据上报相关的器械
task：一些杂乱无章的异步事情放这儿了
ui：和page差不多，也是林林总总的activity和view。微信小程序现实的容器页面（5个）和种种功效与异常页面
widget：所有露出给js的native控件都在这儿了。实在并不多
其他文件中值得关注的一些器械：
a.class即AppBrandBridge是小程序主路由控制器，持有着当前所有小程序
f.class看起来是AppBrandService，持有后台运行的jscore
现在可以获得的信息
也许知道每个包都原谅一些什么代码之后，我们就可以对微信小程序举行一些挖掘了。
wxapkg解包
通过抓包我们可以发现，每次进入小程序列表后，就会通过网络抓下来所有小程序的wxapkg包，然后所有需要的器械都在内里了。那这个wxapkg在哪儿解包的呢？经由搜索，我们发现是appcache/f.class即AppBrandWxaPkg完成的这段事情。
由于混淆得一塌糊涂，因此我剖析现实wxapkg之后自己实现了一次解码（python）：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
#!/usr/bin/python
# lrdcq
# usage python wxapkg_unpack.py filename, unpack at filename.unpack
import sys,os
import struct
class WxapkgFile:
nameLen = 0
name = “”
offset = 0
size = 0
with open(sys.argv[1], “rb”) as f:
root = os.path.dirname(os.path.realpath(f.name))
name = os.path.basename(f.name)
#read header
firstMark = struct.unpack(‘B’, f.read(1))[0]
print ‘first header mark = ‘ + str(firstMark)
info1 = struct.unpack(‘>L’, f.read(4))[0]
print ‘info1 = ‘ + str(info1)
indexInfoLength = struct.unpack(‘>L’, f.read(4))[0]
print ‘indexInfoLength = ‘ + str(indexInfoLength)
bodyInfoLength = struct.unpack(‘>L’, f.read(4))[0]
print ‘bodyInfoLength = ‘ + str(bodyInfoLength)
lastMark = struct.unpack(‘B’, f.read(1))[0]
print ‘last header mark = ‘ + str(lastMark)
if firstMark != 190 or lastMark != 237:
print ‘its not a wxapkg file!!!!!’
exit()
fileCount = struct.unpack(‘>L’, f.read(4))[0]
print ‘fileCount = ‘ + str(fileCount)
#read index
fileList = []
for i in range(fileCount):
data = WxapkgFile()
data.nameLen = struct.unpack(‘>L’, f.read(4))[0]
data.name = f.read(data.nameLen)
data.offset = struct.unpack(‘>L’, f.read(4))[0]
data.size = struct.unpack(‘>L’, f.read(4))[0]
print ‘readFile = ‘ + data.name + ‘ at Offset = ‘ + str(data.offset)
fileList.append(data)
#save files
for d in fileList:
d.name = ‘/’ + name + ‘.unpack’ + d.name
path = root + os.path.dirname(d.name)
if not os.path.exists(path):
os.makedirs(path)
w = open(root + d.name, ‘w’)
f.seek(d.offset)
w.write(f.read(d.size))
w.close()
print ‘writeFile = ‘ + root + d.name
f.close()
|
另外现实文件结构如图：
看起来很清晰的解包代码，通过这些代码，我们就可以把微信下载下来的wxapkg手动举行解包了，进而可以继续剖析实在现原理。
页面加载
一最先的小程序列表界面是ui/AppBrandLauncherUI.class，然后通过AppBrandProcessProxyUI启动了小程序的AppBrandUI。
进入程序后，我们整理出最要害的activity和view：
ui/AppBrandUI.class 小程序主activity
page/f.class AppBrandPageContainer
page/e.class SwipeBackLayout的继续，每一个当个侧滑页
page/h.class AppBrandWebView的逻辑容器，耦合webview和其他控件的逻辑
page/l.class AppBrandWebView，主逻辑webview
AppBrandUI->f页面->e页面->h页面->l页面，通过这一条界面链条传到webview里最要害的器械，就是当前途序的appId和版本号。然后webview就加载了这样的器械：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
//h.class
if (paramString.dOS == null) {
paramString.dOS = (paramString.RA() + “page-frame.html”);
}
paramString.loadUrl(paramString.dOS);
//l.class
final String RA()
{
if (this.dOR == null) {
this.dOR = (“https://servicewechat.com/” + this.dzg + “/” + com.tencent.mm.plugin.appbrand.a.mr(this.dzg).dDB.dBs + “/”);
}
return this.dOR;
}
|
现着实webview中加载了形为https://servicewechat.com/{appid}/{version}/page-frame.html的页面。这个页面实在被定向到wxapkg中的page-frame.html，它通过jsbridge再挪用到代码其余部门。
如何关闭WordPress PHP错误
如何关闭WordPress PHP错误
另外一边，还启动了一个f.class即AppBrandService。启动AppBrandService的代码中会开一个jscore，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
this.dWV = new AppBrandJSInterface(this);
if (com.tencent.smtt.sdk.aa.fM(com.tencent.mm.sdk.platformtools.aa.getContext()))
{
this.dzh = new i(com.tencent.mm.sdk.platformtools.aa.getContext(), this.dWV, “WeixinJSCore”);
g.iuh.a(434L, 2L, 1L, false);
v.i(“MicroMsg.AppBrandService”, “Using X5 Javascript Engine”);
g.iuh.a(434L, 0L, 1L, false);
OJ();
paramContext = com.tencent.mm.plugin.appbrand.appcache.b.aq(this.dzg, “WAService.js”);
g.iuh.a(370L, 5L, 1L, false);
if (!be.kS(paramContext)) {
break label258;
}
v.e(“MicroMsg.AppBrandService”, “get Null Or Nil service js”);
g.iuh.a(370L, 6L, 1L, false);
}
for (;;)
{
paramContext = com.tencent.mm.plugin.appbrand.appcache.b.aq(this.dzg, “app-service.js”);
g.iuh.a(370L, 9L, 1L, false);
if (!be.kS(paramContext)) {
break label281;
}
v.e(“MicroMsg.AppBrandService”, “get Null Or Nil app-service js”);
g.iuh.a(370L, 10L, 1L, false);
return;
this.dzh = new h(com.tencent.mm.sdk.platformtools.aa.getContext(), this.dWV, “WeixinJSCore”);
g.iuh.a(434L, 1L, 1L, false);
v.i(“MicroMsg.AppBrandService”, “Using WebView Based Javascript Engine”);
break;
label258:
com.tencent.mm.plugin.appbrand.k.c.a(this.mContext, this.dzh, paramContext, new c.a()
{
public final void OK()
{
v.e(“MicroMsg.AppBrandService”, “service inject library js fail”);
g.iuh.a(370L, 6L, 1L, false);
com.tencent.mm.plugin.appbrand.report.a.S(f.this.dzg, 24);
}
public final void onSuccess()
{
f.this.dzh.evaluateJavascript(“wx.version”, new u() {});
g.iuh.a(370L, 7L, 1L, false);
}
});
}
|
反编译得稍乱，不外这实在就是两种情形的逻辑。使用X5 Javascript Engine并实例化出一个i.class或者使用WebView Based Javascript Engine并实例化出一个h.class。i.class封装挪用的是腾讯的x5js引擎，而i.class是一个不会显示的webview，他们都实现了相同的接口b.class，内里两个方式，第一个显然是onDestroy，第二个就是最要害的evaluateJavascript了。
这样一来，我们就可以画出整个微信小程序的运行构架和链条了：
页面路由
好比js路由界面打开是jsapi/an.class，我们追踪一下代码。
它从a.class即AppBrandBridge的map：Map<String, com.tencent.mm.plugin.appbrand.page.f> dyQ中取出了当前应用（dzg）的f页面AppBrandPageContainer。然后在f中新建了一个e并完成了动画，而且可以看到f拥有两个数组来持有差异打开方式的e页面。
可以获得的信息是：a(AppBrandBridge)持有了当前每一个打开的小程序的主界面f（AppBrandPageContainer），之以是不持有每一个activity也许是为了利便挪动容器位置或者缓存相关的问题吧；每一个小程序有一个f，其打开的每一个页面是一个e(SwipeBackLayout)，固然每一个e配有一个l（AppBrandWebView）来出现界面。
因此可以明白为，每一个历程（AppBrandProcessProxyUI）启动一个微信小程序，拥有一个AppBrandUI，它的最焦点的是AppBrandPageContainer，内里最多原谅5个界面（e）。这样我们就可以画出微信小程序的界面结构了：
思量到同样代码中可以看出，有5个AppBrandProcessProxyUI即微信最多可以启动5个小程序，而每个小程序最多有5个页面即5层SwipeBackLayout即5个webview，整个小程序部门最坏情形会拥有5×5+1共计26个jscore。
回到界面路由，由于当个小程序都在一个AppBrandPageContainer中，因此所有的路由操作只需要定位到这个f界面，做界面动画就可以了——事实上就是这样做的，除了动画，AppBrandPageContainer持有两个数组来治理差异打开方式的SwipeBackLayout，路由操作同时是在对这两个数组举行操作。而现实详细SwipeBackLayout实例化的实现，是凭证传入的JSONObject内容确定的了。其他路由方式均同理。
native控件
我们领会到微信小程序每一个界面就是一个webview，那所有界面都是h5的咯？似乎并不是，开着安卓的界面界限显示我们就可以发现部门view是native的控件，事实上打开WAWebview.js我们就可以看到，有专门的behavior：wx-native来标柱一个view是否是纯native的控件，就算没标注，好比wx-input控件，也在部门状态下用native来实现的。
我们用wx-input举例子看看它是怎么交互的。首先看到控件内监听器，注册：”input.input”: “_inputKey”，当输入的时刻，回调到_inputKey，而_inputKey的代码是：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
_inputKey: function(e) {
var t = e.target.value;
if (this._value = t, this._checkPlaceholderStyle(t), this.bindinput) {
var n = {
id: this.$$.id,
dataset: this.dataset,
offsetTop: this.$$.offsetTop,
offsetLeft: this.$$.offsetLeft
};
WeixinJSBridge.publish(“SPECIAL_PAGE_EVENT”, {
eventName: this.bindinput,
data: {
ext: {
setKeyboardValue: !0
},
data: {
type: “input”,
timestamp: Date.now(),
detail: {
value: e.target.value,
cursor: this.$.input.selectionStart
},
target: n,
currentTarget: n,
touches: []
},
eventName: this.bindinput
}
})
}
return ! 1
},
|
这就很有意思了，js代码把当前input的id，所有数据和在页面中的坐标通过JSBridge发送给了native。对于在java中的代码是jsapi/a/a.class即AppBrandJsApiInputBase，接下来的事情人人都知道了，无非是凭证传入的json中的样式绘制native控件，然后接着处置。
上面这样的js代码在WAWebview.js中有许多出，我们可以完整的总结出到底有哪些native控件而且在native中的代码对应：
input,textarea : jsapi/a包 widget/input包实现
datepicker : jsapi/b包 widget/b包实现
map : jsapi/map包 widget/AppBrandMapView.class实现
canvas : c包 widget/AppBrandDrawableView.class实现
video : x5原生实现，不是小程序完成的
其中有意思的是这些native实现的view泛起在了文档scroll-view的tips中：“请勿在 scroll-view 中使用 textarea、map、canvas、video 组件”。想想确实可以明白，若是是在web第一层塞入的native控件，可以很利便的让native控件和网页一起转动；而scroll-view显然只是个html的div实现的，native很难监听到div内里的转动，固然也没发让这些native的控件一起滚，因此就gg了。
手码两万余字，SpringMVC 包教包会
手码两万余字，SpringMVC包教包会 1.SpringMVC简介 1.1SpringWebMVC是什么 SpringWebMVC是一种基于Java的实现了WebMVC设计模式的请求驱动类型的轻量级Web框架，即使用了MVC架构模式的思想，将web层进行职责解耦，基于请求驱动指的就是使用请求-响应模型，框架的目的就是帮助我们简化开发，SpringWebMVC也是要简化我们日常Web开发的。在传统...
