云服务器ecs选择

最近开发的首款HarmonyOS app——运动记忆，跑友将华为、Zepp、小米、vivo、三星、Keep、悦跑圈、RQrun、动动、行者运动记录导出后，可通过运动记忆app转换成fit、tcx、gpx、kml格式文件同步导入高驰、佳明、RQrun、Strava等主流运动平台，这款app目前已经上架HarmonyOS 应用商店。

在开发过程中总会遇到一个问题这部分逻辑应该放到app里面实现还是放到服务端实现？，因为之前已经有了运动健康转换工具，根据当时的设计，为了减少转换过程中对服务器cpu算力的大幅消耗，很多逻辑是放在了云服务器上。

根据上图可以对当时的设计有个大致的了解，图中的云服务器你可以认为它的算力足够强（严格来说是足够稳定），它能保证程序能持续运行至正常结束，目前仅剩预检过程在服务器执行，因为转换过程不是在自己的服务器进行了，不会出现转换时服务器卡死，也就不会影响用户的正常访问了。

这样分离肯定是各有利弊的，那结合运动记忆app来梳理下优缺点。

重后端轻前端的优点

开发新渠道效率更高，比如再开发一个IOS版本app，只要开发必要前端界面，然后和后端服务连接起来就可以了。修复bug更快，如果逻辑在app里面，调整后还需要发布到应用商店，需要等待审核完毕，且客服升级app调整业务逻辑，拆分服务更便捷，因为主要逻辑都在服务端，自己可自由发挥，只需要保证app等前端调用的接口兼容老版本即可避免有些前端语言无法实现现有功能，比如不少转换库不支持HarmonyOS的arkTs语言降低前端被抓包、破解的风险，即使遭受恶意攻击，服务端及时拦截即可

重后端轻前端的缺点

app上线有套壳风险，因为你的前端太轻量了，平台可能不愿意特别是比较繁重的业务表现出来的异步效果太明显，比如运动记忆app目前就很明显，即使转换一条小小的记录也得等服务器转换完成后异步通知前端

运动记忆app怎么选的

阿里云服务器是干什么的

核心的转换功能目前采用了重后端轻前端的设计，其中一个主要原因是部分功能artTS无法实现，或者改造难度太大。

对于转换效果展示这类功能适合用native实现，比如地图敏感信息隐藏，长截图等。

运动健康转换工具

计算型GPU云服务器

条友这一周运动记忆

云服务器控制面板