专家谈如何从传统开发向移动领域转型

  • 崔康

2013 年 1 月 14 日

话题:移动AndroidiOS语言 & 开发架构文化 & 方法

目前国内从事移动开发的工程师越来越多,除了新手之外,其中有许多人从传统桌面或者互联网开发中转型到移动领域,如何使转型之路更加顺畅,且看几位国内技术专家的心得分享

覃超是 Facebook 的工程师,他认为移动开发更加注重程序的效率:

我个人感觉 Mobile 上面更加注重程序的效率,程序要简洁,速度快,同时复杂度要尽量低。另外就是在写程序时具体要注意的事项,由于 Mobile 的处理能力不及桌面电脑,所以要格外注意将非 UI 相关的操作放入到 worker thread。相比开发桌面程序或者 web app,亦或者是现在的 iOS 或者 Android 开发,MVC 模式已经深入人心,它的本质就是把代码按照其做的事情分类,坐不同工作的代码在不同的模块里; Thread 分类和它也类似……

他以在 Facebook 的实际工作经验举例:

刚开始进行 Android Facebook 和 Facebook Messenger 开发的时候,我们的 Tech Lead——Jon Perlow 就在 code review 中不断指出我的很多操作还是像桌面程序一样放在主线程中,而 Android 下主线程即 UI thread,这样就很可能降低程序的流畅性。而且很多时候,也其中蕴藏着一定的平衡和折中。因为移入 worker thread 后,程序会出现很多 async method call 和 callback function/class, 这样对代码的可读性和以后的维护都是挑战,同时线程的切换和对于共享资源的同步也是会带来性能的损失,所以在写的时候要具体问题具体分析。比如说大规模 I/O 操作和上百万次的循环,自然不用说;但是在很多情况下,就没有如此明显吧,比如说判断一个文件是否存在, new File(getDucumentFolder + "/xyz").exist() 也算 I/O 操作,那到底要不要移入 worker thread 呢?

现在主要的手机平台就是 Android 和 iOS,覃超建议两个都要去了解,然后专注于一个平台:

回到上面那个线程切换的问题,Android 有三种办法:AsyncTask, Handler, Executor. 在代码里面(还有 Stack Overflow 上面的讨论),AsyncTask 是最差的办法,它属于 Google 自己加入的一个 Hack,大量在自己的 Android App 里面使用会发生阻碍程序性能的奇怪问题(因为你对它的 worker thread pool 没有任何控制);Handler 比较简单,适合将单个任务快速丢到另外的 thread 里面执行,但是从源代码就可以看出 Handler 本质上也是在调用 executor。最后就是 Executor 自己了,它的坏处是比较复杂,不注意容易出错,但是好处就是性能好,而且功能强大。可以自己定义 queue 的属性,指定 thread pool 的大小,和筛选并处理或者取消还没被执行的任务等等。所以只有在源代码里面去确认后,才会对每个模块在使用有直接和全面的了解。这样就能理解为什么公司里面 Android 的编程规范里面来一句“Don't use AsyncTask"是什么意思……多提一句,如果两个平台都做的话,还可以比较在 iOS 下面对线程切换的做法,iOS 上鼓励的是使用 GCD (grand-central-dispatch)。他们各有自己的特点,但是个人认为 iOS 的 GCD 更加简单,也更加符合人的思维……

友盟技术总监陈彧堃认为这是一种“工种转型”:

技术为产品服务,产品依托于生态系统。第一,在移动生态系统中,手机对于人的可识别度是超过传统互联网的,传统的 cookie 跟踪方法带来用户定位的模糊性,给数据清洗和挖掘带来了很大的限制。而在移动上,imei 和 udid 是更干净的用户标识方式,基于此,可想象的数据挖掘空间更大。第二,移动设备占据的是用户的碎片化时间,用户行为更丰富;第三,用户目前还习惯于一个应用只干一件事,需要 App 非常体贴用户才能长期占有用户的时间。

