作者m339606 (mize)
看板MacDev
标题[心得] 从Xamarin转Swift
时间Thu May 25 21:27:36 2017
前言:
今天突然心血来潮想写看看自己对於Xamarin的心得,与转换到纯Swift的过程
如果是想进来看教学的可以直接上一页了 XD
一、投入iOS开发
原本工作是处理政府相关的WebForm专案,因缘际会下在公司接到有iOS的开发专案,在被
老板指定(强迫)下必须找解决方案开始做,当时的选择方案有三个
1.Xamarin.iOS => 使用C#开发,又有.Net的强大支援
2.Cordova => 使用网页语言开发
3.纯原生
在思考後选择了Xamarin.iOS做为开发平台,持续了约两年,共开发两个案子
一个为企业内部使用,另一个已上架
二、资源瓶颈
刚开始的时候因为完全没有接触过iOS
Xamarin在当时中文的只有一个Blog有入门教学,而且真的只有入门Hello World而已
再搜寻国外相关的教学也相当的少,陷入了学习的瓶颈
於是这时候开始学会看OC的教学文章自己转译到C#上。
Xamarin的卖点之一可以使用强大的.Net第三方library
但是并不是每个都可以使用,必须要支援PCL
.Net自己的则是99%以上都可以正常使用
而iOS原生自己数量庞大的第三方library则是99%都无法使用
iOS原生的library必须有人建立Xamarin的专案使用桥接发布,或是原作者自己另外写一
套
综上所述,Xamarin的library数量相当的少,许多功能必须自己手刻
很多时候找到iOS原生有的library但是却没办法用相当痛苦阿!
三、转Swift
因为原本的专案都进入维护期,又换公司需要开启新专案,我就毅然决然放弃了Xamarin
投入原生开发
初期相当的不适应,要将原本Xamarin自己写的library移植到Swift
许多.Net中的糖糖在Swift通通没了,要不断的寻找替代方案或是手刻
但是这痛苦的期间也只维持了大约半个月
Xamarin.iOS与原生开发最大的差别在IDE、语言、第三方library,而iOS的开发知识则是
原封不动
例如StoryBoard、Xib、各种View使用方式等等...
藉着原本在Xamarin上学会的相关知识,克服了语言差距顺利的开始了纯原生的开发
到目前专案已经进行了半年多,深刻觉得原生拥有的资源真的是最多的。
结语:
1.如果你是没有任何程式经验想投入iOS开发
建议不要绕远路直接走原生开发,我推荐 Swift :)
2.如果你是原生的iOS开发者,为了想要使用Xamrin来达成一次开发多平台
你要使用的应该是Xamarin.Forms,这一套特别为了多平台做了相容性开发
但是这种方式或许必须牺牲原生特效、功能,
对於Forms我只有初步使用就觉得难用放弃没有更深入了解
按照现在趋势,或许你使用React Native是比较好的方式?
3.如果你是C#的开发者,为了不想换语言所以想选Xamarin
或许在初期一切都是那麽的熟悉,但是一旦碰到App的开发知识就是一片白纸得从头学
想要针对Xamarin找资源又异常的困难,到最後还是得去翻原生的资源自己转译
你原本在C#中不管是WinForm还是WebForm、MVC.Net的知识,在APP开发中九成以上派不上
用场我在开发中最有用的知识只有.Net的多执行续处理
虽然这套在进入Swift後就完全废掉了
现在Swift对於C#开发者而言已经相当亲和,已经不像学习OC那麽的痛苦了
如果这样还是没改变你的想法,只能祝福你了:)
QA:
Q:Xamarin要付费吗?
A:我那个时候Xamarin尚未被M$收购,收费最低就是一年999美金,另外有免费的学生授权
目前微软有Community版可以直接免费使用,但是要注意条款限制
而如果原本有VS授权的则会直接拥有同级别的Xamarin授权
Q:Xamarin使用的人数多吗?
A:从104上找职缺的话,全台湾或许还没超过10家公司有在使用
Q:Xamarin.iOS开发的App可以顺利上架吗?
A:完全没有问题!
Q:Xamarin需要的IDE与环境
A:Xamarin可以直接挂在Visual Studio上使用,但是开发iOS还是必须要有一台mac当Host
来编译,推荐直接使用Xamarin Studio在mac上直接编写
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.26.236.52
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/MacDev/M.1495718860.A.F5F.html
1F:推 mhsu2k9: 感谢分享 05/25 22:49
2F:推 ctweng13: 感谢心得分享 05/26 00:38
3F:推 areyo: 还好一开始就用OC去写 05/26 07:03
4F:推 kyushu: 在 ios 上,不是写swift,oc的方式我觉的是推不起来的 05/26 13:37
5F:推 tentenlee: 最近还在想说要不要玩看看...还是放弃好了 05/26 15:27
6F:→ yuanruo: 很多用这个都是有核心技术 C/C++ library 要共用双平台 05/27 22:00
7F:→ yuanruo: UI相对来说不是重点就会用这个,因为技术核心不是在视觉 05/27 22:01
8F:推 Blueshiva: 核心技术是C/C++ Lib的,除非那个核心技术牵涉到UI,不 05/28 17:25
9F:→ Blueshiva: 然个人觉得还是直接用OC/Swift去串就好。目前知道核心 05/28 17:25
10F:→ Blueshiva: Lib跟UI有关的,大概只有游戏跟导航两种 05/28 17:26
11F:→ uranusjr: 核心在 C/C++ 在 iOS 没问题, 但 Android 就很麻烦 05/28 17:37
12F:→ uranusjr: 所以我是可以理解啦, 如果 Android 要用 NDK 那乾脆就用 05/28 17:38
13F:→ uranusjr: 这类工具也不失是合理考量 05/28 17:38
14F:推 Blueshiva: Android要用C/C++ Lib很麻烦吗?这点我倒是不清楚,不 05/28 17:39
15F:→ Blueshiva: 过听说Spotify就是这样搞的,各平台的client基本是都只 05/28 17:39
16F:→ Blueshiva: 是个小介面,底下全部是共通的lib 05/28 17:40
17F:推 eggeggss: 不会啊..有写过wpf超好转的,尤其用mvvm的架构 03/06 20:25
18F:→ eggeggss: 很适合用在大型专案上..其他的技巧像是linq,orm,di 03/06 20:28
19F:→ eggeggss: 完全都是承袭以前经验 03/06 20:28
20F:→ eggeggss: 至於ios机制上的知识,的确这是要从原生语言去补没错 03/06 20:29
21F:→ eggeggss: 以及原生资源的不足都是跨平台工具的缺点 03/06 20:30
22F:→ eggeggss: viewModel拉出来除了可以在其他专案共用逻辑之外 03/06 20:32
23F:→ eggeggss: 也可以用在单元测试上 03/06 20:32
24F:→ eggeggss: 个人是觉得很方便,若遇到原生语言的东西就去k官网 03/06 20:33
25F:→ eggeggss: 如果没套件就自己写啊,整个类别都被搬到c#了 03/06 20:35