说转型 － 转载

 

【覃超的回答(91票)】:

说“转型”可能我还不够资格，由于我从工做开始就直接在作mobile，只是以前在大学里面搞过一些程序竞赛和TopCoder的组件开发在桌面电脑上面，因此从一开始我就是还没彻底定型的程序员，基本上什么东西都须要从头学习。第一次真正开发mobile程序仍是在CMU读master的时候，那时作毕业论文，研究Android系统的安全性，因而第一次装了Android的文档和本身照着样例写了一个，感受还挺不错（其实就是写Java）再后来就是进入Facebook后，从Boot camp毕业后就进入Mobile team，当时公司里面大部分人仍是搞PHP的，可是公司鼓励你们作Mobile开发，说是之后的方向，因而我从一入职就开始了全面的Mobile开发。

我的的经验以下：

技术方面： 我我的感受Mobile上面更加注重程序的效率，程序要简洁，速度快，同时复杂度要尽可能低。另外就是在写程序时具体要注意的事项，因为Mobile的处理能力不及桌面电脑，因此要格外注意将非UI相关的操做放入到worker thread。相比开发桌面程序或者web app，亦或者是如今的iOS或者Android开发，MVC模式已经深刻人心，它的本质就是把代码按照其作的事情分类，坐不一样工做的代码在不一样的模块里； Thread分类和它也相似。刚开始进行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呢？另外不少时候，你最开始的函数里面，可能操做很是简单，就直接在Main thread里就可，但是后来其余人在refactor的时候，将这些操做放开到好几个function里面去作，而后在之后的版本中，因为加入了新的feature，每一个function里面都比以前要作更多操做的时候，就逐渐逐渐地让Main thread的负担加剧，搞到最后给用户的感受就是这个App功能是变多了，但也愈来愈笨重，愈来愈容易crash。因此说，不要在UI thread里作事这点，想必只要智商上80的人都懂，可是真正要执行的时候并非如此得显而易见，而同时，公司里的项目都是多人做战，每一个人通常都着眼于本身作的那一块，这样很容易就形成最后UI Thread里面的工做量远比开始设计的要多。

如今主要的手机平台就是Android和iOS，因此建议两个都要去了解，而后专一于一个平台。若是Android的话，除了看Google官网外（http://developer.android.com/training/index.html ）， 不少时候当你具体要调用一个API，可是文档上面有疑惑的时候，最好的办法确定仍是能回到代码里面去确认。通篇浏览Android的代码确定不现实，我我的（也是公司里面）以为最有用的办法就是安装plugin：https://chrome.google.com/webstore/detail/android-sdk-reference-sea/hgcbffeicehlpmgmnhnkjbjoldkfhoin ，而后搜到文档后，页面上直接有一个连接 (View Source)来方便查看代码。回到上面那个线程切换的问题，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"是什么意思。（不少人问我为何不能用AsyncTask，其实在Android API的document里面就有http://developer.android.com/reference/android/os/AsyncTask.html#execute(Params...) ， 看它本身的注释。另外还有一个blog：http://commonsware.com/blog/2012/04/20/asynctask-threading-regression-confirmed.html ) 多提一句，若是两个平台都作的话，还能够比较在iOS下面对线程切换的作法，iOS上鼓励的是使用GCD (grand-central-dispatch)。他们各有本身的特色，可是我的认为iOS的GCD更加简单，也更加符合人的思惟。

另外就是UI方面，我作过Facebook Messenger for iOS的UI，可是设计毕竟不是来自本人之手，因此只当是本身的拙见。我的以为UI越简洁越好，另外就是在设计UI的不要进入误区：认为app的Android版本和iPhone版本UI要如出一辙。还有一些本身在作UI的时候，designer给个人细节性的建议：“好比text通常加一个pixel的半透明的shadow“， 按钮（透明）的实际大小通常比贴图再大一些，这样更方便用户触摸。

