網絡時代寧河小程序開發文檔，獲取信息寧河小程序開發文檔的渠道變寧河小程序開發文檔的更多，也更便捷。然而在汪洋如海的知識里，如何能找到自己的方向，這需要一些技巧。

　　新的技術，往往是之前的一些技術，發生了一些突破，創新后變成了一種新的概念，描述，然而本質不會改變，我們要找尋的便是，通過網絡零散的知識，如何快速形成自己的學習計劃。

　　很多人遇到新的知識，總是顯得焦慮、不得章法，導致迷茫慌亂，反反復復地沒啥進展，時間成本很大，卻收效甚微。究其原因，在于沒得思路，不知該如何去學習。

　　一個新的知識出來，首先要看的是它是什么，它能做什么，對你而言你是要致力于這個方向，還是只是淺嘗輒止？每個人的精力有限，有時要學會借力打力，見招拆招。而不是自己奮力先自行修煉，認為自己可以出山，才出關道士下山。

　　如今知識爆炸時代，如果門門都去掌握，肯定是不現實的。如此就要去關注自己感興趣的方向，然后深入將核心掌握，然后抽離出來模型，放入實踐中進行驗證，完成自己的一套知識體系。

　　舉個例子，手機系統，拋開其他先做一個模型，手機組成為硬件，驅動，軟件。經歷過單片機，嵌入式開發版的人來說，拿到一些板子，外接一個LCD，然后自己去照著手冊，編寫驅動程序，封裝一些接口，讓做應用軟件的人員，直接使用調試好的這些接口，來完成功能實現。

　　當開發復雜的應用時，要做多任務，但顯示界面沒有一套UI庫，于是開始找開源的系統，比如μC/OS II 和uclinux等一系列的系統便涌了出來，解決任務，進程創建，調度現場保護等等，讓我們可以快速使用多任務而不用關注太多細節；多進程，完成更加復雜的事情，界面控件，響應，再借助別的GUI系統，比如wxwidget和 qt等等來完成搭建我們的界面庫，將其移植過來配合我們的系統，來實現繪制，響應。

　　關于操作系統，GUI的內部實現，我們可以不必深究，但必須了解其機理和懂得操作系統的大致實現進程的方式，比如構造一個PCB表，構造堆棧控件，線程切換保護現場模式。要能夠自己打通，形成自己的一套概念。

　　技術千變萬化，卻萬變不離其宗。腳本語言出現了那么多，實質還是一個解析器。按照約定，去讀取解析然后執行。然后我們把這個約定叫做語法，把解析叫做語法分析。將很多東西進行一句話總結。一句話模型，是自己先對某個知識，形成一個簡單的概念，然后順著這個方向，去細化知識，理解實現原理，然后回過頭來，加深一句話的總結，做到心中有數。

　　在剛接觸一個新的知識的時候，首先要做的是，搜索概念，了解它是干嘛的，然后去看下大家都用它在做什么。然后看下它是否能解決你的訴求。距離SDL框架來說，第一件事便是了解，它主要解決什么？它主要解決圖片的渲染，就是如何將一幀畫面顯示在各個平臺。用它來做個圖庫肯定是可行的。想用它播放視頻，既然它就是圖片顯示，那視頻解碼出來就是一幀圖片，如果借助其他的庫將視頻解碼出來，拿過來讓SDL去顯示，就可以播放視頻了。于是就找到了ffmpeg+SDL組合來完成視頻播放器。

　　那么它做游戲可以嗎？可以。想做復雜的，比如有地圖文件，物理碰撞，粒子炸彈效果，界面GUI，我們發現SDL本身沒有，所以要用它就需要移植。有人會說，何必呢？有一些現成的游戲引擎，支持的很好了。比如cocos2d和libgdx，開發游戲來說更加方便，快捷。確實如此，那么我們用SDL的意義在哪呢？其實SDL要做的很簡單，比如你開發了一個游戲，比如之前是在一個特定顯示器的，然后自己想移植到PC上或者ios或者android來玩，那么你要做的就是事件匹配，觸摸匹配，以及繪制匹配，而這些SDL已經幫你做好了，你就可以參照SDL的官方文檔將游戲移植過來了。

　　回到主題，我們怎么快速的掌握一個新的知識呢？

　　首先，官網介紹。官網會將它的用途講解出來。這個概念，你要快速形成模型來決定是否需要學習，短時間內是否能夠掌握。不必勉強不擅長的一味逞強去學習，到頭來自己迷茫，也沒啥收獲。比如學習手寫識別，做過一些demo，但是識別率比較低，而自己嘗試了下，發現這個領域，自己是沒法短期突破，因為不著思路，所以就要退出，說明這個方向不適合自己，就不要瞎去研究。當然，如果你有的是時間、須要研究，那就另當別論了。

　　從開始的技術流，看到什么都去學下，導致很多東西都是略知皮毛，導致都沒深度，沒有深度，意味著沒有競爭優勢。某個方向，發展成自己的優勢，尤為重要。技術流是做技術的核心競爭，但不可太過零散，要做到收放自如，哪些必須掌握，哪些可以一筆帶過，哪些需要研究一番，抓住主干，切不了細枝末節都牢牢抓住。當然，如果就是專攻此方向，那就另說。

