說轉型 － 轉載

 

【覃超的回答(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

知乎文章轉載請註明: 技術人員在轉向移動開發過程當中