# 阿里云公测版迁移到正式版
为了开发者更方便的将业务从公测版迁移到正式版，我们提供了公测版一键迁移到正式版的功能，开发者可在[uniCloud控制台](https://unicloud.dcloud.net.cn)操作迁移，流程如下：
## 购买正式版迁移空间
公测版迁移正式版，需通过`迁移正式版`操作来下单购买待迁移的正式版空间，该操作会为两个空间增加迁移绑定关系，方便后续迁移配置。
迁移时，可以选择新空间使用**按量计费**或**包月套餐**。
如选择套餐，目前会根据公测版老服务空间最近三十天的平均用量水位，一共十二项计费指标，然后分别和不同档位套餐的阈值相比较。最低套餐满足了每一项指标都不超限。
经与阿里云协调，已上线新版推荐套餐方案，改为只强制校验5个计费指标：
- 云数据库容量
- 云存储容量
- 前端网页托管容量
- 过去30天云存储累计CDN流量
- 过去30天前端网页托管累计CDN流量
满足这5个指标，就可以迁移。其他指标超过使用的套餐会发出警告，但也允许迁移。
如果你的迁移选项里只有按量计费，没有套餐，那说明即便是最高档的套餐也无法满足。
因为老空间未提供流量统计，且一直免费。导致很多开发者不知道自己的流量和存储消耗多大，可能会惊讶于最低套餐的标准。
对于认为套餐超过预期的开发者，可能是存储里过多无用文件或代码需要优化，推荐改用按量付费，跑1天看看使用量消耗到底在哪里，问题出在哪里，然后优化下代码和存储，把成本降下来。
虽然用户量小，但套餐推荐较高，常见的问题有：
1. 存储文件体积太大，低档套餐的存储不够，迁移不了
2. 定时任务导致云函数使用量和数据库读写量偏高
3. 不合理的代码设计，一个页面发起太多请求次数
4. 云函数运行内存设的太高。正常情况下256M内存是够的。可以在[云函数package.json](https://uniapp.dcloud.net.cn/uniCloud/cf-functions.html#memory)或web控制台调整。
5. 如果之前使用uni统计，建议调整下统计的上报数据频率和云端跑批频率。不能太造资源。[详见](https://uniapp.dcloud.net.cn/uni-stat-v2.html#savemoney)
DCloud始终是为开发者提供更高性价比方案的产品服务公司，DCloud不会为了挣钱故意推荐开发者用不着的高档套餐。
目前包月套餐可以转按量计费，但按量计费还不能转包月套餐。我们会推进阿里云尽快解决。
在购买待迁移空间前，已经可以获取到迁移后云存储上传及下载的域名，**开发小程序的话，由于小程序安全域名白名单在客户端有缓存，建议迁移前两天将云存储域名添加到白名单**。
下单时可设置迁移任务执行的时间，迁移时间仅支持两小时后到三天内的时间点，在未开始执行之前可更改迁移时间。
由于待迁移正式版空间是一个全新且独立的空间，所以在创建后会分配新的SpaceId，规则为`mp-公测版SpaceId`。
为了更好的在云函数/云对象中兼容，购买待迁移正式版空间时， 可选择`是否在云函数/云对象代码中兼容 SpaceID`，如果开启该选项，迁移后在云函数/云对象内获取的`context.SPACEINFO.spaceId` 及 `cloudInfo` 内的 SpaceId 将保持不变，仍为原公测版SpaceId。开发者可以通过`context.SPACEINFO.useOldSpaceId` 或 `cloudInfo.useOldSpaceId`判断当前获取的spaceId是不是迁移前的，true表示当前服务空间在云函数内取到的服务空间id为迁移前的服务空间id，否则为新空间id。如运行本地云函数，此特性于`HBuilderX 3.6.13`起支持，云端默认支持此特性。**迁移后的新服务空间id为旧空间id加`mp-`前缀。**
**注意**：
- 公测版不可迁移到正式版的免费版（开发者版）
- 目前还不支持跨账户迁移，但已经在做，预计很快上线
- 购买待迁移正式版空间后，为了保证数据迁移的一致性，此时的正式版空间无法在HBuilderX关联、无法在控制台创建数据表、无法在云存储及前端网页托管上传文件等操作，直至迁移完成。
- 只有通过`迁移正式版`完成创建的正式版服务空间才支持一键迁移，原已创建的正式版空间无法使用该功能。
- 如果客户端为小程序，请在迁移前先到小程序后台配置新的上传域名到上传域名白名单（注意不要移除公测版服务空间的上传下载域名），**由于小程序安全域名在微信客户端内有缓存，建议再迁移前两天进行配置**
- 建议在半夜等用户不访问的时间进行迁移。迁移过程耗时数分钟（具体取决于云存储的文件量），迁移中大多数功能仍可以使用，但云存储的上传功能在迁移中会关闭。
- 正式版固定IP代理出口IP和公测版不同，如有在三方平台配置域名白名单请自行修改，参考：[阿里云固定IP](cf-functions.md#aliyun-eip)
- 迁移到正式版后公测版服务空间的数据库备份不会被迁移过来
- 迁移到正式版后开发者下次在HBuilderX打包发行时会使用正式版服务空间ID。请注意这时候需要修改小程序request域名白名单，将`api.next.bspapp.com`添加到request域名白名单内
- 迁移到正式版后公测版服务空间前端网页托管默认域名将在公测结束后自动回收
- 迁移到正式版后不可删除公测版服务空间，需等待公测结束后自动回收
## 迁移开始
系统会在设置的迁移时间自动开始执行迁移任务，迁移逻辑及注意事项如下：
### 云数据库
- 云数据库无需迁移，会将公测版服务空间的数据库关联到正式版上，所以**请勿删除公测版数据**
迁移期间是否可正常服务：是
迁移类型：无感迁移
迁移耗时：无
### 云函数
- 云函数定时任务、url化配置及自定义域名会一并迁移，公测版服务空间的url化请求会自动转发到正式版服务空间上
- 如果绑定了自定义域名，此时仍会请求到公测版空间然后转发到正式版空间，您也可以将域名解析到正式版服务空间，免去请求转发的逻辑
阿里云公测版callFunction请求、云对象调用使用了`api.bspapp.com`这个域名，正式版是`api.next.bspapp.com`。为避免迁移后旧客户端（迁移前发布的客户端）无法访问到新服务空间，阿里云做了请求转发，迁移完成后旧客户端仍会请求`api.bspapp.com`而阿里云会把发送到旧空间的请求转发到新空间去。从而保证迁移前后旧版本客户端能正常请求云函数
url化访问时不管是默认域名还是自定义域名均和上述转发逻辑类似。开发者也可以将自定义域名解析到新空间去，省去请求转发的逻辑。
迁移期间是否可正常服务：是
迁移类型：无感迁移
迁移耗时：约3-5分钟
### 跨域配置
- 由于正式版跨域配置上限为9条，跨域配置记录迁移后可能会超上限，此时无法新增。正式版跨域配置支持泛域名，可将公测版配置的多个子域名删除后添加一条泛域名
- 跨域配置同时会对前端网页托管生效，如果你迁移前配置了前端网页托管自定义域名。迁移后需要先将前端网页托管的自定义域名重新绑定后才可添加新的跨域配置。
迁移期间是否可正常服务：是
迁移类型：无感迁移
迁移耗时：很短，可忽略不计
### 云存储
- 云存储在迁移开始后，上传文件的功能不可用，访问不受影响
- 原云存储链接仍可正常访问，流量费用会计到正式版空间，正式版空间如果是包年包月则从资源用量中扣除，如果是按量计费则会出账并从余额中扣除，出账时间为T+2
- 使用HBuilderX 3.6.10-alpha或3.6.5-正式版之前的版本发布的应用，迁移后上传文件会报错（错误信息为：`文件上传失败`，web端上传请求会返回403错误码），需要使用更新的HBuilderX版本重新发布应用（不管是app、小程序、web均需要重新发布）
- 正式版新上传的视频文件，视频截帧只支持H.264编码格式，不支持H.265编码格式，原公测版上传的视频不受影响
迁移期间是否可正常服务：可正常访问，不可上传
迁移类型：有感迁移，迁移期间不可上传文件
迁移耗时：单文件体积较大，1GB迁移耗时约1分钟；单文件体积不大文件较多，1万个文件耗时约30分钟
### 前端网页托管
- 前端网页托管文件及自定义域名会一并迁移，迁移期间访问不受影响
- 网站首页需设置为index.html，如果设置为其他子目录(xxx/index.html)，迁移可能会失败
- 单页应用配置取消，改为由错误页面实现，迁移时会自动将开发者配置的单页应用目录转为错误页面配置项，开发者无需操作
- 默认域名及自定义域名此时仍会请求到公测版空间，与云存储不同的是不会转发到正式版空间
- 正式版空间如果为按量计费，在迁移任务执行时会自动开通前端网页托管
迁移期间是否可正常服务：是
迁移类型：有感迁移，迁移完成后自定义域名需重新绑定及解析CNAME到正式版
迁移耗时：单文件体积较大，1GB迁移耗时约1分钟；单文件体积不大文件较多，1万个文件耗时约30分钟
## 迁移完成
在迁移任务执行完成后，业务中公测版服务空间相关的数据会一并迁移至正式版：
1. 插件市场购买的付费插件
2. 公测版服务空间购买的Redis
3. 公测版服务空间添加的协作者
4. 公测版服务空间添加的安全网络及IP防刷配置
此时公测版服务空间将无法在[uniCloud控制台](https://unicloud.dcloud.net.cn)操作，无法在HBuilderX关联， 正式版服务空间已完全替代公测版，可在HBuilderX关联进行打包。
### 迁移完成后的TODO
- 检查云函数运行是否正常，比如定时任务及url化是否正常、云函数/云对象中获取到的SpaceId是否符合预期
- 检查云存储上传是否正常，公测版服务空间的上传请求会转发到正式版，所以上传的文件会在正式版里体现
- 检查前端网页托管是否正常，比如自定义域名的访问。如果有使用默认域名请尽快替换为正式版域名
### 前端网页托管绑定了自定义域名
如果绑定了自定义域名，则仍会请求到公测版服务空间，此时正式版上传的文件并不会反向同步到公测版，导致自定义域名无法访问新上传的文件。
由于自定义域名仍绑定在公测版服务空间，正式版空间前端网页托管的域名状态为`需解绑后重新绑定`
需要开发者在[uniCloud控制台](https://unicloud.dcloud.net.cn)将自定义域名删除后重新绑定，通过该操作获取到新的CNAME后，将域名解析更换到新的CNAME以完成域名迁移。 这个期间前端网页托管自定义域名访问会中断，建议在访问量较低的时候处理。
## 迁移后uniCloud特殊业务消耗费用说明
很多开发者使用uniCloud是因为短信、app一键登陆、iOS通用链接、app升级中心、uni统计等业务。
当阿里云计费后，开发者关心这些业务造成的成本有多少？本章节将为开发者进行测算。
首先iOS通用链接的费用是可以忽略的，开发者的免费版即可满足需求。
### 短信及一键登录资源消耗评估@sms-unilogin-fee
`短信`和`一键登录`业务涉及费用的部分主要是云函数/云对象的使用量、调用次数、和出网流量(如：使用`uni-id-co`或自定义的云函数/云对象来发送短信)。
接下来，我们对不同资源，分别进行费用评估。
我们按照uniCloud官网列出的[按量计费](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)规则，可以简单得出如下公式：
`云函数/云对象费用 = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8`
其中：
- 资源使用量 = 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数
- 调用次数 = 发送短信条数（一般情况下发送条数 = 调用次数，特殊情况除外）+ 一键登录调用次数（如果只使用其中某一项业务，则可设另一项业务调用次数为0）
我们假设如下数据模型：
- 云函数内存：512M，即0.5G （云函数内存默认为512M，用户可以自定义设置，最低可设置为128M。如果您仅发送短信，没有其他复杂业务，那么内存设为128M可以进一步的降低费用）
- 云函数平均单次执行时长：200毫秒，即0.2秒
- 短信和一键登录业务平均每日调用次数：10000次
- 出网流量：单次请求 2 KB
按照如上公式，其`短信`业务云函数每天的费用为：
```
云函数费用（天） = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 0.5G * 0.2S * 10000 * 0.000110592 + 10000 * 0.0133/10000 + 10000 * 2 * 0.8 / (1024 * 1024)
= 0.110592 + 0.0133 + 0.0152587890625
= 0.1391507890625（元）
≈ 0.139（元）
```
结论：如果你的`短信`和`一键登录`业务平均每天发送条数为10000条，使用阿里云正式版云服务空间后，对应云函数每天大概消耗0.139元，对比之前的短信和一键登录费用，平均每次调用多花0.0000139元，几乎可忽略不计。
### App升级中心消耗资源评估@uni-upgrade-center
近期，uniCloud阿里云版开始正式商用，部分开发者对基于uniCloud的`uni-upgrade-center`等云端一体业务，开始纠结，不清楚这些业务预计会花费多少钱，不清楚相比传统服务器而言，何种方案性价比更好。
本文尝试算细账、算总账，以阿里云[按量计费](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)为例，详细预测`uni-upgrade-center`在不同用户规模下的资源消耗及对应费用，帮助大家明智选择，无忧开发。
本文主要分为三个部分：
- `uni-upgrade-center`消耗的资源费用测算(云函数、云数据库、云存储、前端网页托管分别测算)
- `uni-upgrade-center`给你带来的收益
- 综合考虑，你该如何选择
`uni-upgrade-center`升级中心涉及费用的部分主要分为：
- 云函数：`uni-upgrade-center`云函数，将客户端版本和服务端最新版本进行对比，返回是否需升级的逻辑
- 云数据库：`opendb-app-versions`表，存储版本信息
- 云存储：放置近期的升级包资源（apk/ipa/wgt）
- 前端网站托管：部署`uni-admin`，管理员发布新版本
接下来，我们对不同资源，分别进行费用评估。
#### 云函数
启用`uni-upgrade-center`升级中心后，你的App每次启动，会请求一次`uni-upgrade-center`云函数。
我们按照uniCloud官网列出的[按量计费](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)规则，可以得出如下云函数资源消耗计算公式：
`云函数费用 = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8`
其中：
- 资源使用量 = 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数
- 调用次数 = App日活 * 每日活用户平均每天启动App次数，因为App每次启动，均会执行检查更新逻辑
我们假设如下数据模型：
- 云函数内存：256M，即0.25G；注意云函数内存默认为512M，`uni-upgrade-center`云函数建议设置为256M
- 云函数平均单次执行时长：100毫秒，即0.1秒
- 每日活用户平均每天启动App次数：2次
- 出网流量：0，升级中心无需链接外网
按照如上公式，你的App若有100个日活用户，其升级中心云函数每天的费用为：
```
云函数费用（天） = 资源使用量 * 0.000110592 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 云函数内存（单位为G） * 云函数平均单次执行时长（单位为秒） * 调用次数 + 调用次数 * 0.0133 / 10000 + 出网流量 * 0.8
= 0.25G * 0.1S * 100 * 2 * 0.000110592 + 100 * 2 * 0.0133/10000 + 0
= 0.00081896（元）
```
即：你的App日活为100，使用`uni-upgrade-center`商业版后，对应云函数每天大概消耗0.00081896元。
据此，可计算其每月的费用为：0.00081896 * 30 = 0.0245688，即每月只需2分钱；
同理，我们可推导出日活为1000、10000、10万的App，其升级中心云函数每月费用如下表：
|日活 |资源使用量计费（元） |调用次数计费（元） |出网流量计费（元） |合计（元） |
|:-: |:-: |:-: |:-: |:-: |
|100 |0.0165888 |0.00798 |0 |0.0245688 |
|1000 |0.165888 |0.0798 |0 |0.245688 |
|10000 |1.65888 |0.798 |0 |2.45688 |
|100000 |16.5888 |7.98 |0 |24.5688 |
日活1000的App，云函数月度消耗才两毛五（0.25元），真是毛毛雨了。
#### 云数据库
按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)介绍，云数据库费用 = `容量费用 + 读操作次数费用 + 写操作次数费用`，其中：
- 容量费用：数据库存储容量（单位为G） * 0.07
- 读操作次数费用：读操作次数（万次） * 0.015
- 写操作次数：写操作次数（万次） * 0.015；
##### 容量费用
我们以`hello uni-app`为例，`opendb-app-versions`数据表中共存储30条升级记录，容量大小为8K。
据此可计算出`opendb-app-versions`表的日存储费用为：`8/1024/1024 * 0.07 = 0.000000534`
> 容量计费单位是G，故需先将8K折算成M，再折算成G，故上述公式中连续除了两个1024
1月按30天算，则月存储费用为`0.000000534 * 30 = 0.000016`，还不到1分钱，可忽略。
注意：数据库容量仅跟发布版本多少有关系，跟日活用户无关。
##### 读操作次数
在uni升级中心业务中，云函数`uni-upgrade-center`每次执行，仅调用一次数据库读取（读取一次`opendb-app-versions`表），故数据库的读操作次数等同于云函数的`调用次数`，前文有过公式，云函数调用次数 = `App日活 * 每日活用户平均每天启动App次数`，每日活用户平均每天启动App次数我们假设为2次。
我们即可推算，如果一个App的日活为100，则uni升级中心每日云数据库读操作次数费用计算如下：
```
读操作次数费用 = 读操作次数（万次） * 0.015
= 云函数调用次数（万次） * 0.015
= App日活 * 每日活用户平均每天启动App次数 / 10000 * 0.015
= 100 * 2 / 10000 * 0.015
= 0.0003
```
1月按30天算，则每月云数据库读操作次数费用为`0.0003 * 30 = 0.009`，还不到1分钱。
同理，我们可推导出日活为1000、10000的App，其uni升级中心每月云数据库读操作次数费用为9分钱、9毛钱。
##### 写操作次数
`uni-upgrade-center`升级中心，写数据库操作很少；管理员仅在每次发布新版时，通过`uni-admin`向`opendb-app-versions`表插入一条新版本信息；用户端App每次启动检查升级，无需数据表的写入操作，故写操作次数可忽略为0；
##### 小结
因为容量费和写操作次数费用均可忽略为0，根据公式：
```
云数据库费用 = 容量费（忽略为0） + 读操作费用 + 写操作费用（忽略为0）
= 读操作费用
```
可推导，uni升级中心的云数据库计费主要是读操作次数计费，因此我们进一步得出如下预测：
|日活 |容量费（元） |读操作次数费用（元） |写操作次数费用（元） |合计（元） |
|:-: |:-: |:-: |:-: |:-: |
|100 |0 |0.009 |0 |0.009 |
|1000 |0 |0.09 |0 |0.09 |
|10000 |0 |0.9 |0 |0.9 |
|100000 |0 |9 |0 |9 |
#### 云存储
按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)介绍，云存储费用 = `容量费 + 下载操作次数计费点 + 上传操作次数计费点 + CDN流量费`。
如果您的应用每次均上架到apple store或安卓各应用商店，升级时从应用商店下载安装，则云存储费用为0，因为使用的是应用商店的存储和CDN下载流量，本计费点测评章节可直接跳过。
> uni-upgrade-center 支持设置应用新版安装包下载地址为应用商店地址，这样就可以使用应用商店的存储和CDN，不消耗uniCloud的云存储资源。
现阶段，iOS平台均需上架apple store，我们可以忽略iOS平台的云存储消耗。
如果您的安卓apk安装包及wgt差量升级包全部托管在uniCloud云存储中，我们也可以算算这笔账。
##### 容量费
容量费主要是存储费用，我们可以定期将过期版本删除，从而节省容量费。
假设我们在云存储中保留最近5个版本的文件，apk/wgt全部保留，大小假设分别为：40M、10M。
>如前所言，ipa需上架apple store，不使用云存储，测评可忽略。
则每天容量费用为：`5 * (40+10)/1024 * 0.0043 = 0.0010498`
据此，可计算其每月30天的容量费用为：`0.0010498 * 30 = 0.031494`，即只需3分钱；
注意：云存储容量仅跟保留的历史升级包多少有关系，跟日活用户无关。
##### 下载操作次数计费点
下载操作次数计费点：仅触发文件下载时会触发，若无新版本下载，则不会触发。
假设你的App日活为100、月活为1500，每月发一次版本；月活用户中，50%会选择升级到新版本，我们可计算下载次数为：`1500*50% = 750次`。
而云存储的下载操作次数计费规则为：每万次0.01元，即每万次下载1分钱，750次下载远还不到1分钱，故下载操作计费点可直接忽略。
##### 上传操作次数计费点
每次App发版，仅需管理员上传一次新的资源包，用户App端检查升级时，不涉及上传操作，故上传操作次数计费点亦可忽略。
##### CDN流量费
CDN流量费：我们假设50%概率启用wgt资源包升级（升级包为10M），50%概率为整包升级；而整包升级中，20%为苹果用户（使用apple store流量），80%为安卓用户（升级包为40M）。
则按照如上数据模型，日活为100的App，假期其月活为1500，而月活用户中，50%会选择升级到新版本，即750人选择升级，不同升级包消耗CDN流量如下：
- wgt资源包CDN流量：750 * 50% * 10 / 1024 = 3.662G
- 苹果整包升级CDN流量：使用apple store流量，uniCloud云存储流量为0
- 安卓整包升级CDN流量：750 * 50% * 80% * 40 /1024 = 11.719G
即：日活为100的App，月度CDN流量为：`3.662 + 0 + 11.719 = 15.381G`，对应费用则为：`15.381 * 0.18 = 2.76858` （元）
同理，我们可推导出日活为1000的App，其升级中心云存储每月的CDN费用为27.6858元。
##### 和传统 OSS + CDN 对比
如果你不用`uni-upgrade-center`，选择如阿里云的传统`OSS + CDN` 方案，同样按量计费的情况下，1PB流量以内，传统CDN都没有价格优势；传统CDN每GB的起步价为0.24元，而uniCloud云存储CDN每GB的费用为0.18元。
详见：[阿里云官网CDN定价详情](https://www.aliyun.com/price/product?spm=a2c4g.11186623.0.0.4a6f31c9cwW5vQ#/cdn/detail/cdn)
1PB流量是什么概念？我们以每个安卓安装包为40M为例，需要 `1 * 1024 * 1024 * 1024 / 40 = 26843546`，即需要2600万人次安装包下载才能达到1PB流量，你可以评估一下你的App何时可以达到这个量级。
> 具体解释一下：1PB = 1024TB，1TB = 1024G，1G = 1024M，故上面公式连乘3个1024
也有人说了，购买阿里云CDN资源包可以更便宜。确实，购买大额资源包会更便宜，但这个方案有两个缺点：
- 这个资源包仅仅是CDN流量包，你还需要购买OSS回源流量包，而uniCloud直接将回源流量费用包在CDN费用之内了，无需额外购买回源流量。
- 预付费，在业务发展不明朗的情况下，一次性投入太多钱；一旦业务失败，CDN资源包未消耗完毕，也不能退款，浪费资金；而按量计费则没有这个问题，真实用多少资源，就花多少钱；
综合来看，uniCloud云存储相比传统云厂商的`OSS + CDN` 方案：
- 都选择按量计费，uniCloud版CDN默认0.18元更具价格优势；
- 预付费方式，选购云厂商CDN资源包，需额外购买回源流量包，对普通开发者，特别是中小开发者，并不友好，此时依然是uniCloud按量计费的云存储更具性价比。
#### 前端网页托管
`uni-upgrade-center`需要和`uni-admin`配合使用，`uni-admin`需要部署在前端网页托管中。`uni-admin`主要是管理员使用，使用频次较少，流量也较低。
按照[uniCloud官网](https://uniapp.dcloud.net.cn/uniCloud/price.html#aliyun-postpay)介绍，前端网页托管费用 = `容量费 + 流量费`。
##### 容量费
`uni-admin`编译后为4.7M，按照官网每GB每天0.0043元的规则，`uni-admin`的月度容量费为：`4.7 / 1024 * 0.0043 * 30 = 0.00059`，不到1分钱，可忽略。
##### 流量费
管理员登录`uni-admin`，到升级中心管理页面浏览并发布新版，所需流量不超过3M，即使每月发布2次更新，流量费预估为：`3 / 1024 * 0.18 * 2 = 0.00105`，也不到1分钱，也可忽略。
#### 合并总结
细项对比完了，我们来合并看看，使用uniCloud升级中心，到底需要花多少钱，相比传统自己研发升级逻辑、搭建升级中心，哪些地方都需要花钱，差异点在哪里？
不管是开发者自研的升级方案，还是`uni-upgrade-center`，存储+CDN的费用都是必需的，前文也将传统`OSS+CDN`和uniCloud云存储的性价比进行了对比，均按量计费的模式下，uniCloud更具性价比；以资源包方式购买传统CDN模式下，各有优劣。
既然两个方案，都绕不开云存储，那我们暂时抛开云存储对比，将其他各项按照日活用户规模罗列一下，看看`uni-upgrade-center`在其他维度所需费用。
|日活 |云函数（元） |云数据库（元） |云存储（元） |前端网页托管（元） |合计（元） |
|:-: |:-: |:-: |:-: |:-: |:-: |
|100 |0.0245688 |0.009 |忽略 |0 |0.0335688 |
|1000 |0.245688 |0.09 |忽略 |0 |0.335688 |
|10000 |2.45688 |0.9 |忽略 |0 |3.35688 |
|100000 |24.5688 |9 |忽略 |0 |33.5688 |
### uni-upgrade-center 给你带来的收益
使用`uni-upgrade-center`，免费获取、一键安装，你将获得：
- 经受大量App验证的、完备的检查升级逻辑，同时支持整包/资源包升级，支持静默升级，支持强制升级；
- 完备的管理功能，分平台发布新版、下线老版，关联应用商店，分渠道发布等。
- 代码开源，随意定制
如上功能，如果你使用传统模式自研，需要前后端配合开发，后端使用php/java做接口，前端发起Ajax请求，处理服务端的各种响应和错误码，处理升级弹窗提醒，这些功能做完善至少需要4个工作日。
假设工程师月薪18K，社保等综合管理成本是薪资的1.4倍，则4个工作日的综合成本为：`18*1000*1.4/22 * 4 = 4582元`。
### 总结
再次说回`uni-upgrade-center`，相比传统方式自研升级中心，存储+CDN的钱都是要花的，我们忽略它。
其它云函数、云数据库等，虽然看起来是额外增加的费用，但实际上你使用传统php/java自研升级逻辑，除了自研人力费用，后期也是需要消耗CPU、内存、带宽资源的，只是这些费用合并到虚拟机的整体租用成本中，你无法拆出来计算罢了。
再看回刚才的计算表，以1000日活用户来说，云函数、云数据库每月才多了0.34元，每年才多了4块钱（不考虑云存储CDN的情况下），一年多花4块钱，可以省掉自研的4500多元人工费用，可以让工程师将更多精力投入核心业务中。这5块钱的买卖，不划算吗？它不香吗？
|日活 |云函数（元） |云数据库（元） |云存储（元） |前端网页托管（元） |合计（元） |
|:-: |:-: |:-: |:-: |:-: |:-: |
|100 |0.0245688 |0.009 |忽略 |0 |0.0335688 |
|1000 |0.245688 |0.09 |忽略 |0 |0.335688 |
|10000 |2.45688 |0.9 |忽略 |0 |3.35688 |
|100000 |24.5688 |9 |忽略 |0 |33.5688 |
不重复制造轮子，聚焦业务，快速验证模式，实现商业增长，才应该是聪明工程师的追求。