小程序的真机体验和模拟器体验是不一样的
发表时间：2023-12-05 08:09:34
文章来源：炫佑科技
浏览次数：159
菏泽炫佑科技 菏泽炫佑小程序开发 菏泽炫佑app制作 炫佑科技
小程序的真机体验和模拟器体验是不一样的
一般来说，小程序的开发成本比较低。 即使像我这样不懂Web前端的iOS程序员，甚至是只了解一点Java的iOS程序员，也可以在1到2天内快速开发一个。 小程序（当然，阅读文档的时间是单独计算的）。
目前小程序的权限还比较紧张，很多数据无法获取。 这也暂时限制了微信小程序的应用前景。 希望以后能放松点。
小程序真机体验
测试环境
6S加
iOS 10
中度至慢速 Wifi 环境
说说体验：一般来说，真机体验和模拟器体验是不同的。 我个人总结如下：
模拟器不显示微信自动生成的导航栏
模拟器的适配布局有偏移（eg：同样是6S Plus，模拟器6SP上的（x，y）坐标与真实6SP上的（x，y）坐标不同，有少量偏移）
IDE 有一些错误。 模拟器上运行的程序是正常的，但真机上运行的程序可能会有bug。
微信小程序真机代码大小限制为1M
真机调试中的陷阱
调试方法
还有一个类似于模拟器中的控制台用于真机调试，同事也可以通过.log()进行调试。 二分调试（注释+输出）应该是目前真机上小程序*好的方法。
真机运行图
目前的真机调试流程： 在微信网页开发工具中上传代码 => 官方自动生成二维码 => 只有绑定了App ID的微信用户才能扫描二维码 => 扫描后会自动微信显示 打开小程序
点击微信导航栏左上角按钮后，将直接返回微信。 单击右上角的按钮后，会出现一个菜单。 菜单包括（控制台、启动、取消等按钮）
当我**次在手机上运行该应用程序时，我遇到了几个神奇的错误。 在此分享给大家，以免同行们落入陷阱。
Bug 1 - IDE Bug - this.data。
错误 1 代码
10
11
12
13
14
15
16
17 号
18
const = 0 //应用程序启动时的状态
const = 1 // 应用计时状态
const = 2 // 申请完成状态
页（{
数据： {
// 计时状态-动态
:
},
: (e) {
如果（！==）{
//
} 别的 {
//
})
错误 1 代码
仔细分析这段代码应该可以看出写的不对，应该使用this.data来获取。 这其实是一个比较简单的问题，为什么要提呢？ 主要是因为这一段在模拟器上可以正常使用（即IDE正常编译运行，并且可以触发后续事件）。 但真机上会出现明显的bug（卡住，即无响应）。 一般来说，当我们没有写this.data时，官方IDE会提醒我们，但也不排除像我这样的特殊情况。 所以，当真机调试时出现神秘bug时，不妨看看是不是这个问题。
错误 1 代码
10
11
12
13
14
15
16
17 号
18
const = 0 //应用程序启动时的状态
const = 1 // 应用计时状态
const = 2 // 申请完成状态
页（{
数据： {
// 计时状态-动态
:
},
: (e) {
if (this.data.!==) {
//
} 别的 {
//
})
错误 2 - - e..
错误 2 代码
{{物品}}
: (e) {
让 idx = e../38
// 使用idx判断哪个按钮被点击
这。（{
：[[idx]]，
: [[idx]] + ":00"
})
错误 2 代码
该代码在模拟器上也运行良好，但在真机上出现错误（卡住）。 后来分析后，主要发现布局不一样。 它也是 6S Plus。 模拟器 6SP 上的 (x, y) 坐标与真实 6SP 上的 (x, y) 坐标不同，有很小的偏移。 因此，得到的值不能被38整除。使用浮点值作为数组下标值，结果可想而知。 按钮判断应该使用id判断的按钮。
错误 2 代码
{{物品}}
: (e) {
让 idx = e..id
// 使用idx判断哪个按钮被点击
这。（{
：[[idx]]，
: [[idx]] + ":00"
})
Bug 3 - 真实机器代码大小限制
微信小程序限制小程序大小为1M。 由于我们团队的小程序资源较多（音频、图片）等，项目文件夹的大小远远超过1M。 该怎么办？ 只把资源文件放在后端，然后进行资源请求。 我们把资源放进去，然后在使用的时候请求资源，请求完之后缓存起来，避免二次加载。 完成此操作后，项目文件立即下降到 400 Kb 多一点。 我认为运行模拟器时您不会注意到代码限制。 对于一些开发（比如打算彻底迁移app的朋友）来说小程序的真机体验和模拟器体验是不一样的，即使把资源文件去掉，我的纯代码太大了，微信也不会上传。 我应该怎么办？ 我觉得解决办法应该是参考iOS的热更新，把一些程序放在后端，等页面实际使用后再发出请求。
小程序的应用前景
作为一名希望有产品思维的iOS程序员，我认为小程序未来在某些领域有很大的潜力。 下图是我个人看好的小程序的应用方向。 在我看来，小程序应该“走开”，过多的停留应该交给App来处理。 毕竟，不可能在微信内部创建一个小微信，对吧:-P？
我个人感觉App和RN有很大的区别。 RN更常用于Apps中，但由于Apps无法在浏览器中打开微信小程序开发ide，因此它们可能仍然是自己的同类。
*后我想用几句话来结束这篇文章。 王伯钧笑道：
不懂互联网的普通人往往会高估小程序的价值和意义，而懂互联网的程序员往往会低估小程序的未来价值。 在我看来，唯一不变的就是变化，为什么不拥抱这种变化呢？ 就亲吻吧！
