本文是对目前主流移动应用开发(Android/iOS)的 IDE、开发语言、跨平台框架做了一个梳理与总结。
AppX @ifeegoo https://www.ifeegoo.com/appx.html。
提醒:以下内容较长,如果想直接进入精简版:可参见 AppX GitHub 版本,求 star。本来觉得应该分部分写,但是后来发现这些内容相关性比较大,所以一口气串联了起来,如果你有时间,建议细读,肯定会有意想不到的收获!
一提到主流移动应用开发(Android/iOS),多数人第一想到的 IDE 必然是 Android Studio/Xcode,而开发语言必然是 Java|Kotlin/Objective-C|Swift。其实能够进行 Android/iOS 应用开发的 IDE、开发语言、跨平台框架还是蛮多的,接下来我们就一起梳理下这块的内容。
表 1:常见的 Android 原生开发的 IDE
No. | IDE | 支持操作系统 | 是否免费 | 备注 |
1 | Eclipse + ADT | Windows/macOS/Linux | 免费 | 早期 Android 官方 IDE。 |
2 | Android Studio | Windows/macOS/Linux | 免费 | 现在 Android 官方 IDE。 |
3 | IntelliJ IDEA | Windows/macOS/Linux | 社区版免费,终极版收费 | 等同于 Android Studio。 |
4 | AIDE | Android | 免费 | Android 系统中的 IDE。 |
1.Eclipse + ADT
Eclipse + ADT(Android Development Tools)是早期接触 Android 开发必备的 IDE。Google 最早选择 Java 作为 Android 开发语言,以及使用 Eclipse 这样一个大的通用 IDE 平台,自己只是开发一个 Eclipse 的 Android 开发插件:ADT。这样的好处是便于以小成本快速获取大量的开发者来参与到 Android 开发中,因为 Java 已经流行这么多年,而且开发语言的学习难度不大,同时 Eclipse 作为 Java 开发流行的 IDE 平台,对于老司机以及新手来说,对它的适应性绝对没有问题。
Google 早期肯定不会选择非主流的开发语言作为 Android 开发的首选语言,同样也不会选择自己重新开发 Android 专用的 IDE,这绝对是一个耗费巨大精力,甚至是不讨好的活。要知道,做 IDE 能够做到像 JetBrains 这样优秀,真的不是一件容易的事情,虽然 Google 可以投入这样的精力,但是绝对没有必要,尤其是面对 Apple 在 2007 年 6 月份发布了 iPhone OS(后来 iPhone OS 改名为 iOS) 1.0 版本,早于 Google 在 2008 年 9 月发布的 Android 1.0 版本,而且 Apple 官方在 2003 年秋季已经发布了 Xcode 1.0 版本。如何更加快速的拉拢开发者,Eclipse + ADT 的模式,绝对是明智的。
但是随着时间的推移,Android 开发者慢慢发现 Eclipse + ADT 的 IDE 是有各种 Bug(尤其是 Mac 版本),编译运行速度缓慢,最要命的是 Android 模拟器的运行速度,和同时期的 iOS 模拟器相比,简直到了被秒杀的地步,这也给了当时专注做第三方 Android 模拟器的 Genymotion 绝佳的发展机会。
到了 2013 年初,Android 系统已经在智能手机市场占有率接近 80%,日益增长的用户和大量涌入的开发者,使得
Google 意识到:工欲善其事,必先利其器。Google 终于在 2013 年 5 月份的 Google I/O 大会上宣布了具有历史意义的 Android 官方 IDE:Android Studio。
而随着 Android Studio 不断的完善和成熟,Google 官方在 2015 年 6 月正式宣布:在 2015 年底,结束对 Eclipse 中的 ADT 的开发和官方支持。
An update on Eclipse Android Developer Tools
以上描述大致意思是:为了更加专注让 Android Studio 变得更好更快,宣布停止对 Eclipse 中的 ADT 的开发和官方支持,包括 Eclipse ADT 插件和 Android Ant 构建系统。
在 2013 年官方推出的 Android Studio 的时候,我们就有关注,直到 2014 年 12 月份推出了第一个稳定版本 v1.0,我们意识到是时候切入进来了,但是由于公司的方案项目关联太多,而且开发时间紧、任务重,并没有立即切入进来。直到当时有一个智能摄像头的项目,方案商是台湾的,他们移交代码给我们的时候,发现他们已经开始使用 Android Studio 了,我们必须加快进度了。
结合当时公司的 Android 开发项目和人员的情况,做了一个非常重要的决定:从 2015 年 5 月 1 日起,所有的新项目必须无条件使用 Android Studio 开发,旧有的项目继续开发的话,转成 Android Studio,开发主管强制执行。虽然刚开始的时候,大家各种不熟悉,一定程度上影响了开发进度,但是 Android 开发者也乐于接受新的官方 IDE,两个月之后,所有的 Android 开发人员都已经很熟悉 Android Studio 了。
后来发现在 2016/2017 年上半年,面试 Android 开发人员的时候,有部分人都还没有开始使用 Android Studio 进行开发,这个就真是不应该了。他们给出的理由:有的说公司就我一个做 Android 开发的,之前的项目就一直用 Eclipse + ADT 的,我一个人也懒得换了。有的说公司领导也没有提出要使用 Android Studio,我自己就私下用用而已。有的甚至说 Android Studio 用得不习惯,比如快捷键什么的。
IT 行业是一个更新迭代快得吓人的行业,很有可能你两个月不跟上潮流,就落后了。我们要时刻保持对自己行业的敏锐性,积极的了解和使用各种新工具和新知识,才能在不断变化和迭代中,保持自己的竞争力。
参考资料:[官方]如何从 Eclipse 迁移至 Android Studio
2.Android Studio
Android Studio 一出,Android 开发者很是兴奋,终于有了自己专用的 IDE 了。Android Studio 确实能够让 Android 开发者面对 iOS 开发者使用 Xcode 的优势时的尴尬感降低不少。但是作为 Android 开发者本身,还是需要知道,其实 Android Studio 本质和 Eclipse + ADT 是一样的。可以这样来理解:
Android Studio = IntelliJ IDEA + Android plugin
我们看看 JetBrains 公司在发布 Android Studio 之后,官方的 IntelliJ IDEA and Android Studio FAQ:
No. Android Studio and the Android plugin for IntelliJ IDEA are built from the same code, and all of the changes in Android Studio are, and will continue to be, available in IntelliJ IDEA releases.
从以上描述来看,其实 Android Studio 就是 IntelliJ IDEA + Android plugin,只是很多新的功能和修改,优先在 Android Studio 上推出。其实 Android 开发者也不必沮丧,虽然 Android Studio 不像 iOS 开发的官方 IDE Xcode 是 Apple 公司从头开发的,但是从以下两点信息来看,Android Studio 的将来是不会比 Xcode 要差,甚至可能要比 Xcode 要好。
1.在 Android 官方发布不再支持 Eclipse + ADT 的公告文章中:An update on Eclipse Android Developer Tools 有下面一段话:
为了实现这一目标并且更加专注于努力让 Android Studio 更好、更快,我们将会在年底(2015 年年底)结束对 Eclipse 中的 ADT 的开发和官方支持,具体包括 Eclipse ADT 插件和 Android Ant 构建系统。
2.在 Android 官方宣布推出 Android Studio 的文章中:Android Studio: An IDE built for Android 有下面一段话:
为了开发 Android Studio,我们和当今最先进的 Java IDE 之一的创建者 JetBrains 公司进行合作。基于强大、可扩展的 IntelliJ IDEA 社区版本,我们添加了专门针对 Android 开发的功能,这些都能够帮助你简化和优化你每日的工作流。
从 “focus all of our efforts” / “we cooperated with JetBrains” / “features that are designed specifically for Android development” 等字眼,我们可以看得出 Android 官方的决心,在当今最优秀的 IDE 开发商之一的 JetBrains 和 Google 的强大技术背景,以及 Android 平台本身的开放,还有更多第三方开发者的贡献,Android Studio 成为一流的 Android 开发的 IDE 指日可待!
备注:2017 年 5 月份,Google I/O 宣布 Android Studio 3.0 版本,这是一个大版本更新,更新的内容包括:支持 Kotlin 语言、Java 8 语言特性、Instant App 、Android Things 新模板、Android O 开发者预览等。强烈推荐尝试!
3.IntelliJ IDEA
上文已经提到过,Android Studio 可以等同于 IntelliJ IDEA + Android plugin,而 IntelliJ IDEA 已经内置了 Android plugin,只需要像 Android Studio 一样安装 JDK 和 Android SDK 就行了。除了新功能优先发布在 Android Studio,其他的可以认为是一样一样的。建议直接使用 Android Studio 就可以了,这样看起来也更有 Android 开发者的归属感。
4.AIDE
这是一家位于德国的 appfour 公司出品的一个能够让你在 Android 设备上开发 Android 应用的 IDE,听起来是不是怪怪的?对,就是在 Android 设备上开发 Android 应用。大家第一反应觉得在 Android 设备上进行开发,性能能跟得上吗?开发方便吗?其实随着现在 Android 设备性能越来越好,并且还有诸如 RemixOS 这种针对 PC 交互优化操作后的 Android 系统,在 Android 设备上进行 Android 应用开发就不会觉得怪怪的、性能跟不上、操作不方便。你可以将 Android 等同于 Windows/macOS/Linux 一样的操作系统。
如果你想要在 Android 设备上体验开发 Android 应用的乐趣,AIDE 绝对是你的第一选择,但是缺点也比较明显,陌生的交互操作,不适合大型项目(编译运行慢),同时部分功能还需要付费。而且我们自己开发的时候,不仅仅是在 IDE 里面写写代码而已,我们还需要在网上查找资料,导入本地文件,引入第三方库,而在 Android 设备上,这一切的交互,还不适合高效率开发,但是论装逼,这种方式还是挺适合的。
综上所述,Android 原生开发 IDE 推荐情况如下:
推荐指数:强烈不推荐
说明:如果你看到这篇文章的时候还在继续使用 Eclipse + ADT 开发 Android 应用而都没有用过 Android Studio,你一定要从今天开始启用 Android Studio,完全放弃 Eclipse + ADT,尽管刚开始会影响开发效率,但是这没得选,否则你在 Android 开发这块根本就混不下去了。
推荐指数:☆
推荐人群:尝鲜与装逼的老司机。
说明:在 Android 设备上开发 Android 应用,基于开发习惯、性能和效率来说,不适合我们大多数 Android 应用开发者,但是作为体验和装逼用,效果还行。
推荐指数:☆
推荐人群:基于 IntelliJ IDEA 进行 Java 开发的老司机。
说明:上文已经描述过了,其实 Android Studio = IntelliJ IDEA + Android plugin,不要说切换过来不习惯,其实他们基本上差不多,而且新功能都是在 Android Studio 上首发,强烈建议切换过来,这样更加的专业与高效。
推荐指数:☆☆☆☆☆
推荐人群:新手与老司机皆宜。
说明:没有什么好说的,Android Studio 是 Android 原生开发最适合的 IDE,没有之一。
表 2:常见的 iOS 原生开发的 IDE
No. | IDE | 支持操作系统 | 是否收费 | 备注 |
1 | Xcode | macOS | 免费 | 官方 IDE。 |
2 | AppCode | macOS | 收费 | JetBrains 公司出品。 |
3 | Swift Playgrounds | iOS[iPad] | 免费 | Apple 公司出品在 iPad 上学习 Swift 的 App。 |
1.Xcode
从 2003 年 Xcode 1.0 版本,到现在的 Xcode 8.x 版本,13 年多的迭代,加上 Apple 产品的一贯对品质的要求,虽然称不上卓越,但是相对于早期 Android 开发的 IDE,绝对堪称优秀。iOS 开发人员无人不知,无人不晓。但是由于 Apple 的不开放,没有很多第三方的开发者深度参与 Xcode 的迭代,很多诸如代码补全、代码注释、自动导入头文件功能,要么就是没有多大提升(代码补全),或者就是迟迟不推出(代码注释),再就是可能永远都不会新增(自动导入头文件)。
还有一个就是一些第三方开发者开发的不错的第三方插件功能,官方再出一个类似的功能,完全不用第三方开发者的,连基本的 Inspired by *** 都没有,自己不努力,别人为你添砖加瓦,你反倒 copy 过来,对贡献者没有丝毫的尊重。
而且在最新的 Xcode 8.0 版本之后,不支持第三方插件,之前的部分第三方插件实现的功能,官方有替代方案,但是有的部分功能还没有原来的第三方插件强大,大家感觉这个是 Apple 对所谓的 Xcode 安全性的矫枉过正,不知道是不是被 XcodeGhost 事件搞得有点怕了。
Xcode 再怎么差,也是官方的 IDE,至少基本的功能、稳定性以及安全性是有保障的,对于新手来说,没得选择,必须学会使用 Xcode。
2.AppCode
刚才上面说了,对于 iOS 开发新手来说,没得选择,必须学会使用 Xcode,毕竟是官方的 IDE,如果你是老司机,也可以尝试下 JetBrains 公司出品的 AppCode,世界上最优秀的 IDE 公司之一,是值得信赖的。
1.代码补全。这种功能对于 IDE 来说不是新功能。但是 AppCode 的代码补全更加强大和智能,诸如非开头打头提示,结合代码上下文提示。(备注:结合代码上下文来提示代码补全,在容易产生混淆的导入情况下,很是有用。有用过 Eclipse + ADT 开发 Android 的人对 List 容易错误导入:java.awt.List,其实更多时候需要的是:java.util.List。)
2.代码生成。对于没有定义的变量,可以通过快捷键来生成。方法声明之后,通过快捷键生成方法实现,还有自动协议实现等。
3.快速导入头文件。做过 Android 开发的人,刚开始做 iOS 开发,最难受的就是没有自动导入头文件功能,而 AppCode 可以提醒快捷导入头文件。
4.代码重构。重命名、抽取方法、转换方法、常量转局部变量等强大的代码重构功能,让你代码优化更加快速。
5.CocoaPods 的自动 Install,这一点非常的好用,Xcode 里面你用 CocoaPods 导入第三方库的时候,还需要进行命令行操作,而在 AppCode 里面,你只需要编辑 Podfile 文件即可。
同样,AppCode 也有以下缺点:
1.AppCode 从以前旧版本开始就不再支持 Xib 和 StoryBoard 的编辑,当在 AppCode 里面编辑文件的时候,会直接跳转到 Xcode 里面。在官方社区里面已经说明了这一点:Does AppCode support drag/drop for Storyboards?
Nevertheless, we have the issue in the tracker: https://youtrack.jetbrains.com/issue/OC-12495. Feel free to comment or upvote.
2.AppCode 是需要依赖于 Xcode 的,没有安装 Xcode 的话,是不能进行全部的开发工作,除了第一个缺点之外,还有诸如应用上传 App Store,以及其他部分功能依赖 Xcode。
备注:在最新的 AppCode 2017.1 版本追加了对 Swift 3.0 版本的支持。
综上所述,iOS 原生开发 IDE 推荐情况如下:
推荐指数:☆☆☆☆
推荐人群:新手与老司机皆宜。
Xcode 作为 iOS 开发官方的 IDE,虽然有不尽如人意的地方,但是其性能和基本的功能还是没有问题的,而且部分功能还是其他第三方 IDE 不具备的。作为一个新手,Xcode 必须“入坑”。
推荐指数:☆☆☆☆
推荐人群:老司机。
1.在 Xcode 中创建新工程。
2.在 Xcode 中配置工程。
3.在 AppCode 中配置 CocoaPods。
4.在 AppCode 中编写代码。
5.在 Xcode 中编辑 Xib 和 StoryBoard。
6.在 Xcode 中调试代码。
7.在 Xcode 中导出 .ipa 包或提交到 App Store。
推荐指数:☆☆
推荐人群:学习 Swift 的新手。
这是一个利用游戏交互的方式,让你能够在 iPad 上面学习 Swift 编程的 App,虽然不如 Android 中的 AIDE 那么强大,也算是一个小型 IDE 了。Swift Playgrounds 适合刚入门学习 Swift 的人。
表 3:常见的 Android 原生开发的开发语言
No. | 开发语言 | 推荐的 IDE | 备注 |
1 | Java | Android Studio | 官方早期首选的进行 UI 和逻辑开发的语言。 |
2 | Kotlin | Android Studio | 2017 年作为官方首推开发语言。 |
3 | C/C++ | Android Studio | Native 开发语言。 |
1.Java
推荐指数:☆☆☆☆
推荐人群:新手与老司机
在前文中已经解释了 Google 为什么会选择 Java 作为 Android 的首选开发语言。Java 对于想要成为 Android 开发老司机的人来说,是必学的。Java 语言清晰易懂,学习起来相对容易。
有不会 Java 的即将加入 Android 开发的新手可能会问:既然 Google 官方将 Kotlin 作为首推开发语言,那么我是不是可以直接学习 Kotlin 而不管 Java 了呢?答案肯定是否定的,因为现在的 SDK 源码都是 Java 的,而且很多优秀的第三方库基本上都是 Java 的,Kotlin 才刚刚被 Google 宣布成为 Android 开发首选语言,想要完全取代 Java,还需要很漫长的时间。这个时候应该是巩固 Java 的同时,开始介入 Kotlin。
2.Kotlin
推荐指数:☆☆☆☆☆
推荐人群:熟悉 Java 的老司机
2017 年 5 月份 Google I/O 大会上,Google 宣布 Kotlin 语言成为 Android 开发的一级语言,那一刻,江湖人送外号“专利流氓”的 Oracle 公司,应该早就意识到这个时刻迟早会到来。当初 Oracle 公司对 Google 在 Android 中使用 Java 的专利问题,步步紧逼、咄咄逼人,提出高额索赔,最终还是败诉。Google 为了摆脱这个“定时炸弹”,和 Kotlin 眉来眼去,最终娶上门,吃下这颗定心丸。
1.100% 兼容 Java。
2.比 Java 更安全。比如对于空指针的处理,物化泛型对类型安全的处理。
3.比 Java 更简洁。比如大量的语法糖。
4.Kotlin 可以编译成 JavaScript 代码。
5.Kotlin 具备各种新语法:函数字面量、内联函数、空安全、自动转型、字符串模板、一级代理、类型预测、物化泛型等。
将来 Android 开发很有可能是 Kotlin 的天下,现在(2017 年 5 月份)开始上车,你就赢在了起跑线上。一定要抓住这个切入时机,Kotlin 搞起来!
参考资料:[官方]Kotlin 与 Java 比较
Tip:Kotlin 名字来源于俄罗斯的 Kotlin 岛。Kotlin 应该是俄语,不能直接以英语的读法来发音。在 Kotlin 官方针对 What is the correct English pronunciation of Kotlin? 回复中有以下说明:
yole@JetBrains Team
It is usually pronounced with the same sound as in “cot”: http://www.dictionary.com/browse/cot
根据以上说明来看,官方给出的 Kotlin 的正确英文发音:[kot]。
C/C++ 一般是通过 NDK(Native Development Kit) 来运用到 Android 开发中的。这个里面,我们需要好好理解一下 Native 这个词了。在 Native(计算机相关) 的维基百科词条 里面有这样一段话:
以上一段话中的后面一句的意思是:“Native” 这个词一般以 “Native Mode” 或 “Native Code” 形式出现。也就是 “Native 模式” 或 “Native 码”。“Native” 有“原生的,本地的”,我们可以将“Native Code” 翻译成“原生码”。维基百科将 Native Code 的维基百科词条 直接重定向到 Machine Code 的维基百科词条。因此我们可以将 “Native Code” 理解为“机器码”,是一套可以直接由 CPU 执行的指令集。
1.保护重要代码逻辑。Java 代码很容易被反编译,而 C/C++ 库的反编译难度较大。
2.可以方便直接使用现成的 C/C++ 库,不用自己还去用 Java 来实现。
3.提高程序的执行效率,C/C++ 编译之后是可以直接被 CPU 执行的指令集,效率要比 Java 高。
4.提高可跨平台性,用 C/C++ 编写的代码可以被很多其他平台直接使用。
除了以上几种情况下,建议使用 Java/Kotlin 来开发 UI 和普通逻辑。
备注:由于 C/C++ 代码编译之后,是可以被 CPU 直接执行的底层指令集,CPU 又有不同的架构,所以我们 C/C++ 代码需要生成针对不同架构的库,例如:armeabi/armeabi-v7a/arm64-v8a/x86/x86_64/mips/mips64 等。
表 4:常见的 iOS 原生开发的开发语言
No. | 开发语言 | 推荐的 IDE | 备注 |
1 | Objective-C | Xcode/AppCode | 官方早期首选的进行 UI 和逻辑开发的语言。 |
2 | Swift | Xcode/AppCode | 2014 年作为官方首推开发语言。 |
3 | C/C++ | Xcode/AppCode | Native 开发语言。iOS 支持 Objective-C/C/C++ 混合编译。 |
1.Objective-C
推荐指数:☆☆☆☆
推荐人群:新手与老司机
Tip:Objective-C,这个单词,很多 iOS 开发人员经常有意无意写成:ObjectC/Object-C 之类的,这是错误的写法,也不要简写成 OC,尤其是在简历中,所以要注意下这个细节。
Objective-C 属于一门比较古老的语言了,出现在 1984 年。一门能够坚持 30 年以上的编程语言,很难从严格意义上讲,有什么所谓的缺点。我们也不能进行批判,因为它已经经过了历史的检验。如果你了解 Java,同时也懂 Objective-C,就从我一个 Java 到 Objective-C 学习的角度列举一些这两者之间的区别,让读者自行意会。
1.Java 使用的是“.”语法,Objective-C 使用的是“[]”语法。
2.Java 有 “package” 方式来隔离相同类名的文件,Objective-C 不能出现相同类名的文件,需要通过类前缀来加以区分,可以理解为没有命名空间。
3.Java 方法的声明和实现都在同一个 “.java” 文件中,Objective-C 公开方法的声明需要放在 “.h” 文件中,方法的实现需要放在 “.m” 文件中。
4.Java 重写父类方法,需要标记 “@override”,而 Objective-C 没有标记。
在 TIOBE Objective-C 编程语言趋势 中有以下数据:
从上图中,我们可以很清晰直观的看到:在 2002 年到 2009 年上半年,Objective-C 还是一门很小众的编程语言,但是从 2009 年下半年到 2014 年 4 月份,市场占有率快速增长。我们再来看看
Apple 的明星产品 iPhone 在这几年发生了什么变化:
iPhone 部分版本发布时间:
iPhone 3G: July 11, 2008
iPhone 3GS: June 19, 2009
iPhone 4: June 24, 2010
iPhone 4S: October 14, 2011
iPhone 5: September 21, 2012
iPhone 5C, 5S: September 20, 2013
iPhone 6/6 Plus: September 19, 2014
很明显,自从 2009 年 6 月份开始,iPhone 3GS 出来之后,使用 Objective-C 开发 iOS 应用的人逐渐增加,直到 iPhone 6/6 Plus 时到达了一个顶峰。为什么图中从 2014 年 4 月份之后就开始下滑,而且下滑得比较厉害呢?这个下面和下面我们提到的 Swift 有很大关系。
虽然说从以上统计趋势来看,Objective-C 基本上是被 Apple 的 iOS 开发带了节奏,而且现在下滑得厉害。那么对于 iOS 开发新手来说,面对 Apple 新推出的 Swift,还有没有必要学习 Objective-C 呢?和 Android 开发新手面对 Kotlin 和 Java 一样的回答:我们肯定要学习 Objective-C,因为之前大部分第三方库,原有的项目等都还是用的 Objective-C,如果你不懂,怎么才能在这些原有的代码上进行开发,难道你要让他们所有人都全部转成 Swift?显然,这个不现实。我们不仅要学,而且要加快进度,尽快的成长为 Objective-C 的老司机,而且还要抓紧切入到 Swift 中去,这样你才会在 iOS 开发这块保持自己的竞争力。
2.Swift
推荐指数:☆☆☆☆☆
推荐人群:老司机
自从 Apple 在 2014 年发布 Swift 以来,引起了强烈的关注,特别是 2015 年 11 月份左右,以 Apache License 2.0 的许可形式对 Swift 进行开源,这就意味着大量的第三方开发者都可以来参与贡献 Swift 了,给开发者注入一针强心剂。一时间,Swift 将取代 Objective-C 的言论四起。
1.更加现代。抛弃了“[]”语法,选择了“.”语法。显然“.”语法更加深得人心。同时沿用之前的标签语法,让调用和参数的“备注”更加清晰明了。
2.更加简洁。方法声明和实现都放在同一个文件中,无需结尾分号等。
3.更加安全。例如对 “nil” 的处理。
4.内存管理统一化。
5.新的开发工具:例如 Playground。
Swift 从 2015 年 2 月份的排名第 27 位,到 2017 年 3 月份的排名第 10 位。短短两年间就排入了前十位,而且最近一年一直都在快速增长。
同样从上图我们也看到了 Objective-C 的持续下滑,为什么在 2016 年 2 月到 2016 年 11 月有短暂的回升呢?这是一个比较有意思的变化。我们看看这个时间段 Swift 干了什么:
以上时间段正好介于 Swift 2.2 版本向 Swift 3.0 版本演进的阶段,其实 Swift 刚出来,直接来拿进行 iOS 开发必然有各种坑,我猜测可能是一批直接从 Swift 入手的开发者,转而还是投入到 Objective-C 的怀抱中,使得 Objective-C 的市场占有率有一定的回升。等到 2016 年 9 月份 Swift 3.0 大版本出来之后,Objective-C 市场占有率又下降了。在 2017 年 5 月份的最新编程语言排名来看,Swift 排名(第 13 名)超过了 Objective-C(第 15 名)。各位司机们,Swift 3.0 版本发布之后,是时候赶紧上车了!
C/C++ 在 iOS 开发中,与在 Android 开发中,不太一样,本来 C/C++ 就和 Objective-C 属于同一系的,对于一开始就接触 Objective-C 的老司机来说,C/C++ 没有什么太大难度。
1.可以方便直接使用现成的 C/C++ 库,不用自己还去用 Objective-C 来实现。
2.提高可跨平台性,用 C/C++ 编写的代码可以被很多其他平台直接使用。
说了这么多移动应用原生开发相关的内容,其实我们还有很多其他的 IDE、编程语言和开放框架可以用来开发应用,尤其是跨平台开发,是非常重要的内容,我们继续梳理下。
在梳理跨平台开发(Android & iOS)内容时,有一个非常重要的概念需要我们有一定的理解:Native App/Web App/Hybrid App 三者之间的区别。根据我初步的了解,我画了一张图和辅助一张表格来辅助理解:
Tip:经常看到一些人容易将 Hybrid 错误的拼写成 Hybird,请注意这个词的写法,意思为:混合的。大家是否有留意到一些混合动力汽车,车后会标记 Hybrid 这个单词。
如果没有进行过 Native App/Web App/Hybrid App 三种不同类型的 App 开发,不容易深刻理解这三者之间的共同点和差别。但是对于初学者来说,我们只需要从大的方向上来理解这三种类型的 App 即可。
从上图中,我们可以这样来理解:
是用官方的原生开发语言,Android 的 Java/Kotlin/C/C++ 和 iOS 的 Objective-C/Swift/C/C++ 来开发的,或者是通过第三方语言(例如:C#/JavaScript+HTML+CSS/Python/Ruby/Qt/…)“桥接中转”来利用原生开发语言来开发,可生成和发布对应的 .apk/.ipa 包的 App。能够发挥设备最大限度的功能和性能。可以通过热更新或包更新的方式进行版本迭代。
备注:“桥接中转”技术可以用一个生活中简单的例子来类比,一个不懂德语的中国人(第三方语言)想要和一个不懂汉语的德国人(Andriod/iOS 系统)来沟通,需要通过英语(Java/Kotlin/C/C++|Objective-C/Swift/C/C++)来中转交流。
是采用 Web 技术实现的运行在浏览器中的“看起来像” App 的 Web 网站。由于是通过 Webview 机制来加载的 Web,设备功能和性能都受到了一定的限制。可通过服务器立即更新的方式进行版本迭代。
可以理解为 Native App + Web App = Hybrid App,Hybrid App 是外部表象(可生成和发布对应的 .apk/.ipa 包)为 Native App,内部主要功能采用 Web 技术实现,运用 Webview 机制加载主要功能。可通过服务器立即更新的方式对主要功能进行版本迭代,而局部功能可以通过热更新或包更新的方式进行版本迭代。
备注:不要认为我的 Native App 中使用了一个 WebView 来加载一个应用展示页面,就认为这个应用就是 Hybrid App,内部主要功能采用 Web 技术来实现,并且 Android 和 iOS 共用的 Native App 才算 Hybrid App。
最后一个问题,我们在做移动端开发的时候,纠结应该选择原生开发、跨平台原生开发、跨平台混合开发还是跨平台网页开发呢?
针对于公司来说,如何选择 Native App/Hybrid App/Web App 开发,还是三者都有,是需要很多因素来综合判断的,以下列表可供选择参考。
表 5:Native App VS Hybrid App VS Web App (备注:以下内容并未着重考虑游戏应用)
VS | Native App | Native App(c-p) | Hybrid App | Web App |
推荐语言 | Android: Kotlin/ Java/C/C++ iOS: Swift/ Objective-C/C/C++ |
JavaScript+HTML+CSS/ C#/Qt |
JavaScript +HTML+CSS |
JavaScript +HTML+CSS |
推荐框架 | * | React Native/ Xamarin/Qt |
Ionic+PhoneGap | Ionic+PhoneGap |
推荐 IDE |
Android: Android Studio iOS: Xcode+Appcode |
React Native: Nuclide/Deco Xamarin: Xamarin Studio |
WebStorm | WebStorm |
WebView | 非必要 | 非必要 | 必要 | 必要 |
应用形式 | Android:.apk 包 iOS:.ipa 包 |
Android:.apk 包 iOS:.ipa 包 |
Android:.apk 包 iOS:.ipa 包 |
Web |
更新方式 | Android:.apk 包更新 iOS:.ipa 包更新 Android & iOS: 热更新 |
Android:.apk 包更新 iOS:.ipa 包更新 Android & iOS: 热更新 |
Android:.apk 包更新 iOS:.ipa 包更新 Android & iOS: 1.热更新 2.服务器端更新 |
服务器端更新 |
分发方式 | Android: 1.Google Play 2.第三方商店 3.自主分发 iOS: 1.App Store 2.TestFlight 3.测试包(自主/第三方) 4.企业包(自主/第三方) |
Android: 1.Google Play 2.第三方商店 3.自主分发 iOS: 1.App Store 2.TestFlight 3.测试包(自主/第三方) 4.企业包(自主/第三方) |
Android: 1.Google Play 2.第三方商店 3.自主分发 iOS: 1.App Store 2.TestFlight 3.测试包(自主/第三方) 4.企业包(自主/第三方) |
服务器分发 |
技术难度 | ☆☆☆☆ | ☆☆☆☆☆ | ☆☆☆ | ☆☆ |
潜在坑 | ☆☆☆ | ☆☆☆☆ | ☆☆ | ☆☆ |
功能 | ☆☆☆☆☆ | ☆☆☆☆☆ | ☆☆☆ | ☆☆ |
性能 | ☆☆☆☆☆ | ☆☆☆☆ | ☆☆☆ | ☆☆ |
人力成本 | ☆☆☆☆☆ | ☆☆☆☆ | ☆☆☆ | ☆☆ |
推荐参考 | 1.传统方式 2.不考虑成本 3.追求功能和性能 |
1.现有技术快速切入 2.考虑成本 3.考虑功能和性能 |
1.现有技术快速切入 2.考虑成本 3.功能和性能不敏感 |
1.Web 代入 App 2.成本敏感 3.功能和性能不敏感 |
说完 Native App/Hybrid App/Web App 的区别,我们来梳理下跨平台开发框架:
表 6:常见的移动应用(Android & iOS)跨平台开发框架(Native)
No. | 框架名称 | 开发者 | 基于 | 推荐的 IDE |
1 | React Native | JavaScript | Nuclide/Deco | |
2 | Titanium | Appcelerator | JavaScript | Appcelerator Studio |
3 | NativeScript | Progress | JavaScript/TypeScript | Visual Studio Code/WebStorm |
4 | Xamarin | Microsoft | C# | Xamarin Studio |
5 | Qt | Qt | C++ | Qt Creator |
6 | Flutter | Dart | IntelliJ IDEA | |
7 | Codename One | Codename One | Java | IntelliJ IDEA |
8 | RubyMotion | Scratchwork | Ruby | RubyMine |
9 | PyMob | Pyzia | Python | * | 10 | B4X | Anywhere Software | Visual Basic | B4X |
11 | Lazarus | Lazarus Team | Pascal | Lazarus IDE |
推荐指数:☆☆☆☆
如果说你现在想要接触跨平台 Native App 开发的话,第一推荐的必然是 React Native,由“App 时代”的顶级互联网大公司 Facebook 维护的在 GitHub 上有接近 50K 的 Star 数,和超过 1300 个贡献者,虽然说并未发布正式版本,但是目前最新的版本已经到了 v0.45.1(2017 年 5 月份),如果你会 JavaScript/HTML/CSS,做跨平台 Native App 开发,首推的便是它了。
官方的 Slogan 有一句话:Learn once, write anywhere,意为:一次学习,到处编写。而不是:Write once,
run anywhere:一次编写,到处运行。也就是说,这个不是基于“一套代码”。
所谓“一套代码”,英文为 one code base,可以这样来理解,你写了一套通用代码,不需要针对 Android/iOS 平台分别编写额外的代码(部分平台相关的处理除外),就可以同时运行到两个平台了。Learn once, write anywhere 的意思是指:只需要学习一次,用学习到一套方法,来分别处理 Android/iOS 的应用逻辑,虽然部分逻辑可以共用,但是有些诸如 UI 层面的逻辑,还是需要分别处理。这种情况,不能称之为 one code base。
另外在 Hybrid App 开发中,会出现 one code base 的说法,因为 Hybrid App 主要基于 WebView 技术来实现的,而 Android & iOS 系统上 WebView 并没有太大差异化。
比如官方 API 中对于 DatePicker 这个控件,有两个 API:DatePickerAndroid/DatePickerIOS
2017 年 7 月份左右,由于 Apache 基金会对于 Facebook 采用的开源许可证提出异议,造成各大使用 React Native 框架的大公司一阵惊慌,尤其是国内的公司,大家纷纷开始采取替代方案,但是没过不到一个月的时间,Facebook 又更换了 React Native 的开源许可证,让大家又看到了曙光,让本来有机会上位的 NativeScript 又尴尬的沉寂了。这是一段不错的小故事,在这里就不展开了。可以参阅以下资料:
延伸阅读:
知乎专栏文章: React 的许可协议到底发生了什么问题?
知乎专栏文章: 都在封杀 React/React Native ,那我到底还该不该继续学呢?
2018-07-16 追加:
1.Airbnb 放弃 React Native
2.Udacity 放弃 React Native
推荐指数:☆☆
其实他们两个的原理与 React Native 差不多,但是基于 React Native 的强势与蓬勃发展,我认为以上两个基于
JavaScript/HTML/CSS 的跨平台开发 Native App 的框架,作为尝鲜,试一试就可以了。如果你不把 React Native 作为生产力首选,那么这两个也没有太大必要选择了。
备注:网络上有传闻早期 Titanium 是基于 WebView 技术的 Hybrid 解决方案,而后改成的基于 JavaScript/HTML/CSS 的 Native 方案。
Xamarin 是由微软推出的使用 C# 来进行跨平台开发 Native App 的框架,如果说你是一个 C# 开发者,可以一试。由于微软一直在大力推广,性能和更新迭代也还不错。
Qt 则是 Qt 公司的基于 C++ 框架,可以进行跨平台的 Native App 的开发,性能这块也还不错,对于 C++ 开发者,可以一试。
推荐指数:☆☆
Flutter 框架是由 Google 开发的基于 Dart 语言的,目前还是处于 alpha 阶段。Dart 是一种结构化的 Web 编程语言.Flutter 这个框架可以稍微关注下。
2018-09-13(Thu) 追加:目前 Flutter 已经开始推广起来了,我们可以通过 Android Studio 安装 Dart 和 Flutter 的插件就可以使用。Flutter 目前主要是针对 Android 和 iOS 的跨平台 UI 框架。具体细节技术问题可以参考 Flutter 官方 FAQ。
2018-12-06(Thu) 追加:Flutter 现在已经更新了 v1.0,在官网下面有这样一段话:Flutter 能够让你基于一套代码来构建漂亮的 Android 和 iOS 应用。这就表明 Flutter 完全可以跨 Android/iOS 平台代码重用。
推荐指数:☆
针对于 Codename One 采用 Java,RubyMotion 采用 Ruby,PyMob 采用 Python,B4X 采用 Visual Basic 和
Lazarus 采用 Pascal 的跨平台开发 Native App 的解决方案,个人认为只需要知道有这个就行了,正式的生产中,不建议使用了。
推荐指数:不推荐
讲到这里,顺便提一下微信小程序。据了解微信小程序是基于类似 React Native 技术,基于微信应用上的“应用”,我们可以理解为微信的“插件”更为合适,叫小程序的话,可以让第三方开发者觉得这个程序至少还是我们的,其实我认为是给微信开发插件而已。微信小程序是可以随着微信应用本身运行在 Android/iOS 系统中的。
而由于苹果 App Store 的生态,是对微信建立“国中国”是有很大的警惕的,而微信也是小心翼翼,只敢以“小工具”的面貌示人,像游戏或者其他重量级的内容,现在还不敢加入。
之所以没有把微信小程序列举出来,因为我个人确实是不推荐做微信小程序,或许有些场景实用。曾经看到一个做表情的小程序:“鬼畜表情包”,我认为这个还是不错的。其他的腾讯自己出的“王者荣耀群排行”小程序,也是蛮有实用场景的。除此之外,我见到的小程序,最后都不用了,不知道自己为什么不用了,可能是从心底就不是很认同这种实用场景了,可能还是用户体验,再就是入口太深问题。
另外腾讯出的针对开发者的东西,无论是之前的微信智能硬件、QQ 物联,还是现在的小程序,用过的人,或者见过网上吐槽的,各种 bug ,文档的不健全,咨询解答等服务匮乏,反馈慢。我从来不怀疑腾讯的技术能力,我怀疑的是腾讯是否真的用心去做这样的事情,真的,真正用过的人都懂,无需解释。所以,除非腾讯真的用心去做,否则真的没有必要去搞了。
如果想要了解微信小程序的技术架构,可以参见:微信小程序架构解析-腾讯前端专家渠宏伟。
微信小程序架构图
另外顺便提一下支付宝的小程序。阿里这块出小程序也算是一种跟进策略了,产品上没有什么创新我们有知道这个东西就可以了,实际用到的时候,再去进行具体开发实践吧。
支付宝小程序架构图
2017 年 8 月 20 日:科技大 V @Fenng 爆料:支付宝小程序的公测代码文档中赫然出现微信小程序团队各位开发者的名字。支付宝知乎官方账号在当天晚间正式发布道歉信,承认错误。支付宝小程序团队承认,在编写开发文档的示例部分时,直接copy了微信的示例。目前该团队已经立刻修改了这一部分代码,并向微信小程序团队道歉。
这个事件也间接证明了,支付宝小程序只是一种跟进策略了。
2018-09-13(Thu) 追加:目前微信小程序似乎也火起来了,我们看到了更多使用的产品场景,比如办公室无人货架的支付小程序,这个还是比较使用的,还有腾讯的企业邮箱小程序,其他的诸如九宫格图片处理,也还是不错的。
表 7:常见的移动应用(Android & iOS)跨平台开发 UI 框架(Native)
No. | 框架名称 | 开发者 | 基于 | 推荐的 IDE |
1 | NativeBase | Geeky Ants | React Native | Nuclide/Deco |
2 | weex | Apache | JavaScript/HTML/CSS | Nuclide/Deco |
3 | Kivy | Kivy | Python | Nuclide/Deco |
UI 框架,顾名思义,仅仅是用来处理 UI 的,给你封装好了各种 UI 控件,不处理其他的逻辑。
推荐指数:☆☆
NativeBase 是基于 React Native 的 UI 框架,还基于不同的设计风格,Android 的 Material Design 和 iOS 的 Flat Design 提供不同风格的控件。
推荐指数:☆☆
Weex 原本是由 Alibaba 开发的 UI 框架,后来转给 Apache 基金会了。Weex 支持 vue.js。
推荐指数:不推荐
Kivy 是基于 Python 的 UI 框架,我们仅仅需要了解有这个就行了。
表 8:常见的移动应用(Android & iOS)跨平台开发框架(Web/Hybrid)
No. | 框架名称 | 开发者 | 基于 | 推荐的 IDE |
1 | Cordova | Apache | JavaScript/HTML/CSS | Visual Studio/WebStorm |
2 | PhoneGap | Adobe | Cordova | WebStorm |
3 | Ionic | Drifty | Cordova/AngularJS | WebStorm |
刚刚对 Hybrid App 开发有一定了解的人,一定听过这 Cordova/PhoneGap/Ionic 三个框架,但是他们之间的区别,还是有点让人感觉混淆。
Adobe 公司在 2011 年收购了 PhoneGap 的公司 Nitobi,并且将名字正式命名为 PhoneGap。而后将代码开源并转移给了 Apache 基金会,Apache 将其命名成 Apache Cordova。Apache Cordova 是一个开源移动应用开发框架,它允许你使用诸如 JavaScript/HTML/CSS 等标准 Web 技术进行跨平台开发。
现在的 PhoneGap 基于 Apache Cordova 框架,但是 Adobe 为其提供更多的工具和服务。
而 Ionic 也是基于 Apache Cordova 框架,但是引入了 AngularJS,提供了更加美化的 UI 控件。
可以这样粗略的理解:PhoneGap 和 Ionic 的内核是 Apache Cordova,但是 PhoneGap 提供更多的工具和服务,而 Ionic 提供更加美化的 UI 方案。所以,可以结合 Ionic + PhoneGap 一起使用。无疑这个是 Web/Hybrid App 开发的上等方案。
表 9:常见的移动应用(Android & iOS)跨平台开发 UI 框架(Web/Hybrid)
No. | 框架名称 | 开发者 | 基于 | 推荐的 IDE |
1 | jQuery Mobile | jQuery | jQuery | WebStorm |
2 | Sencha Touch | Sencha | JavaScript/HTML/CSS | IntelliJ IDEA |
3 | Mobile Angular UI | mcasimir | AngularJS | * |
4 | Onsen UI | Monaca Team | JavaScript/HTML/CSS | * |
5 | Framework7 | iDangerous | JavaScript/HTML/CSS | * |
6 | MUI | DCloud | JavaScript/HTML/CSS | HBuilder |
以上列举的 Web/Hybrid App 的 UI 框架,只有真正使用过,才知道他们之间的不同点,已知的一些不同点就是 JavaScript/jQuery/AngularJS 的不同语言的区别。由于本人没有真正使用过,所以建议读者自行尝试。
备注:还有一种诸如 Telerik Platform/Monaca/The App Builder 这种 Cloud IDE,是不建议使用的,编码、调试、打包、发布都在云端操作,一旦网络或者服务存在问题,就搞大了。
另外还需要了解的是 Android 中有两种与 App 相关的特殊技术。
表 10:Android App 新技术
No. | 名称 | 基于 | 备注 |
1 | Progressive Web App | Web | 浏览器可将 Web 页面转成看起来像本地原生的 App。 |
2 | Instant App | 不清楚 | 浏览器访问 Web 页面,直接加载看起来像本地原生的 App。 |
推荐指数:☆☆☆
说明:Progressive Web App 技术是 Google 2015 年推出的可将 Web 页面 App 化的技术。具体功能展示参看上面的动态图。
Progressive Web App 相对于普通的 Web App 的主要优势在于:
1.可以添加添加到桌面,实现进入看起来像一个本地原生的 App。
2.可离线浏览部分数据和功能。
3.可使用通知和其他设备功能。(Google 承诺以后会与本地原生应用相同级别)
4.性能优化更好。
举例:BuzzFeed Tasty
使用步骤:
1.Google Chrome 浏览器地址栏输入:https://www.buzzfeed.com/tasty 然后 “Add to Home screen”。
2.在桌面上的图标点击进入即可。
注意:
1.不要认为只有 Google Chrome 浏览器才支持这个功能。其他部分浏览器目前也支持,比如:三星浏览器。
2.不要认为只有在 Nexus 手机上自带系统级的 Google Chrome 浏览器,或者是 Samsung 手机上自带的系统级的 Samsung Internet Web Browser 浏览器才支持这个功能。只是和这个浏览器是否支持 Progressive Web App 功能有关,和是否是系统级浏览器无关。Chrome 57 版本开始支持 Progressive Web App 功能。三星浏览器开始支持 Progressive Web App 功能的初始版本未知,不过三星对 Progressive Web App 还是蛮重视。
3.不要认为任何一个 Web 页面通过浏览器访问,然后通过添加到 Home screen,就可以自动实现 Progressive Web App 功能,这个需要自己去处理 Web 页面,自己引入 Progressive Web App 技术。
4.虽然说 iOS 系统中的 Safari 浏览器不支持 Progressive Web App,但是这并不代表着 Progressive Web App 在 Safari 浏览器上面完全不能用,只是部分属性或者功能不可用,不能添加到桌面,以本地原生 App 的样子进行启动,其他的还是可以使用的,因为 Progressive Web App 的本质还是一个 Web App。2017 年 10 月 24 日追加内容:目前 iOS 系统中 Safari 浏览器已经开始整体支持 Progressive Web App 功能,可能有部分特性不支持。想要测试效果的朋友依然可以在 Safari 浏览器中输入:https://www.buzzfeed.com/tasty 然后 “Add to Home screen”。
推荐指数:☆☆☆☆
说明:Instant App 是 2016 年 Google I/O 大会上提出的概念。大概的功能特性是这样:在 Android 设备上,你可以通过浏览器载入一个支持 Instant App 特性的 URL,然后就表象为:直接就像使用本地原生应用一样的感觉,而完全不需要下载和安装。如果说性能能够优化到分辨不出是本地 Native App,还是 Instant App,这绝对是一个非常具有划时代的技术,很多的应用我们只是偶尔使用,或者尝试使用某个应用,但是我们还是必须得下载安装,然后才能使用。这种技术可以直接通过网络载入这个应用,而不需要下载安装,如果说觉得这个应用很烂,我们就没有必要下载安装了,对于想要快速体验某个应用的用户来说,实在是黑科技。
注意:
1.2017 Google I/O 上发布的 Android Studio 3.0 (Canary) 预览版中已经加入对 Instant App 的开发支持了。
2.目前官方告知的是 Android 6.0[API Level 23] 及以上版本才支持 Instant App,但是后续版本会支持到 Android 5.0[API Level 21]。
3.Instant 功能是需要依赖 Google Play 服务的,因此目前国内 Android 手机没有安装 Google Play 服务并且没有翻墙的话,是不能体验这个功能的。
4.要想体验这个功能,首先你需要找到一个 Instant App 的例子,按照网上提供的例子,自己在 Nexus 5X(Android 7.1.1) 手机上测试并未出现 Instant App 的功能,网上资料提示需要在设置中打开 Google -> Instant Apps 开关,但是我的 Nexus 5X(Android 7.1.1) 没有这个设置,原因未知。
Tip:还有另外一个概念 Instant Run:这是在 Android Studio 2.3 新增的一个运行机制,这种技术能够显著减少项目构建和部署的时间。而 Instant App 是一种 App 运行技术,在 Android Studio 3.0 才开放给开发者。
最后再简单介绍下几个移动应用开发“跨平台”的其他特殊手段。
表 11:移动应用开发“跨平台”的其他特殊手段
No. | 名称 | 备注 |
1 | J2ObjC | 可以将非 UI 相关的 Java 代码转换成 Objective-C 代码。 |
2 | MyAppConverter | 可以将 Objective-C 代码 转成 Swift/Java,包含部分 UI 代码。 |
3 | Apportable | 可以将 iOS 应用整体转换成 Android 应用。 |
推荐指数:☆☆☆
推荐人群:尝试跨平台代码转换的老司机。
图片引自:Using J2ObjC for Cross-Platform Development
J2ObjC 是 Google 开源的能将非 UI 相关的 Java 源码转换成 Objective-C 源码的命令行工具。在 J2ObjC Github 页面项目说明中有以下一段话:
J2ObjC does not provide any sort of platform-independent UI toolkit, nor are there any plans to do so in the future. We believe that iOS UI code needs to be written in Objective-C, Objective-C++ or Swift using Apple’s iOS SDK (Android UIs using Android’s API, web app UIs using GWT, etc.).
J2ObjC cannot convert Android binary applications. Developers must have source code for their Android app, which they either own or are licensed to use.
J2ObjC 不会提供任何跨平台 UI 工具包,在将来也不会有任何的关于此内容的计划。我们认为 iOS UI 代码需要机遇 Apple 的 iOS SDK 使用 Objective-C,Objective-C++ 或者 Swift 代码来编写(Android UI 应当使用 Android API,Web App UI 使用 GWT 等)。
J2ObjC 无法转换 Android 二进制应用。开发者必须拥有或者授权使用的 Android 应用的源代码。
以上内容也印证了 J2ObjC 仅仅是用来转换非 UI 相关的 Java 源码到 Objective-C 源码的开源命令行工具。
推荐指数:☆☆☆
推荐人群:尝试跨平台代码转换的老司机。
MyAppConverter 是一个能够将 Objective-C 源码转成 Java 源码。与 J2ObjC 更进一步的便是:他可以转换部分 UI 源码,可以从官方文档中看出有以下 UI 转换:
表 12:MyAppConverter iOS 到 Android UI 转换对应表
No. | iOS UI | Android UI |
1 | UIView | RelativeLayout |
2 | UILabel | TextView |
3 | UIButton | AppCompatButton |
4 | UIImageView | ImageView |
5 | UITextField | EditText |
6 | UITextView | EditText |
7 | UISlider | AppCompatSeekBar |
8 | UISwitch | SwitchCompat |
9 | UISegmentedControl | RadioGroup |
10 | UIWebView | WebView |
11 | UITableView | ListViewCompat |
从官方文档的详细描述中看,每一个 iOS UI 布局或控件,都有对应的 Android UI 布局或控件,而且还细化到属性的一一对应。这个官方文档非常适合同时从事 Android 和 iOS 开发的同学进行参考。
推荐指数:☆☆
推荐人群:尝试跨平台应用转换的老司机。
目前官方分别提供应用和游戏的转换方案。针对应用的转换方案官网目前还打不开,也没有办法尝试。但是针对游戏的转换方案:SpriteBuilder这是一个开源的解决方案。
本文中提到的 Android 和 iOS,是通用广义范围的,是指 Google 和 Apple 移动端生态的。包括以下内容:
表 13:Android VS iOS 生态
分类 | Android | iOS | 备注 |
主系统 | Android | iOS | 主要用于手机和平板的移动操作系统 |
手表 | Android Wear | watchOS | 用于手表的移动操作系统 |
电视 | Android TV | tvOS | 用于电视的操作系统 |
汽车 | Android Auto | CarPlay | 用于汽车上依赖于手机的车载移动操作系统 |
物联网 | Android Things | HomeKit* | 用于物联网技术与产品 |
Android Wear/Android TV 与 watchOS/tvOS 均是基于 Android/iOS 主系统精简或者是修改适合当前平台的定制系统。而 Android Auto 和 CarPlay 都是需要借助数据线连接手机使用(具体细节暂未有机会使用体验)。Android Auto 相对于 Android 手机 UI 变化较大,而 CarPlay 相当于一个放大版的 iOS 系统。
Android Things 其实是早期 Brillo 的升级版本,是一个物联网操作系统。基于 Android 系统,但是针对物联网环境做了性能和开发的优化,让熟悉 Android 开发的人员也可以快速进入物联网开发领域,而 HomeKit 目前来说只是 iOS 系统中一个可以和各种智能硬件通信的 App。
延伸阅读:
@onevcat:2015-03-27 跨平台开发时代的 (再次) 到来?
说明:iOS 大神猫王早期的对移动端跨平台开发的看法。
@nwind: 2015-05-11 聊聊移动端跨平台开发的各种技术
说明:Baidu FEX 的前端大神 nwind 对移动端跨平台的深入剖析。
暂完结,会不停更新迭代。
AppX @ifeegoo https://www.ifeegoo.com/appx.html。