一个完美的产品不是完成基本功就完事,要完美处理各种细节。SwiftUI在技术栈积累不够和各种组件前不建议实际应用。作为知识储备是必要,立即实施风险太大,没有必要。我们很欣赏SwiftUI简洁性和快速开发,很多细节需要我们解决。方便和功能强大是相悖的。正如java和C/C++的关系。使用java基本不关注指针使用和内存使用,方便好学。C/C++需要处理烦人的指针和内存使用问题,正因为它更接近底层,所以能实现java实现不了的问题和响应比java快30%。一个好的软件不取决于采用那种语言,而是取决于开发软件的人。SwiftUI还任重道远,不要过于追求新技术。
由于Struct内不能直接打印日志和立体图是乱码决定了SwiftUI是一个错误的产品,基本上相当于以前的storyboard。只是相当于以前直接拖入控件变成代码实现UI。一个好的软件缺少不了强大的日志系统,只靠接口和效果,单步跟踪,没有日志的软件,很难保证软件质量,更无法维护。我在很多公司见到许多app直接从来不打印日志,真不知道他们怎么开发出app的,这样的app质量可想而知,后期维护简直是噩梦。SwiftUI是一切皆view,大量使用Struct基本上是从设计上摒弃日志,真不知道设计他的人是聪明还是傻!为了节省一点内存,而放弃可维护性,得不偿失。以前全使用storyboard和xid的人有多少,用代码实现ui的又有多少。现在又换成这样不能打印日志和立体图的SwiftUI,简直是技术退步。Swift语言是语言的进步,他是强类型的语言,会自动约束程序员的语法错误。而object c是弱类型的语言,很多语法错误不检查,过于啰嗦,全靠程序员的严谨性和代码质量。弱类型也存在优点:在高质量的程序员手里灵活性很好。就像c语言和c++语言的进步一样。c++在某些应用中无法代替c 语言。新公司员工没有大公司的架构建议采用swfit开发,不建议采用SwiftUI技术,采用代码实现ui就可以。若是大公司对质量控制很好,有很好的object c的mvvm架构,建议采用mvvm架构。不建议为了追求新技术放弃优秀的object c的mvvm架构(带app网关,ReactiveObjC,页面路由)。咨询过许多大厂的框架,他们仍旧采用object c语言开发的居多,采用mvvm架构(带app网关,ReactiveObjC,页面路由)。swfit比object c语言更先进,但是限制也更多。好的软件,主要取决于开发软件的人和框架,而不取决语言本身。不是使用的先进的语言开发的软件就好。有人说大厂很多都是网页,开发的软件太多,无法转swfit。这样是一方面的原因,但是不是全部。主要是大厂的框架足够优秀,代码质量要求严格,灵活性好。不要认为SwiftUI有Swift这几个字就认为它是Swift更高级的形式,其实他只相当于原来的storyboard,是控制器和view的组合体。我不推荐使用SwiftUI。使用SwiftUI还是使用object c取决公司的技术积累,是否有十分好的架构。若是啥架构都没有,建议采用Swift;若有很好的大公司object c建构,建议采用object c架构。再次说不要采用SwiftUI技术。