上面都是在讨论的时候，即兴想到的东西，没有太多整理。不过这两年在FB的打磨让我以为最重要的不是你的技术多牛，写代码写得多快，而是适应力要强，可以也愿意push本身去转型。我见过很多人，以前对某一技术或者某一领域炉火纯青了，就一直想呆在本身的领域里，说是精益求精也好，说是吃老本也好，更有甚者就是想用老本的技术来用于新的领域。Mobile上面跑HTML5的离线App我以为就是其中一个，具体细节我整理一下，放到另一个问题里。

【陈彧堃的回答(69票)】:

应邀做答，抛砖引玉了。

对于技术人员来讲，怎么从互联网向移动互联网转型？基础技术是相通的，C++/Java/LAMP这些基本功，若是拿到移动上就不能用了，码农的日子未免太苦逼。

彷佛「技术转型」一说过重，我更倾向于说「工种转型」。

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

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

这三个特色集中体如今社交应用或者包含社交元素的应用中，这和友盟最近的观察是不谋而合的：移动应用的社交化正在成为趋势。社交元素的加入，使移动应用的社区化和用户粘性获得大幅提高。硅谷一个投资人Fred Wilson之前提了一种说法叫「MobileFirst Web Second」：http://www.avc.com/a_vc/2010/09/mobile-first-web-second.html，最近他又跳出来写了篇文章叫「RethinkingMobile First」：http://www.avc.com/a_vc/2012/12/rethinking-mobile-first.html，就是在强调移动对于消费者和社交导向产品的重要程度，这和咱们的观察契合。

那么对技术人员来讲，移动+社交会带来怎样的挑战呢？如何「工种转型」？

 

第三方信息抓取技术，个性化推荐，和社交关系图谱

在社交化以后，用户的兴趣和标签能够从站内行为分析，也能够经过多个社交平台的API取得用户公开的数据进行交叉挖掘和分析，这是个性化推荐的基础。个性化推荐会让应用变得情感化，一个让用户以为有感情的应用，固然在设备上留存的时间也变长了。每一个应用都有本身的用户体系和用户行为，有一套本身的用户模型。但不能只依靠站内行为，缘由有二：

1. 站内行为不能解决冷启动问题

    

    

2. 社交平台上（如新浪微博，腾讯微博等）上有大量的用户数据，和站内行为互补，甚至远远超越站内用户行为。用户的挖掘工做可深可浅，浅的简单抓用户自定义标签，把设备和人等同起来；深的能够考虑：第一，为用户标签创建语义化模型。一堆标签不足以表明用户，想了解一我的须要创建层次化，归类化的用户属性模型；第二，考虑设备和人的多对多关系，目前主要指单用户使用多设备，手机，平板，用户行为有很大差别；第三，区分用户的转发和原创等细节行为的语义区别；第四，应用内用户属性的扩散挖掘。社交用户比例不太多是100%。但能够经过已知社交用户数据和站内信息交叉来扩散，用户会和信息交互，会产生大量的用户和信息之间的关系，也初步构建了站内的社交关系图谱，站内社交关系一旦生成，即可以将大量的社交信息扩散到非社交用户上，成为个性化推荐的基础。谈到个性化推荐，就不得不提Amazon在十多年前提出的协同过滤，通过这么多年的发展，目前已经成为工业界个性化推荐的标配技术，以及学术圈中一大研究方向。协同过滤的无数变种和改进也被普遍应用在不一样的产品中，但残酷的是，推荐算法的应用是个骑驴找马的长期抗战过程，会参合进用户属性，用户习惯，用户历史行为等不少因素，是须要长期反复训练才能不断完善的。

简单来讲，用户挖掘关键在于站内用户行为分析，用户—内容的关系图谱，用户—用户关系图谱。

 

碎片化时间，复杂环境使用体验，和海量数据

