一套代码两端运行不靠谱?是时候放弃 C++ 跨 Android、iOS
来源:    发布时间: 2019-09-01 17:46   11 次浏览   大小:  16px  14px  12px

  「Write once,run&#

  「Write once,run anywhere!」思必是许众开拓者以及企业求之不得的期望,不过正在剖析跨平台中的各种本钱之后,咱们不禁发问,这种政策真的靠谱吗?

  今天,云存储公司 Dropbox 就此发文了解了这一近况,其示意不停以后,他们均行使了 C++ 言语编写跨 Android、iOS 端的代码,不过进程了 6 年的施行之后,他们发摩登码共享相干的隐变成本太高,还不如直接发轫写两套代码,最终,其放弃了本来的开拓形式,转而行使每个平台的原生言语(如 Swift 和 Kotlin)。接下来,咱们将周到知道个中的缘起以及正在跨开拓流程中所消磨的本钱。

  Dropbox不停有一个共享转移筑立上的iOS和Android代码的政策:行使C++言语编写。

  这种政策背后的思法很单纯:使用C++编写一次代码就够了,不然就须要用Java和Objective C写两次。咱们于2013年动手采用这种C++的政策,当时咱们的转移工程团队范畴相对较小,况且须要支撑急速拉长的转移进展远景。咱们须要找到一种形式,让这个小团队急速颁布大方iOS和Android代码。

  直到近来,咱们才决议统统摒弃这种政策,转而行使每个平台的原生言语(首要是Swift和Kotlin,咱们刚动手做转移开拓的时分这些言语还没有闪现)。做这个决议的起因干系到代码共享相干的隐变成本。我将正在本文平分享咱们公司正在有用共享代码方面取得的体味教训。本来,总共这些都源自统一个根本题目:

  假如以非尺度的办法编写代码,咱们就须要担负非常的开销(假如采用普遍行使的平台就没有这种费心)。结果却发掘,这种非常的开销凌驾了写两次代码的价格。

  正在深远先容咱们碰着的总共分别的非常开销之前,我思先澄清一下,现实上咱们之前的倾向(即大无数代码都用C++开拓)从未告终。采用C++激发的非常开销导致咱们无法统统朝着这个倾向迈进。

  请属意,众年以后谷歌和Facebook等至公司不停正在开拓可扩展的代码共享办理计划。然而,迄今为止这些办理计划的采用限度如故很有限。固然你能够使用React Native或Flutter等级三方代码共享办理计划,来避免本文描摹的片面非常开销,但仍有极少开销避无可避,起码正在个中一项身手进展成熟之前咱们如故须要担负这些非常的开销。比方,Airbnb也由于本文中描摹的很众起因,而不再行使React Native。

  假如咱们保持行使平台原生言语,那么这些代码都没有须要,况且咱们为开源项目功绩的代码也能够让更众行使平台原生言语的开拓职员受益。固然咱们能够使用开源的C++代码库,但C++开拓社区的开源文明并不如转移开拓社区那般壮大(异常是转移开拓社区中没有C++转移社区)。

  请属意,这些本钱正在C++中异常高(与Python或C#等其他非原生言语比拟),由于它匮乏简单全数的尺度库。即使如斯,C / C++是谷歌和苹果独一支撑的带编译器的言语,因而行使其他言语会晤对更众其他须要处罚的题目。

  转移生态体系有很众能够普及开拓成果的东西。转移的IDE异常厚实,谷歌和苹果为普及各自平台上的开拓体验参加了大方资源。因为咱们没有采用默认的平台原生言语,于是无法享福这些好处。最值得属意的是,平台原生言语的调试体验平常都远胜于正在平台默认的IDE中调试C++代码的体验。

  有一个令我异常难忘的例子,有一次激发后台线程框架死锁的某个bug导致咱们的使用屡屡溃败。假使正在单纯的尺度身手栈中,你也很难确定这类的bug。由于这个题目须要调试正在C ++和Java之间屡次切换的众线程代码,于是咱们花费了数周时刻才修复!

  除了丢失了一大宗东西除外,咱们还须要花时刻修筑支撑C++代码共享的东西。最主要的是,咱们须要一个自界说的修筑体系,个中包蕴打包C ++代码以及Java和Objective-C的库,还须要天生Xcodebuild和Gradle都能领略的修筑倾向。这个别系占用了咱们的大方资源,由于它须要一向的更新,本领支撑两个修筑体系的更正。

  虽说iOS和Android使用都是“转移使用”,况且二者平常都具备无别的特征和效用,但平台自身确实存正在极少影响告终的差别。比方,使用正在每个平台上推行后台职司的办法是分别的。即使咱们采用了这种跨平台式政策,固然刚动手尚有点相通,可跟着时刻的推移差别也渐渐拉大(比方,与相机相册的交互等)。

  因而,现实上“只需编写一次代码就能够正在分别平台上开箱即用”的说法只是一个传说。最终为了将代码集成到分别的平台上,你如故须要花费大方时刻编写特定于平台的代码(况且有时你须要改动C++层的代码!)。

  因而,只需编写一次代码只是一个恒久无法兑现的好梦,这种做法并没有太大长处。

  结果,固然这不是最主要的身分,但培训和/或雇用开拓职员正在咱们自界说的身手栈上办事也有必定的本钱。当初采用这种转移政策时,咱们具有一批体味厚实的C++开拓职员。该小组承担启用了这个C++项目,并为Dropbox培训其他转移开拓职员。

  过了一段时刻后,这些开拓职员渐渐跳转到了其他团队和其他公司。留下的工程师没有足够的体味挑起身手指挥的大梁,况且任用具备C++体味且对转移开拓感风趣的高级工程师也越来越难。

  最终,咱们深陷缺乏爱护C++代码库的合头专业学问的逆境。重获这种专业学问的独一形式是投资如下个中一个倾向:

  培训内部的转移(或C++)工程师,然而假如你没有具备这些身手力的职员来做培训,这种形式也行欠亨。其它,早正在中央小组的职员产生更正之前,大无数转移工程师就对进修C++落空了感风趣,因而找不到培训对象也是一个大题目。

  正在任用题目之上,支柱咱们的身手栈面对职员去留的题目,由于转移开拓职员底子不思掺和C++的项目。这导致很众有才具的转移工程师都分开了这个项目,结果自界说身手栈的爱护办事陷入了举步维艰。总的来说,转移开拓社区的进展日眉月异,合乐888新身手和形式屡屡闪现,且被迟缓采用。良好的开拓职员都愿望测验最新的身手。

  正在具有尺度身手栈的成熟产物处境中,跟上最新身手和产物的程序是一项很大的挑衅。有时,为了依旧安定,你不得不去世采用新身手的速率。假如你将自身封锁到某个自界说身手栈中,远离转移生态体系的花花寰宇,那么这种挑衅的难度会快速上升。

  固然“只需编写一次代码”的说法听起来性价比很高,但现实的非常开销会导致这种做法得不偿失(并让你大失所望)。最终,咱们放弃使用C++(或任何非尺度的办法)共享转移代码,转而行使平台原生的言语编写代码。

  其它,咱们也愿望咱们的工程师享福欢欣的办事光阴,并为回馈社区做功绩。这也是咱们决议向行业尺度看齐的起因。

  对待云云一套代码两头运转的本钱的推算与行使,网友也纷纷揭晓了自身的观点:

  我不了然像Dropbox这种范畴的公司明明统统能够采用平台原生言语,为什么还要使用C++开拓转移使用。

  话说回来,咱们公司有一个异常老的ERP体系,咱们须要开拓极少转移使用。当时咱们的团队中惟有7私人,却有许众项目须要爱护,再加上琢磨到共享代码的本钱以及咱们对C#的谙习水平后,咱们选拔了Xamarin。这绝对是一个折衷计划,但也不失为一种务实的选拔。

  假如你有才华雇佣Java或Obj-C的开拓职员,况且恳求他们担负起转移开拓的办事,那么就应当琢磨行使平台的原生言语。

  不过,假如你是一家小公司,且具有Java和C#的开拓,同时Obj-C和C#开拓职员的任用有难度,那么就能够琢磨Xamarin或其他跨平台共享代码。

  进程众年的屡次验证后,我也得出了无别的结论。正在两个转移平台之间共享任何定制的营业逻辑(模子、限度器等)并不明智。假如你有极少异常棘手的初级算法或库,或者你须要琢磨到速率、数据库、加密,厚实的图形等,那么能够测验使用C ++或其他言语共享模块。除此除外,即使是谷歌和苹果测验使用CRUD使用来告终高效的代码共享,结果也无果而终。

  依托 “互联网+AI 机械人+体验式效劳”形式,「科卫机械人」获 5000 万元 A 轮融资

Power by 建站之星 | 美橙互联 版权所有