从开发者的角度看待各移动平台 ios/android/wp7/win8

T_T 这伪技术博客都快给写成Tron的读书笔记专栏了,这样可不行欸~
如今正是移动平台的战国时期,厌烦了去讨论移动平台的未来,也无意于在HTML5和Native App之间纠结。本文只从开发者纯技术的角度聊聊各移动平台的特性。

1.WP7
个人挺喜欢wp7的系统,所以连带着也喜欢起wp7的开发。WP7开发常常与MVVM(Model-View-ViewModel)模式一起出现。抛开执行效率不谈,我觉得MVVM是在移动平台上写起来最优美的数据绑定策略。当然,MVVM与WPF/SL的整体架构是分不开的。现在虽然有好事者在安卓上也整了一套MVVM框架,但我总感觉怪怪的。MVVM可以使开发者把UI操作的注意力集中到ViewModel层上,对于双向绑定、单向绑定、集合绑定都有很好的解决方案,配合起WPF的UI分离策略,让人写起代码干净而利落。
由于众所周知的分辨率问题,长期以来WP7开发者都对IOS/安卓持有十足的心理优越感。但是随着lumia920等产品发布,wp7的分辨率480×800的单一格局也被打破了。目前来看,新的分辨率带来的冲击似乎也并不大。老式的WP7.1 480×800程序会直接拉伸到高分辨率。虽然浪费了一些分辨率,但这对不少直接用绝对坐标做布局应用来说(这在wp上相当普遍),至少没有产生明显的UI BUG。
由于WP系统的Metro风格,UI设计变得极为轻松。反正走简约风嘛,装一个Metro Studio就已经解决了我几乎一半的UI工作。
微软的IDE和文档也挺不错,wp7开发还算愉悦。

2.Win8
虽然同样是.net wpf silverlight那一套东西,但wp7应用移植到win8上对我来说几乎是重写(除了ViewModel层可以直接复制粘贴)。如果我没记错的话,wp7应用基于.net 3.5的阉割版,而win8的metro应用是基于.net 4.5的阉割版。而.net各个版本之间的变化我觉得还是不小的。
.net 4.5对于我来说最大的惊喜是await/ async异步编程语法,我觉得仅此一条在我心中的份量已经超过了c++ 11的全部新特性。已经被异步编程时的各种匿名函数花括号晃花了眼?不想再在网络请求时使用各种delegate且纠结于各种双向引用带来的内存泄漏?在多级网络请求时形形色色的异常处理语句总让人一头乱麻?试试await语法吧,绝对超乎想象。
由于win8是新平台,各种第三方sdk不是比较少,而是几乎没有。因为我做的是个社交应用,只好先写个REST网络封装库,再依次写了SinaWeibo for win8 SDK, Renren for win8 sdk, Douban for win8 sdk。借助于await语法在异步编程开发效率上带来的提升,写这些sdk倒也没花多少时间。
wp7/win8应用的桌面瓷贴特性是其它平台都没有的,这一点可以好好利用一番。

3.ios
由于笔者是从win8开发切换到ios上,所以初入ios门不免有一夜回到原始社会之感。
最大的不适应来自UI编程,虽然xcode也自带有可视化的UI开发工具,但我感觉那东西连玩具都不如。99%的UI布局工作还是要手工敲object-c代码。最让人受不鸟的是ios中居然没有原生的相对定位布局方法(类似于wpf中的StackLayout或是安卓中的LinearLayout),所有控件坐标几乎都要拿代码计算,遇到一个可变高度的列表那简直让人头皮发麻了。
好在ios上有不少优秀的开源类库,例如facebook团队贡献的three20就被ios开发者广泛使用,几乎都快成为准官方库了。
ios5以后开发者轻松了不少。一是苹果推出了ARC(Automatic Reference Counting)机制,省去了手动释放内存的工作,但是把应用了ARC的代码和没有应用ARC的代码(很多是第三方库)放在一起使用还是要额外花点功夫;二是storyboard。storyboard可以让UI开发变得类似于产品原型设计,把众多的页面UI和跳转关系集中到一张大表中。虽然没有本质上解决ios在UI开发上的乏力感,但是storyboard至少极大的方便了开发人员理解页面跳转关系。这算得上是ios开发中为数不多的亮点。
纯粹从技术的角度来说,我真不希望ios做大,微软的技术解决方案不知甩苹果几条街。但没办法,广大开发者还指望着从ios这个最吸金的平台上多分一杯羹呢。

4.android
如果需要用一句话证明我写过安卓程序,我会毫不犹豫的写出:pixels = dips * (density / 160)
如果一句话不够,我会再加上一句: API 10 = Android 2.3
针对安卓的分辨率问题,广大开发者们已经不能吐槽得更多。我觉得和分辨率的碎片化相比,真正要命的是操作系统的碎片化。虽然官方强烈推荐使用安卓4.0的新控件,但是目前2.3以及各种奇葩机的市场占有率仍然让人眉头紧锁。作为我个人来讲,我宁愿用老版本的API自己动手画控件,也是万万不敢尝螃蟹的。
当然了,Java是个好东西。如果不是为了开发ios,应该鲜有人主动去学o-c。但是Java总归是有足够的群众基础的,在语言层面上对大多数人来讲几乎没有学习成本。成本主要存在于安卓测试机上了,因为谷歌给弄的安卓模拟器和wp、iphone模拟器相比实在是太过坑爹。据说在mac上的安卓模拟器运行会流畅点,不过我总觉得这是google的阴谋,逼得开发者们不得不买上一大把测试机。当然了,这点测试机的钱,对于IT巨头而言当然算不上什么,对于小团队来说就稍显麻烦了。由此又催生了一批专业的安卓APP测试公司,这里就不展开讲了。
安卓的UI开发有点类似于WP,但是在数据绑定上还是难以与之匹敌。对于9 Patch(9宫)图的原生支持也是安卓UI开发的一个亮点,在安卓的sdk工具包里专门有个工具来制作9 Patch图。ios上也有相应api来实现类似功能,但没有安卓这么方便。而WP更是完全没有提供对9 Patch图的原生支持。
之前在各平台很少遇到的内存泄漏,在安卓上以Out of Memory Exception(OOM)的形式大放异彩。虽然OOM的出现本质上还是由于APP的代码没写好,但我总感觉在安卓上出现OOM的概率比其它系统上高了很多,不知是不是我的错觉。
安卓的开发权限还是挺自由的,做开机启动、后台运行推送什么的,只要在程序包里标名权限并得到用户安装允许就行了。貌似wp和ios根本不允许开机启动,安卓的后台运行和推送相比于WP、IOS的推送机制也方便了很多,这些特性方便了开发者的同时,也为流氓软件留下了滋生的土壤。

最后,衷心希望HTML5早日一捅浆糊,在self和this之间纠结,在 cialis without prescription.count.size.length之间徘徊,这是人干的事嘛~

4 thoughts on “从开发者的角度看待各移动平台 ios/android/wp7/win8

发表评论

电子邮件地址不会被公开。 必填项已用*标注