我们把 iOS 的 Cocoa Touch 移植到了 Android
这是我最近一年在做的项目,用我们老大的话说,就是“能不能弄一个东西,让我的 iOS 程序一行代码不用改,却能运行在 Android 上”。为了这个目标,我们最后弄出了个这样的东西。
说起来我们之所以要做这个东西也是蛮有趣的。事情的起因,我们需要把一个为 iOS 写的排版引擎移植到 Android 上。但我们觉得这个排版引擎实在是太复杂了,而且把一个写好的 iOS 程序重新写个 Android 版本很无趣,那就变成了跟抄作业一样把 Objective-C 代码换成 Java 代码的行为了。
于是,为了移植这个排版引擎,我们面临两个选择:
把排版引擎移植到 Android
把 iOS 移植到 Android,不改排版引擎,直接在 Android 上跑
最终,我们选择了 2,于是我今后的一年(至今)就在搞这个东西了。
谈谈我个人的体会吧。我参与到这个项目之后,就真正体会到了 iOS 的博大精深。我之前当然知道 iOS 一定有很多很多东西,但是当真正参与了这个项目,才发现 iOS 居然是如此的庞大。以至于它的一个小小的方面居然就包含了那么多东西。
我本人的工作主要是把 Cocoa Touch 层移植到 Android 上去。具体就是如图:
把最上面那个青蓝色的方块移植到 Android 上去。顺便一提,iOS 的很多库是和 Mac 共用的。Apple 会用开源项目,Apple 自己闭源的东西会被别人开源。因此,如果是有历史的库,而且和 Mac 共用的库,一般都有开源项目可利用。但是 Cocoa Touch 层就比较坑爹,几乎没有可用的开源项目可直接使用。
于是,我本人的工作就是,手写 Cocoa Touch 层的代码,这个工作花了大概一年的时间。
某种意义上,我的任务性质有点像逆向推导出 Cocoa Touch 的内容。我需要查阅 Apple 的 API 文档,对文档的阅读要到细致到每个单词。然后给 h 文件填充实现,实现内容和 Apple 的程序员的实现越接近越好。但有一件事是 Apple 的程序员绝对不会做但我会做的,我还需要通过 JNI 调用 Android 的 API,并用 Java 编写一些功能让 Objective-C 使用。总之,至少在 Cocoa Touch 层这里,我要骗目标代码说它是在 iOS 上运行,而不能让它发现其实它是在 Android 上运行。
这个工作最麻烦的地方其实并不是在于“写出一个 Cocoa Touch 层”。光是写个 Cocoa Touch 是很简单的。难点在于,我手头能拿到的只有 Apple 的 API 文档以及和 h 文件。但是 API 文档给出的细节并不充足,这也可以理解,因为 API 文档是给开发 iOS 的开发者看的,可不是给我这种人看的。
因此,令人头疼的地方在于,针对具体实现,很多状态是隐藏的,也没有必要让 iOS 开发者知道这些状态,因此这些细节也绝对别想在 Apple 的 API 文档里找到。但是我必须知道这些细节,如果不知道这些细节,或者我自己写个实现有偏差的东西,到了 Android 上跑后会看到巨大的差异,而且这种差异极其难以定位。我这么说可能难以理解(恕我表达能力有限),总之就是“差之毫厘谬以千里”这样子。
这种定位的困难如果处理不当,对进度影响是很恶劣的。因为 bug 出现的地方可能和实际暴露的点之间隔了好多层呢。可能涉及到排版引擎的代码、各种开源项目的代码、我本人写的代码等。你要把 bug 和出问题的地方联系起来,不把整个项目拆了是做不到的。这种事情出一次,你也许得浪费 3、4 天时间来收拾。
而且更棘手的地方在于,如果你处理不好,这种现象可能每天都会冒出来。如果连续出个10几个,你就只能自杀了。幸运的是,我真的有认真考虑过这些可能性,并作了一些措施,结果,这一年里这种事情只出过几次。(但这几次就够呛了。)
这种问题经过我摸索,基本上靠两种方法解决。
第一,建立假设模型,然后实验。通过实验结果获取反馈,或者修改模型,或者证实模型。模型一旦证实,就可以开始码代码了。
第二,做实验可以获得大部分细节,但是某些太细节的东西做实验也没法活的。就只好先实现一个版本,然后假设它没有太大问题,等到之后证实有问题再改。
后一种情况比较坑爹,有些问题需要 3 个月才能暴露。将 3 个月后出现的问题与 3 个月之前写的代码联系起来是一件很头疼的事情。好在我 git 操作还算熟练。
对比起之前在另一家公司写业务逻辑代码的 Debug 过程,简直不要太轻松。有强大的 IDE,加上仅仅通过设置断点和打印日志就能发现 bug,简直太美好了。
现在,我们的排版引擎已经能顺利在 Android 上运行了。
你能想象,你用 MacBook 接上一台 Android 平板和一台 iPad,然后在 Xcode 按一个按钮,你的 Android 平板和 iPad 会同时打开一个相同的 App。目前我们就能达到这种程度。
不过很遗憾的是,我们的团队恐怕过几个月后就要解散了。虽然这个项目还有很多工作可以继续做,但是我们的团队恐怕不会继续做它了。以后可能会把它开源吧。
====================================分割线================================
文章转载自 开源中国社区[http://www.oschina.net]
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
FBI 威逼苹果交出 iOS 源代码
网易科技讯 3月15日消息,据美国媒体报道,美国司法部警告苹果,如果不帮助FBI解锁圣伯纳迪诺市枪击案一位凶手的iPhone,可能会强制该科技巨头交出操作系统的完整源代码。苹果就iPhone加密问题与FBI打的不可开交。 苹 果CEO蒂姆·库克明确表示,提供后门不仅可帮助联邦探员打开iPhone,而且也能帮助怀有恶意的黑客用于丑恶目的。周四苹果和FBI将出席法庭的听证 会。司法部最新的43页案件指导意见暗含对苹果的威胁,文件称如果苹果不拿出易受攻击版iOS系统绕过iPhone5c的密码保护,政府可能强制该公司提 交:iOS源代码和运行修改后软件所需的iPhone电子签名。 然后FBI自己的软件程序员可能制作有后门的、除去了安全功能的iOS系 统,然后贴上苹果的电子签名。司法部的文件称:“由于上诉讨论过的原因,没有源代码和苹果的私人电子签名,FBI无法自己修改法鲁克的iPhone软件。 政府不想强迫苹果交出源代码和电子签名,因为这种要求苹果可能不愿接受。但如果苹果愿意,可能提供一个不要苹果程序员费多少力的选项。” 苹果首席律师布鲁斯·休厄尔(Bruce Sewell)称,该文件是“污蔑苹...
- 下一篇
Android 构成垄断了吗? 是的
近日,美国反垄断监管机构开始调查谷歌(微博)Android操作系统是否存在反竞争行为。肯定会有一些人会问,Android真的构成垄断了吗? 谷歌本身不制造手机,它也没有逼迫任何人使用Android——是手机制造商自己选择了在手机上搭载这个软件。谷歌对Android并没有百分之百 的控制权,举例来说,数以亿计的Android智能手机在中国销售,既没有得到谷歌的“祝福”,手机上也没有谷歌的应用。Android是开源的,与 之相对的是封闭的苹果iOS,两者在美国市场进行着健康的、势均力敌的竞争。谷歌Android占有59%的市场份额,苹果iOS占有38%。从消费者的角度来看,这是一场公平的竞争,并不涉及垄断。 谷歌拥有发言权的主要地方是,它可以决定哪些设备能搭载谷歌应用和服务。如果你把这叫作垄断,那么这也是一种很公平的垄断:如果你投入了时间和金钱来开发 Gmail、Chrome浏览器、谷歌地图和YouTube这些复杂的应用,那么你就应该有权决定谁能使用它们。但是,当你考虑到谷歌最重要的应用时,事 情就变得更加有趣了——这个应用就是谷歌Play Store应用商店。它是Android应用的一个...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8