举个例子,地图应用中的 Local Search,用户随时根据自己的位置查询附近的餐厅 POI(Place of Interest)。这个在 Web 上当然很常见,但移动环境中用户位置高频变化,越来越习惯随时随地查询,这就难搞了。甚至出现了新的查询方式:查询周围的人。人的位置不断变化,给后端查询的索引系统在时间和空间复杂度,扩展性等指标提出了更高的挑战。Quad-Tree,R-Tree 这些高维空间索引结构也越来越多应用在工业产品中,MongoDB 和 MySQL 对 R-Tree 的支持就是例子。

对于转型的思路,他提了几点建议:

第三方信息抓取技术,个性化推荐,和社交关系图谱。在社交化之后,用户的兴趣和标签可以从站内行为分析,也可以通过多个社交平台的 API 取得用户公开的数据进行交叉挖掘和分析,这是个性化推荐的基础。个性化推荐会让应用变得情感化,一个让用户觉得有感情的应用,当然在设备上留存的时间也变长了。每个应用都有自己的用户体系和用户行为,有一套自己的用户模型……

碎片化时间,复杂环境使用体验,和海量数据。客户端适配复杂使用环境,比如要考虑强光弱光和交通工具振动环境下的可用性。用户行为构成大量流数据,对后台的数据处理,分析,以及产品迭代都造成了更大压力, Hadoop 被广泛应用在移动系统的分布式数据处理工作中,另外近期 Google 的 Dremel 和 Cloudera 的 Impala 也在为更实时的海量数据查询系统探路……

Peak-Labs 创始人、CEO 季逸超给出了具体的转型建议:

  1. 淡化文件的存在,而凸显应用和工作流。
  2. 尽量避让主线程 /UI 线程,避免锁界面。因为桌面应用锁 UI 的话只不过是一个窗口,而移动应用会给人感觉是“手机”这个整体挂了...
  3. 能迅速完成的操作 / 运算就不要指望后台,自己的程序随时可能被 kill 掉。后台只留给 VOIP、网络操作之类的。
  4. 尽量加快启动速度。移动产品用的频繁,但单次使用远比桌面要短,所以不要出现 Photoshop 那样让用户傻等的情况。即使用个“假象”也要让用户觉得启动挺快的。
  5. 同一个功能最好有多种交互 / 操作方式。不像 Windows 一统桌面江湖,现在各个版本的 android、iOS 用户之间使用习惯迥异,最好能让人们的习惯都能 work…….

海豚浏览器 CTO刘铁锋首先分析了传统 Web 开发人员的技术积累:

  1. HTML + CSS + JavaScript
  2. 各种脚本语言(PHP/http://ASP.NET/JSP/Python/Ruby)操作服务器 API
  3. 服务器数据处理逻辑(O/R Mapping, 数据库连接池,各种如 AOP 等设计模式,甚至 DSL 等等)
  4. 大型服务器的架构设计(分布式架构,各种负载均衡,服务器连接优化)
  5. 数据库(分布式数据库,事务处理,大规模数据的存储、查询优化)
  6. 大数据处理(Hadoop, Hive)等等。

那对于移动开发上需要什么?刘铁锋认为不管是 Android / iOS /WP , 其实对于开发的需求上逐渐回到了 2002 年之前,大概类比 MFC/Delphi 的时代,更加合适:

  1. 界面设计(各种 UI 控件,事件处理)
  2. 数据处理逻辑(客户端缓存、多线程并发)
  3. 网络数据处理
  4. 平台相关特性(系统 API 调用,系统通知机制等)
  5. 各种性能处理。

有关传统开发向移动领域转型过程中的具体讨论,请读者查看原文,也欢迎读者发表自己的看法——如何成功的实现从传统领域到移动领域的职业转型?

移动AndroidiOS语言 & 开发架构文化 & 方法