iOS虚拟支付的限制下，如何优化小程序用户体验？

1.转变售卖主体（虚拟支付转化为实物支付）

关于这一方案通常采取购书赠课、购买线下实体课程（有线下门店）、购买实质的教学光盘/练习题等等。当然还有一些更轻量的转变模式。

小打卡最初希望通过统一使用小打卡明信片用于解决虚拟支付的问题，甚至将口号“购买明信片加入圈子”放在页面标题位置；但截至6月29日小程序体验来看，目前小打卡已经取消了这一方案，点击报名d窗会提示“由于相关规范，iOS功能暂不可用”。

具体取消原因是因为这一方案仍在限制范围内，还是并没有带来实际购买率的提升效果，这还是有待进一步的考证。

当然小打卡在页面中还是提供了一些曲线救国的路径，可以联系圈主咨询或者在分销中可复制付费链接到H5付费。

2.收费调整为免费

有些小程序会牺牲营收来换取用户流量，结合其他功能如分享转发、签到、会员注册等等可得到课程。

虽然从营收来看，减少了课程收入，但是从其他方面可以换取用户粘性，降低拉新成本。对于有些营收占比主要依托于广告的小程序来说，也不失为焉知非福。

比如喜马拉雅，去掉支付入口，但是有通过星星解锁精品课程的获取途径，可以通过分享邀请好友和签到获取星星。

再比如，抽奖助手之前有一个“付费解锁”的玩法，现在已经免费使用。但带来的用户量激增也使得小程序更受广告主青睐。

3.H5支付

通过后台生成课程的H5链接，管理员转发给学员或放至对应入口，完成支付后跳转小程序。目前鲸打卡采用的即是这种模式。

还有部分小程序会标记用户的支付状态，提交支付订单后通过关联的openid给用户公众号推送支付提醒，但这种做法需要用户提前关注服务号，再者提交支付订单后通过服务号通知的方式支付召回，在规则上感觉风险比较大

而小打卡将H5链接通过分销入口嵌入在小程序中，从流程上释放了部分的人工沟通成本，目前微信对于这一种小程序跳转还在默许阶段，需要静观其变。

4.区分终端系统角色分别展示（Android和iOS）

最简单的做法就是按钮的变化，对于Android用户展示正常的支付按钮及标识，对于iOS用户用一些通用型的文案，其他 *** 作指引再通过d窗提醒。比如得到引导下载APP。

但仅仅通过按钮的区分，一些描述的限制束缚也会降低Android用户的购买转化率，使得课程描述不能很好的触动用户的付费意愿（前文也有提及）。

对于这个问题，鲸打卡小程序开发了区分Android和iOS展示的两套课程介绍页设置，使得在Android用户展示的介绍页能更好的展示想传达的内容。

还有一些小程序是将敏感词的描述做成字段形式（如购买须知等等），在iOS上对这些字段进行隐藏。

5.后台控制iOS支付开关过审

为了不破坏C端用户在购买过程中的体验，这是风险极高极冒险的做法。如果被举报发现或支付量达到微信设置的风险阈值，会存在小程序被封的后果。有些小程序会在活动推广的期间为了活动效果短暂去掉iOS支付限制，但是一般来说还是不建议这种挺而走险的办法。

需要

首先，下载并安装Magican。该软件中文名叫魔法罐头，是一款专业并免费使用的优化、监控、杀毒软件，其官网提供pkg安装包下载。

安装完成后，在Finder中打开“应用程序”，双击Magican启动。

打开主界面后，我们便可以在左侧看到和优化有关的项目。

其中，默认程序一项可以查看和修改相应 *** 作（诸如浏览网页、发送邮件等）的默认程序。

启动项则可以查看系统启动时加载的程序和服务。当然，如果有必要，你可以禁止某些程序或服务开机启动，以提高开机速度。

下面，重点来介绍一下“参数”项。在此项中，我们可以个性化Mac OS X系统，并且对它进行优化。

首先，在通用项中，我们可以设置截图的默认保存路径，以及历史菜单显示数目和天数。

在Finder项中（通俗点讲，Finder就相当于Windows系统上的文件资源管理器），我们可以设置是否显示隐藏文件，在窗口标题是否显示路径，是否显示“倾倒废纸篓（即类似于“清空回收站”）等。

在“Dock”项中（类似于Windows系统上的任务栏），我们可以设置它的外观、位置等。在这儿，有一项我建议大家勾选上，那就是“打开单窗口模式”。

它的意思是：浏览文件时始终只显示一个窗口。如果不勾选，则可能会打开多个文件浏览窗口，一来造成桌面凌乱，二来也会增加内存需求，从而降低了系统反应速度。

    在我们 iOS 开发的过程中，会遇到 APP 不流畅的情况。在 屏幕图像显示的那些事儿中 , 讲述了屏幕渲染的流程，当 GPU 或者 CPU 没有在屏幕每一次刷新时完成内容的提交，而造成渲染流水线耗时过长，就会导致重复渲染同一帧数据造成 图像掉帧 ，也就是所谓的”卡顿“。

为了保持流程的UI交互，App的刷新拼搏应该保持在 60fps 左右，其原因是因为 iOS 设备默认的刷新频率是60次/秒，而1次刷新（即 VSync 信号发出）的间隔是，所以如果在 16.67ms 内没有准备好下一帧数据，就会产生”卡顿"。 可以在程序中用 CADisplayLink 来测量帧率），然后在屏幕上显示出来，但应用内的 FPS 显示并不能够完全真实测量出性能，因为它仅仅测出应用内的帧率。

通过子线程监测主线程的 RunLoop ，判断两个状态（ kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ）之间的耗时是否达到一定阈值

     UIKit 的单线程天性意味着 UI 要在主线程上更新，这意味着绘制会打断用户交互，甚至让整个 App 看起来处于无响应状态。但是如果能避免用户等待绘制完成就好多了。 针对这个问题，有一些方法可以用到：例如 异步渲染 ， Core Animation 提供了 drawsAsynchronously 属性。

drawsAsynchronously 属性对传入 -drawLayer:inContext:的CGContext 进行改动，允许 CGContext 延缓绘制命令的执行以至于不阻塞用户交互。它自己的 -drawLayer:inContext: 方法只会在主线程调用，但是 CGContext 并不等待每个绘制命令的结束。相反地，它会将命令加入队列，当方法返回时，在后台线程逐个执行真正的绘制。 根据苹果的说法。这个特性在需要频繁重绘的视图上效果最好（比如我们的绘图应用，或者诸如 UITableViewCell 之类的），对那些只绘制一次或很少重绘的图层内容来说没什么太大的帮助。

---