根据友盟最近的统计数据，移动互联网真正进入高速发展不超过3年，国内Android设备到达1.4亿，iOS设备到达6千万，用户增加速度远高于PC。移动设备占据了用户的碎片化时间，用户的启动次数和使用环境更为复杂。这对开发人员有几点考验：

 

1. 客户端适配复杂使用环境，好比要考虑强光弱光和交通工具振动环境下的可用性。

    

    

2. 用户行为构成大量流数据，对后台的数据处理，分析，以及产品迭代都形成了更大压力， Hadoop被普遍应用在移动系统的分布式数据处理工做中，另外近期Google的Dremel和Cloudera的Impala也在为更实时的海量数据查询系统探路。

    

    

3. 用户使用时间的分散也会给运维人员施压。根据友盟的数据报告，夜里22时，用户的使用会达到高峰，大量的使用会持续到凌晨2点。留给运维的用户透明时间明显缩短了，这也要求开发出更加自动化，智能监控的运维系统。

    

    

4. 产品的开发模式要变革，用户对于应用和内容新鲜感的需求更强烈。Scrum，测试驱动，站会等不必定知足快速迭代的需求，但单枪匹马不可能保持持续的战斗力，因此须要团队在打磨中能摸索出符合本身产品的开发方式。

看上去我谈的是偏后端数据处理，好像在PC和Mobile上没什么纯技术区别，这就见仁见智了。总的来讲，用户标识方式干净，使用户挖掘更有想象空间，因此用户数据挖掘这个工种会更重要；用户使用场景复杂，让Mobile的数据更丰富，处理，分析和反馈的实时性需求更高。使用频次和环境复杂度的量变引发技术需求上的质变，这就是跟PC的大面上的技术区别。

 

【季逸超的回答(60票)】:

后端方面请拜读彧堃同窗的回答，很是赞！我就从前端/客户端说说本身的拙见吧;-)

记得当时iPhone出来后，让人们看到了一个与传统的“窗口”彻底不一样概念的逻辑：界面方面一个应用占满整块屏幕，程序方面代码也都是在严格的沙箱内运行。当时我就意识到这将是一整套全新的规则体系，后来渐渐从表面往深层看，写了几年烂代码慢慢我也有了点心得：

1.淡化文件的存在，而凸显应用和工做流。

2.尽可能避让主线程/UI线程，避免锁界面。由于桌面应用锁UI的话只不过是一个窗口，而移动应用会给人感受是“手机”这个总体挂了...

3.能迅速完成的操做/运算就不要期望后台，本身的程序随时可能被kill掉。后台只留给VOIP、网络操做之类的。

4.尽可能加快启动速度。移动产品用的频繁，但单次使用远比桌面要短，因此不要出现Photoshop那样让用户傻等的状况。即便用个“假象”也要让用户以为启动挺快的。

5.同一个功能最好有多种交互/操做方式。不像Windows一统桌面江湖，如今各个版本的android、iOS用户之间使用习惯迥异，最好能让人们的习惯都能work。

6.最好不要让UI控件太显眼(好比街机游戏中硕大的摇杆遮住了人物)，但也别太隐晦(猛犸浏览器4,哈哈哈)。

7.用户其实很在乎耗电和发热量，桌面用户从不在意…

8.不少功能别人说作不到或说平台不容许不开放的时候，总有人用匪夷所思的奇葩手段实现了…

我的拙见请勿轻信哈~

还有个最近的风气,我的以为有些纠结：每次各类app更新完后，一启动就是几幅小清新图片+几句看不太懂的忧桑文字，其中最后一张带个按钮＂开始体验＂...并且不点掉＂分享到微博＂的话你就中招了...

【刘铁锋的回答(36票)】:

由于具体的开发场景不同，目标的读者的经验各不一。所以，没有具体分享特别具体的技术经验和教训，分享一点转型过程当中，所须要补充的知识点和逻辑上的转变。

移动开发和PC上的开发带来了哪些不同？

