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

【AICon】如何构建高效的 RAG 系统？RAG 技术在实际应用中遇到的挑战及应对策略？>>> 了解详情 



 写点什么

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

覃超是 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 季逸超给出了具体的转型建议：

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

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