　　學會整理、鑒別、快速搜尋答案。比如開發應用第三方庫，網上有很多對比，MPchart和hellochart，但hellochart比較簡單，并且它能解決訴求，于是就嘗試快速上手了。但開發完城后，使用時發現做的很多地方比較死板，讓開發的人員用起來比較別扭，這個就是時間問題了。如果覺得自己是長線要做圖表的，那就每個都看看，找到更適合自己的為止。

　　很多開源的都是需要簡單調試的，于是快速找出可以使用的為止，調整小的問題，需要有能力閱讀代碼完成修改。例如說greendao，一個非常好用的三方數據庫方案，在使用的時候發現不能創建兩個實例，也就是不能有兩個db文件被創建，有很多人開發，想賬戶和應用數據想獨立存儲，放在兩個db里面，那么可以確定greendao做不到，因為它的單例模式不允許，它的很多內容用了一個全局變量。想做成兩個db請換其他開源庫，如果不是必須要兩個db，那可以做兩個table來解決此問題。

　　要有能力解決問題，開源庫會磨煉技術，提升定位，以及修改問題的能力。

　　看完官網的介紹，覺得滿足自己的需求，那么就可以繼續閱讀，主要看下它的wiki或者示例、效果。自己搭建環境調試，看下是否能夠完成，如果過程中發現不是太好，就需要重新去找別的項目，不需在此過多糾結。

　　學完demo發現適合，那就研究下它的基本開發套路，能夠形成一個簡單輪廓，向自己的目標靠近。如果途中出現問題，要能夠從它的文檔中找出問題點，當然首先先百度，google搜索，去甄別答案。

　　如果找到一個開源項目，發現有些功能受限，比如glide，客制化時發現它的加載圖片功能不夠，于是需要研究代碼。

　　閱讀代碼，最好是帶著一個問題去閱讀，比如某個方法，我想擴展下，覺得它的返回，或者回調里面信息不夠，然后去追蹤，分析，定位。這里需要強調的一點是，不要盲目一路去追代碼，學會總結，不要被一些細枝末節的代碼導致迷失方向，比如一個方法就是比較一個點是否在矩形區域內，如果不是必須研究算法，那么我們就只關注這個返回值的判斷地方。對于有些宏，case項，可以看看枚舉值，對于理解會有所幫助；播放一個音頻文件，發現有個case有一個枚舉，TYPE_MP3 那么就可以去看看這個都有哪些枚舉，就能知道這里都支持哪些格式的播放；如果有些枚舉上有個宏控，那就知道這個功能是需要配置，有可能沒有開啟。

　　代碼閱讀的技巧太多，甚至每個人自成一套，只要努力去閱讀，失敗后總結，便會有自己的一套學習方法。

　　學習完后，做了demo，文檔看了一堆，終于解決了問題。于是就可以很歡快的將它納入自己的知識貯備。但如果這個項目后續會多次使用，那么要研究它便是遲早的事情了。需要花費大量的時間，快速整理出來學習思路，照它的demo，跟蹤代碼，理解，掌握。然后能夠打通，同時不會陷入細節里面。

　　到這里已經完成了新的技術的認識，后續便是是否想繼續挖掘，學習，那就要不斷的穿梭在代碼，文檔之間，同時借助搜索引擎來掃除理解的一些障礙。

　　例如需要理解一些android的概念，linux操作系統，虛擬機，surfaceflinger，AMS服務，binder通信機制，以及jni等等，概念先行，會將整體框架搭建起來，了解自己將來的的學習軌跡，并能夠知道自己當前走到哪里了，是否還需要繼續。再例如view.post，我們學到message.post則可以結束了，同時需要貫穿一下放入消息池中，從哪里取出，消費的。也就是handle message 和looper的關系。

　　思考，總是需要有所突破。不能每次都沉浸在別人研究的結論上，在別人的結論上，繼續深入挖掘，才能變成自己的獨特的見解，比別人多走一步，有自己的總結，以及更深更透徹的理解，這才是真正的收獲。

　　當經歷了數次語言的演變，就能透徹的理解演變的背后，往往跟隨著科技的進步。從之前的斤斤計較，對于內存，硬盤，以及堆棧區域大小，跳轉空間限制等等，到現在不需太多關注，編譯器優化，已經能夠做更加高效便捷了。

　　追求效率和品質，永遠是在制衡，到達一個平衡即可，切勿過度導致顧此失彼得不償失。現在的開發，若非實時要求非常嚴格，必須精準的計算執行時間，平時開發基本對于效率不會過度追求，對于計算排序算法不會太過較真，只為在容忍的時間內解決問題即可。

　　學習，在于有目標和有技巧地去掌握。有計劃學習并找到自己喜歡的課題時，請牢記深入學習。如果自己不喜歡，卻比較流行，那就學個demo了解背景，做到知曉即可。

　　開發應用，很多時候不做研究，拿來即可合入項目。如果是偶然開發，風險可以稍后推延，做到大致心中有數；如果是長線開發，比如公司，團體，那么初次使用，可以不做過多計較。如果第二次繼續使用，則需要注意，我們需要研究下代碼評估風險，做到心中有數，對于開源庫的優點、缺點、適合場景等等做出基本判斷。

　　學習永無盡頭，能有一套自成體系的學習方法，比之熟練掌握幾種語法，要有優勢的多。因為知識不斷在迭代更新，手握自己的漸變陳舊的技術，卻無力快速適應新的知識體系，理論，那么，技術革新的車輪，則會毫無情面的碾過你，連同你所經歷的歲月。