有个 typo，上面有个堆写成栈了

@skadi #6 没啥好笑的啊 我的全部思考过程是这样的

比如 #7 给的这个例子里返回了一个 hash 的 byte slice，这个返回值就极有可能生成到栈上影响 GC 性能啊
生成我们想要的 hash 值可以粗略的认为有两步，第一步是计算，第二部将计算结果转为期望的编码 （ hex 或 base64 ）标准库写法这么冗长的原因将这两步拆开了，允许你自己将这两步的结果 slice 自己先塞进去，避免标准库把对象分配到堆上

我前面跟 @orzfly #3 说想错了的意思是，两者确实不是强关联的
比如我前面描述的两步是可以捏到一起的，第二步的结果的 slice 允许当参数传入就好了 所以 #7 的 API 可以大概设计成

result = make([]byte, 0, 64)
err = sha256.SumHex(data, result)

@orzfly 🤔 是我想错了，这么说好像确实不合适

行数可以变短但必然带来额外的开销(内存分配)，一般 go 作为高性能后端对这些都是很敏感的

之前是合作现在是收购了？ (纯猜测，不知道内情

虽然 goroutine 没退，但你 main 函数执行完整个进程就退出了 你可以在 main 结尾加个 select {} 阻塞一下

微信的跳一跳代码中那个黑色的柱状体变量名是 bottle

@timothyye #123 有问题和讨论欢迎提 issue，可以追溯和归档

@wofave #120 是之前的自动调节系数的版本么... 可能是这个问题 https://github.com/faceair/youjumpijump/issues/61

@xqx #107 @roceys #109 QQ 群已解散，请转 github issue

@wenketel
@LinkT 可以试下最新版本，也欢迎提 issue 带上日志

@slgz 这是 go 编译出来的可执行文件，可以直接下载运行
@fashioncj 就怕不是分辨率导致的问题，看上面有反馈 debug 出来关键点的定位是准的但跳的不准。还有个思路是截屏完先 resize 成 720p 然后再匹配坐标，如果愿意帮忙测试的话可以加一下附言中的群。

@slgz #27 这个程序只依赖 adb，但微信不一定能在模拟器里跑起来

@wellsc #24 附下跳错的截图？我看看定位有没有啥问题

@loading #22 日志里定位的坐标是准的 from:[318 728] to:[455 601] press:381ms，这两个点分别在跳跃块底部中心和 右边灰块顶部中心 看你的截图也是 720p 的屏幕，想不到啥原因了...

@loading 方便提供一下跳错了的那一屏的截图么 我应该可以根据截图 debug 一下

@wellsc #10 之前一些内置的常量忘记跟分辨率一起缩放了，有空可以再帮忙测一下

@wellsc #10 红米 3，主题附言里加了个我跑的视频