在我看来，从2002年以后，传统桌面的开发者基本都转向了J2EE/.NET/LAMP等以Web技术或者服务器端开发技术为主的开发方式。使用C/C++/MFC/Delphi等开发C/S模式的用户愈来愈少，甚至工做的需求也开始变得愈来愈少。

这样在技术体系上，开发者的经验开始基本上覆盖在：

 

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的时代，更加合适。

移动开发者的技能需求发生了转变，须要的经验变成了：

充分理解各移动平台的进程架构和程序生命周期逻辑（程序启动，程序被系统suspend/kill， Services）

 

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

 

所以，在学习的路线和须要的经验上有了不一样。

若是须要从非移动开发者往移动开发者进行转型，哪怕一样使用的是Java语言，须要的就是了解不一样的库以及处理不一样领域的具体问题。

在移动设备的开发上，我归结为三大类问题：性能的问题，界面响应的问题，产品的稳定性。这些是技术人员能够须要最为注意和保障的。

【王思达的回答(11票)】:

从桌面端转向移动端，必定要认识到两者不一样的侧重点。桌面端包括web更侧重于逻辑复杂，高级的任务，而移动端的娱乐性明显更强。

就从操做方式提及吧，桌面端主要靠鼠标键盘和touchpad，因此操做精度要高得多，很容易将不少功能集成到一个界面里；但一样的思路就彻底不适用于移动端了（反例我是实在想不起来了，你们能够帮忙想一想），相信一个cluttered ui的app，就算功能再强大，用户盯着你的界面超过3s就会头晕，点击某个button要点好几下才会成功，也一定是一个糟糕的app。

那什么样的操做方式是适用于移动端的呢？ListView的滑动操做就是一个很好的例子，不须要用户任何的思考，只需顺着期待的内容出现的方向滑动，这样intuitive的设计即是王道。相似的设计还有来自Tweetie的下拉刷新，Android 4.0引入标准库的ViewPager等等。上述的操做都有一个共同特色——手势操做。既然移动端（无论是手机仍是平板）是拿在手上的设备，那手势操做成为其杀手锏就绝不奇怪了，天然也就成了区分移动端和桌面端的一个重要特质。PeakJi大神的猛犸浏览器和输入法（忘记名字了）一样也体现了这一点。

有了简单直观的手势操做，还有一个不得不提的feature——push notification。用户很懒，一台机器装了上百个app，可能一个月你的app也就被打开一两次，这固然不是你但愿看到的。若是你的app是网站客户端性质的，那么push notification就是一个很好地利器了。怎么作呢？我总结了下面的流程：

1. 与社交网络链接，获取用户资料，分析用户兴趣

2. 记录用户在你的网站或客户端的使用习惯，逐渐逼近用户真正的兴趣

3. 根据获得的用户兴趣，推送他感兴趣的内容

能够看到，不只仅是“通知”那么简单，像新浪微博那样的，一天一条的palm news，多了只能让人感到annoying，并不能起到和用户很好的沟通的效果；只有推送用户感兴趣的内容，才会引发他们的注意，增长你的app在用户心中的权重。

最后一点我认为很重要的，就是consistency，和操做系统要保持操做习惯的一致性。好比左上角的返回button，Android 4.0的ViewPager滑动换标签等，这样作最大的好处就是下降了用户的学习成本，让你的app和OS融为一体。固然在OS的大框架下，也不乏有新意的app，好比Android下的一款类siri应用Maluuba，大胆地采用了Metro风格的设计，但操做起来并不会以为陌生，最大的缘由就是ViewPager的滑动操做被保留了下来。这样的例子还有不少，一时想不起来了，欢迎你们补充。

话痨打开了就有点收不住了，就这么多吧。

原文地址:知乎

     本文固定连接: http://www.zhihujingxuan.com/17579.html

知乎文章转载请注明: 技术人员在转向移动开发过程当中