IOS11登录时遇到一个请求与PC返回不一致情况, 在小程序调试时IOS上始终没有wx.request() 不能发送请求
尝试解决方法
打开微信小程序调试的设置, 将TLS设为可信任的域名
设置 ---> 项目设置
IOS11登录时遇到一个请求与PC返回不一致情况, 在小程序调试时IOS上始终没有wx.request() 不能发送请求
尝试解决方法
打开微信小程序调试的设置, 将TLS设为可信任的域名
设置 ---> 项目设置
转载于:https://www.cnblogs.com/zhongke/p/9699297.html
今天,使用真机调试时,出现了无法启动程序的错误。错误提示大概是:error fail to launch ***App。当时我仔细核对了密钥文件和签名证书,发现都是正确的,并且有匹配上。可是,无法启动程序,重启
Xcode,甚至重启PC后问题仍然存在;
后来仔细查看了证书和密钥文件相关的文档才发现:发布证书签名的安装包不能直接使用Xcode在
真机上运行,需要打包后安装在真机上,然后运行;
总结,问题出现后,而没有解决的头绪时。最后的办法是从最开始的步骤开始检查,这样才能快速
高效的解决问题;
关于 Date() 函数在 iOS 中的一个小坑
bug
今天遇到了一个诡异的 bug 。一个 Vux
的日期选择组件在 PC 端和安卓端都能正常显示和使用,而在 iOS
端却不能正常出现。经过漫长的调试,终于发现问题出在这一行代码上:
var startDate = new Date('2017-5-3')
这行代码在 PC 端和安卓端都是正常的,而在 iOS
端则会提示 Invalid Date
无效日期。
原因
new Date(dateString)
实际上是调用了 Date.parse()
这个函数。关于这个函数, ECMAScript
规范规定:
如果一个字符串不符合标准格式,则函数可以使用任何由引擎决定的策略或解析算法。 Date.parse()
对于因包含有无效元素而无法识别的 ISO
格式字符串或者日期应该返回 NaN
。
简单的说这个函数在不同的浏览器引擎中会存在偏差,导致对字符串的解析不一致或部分浏览器无法解析。问题应该就是出在这里!是 Safari
不能识别这串字符串。
经过测试,将代码改为如下样子:
var startDate = new Date('2017-05-03')
这样代码就可以 iOS
端正常运行了。坑爹的 Safari
。
参考链接
http://www.jianshu.com/p/5ef7557245f1
这里暂且讨论使用Mac对iOS设备进行调试的方法。至于Android平台,会有细节但不是非常重要的不同。
为什么需要联机Profile?
大部分情况,直接在工作机(PC、Mac)用Unity针对工程进行Profile就能查出性能的瓶颈。
但在不同的设备会有不同的性能表现、甚至一些设备由于硬件设计的原因,导致一些性能瓶颈只有在特定设备上才会表现出来。
针对这些设备相关的性能问题,需要进行联机Profile。Profile的手段概述
iOS设备通过USB连接Mac后,对其进行Profile手段有三种:
上面的3种Profile有以下特点:
确保调试设备能够进行调试你的app
关于Apple Developer和Provisioning Profiles
- 一个apple developer有一个apple id
- 这个apple id下有不同的证书(certificates)。证书证明了这个apple id有能力进行软件的开发、分发。
- 这个apple id下有不同的app,每个app对应一个app id(也称bundle id)。表明这个apple id正在开发、分发哪些app。
- 这个apple id下有不同的设备,每个设备对应一个设备id。表明这个apple id关联了哪些设备。
- 这个apple id下有不同的Provisioning Profiles。一个证书id、一个app id和一个设备id列表,组成了一个Provisioning Profiles。意思是,“因为有了这个Provisioning Profiles,我可以用这些设备来调试这个app”。
所以,要成功让XCode连上你的设备并调试你的app,你必须拥有正确的Provisioning Profile。
更多可以参考Apple Developer官网里的“Member Center”。
在Unity进行Build了之后
大体的准备规则和上面的“XCode进行Profile”差不多,主要差别在后面几步:
项目乃至人生,都是一个选择、试错、总结,再选择、再试错、再总结的循环过程。这个过程并非白费,而是提高自己的经验和能力,减少之后选择错误的几率。
通过Profile找出性能瓶颈的通用步骤如下:
处理方法可以有以下方法:
策划要求敌人批量刷出至少15个,但在iPhone4上,15个敌人已经很卡。
出现瓶颈的设备:iPhone4。目标帧率30fps,所以目标帧时间为33.33ms。考虑到iPhone4是低端机型,允许偶尔降到20fps,所以允许帧时间偶尔达到50ms。
使用Unity进行联机Profile,发现渲染透明物体是性能瓶颈。
尝试过把场景里的透明物体都去掉,效果不明显
所以依次进行了以下“ON/OFF”的尝试。除了寻找真正瓶颈透明渲染之外,中间还输出了其他的结论点
特性 | 帧数 | CPU时间 | GPU时间 | 结论 | 可能美术解决方案 | 可能程序解决方案 |
---|---|---|---|---|---|---|
场景OFF、15小兵 | 12 | 80ms | 39.7ms | CPU瓶颈:小兵占用过多CPU;小兵刷出时依然占用较大CPU | 减少小兵骨骼;减少小兵动画帧数; | 减少小兵trigger节点;场景加载后进入场景前,进行小兵在SpawnPool里的预创建 |
小兵OFF、场景 | 29 | 29.8ms | 33.5ms | 无瓶颈:madfinger的天空盒效率甚高; | 无 | 无 |
小兵OFF、场景 去除所有shadow cast |
30 | 23ms | 32ms | 去除shadow cast/receive可以较好提高CPU效率 | 需要给mesh都去掉shaodw cast/receive | 无 |
场景、15小兵 | 6 | 180ms; | 176ms | 最初情况。场景单独OFF没问题、小兵单独OFF问题不大,但他们同时出现却有大问题。 | 见下面比较方案 | 见下面比较方案 |
场景、15小兵(无阴影) | 15 | 64ms | 43ms | 一当加上场景就卡的原因是,小兵需要投影圆形阴影到场景 | 无 | 程序进行设备LOD,当是低端机的时候,需要去掉所有blob shadow projector |
结论,敌人脚下的Blob shadow projector阴影是真正的透明渲染瓶颈所在,可以采取设备LOD,在iPhone4上直接去除掉这个功能。
可以发现尽管去掉阴影后,效率还是无法达标,所以需要再重新进行一次profile。