拨开迷雾见晴天——分享首次Hybrid App 开发总结

【泛读Hybrid App，初窥端云互动】分享首次Hybrid App 开发总结

背景
一度深陷招人难、留人更难困局的互联网行业，在疫情与寒冬的叠加背景下，经历了大洗牌。前端开发工程师——特别是拥有iOS/Android双端开发能力者，成为市场稀缺工种，既有工程师们的工作内容发生着颠覆性变革。6月中旬，原已不打算继续经营app端业务的公司，意外接到某民营银行的p2p外包业务，囿于公司当下人员结构，我作为前端开发工程师，既无前后端衔接经验，又未涉足过hybrid App开发，且开发时间已压得非常紧迫，无法静待iOS/Android工程师入职，不容多虑，只能硬着头皮去探索。

开发之始
首先，我针对现有业务现状和公司当前的开发实力，在调研hybrid App 各类开发框架后，最终选择了RN(React Native)，这一选择既基于Facebook 的背书，也出于对字节系技术团队的信任。确定了框架之后，调研起各个平台相应的开发工具，以及社区内推荐的调试工具，至此开发环境基本搭建完毕。

尝试与挑战
在上手的前两周，学习阶段很辛苦，反复卡在工程配置上，频繁地请教团队里为数不多的有hybrid App开发经验的同事。也有试图先上手RN开发去减少时间成本，但是业务需求急迫，且产出无法立刻直观地查看效果，容易产生挫败感。

拨云见日
第二个星期结束时，基本能跑通基础业务逻辑。由于缺少RN开发经验，初版代码写得不够优美，且多处参照了RN开发教程，代码的可读性和复用性都没有保障。但是这种办法确实大大缩短了产出时间。

团队讨论
产出初步可用后，团队内部展开了激烈的讨论。我提出的RN开发方案由于底层设计、功能开发成本比预期高很多，遭到了很大争议。事实上，在开发初期的调试过程中，我也体会到开发、打包、热更新过程中的各种坑。即使跳出开发成本这个大坑，在产出版本后，后续平台升级、版本复用，甚至涉及到用户量级增大的情况，都需要很多精力进行资源优化，否则一旦数据量大起来，性能问题就会变得很明显。

成本核算
RN 是一套跨平台开发框架，可以高效开发跨iOS、Android平台的应用，且运行性能比较接近原生App。但现在RN已不在被字节系所支持，RN开发人员也极难招聘。最重要的是，这种方案的投入产出比相对较低。

最终选择
团队在激烈的争论后，一致决定将整个APP 重构，方案也由RN改为了uniapp开发。uniapp作为uniapp框架的迭代版本，保留了uniapp的所有优点，同时还具备RN所不具备的“云开发”能力。云开发将整个uniapp开发流程搬到了云端，为开发者提供了云端编辑器、云端调试器以及云真机等工具，这种方式极大减轻了开发人员对本地环境的依赖，在代码出错时，我们也能非常方便地使用云端调试工具进行调试。

总结与收获
短时间完成一个从原生App到hybrid App迁移，并且直接使用一种新的开发框架，无论对企业还是个人都是一个不小的挑战。Hybrid App开发对团队的考验主要集中在：人员配置、成本核算、技术选型等方面。整个项目下来，我最大的感触便是对于技术人员来说，需要不断开拓眼界，学习新知识。也希望我的经历能给同样面临着难题的朋友一点帮助。