⑴ 阿里IM技術分享(六)：閑魚億級IM消息系統的離線推送到達率優化
本文由阿里閑魚技術團隊逸昂分享，原題「消息鏈路優化之弱感知鏈路優化」，有修訂和改動，感謝作者的分享。
閑魚的IM消息系統作為買家與賣家的溝通工具，增進理解、促進信任，對閑魚的商品成交有重要的價值，是提升用戶體驗最關鍵的環節。
然而，隨著業務體量的快速增長，當前這套消息系統正面臨著諸多急待解決的問題。
以下幾個問題典型最為典型：
1） 在線消息的體驗提升；
2） 離線推送的到達率；
3） 消息玩法與消息底層系統的耦合過強。
經過評估，我們認為現階段離線推送的到達率問題最為關鍵，對用戶體驗影響較大。
本文將要分享的是閑魚IM消息在解決離線推送的到達率方面的技術實踐，內容包括問題分析和技術優化思路等 ，希望能帶給你啟發。
（本文已同步發布於： http://www.52im.net/thread-3748-1-1.html ）
本文是系列文章的第6篇，總目錄如下：
《 阿里IM技術分享(一)：企業級IM王者——釘釘在後端架構上的過人之處 》
《 阿里IM技術分享(二)：閑魚IM基於Flutter的移動端跨端改造實踐 》
《 阿里IM技術分享(三)：閑魚億級IM消息系統的架構演進之路 》
《 阿里IM技術分享(四)：閑魚億級IM消息系統的可靠投遞優化實踐 》
《 阿里IM技術分享(五)：閑魚億級IM消息系統的及時性優化實踐 》
《 阿里IM技術分享(六)：閑魚億級IM消息系統的離線推送到達率優化 》（* 本文）
從數據通信鏈接的技術角度，我們根據閑魚客戶端是否在線，將整體消息鏈路大致分為強感知鏈路和弱感知鏈路。
強感知鏈路由以下子系統或模塊：
1） 發送方客戶端；
2） idleapi-message（閑魚的消息網關）；
3） heracles（閑魚的消息底層服務）；
4） accs（阿里自研的長連接通道）；
5） 接收方客戶端組成。
整條鏈路的核心指標在於端到端延遲和消息到達率。
強感知鏈路中的雙方都是在線的，消息到達客戶端就可以保證接收方感知到。強感知鏈路的主要痛點在消息的端到端延遲。
弱感知鏈路與強感知鏈路的主要不同在於： 弱感知鏈路的接收方是離線的，需要依賴離線推送這樣的方式送達。
因此弱感知鏈路的用戶感知度不強，其核心指標在於消息的到達率，而非延遲。
所以當前階段，優化弱感知鏈路的重點也就是提升離線消息的到達率。換句話說， 提升離線消息到達率問題，也就是優化弱感知鏈路本身 。
下圖一張整個IM消息系統的架構圖，感受下整體鏈路：
如上圖所示，各主要組件和子系統分工如下：
1） HSF是一個遠程服務框架，是bbo的內部版本；
2） tair是阿里自研的分布式緩存框架，支持 memcached、Redis、LevelDB 等不同存儲引擎；
3） agoo是阿里的離線推送中台，負責整合不同廠商的離線推送通道，向集團用戶提供一個統一的離線推送服務；
4） accs是阿里自研的長連接通道，為客戶端、服務端的實時雙向交互提供便利；
5） lindorm是阿里自研的Nosql產品，與HBase有異曲同工之妙；
6） 域環是閑魚消息優化性能的核心結構，用來存儲用戶最新的若干條消息。
強感知鏈路和弱感知鏈路在通道選擇上是不同的：
1） 強感知鏈路使用accs這個在線通道；
2） 弱感知鏈路使用agoo這個離線通道。
通俗了說，弱感知鏈路指的就是離線消息推送系統。
相比較於在線消息和端內推送（也就是上面說的強感知鏈路），離線推送難以確保被用戶感知到。
典型的情況包括：
1） 未發送到用戶設備：即推送未送達用戶設備，這種情況可以從通道的返回分析；
2） 發送到用戶設備但沒有展示到系統通知欄：閑魚曾遇到通道返回成功，但是用戶未看到推送的案例；
3） 展示到通知欄，並被系統折疊：不同安卓廠商對推送的折疊策略不同，被折疊後，需用戶主動展開才能看到內容，觸達效果明顯變差；
4） 展示到通知欄，並被用戶忽略：離線推送的點擊率相比於在線推送更低。
針對「1）未發送到用戶設備」，原因有：
1） 離線通道的token失效；
2） 參數錯誤；
3） 用戶關閉應用通知；
4） 用戶已卸載等。
針對「3）展示到通知欄，並被系統折疊」，原因有：
1） 通知的點擊率；
2） 應用在廠商處的權重；
3） 推送的數量等。
針對「4）展示到通知欄，並被用戶忽略」，原因有：
1） 用戶不願意查看推送；
2） 用戶看到了推送，但是對內容不感興趣；
3） 用戶在忙別的事，無暇處理。
總之： 以上這些離線消息推送場景，對於用戶來說感知度不高，我們也便稱之為弱感知鏈路。
我們的弱感知鏈路分為3部分，即：
1） 系統；
2） 通道；
3） 用戶。
共包含了Hermes、agoo、廠商、設備、用戶、承接頁這幾個環節。具體如下圖所示。
從推送的產生到用戶最終進入APP，共分為如下幾個步驟：
步驟1 ：Hermes是閑魚的用戶觸達系統，負責人群管理、內容管理、時機把控，是整個弱感知鏈路的起點。；
步驟2 ：agoo是阿里內部承接離線推送的中台，是閑魚離線推送能力的基礎；
步驟3 ：agoo實現離線推送依靠的是廠商的推送通道（如：蘋果的 apns通道 、Google的fcm通道、及 國內各廠商的自建通道 。；
步驟4 ：通過廠商的通道，推送最終出現在用戶的設備上，這是用戶能感知到推送的前提條件；
步驟5 ：如果用戶剛巧看到這條推送，推送的內容也很有趣，在用戶的主動點擊下會喚起APP，打開承接頁，進而給用戶展示個性化的商品。
經過以上5個步驟，至此弱感知鏈路就完成了使命。
弱感知鏈路的核心問題在於：
1） 推送的消息是否投遞給了用戶；
2） 已投遞到的消息用戶是否有感知。
這對應推送的兩個階段：
1） 推送消息是否已到達設備；
2） 用戶是否查看推送並點擊。
其中： 到達設備這個階段是最基礎的，也是本次優化的核心。
我們可以將每一步的消息處理量依次平鋪，展開為一張漏斗圖，從而直觀的查看鏈路的瓶頸。
漏斗圖斜率最大的地方是優化的重點，差異小的地方不需要優化：
通過分析以上漏斗圖，弱感知鏈路的優化重點在三個方面：
1） agoo受理率：是指我們發送推送請到的數量到可以通過agoo（阿里承接離線推送的中台）轉發到廠商通道的數量之間的漏斗；
2） 廠商受理率：是指agoo中台受理的量到廠商返回成功的量之間的漏斗；
3） Push點擊率：也就通過以上通道最終已送到到用戶終端的消息，是否最終轉化為用戶的主動「點擊」。
有了優化方向，我們來看看優化手段吧。
跟隨推送的視角，順著鏈路看一下我們是如何進行優化的。
用戶的推送，從 Hermes 站點搭乘「班車」，駛向下一站： agoo 。
這是推送經歷的第一站。到站一看，傻眼了，只有不到一半的推送到站下車了。這是咋回事嘞？
這就要先說說 agoo 了，調用 agoo 有兩種方式：
1） 指定設備和客戶端，agoo直接將推送投遞到相應的設備；
2） 指定用戶和客戶端，agoo根據內部的轉換表，找到用戶對應的設備，再進行投遞。
我們的系統不保存用戶的設備信息。因此，是按照用戶來調用agoo的。
同時： 由於沒有用戶的設備信息，並不知道用戶是 iOS 客戶端還是 Android 客戶端。工程側不得不向 iOS 和 Android 都發送一遍推送。雖然保證了到達，但是，一半的調用都是無效的。
為了解這個問題： 我們使用了agoo的設備信息。將用戶轉換設備這一階段提前到了調用 agoo 之前，先明確用戶對應的設備，再指定設備調用 agoo，從而避免無效調用。
agoo調用方式優化後，立刻剔除了無效調用，agoo受理率有了明顯提升。
至此： 我們總算能對 agoo 受理失敗的真正原因做一個高大上的分析了。
根據統計： 推送被 agoo 拒絕的主要原因是——用戶關閉了通知許可權。同時，我們對 agoo 調用數據的進一步分析發現——有部分用戶找不到對應的設備。 優化到此，我們猛然發現多了兩個問題。
那就繼續優化唄：
1） 通知體驗優化，引導打開通知許可權；
2） 與agoo共建設備庫，解決設備轉換失敗的問題。
這兩個優化方向又是一片新天地，我們擇日再聊。
推送到達 agoo ，分機型搭乘廠商「專列」，駛向下一站：用戶設備。
這是推送經歷的第二站。出站查票，發現竟然超員了。
於是乎： 我們每天有大量推送因為超過廠商設定的限額被攔截。
為什麼會這樣呢？
實際上： 提供推送通道的廠商（沒錯， 各手機廠商的自家推送通道良莠不齊 ），為了保證用戶體驗，會對每個應用能夠推送的消息總量進行限制。
對於廠商而言，這個限制會根據推送的類型和應用的用戶規模設定——推送主要分為產品類的推送和營銷類的推送。
廠商推送通道對於不同類型消息的限制是：
1） 對於產品類推送，廠商會保證到達；
2） 對於營銷類推送，廠商會進行額度限制；
3） 未標記的推送，默認作為營銷類推送對待。
我們剛好沒有對推送進行標記，因此觸發了廠商的推送限制。
這對我們的用戶來說，會帶來困擾。閑魚的交易，很依賴買賣家之間的消息互動。這部分消息是需要確保到達的。
同樣： 訂單類的消息、用戶的關注，也需要保證推送給用戶。
根據主流廠商的介面協議，我們將推送的消息分為以下幾類，並進行相應標記：
1） 即時通訊消息；
2） 訂單狀態變化；
3） 用戶關注內容；
4） 營銷消息這幾類。
同時，在業務上，我們也進行了推送的治理——將用戶關注度不高的消息，取消推送，避免打擾。
經過這些優化，因為超過廠商限額而被攔截的推送實現了清零。
通過優化agoo受理率、廠商受理率，我們解決了推送到達量的瓶頸。但即使消息被最終送達，用戶到底點擊了沒有？這才是消息推送的根本意義所在。
於是，在日常的開發測試過程中，我們發現了推送的兩個體驗問題：
1） 用戶點擊Push有開屏廣告；
2） 營銷Push也有許可權校驗，更換用戶登陸後無法點擊。
對於開屏廣告功能，我們增加了Push點擊跳過廣告的能力。
針對Push的許可權校驗功能，閑魚根據場景做了細分：
1） 涉及個人隱私的推送，保持許可權校驗不變；
2） 營銷類的推送，放開許可權校驗。
以上是點擊體驗的優化，我們還需要考慮用戶的點擊意願。
用戶點擊量與推送的曝光量、推送素材的有趣程度相關。推送的曝光量又和推送的到達量、推送的到達時機有關。
具體的優化手段是：
1） 在推送內容上：我們需要優化的是推送的時機和相應的素材；
2） 在推送時機上：演算法會根據用戶的偏好和個性化行為數據，計算每個用戶的個性化推送時間，在用戶空閑的時間推送（避免在不合適的時間打擾用戶，同時也能提升用戶看到推送的可能性）。
3） 在推送素材上：演算法會根據素材的實時點擊反饋，對素材做實時賽馬。只發用戶感興趣的素材，提高用戶點擊意願。
通過以上我們的分析和技術優化手段，整體弱推送鏈路鏈路有了不錯的提升，離線消息的到達率相對提升了兩位數。
本篇主要和大家聊的是只是IM消息系統鏈路中的一環——弱感知鏈路的優化，落地到到具體的業務也就是離線消息送達率問題。
整體IM消息系統，還是一個比較復雜的領域。
我們在消息系統的發展過程中，面臨著如下問題：
1） 如何進行消息的鏈路追蹤；
2） 如何保證IM消息的快速到達（見《 閑魚億級IM消息系統的及時性優化實踐 》)；
3） 如何將消息的玩法和底層能力分離；
4） 離線推送中如何通過用戶找到對應的設備。
這些問題，我們在以前的文章中有所分享，以後也會陸續分享更多，敬請期待。
[1] Android P正式版即將到來：後台應用保活、消息推送的真正噩夢
[2] 一套高可用、易伸縮、高並發的IM群聊、單聊架構方案設計實踐
[3] 一套億級用戶的IM架構技術干貨(上篇)：整體架構、服務拆分等
[4] 一套億級用戶的IM架構技術干貨(下篇)：可靠性、有序性、弱網優化等
[5] 從新手到專家：如何設計一套億級消息量的分布式IM系統
[6] 企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等
[7] 融雲技術分享：全面揭秘億級IM消息的可靠投遞機制
[8] 移動端IM中大規模群消息的推送如何保證效率、實時性？
[9] 現代IM系統中聊天消息的同步和存儲方案探討
[10] 新手入門一篇就夠：從零開發移動端IM
[11] 移動端IM開發者必讀(一)：通俗易懂，理解移動網路的「弱」和「慢」
[12] 移動端IM開發者必讀(二)：史上最全移動弱網路優化方法總結
[13] IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞
[14] IM消息送達保證機制實現(二)：保證離線消息的可靠投遞
[15] 零基礎IM開發入門(一)：什麼是IM系統？
[16] 零基礎IM開發入門(二)：什麼是IM系統的實時性？
[17] 零基礎IM開發入門(三)：什麼是IM系統的可靠性？
[18] 零基礎IM開發入門(四)：什麼是IM系統的消息時序一致性？
（本文已同步發布於： http://www.52im.net/thread-3748-1-1.html ）
⑵ 一個合格的web前端需要會什麼
1. div和table
這個是最簡單的，也是最基礎的。要熟練掌握div、form table、ul li 、p、span、font這些標簽，這些都是最常用的，特別是div和table，div用於布局、table也可以用於布局，但是不靈活，基本 table是用來和數據打交道。
2.html
HTML是指超文本標簽語言，是目前web領域應用廣泛的語言，我們只需要在html文檔中插入對應的標簽，即可實現web頁面的編寫與排列，所以要熟練掌握HTML基本知識，包括每個標簽的用法等。
3. CSS
CSS指層疊樣式表，可以為HTML標簽自定義樣式，通過設置HTML標簽的樣式，來改變其外形，達到美化與排版web頁面的目的。
4.Javascript
Javascript是網頁腳本語言，它可以在html中運行，設置並修改瀏覽器中的各種對象與變數。例如用來改進設計、驗證表單、檢測瀏覽器、創建 cookies等等，現在各大網站都可以看見 Javascript的蹤影，常見的網站首頁大眼晴、警告提示框、頁面動畫效果等等。Javascript更是一種在客戶端廣泛使用的腳步語言，在 Javascript當中提供了一些內置函數、對象和DOM操作，藉助這些內容我們可以來實現一些客戶端的特效、驗證、交互等!
5.Jquery
Jquery是相當於把js封裝了一套的一個js插件，目的就是操作起來更方便，代碼寫的更少。 Jquery是一個免費、開源的輕量級的Javascript庫，並且兼容各種瀏覽器，同時現在有很多基於 Jquery的插件可供選擇，這樣在我們實現一些豐富的動態效果時更方便快捷，大大節省了我們開發的時間，提高了開發速度。
6.框架
從 bootstrap開始，響應式的珊格系統被後來框架一直沿用，建議學一套主流mvc框架，vue，react， angular兩選一種。
7.會點後台語言
對於前端工程師來說，並不需要像網站程序員樣，編寫對象、開發特殊功能、搭建資料庫。但是前端工程師要掌握基本的頁面GET＆POST傳參、程序判斷語法、程序輸出語法、頁面提交、資料庫查詢與記錄插入，以及掌握HTTP與WEB工作原理、掌握Socket長連接實時網路通信技術、掌握 NOSQL中的 MONGODB的應用、了解PHP語法、了解 MYSQL資料庫的基本操作。
當然，以上技能能夠幫助你成為一個合格的前端工程師，但要成為一個優秀的前端，必須掌握除技術以外的東西，例如設計，用戶等等，因此還需不斷的堅持學習。
⑶ web前端需要學什麼
前端前景是很不錯的，像前端這樣的專業還是一線城市比較好，師資力量跟得上、就業的薪資也是可觀的，學習前端可以按照路線圖的順序，
0基礎學習前端是沒有問題的，關鍵是找到靠譜的前端培訓機構，你可以深度了解機構的口碑情況，問問周圍知道這家機構的人，除了口碑再了解機構的以下幾方面：
1. 師資力量雄厚
要想有1+1>2的實際效果，很關鍵的一點是師資隊伍，你接下來無論是找個工作還是工作中出任哪些的人物角色，都越來越愛你本身的技術專業前端技術性，也許的技術專業前端技術性則絕大多數來自你的技術專業前端教師，一個好的前端培訓機構必須具備雄厚的師資力量。
2. 就業保障完善
實現1+1>2效果的關鍵在於能夠為你提供良好的發展平台，即能夠為你提供良好的就業保障，讓學員能夠學到實在實在的知識，並向前端學員提供一對一的就業指導，確保學員找到自己的心理工作。
3. 學費性價比高
一個好的前端培訓機構肯定能給你帶來1+1>2的效果，如果你在一個由專業的前端教師領導並由前端培訓機構自己提供的平台上工作，你將獲得比以往更多的投資。
希望你早日學有所成。
⑷ 做混合的話Uniapp和Flutter我應該學哪個啊
Uniapp目前比較成熟，而且用的是Vue語法，學習成本比較低，而且行業裡面用的也比較廣泛，而Flutter的話，學習成本略高，因為要學習新的語言，還有就是目前生態不是特別完備，等他再發展發展吧。黑馬程序員官網有成套免費視頻哦，有什麼不懂的可以直接過去學習。您的採納是對我成長的鞭策
⑸ 像美團外賣這樣的APP用一種開發語言，能開發得出來嗎
像美團外賣這樣的APP用一種開發語言，能開發得出來嗎？答案是不能。
美團發展到現在可以說已經是一個【巨無霸】了，裡面集成了很多很多功能，除了核心的外賣，還有 旅遊 、 娛樂 、購物、出行，金融等等業務線，那麼這么多復雜的業務根本不可能用同一種開發語言實現。
那麼美團都用到哪些開發語言和技術了呢？下面就根據我的理解詳細說一下。
前端是把產品的核心服務交給用戶的呈現者，它的表述方式、展示形式以及交互邏輯都跟用戶息息相關，都影響著用戶使用產品的體驗，也就是說直接影響產品的用戶留存。
前端開發主要分為三大類型：Andriod、IOS和PC（H5） ,Android開發語言是Kotlin和Java，IOS開發語言是Object-c和Swift，PC（H5）開發語言就比較雜了，有JS、CSS、HTML，還有很多第三方的前端框架，比如Angular.js、vue.js、Bootstrap、JQuery等等。
關於後端的功能，這一點可以說是眾說紛紜，主要需要考慮的是如何實現功能、數據的交互流程和存取、平台的穩定性與性能等。
那麼後端都用到哪些開發語言和技術呢？
根據後端技術選型的標准，後端可選的開發語言和技術是非常多的。
比如Java體系的話，可以選用SpringMVC、Spring cloud、Hibernate，Mybatis、Mysql、Redis、Memcache、zookeeper、Kafka......；
比如Python體系的話，可以選用Django、Flask、Tarnado、Web2py等，中間件都是通用的，Redis，MQ、MySQL、Kafka等都可以用在python體系中；
當然還有PHP、C、Perl等開發語言。
綜上所述，美團這個巨無霸公司，隨著業務線的擴展用到的技術肯定會越來越多，而且越來越復雜，技術快速變革的時代，適者生存的競爭性也會越來越激烈。
俗話說：羅馬不是一日建成的，任何事都不可能一蹴而就，包含技術。在以後的發展中美團也會逐步更新自己的技術和開發語言的。
至少三種語言。後端一種語言（比如Java丶Go丶Python丶PHP等），後端語言及生態比較成熟。下面重點聊前端App開發。
前台兩種語言（Android和iOS是不同的開發環境。比如Android用Java或者Kotlin，iOS採用Object C++或Swift），稱之為Native開發。
當然創業公司可以用一種前端語言寫App前端，這樣就不需要Android和蘋果分兩種語言寫，寫一次代碼可以編譯成Android和iOS的App，現在通行的方案有Vue之類的DOM渲染模式，以及ReactNative方案（RN）。性能上RN優於DOM渲染但低於用Native開發的App。所以美團這種公司，一定是Native方式寫App，但RN是初創項目不錯的選擇。
與RN競爭的還有一種新貴flutter，是google推出來的，但設計原理與RN不同，性能方面優於RN，只是目前生態不夠健全，國內有閑魚app是採用此技術。未來可能會佔一席之地。
最後，其實App開發已經是強努之末，我覺得主流應該是朝PWA和小程序方向發展。
你好，開發譬如美團這種APP，用一種語言是實現不了的，一個APP有安卓和蘋果兩個操作系統，開發能在安卓iOS端應用的APP主流的開發語言和技術是很多的，如後台有JAVA、C++、PHP、Python等多種開發語言，前端有kotlin、HTML、css、jquery、ajax、bootstrap、angular.js、react、vue.js、node.js、swift、object-c等多種語言和框架。
一個APP的開發是需要前端技術和後台技術共同配合完成，這樣的APP不論是功能還是性能都給用戶很好的體驗，單一開發語言畢竟技術支持有限，所以即使能開發出來，APP的用戶體驗也是不理想的。
一般APP有這幾種開發組合模式：1、原生安卓iOS開發，前端：JAVA、kotlin、swift、object-c後台：JAVA、PHP、C++等後台技術，這種模式開發周期長，成本高，性能好；2、混合APP開發即hybrid app，前端以網頁技術為主，穿插原生開發功能，兼具原生APP和web app的優點，如淘寶、微信等應用都是走的這個技術；3、web app，前端純網頁技術，後台為主流開發語言，這種模式開發速度快，成本低，界面體驗可能弱一些。
可見開發一款APP大多數都是多種語言配合完成，謝謝閱讀。
看完之前的評論，依然好奇為什麼一個語言不能完全勝任。
前端跨平台的方案有react native，cordova,flutter等，如果需要兼容開發小程序，h5頁面，可以採用taro來開發，一套代碼，所有平台通吃。
後端的方案有服務端運行時nodejs，大數據背景下運用而生的資料庫mobgodb，緩存解決方案redis，搜索工具elasticsearch，負載均衡ngix，基本上是需要什麼就有什麼
所以總結下來，一句話，一種語言可以實現類似美團這樣的app和小程序。為什麼美團使用的語言那麼多，一大原因估計是美團app開發的早，當時前端技術不成熟，工具沒現在這么多。
使用混合開發與C++ 進行跨平台開發，有好有壞。
C++ 進行跨平台開發
編寫一次，隨處運行。早在 2013 年，Dropbox 就採用上述策略進行移動開發，這背後的想法很簡單：用 C++ 編寫一次代碼，而不是用 Java 和 Objective-C 編寫兩次。那時，整個移動工程團隊相對還比較小，但需要支持快速增長的移動路線圖。因此，公司希望找到一種方法，使這個小團隊可以快速交付大量 Android 和 iOS 代碼。
如今，Dropbox 完全放棄了這個策略，轉而使用各個平台的原生語言（主要是 Swift 和 Kotlin ，這兩種語言在剛開始制定移動策略時還不存在）。
Hybrid App混合開發
Hybrid App主要以JS+Native兩者相互調用為主，從開發層面實現「一次開發，多處運行」的機制，成為真正適合跨平台的開發。Hybrid App兼具了Native App良好用戶體驗的優勢，也兼具了Web App使用HTML5跨平台開發低成本的優勢。
目前已經有眾多Hybrid App開發成功應用，比如美團、愛奇藝、支付寶等知名移動應用，都是採用Hybrid App開發模式。
移動應用開發的方式，目前主要有三種：
幾種模似都可以開發出應用，小應用無所謂，但是大流量應用，對圖形要求高的如 游戲 等原生開發的效果還是最好
支付寶打開很慢，就是因為採用混合開發，使用人多了不如原生開發
不行的哦。任何你看到的應用和網頁，都需要多個語言開發的，大的分比如前端和後端，用的語言都是不一樣的
⑹ web前端開發需要學習什麼知識
第一階段：
HTML+CSS:
HTML進階、CSS進階、div+css布局、HTML+css整站開發、
JavaScript基礎：
Js基礎教程、js內置對象常用方法、常見DOM樹操作大全、ECMAscript、DOM、BOM、定時器和焦點圖。
JS基本特效：
常見特效、例如：tab、導航、整頁滾動、輪播圖、JS製作幻燈片、彈出層、手風琴菜單、瀑布流布局、滾動事件、滾差視圖。
JS高級特徵：
正則表達式、排序演算法、遞歸演算法、閉包、函數節流、作用域鏈、基於距離運動框架、面向對象基礎、
JQuery：基礎使用
懸著器、DOM操作、特效和動畫、方法鏈、拖拽、變形、JQueryUI組件基本使用。
第二階段：
HTML5和移動Web開發
HTML5：
HTML5新語義標簽、HTML5表單、音頻和視頻、離線和本地存儲、SVG、WebSocket、Canvas.
CSS3:
CSS3新選擇器、偽元素、臉色表示法、邊框、陰影、background系列屬性改變、Transition、動畫、景深和深透、3D效果製作、Velocity.js框架、元素進場、出場策略、炫酷CSS3網頁製作。
Bootstrap:
響應式概念、媒體查詢、響應式網站製作、刪格系統、刪格系統原理、Bootstrap常用模板、LESS和SASS。
移動Web開發：
跨終端WEB和主流設備簡介、視口、流式布局、彈性盒子、rem、移動終端JavaScript事件、手機中常見JS效果製作、Zepto.js、手機聚劃算頁面、手機滾屏。
第三階段：
HTTP服務和AJAX編程
WEB伺服器基礎：
伺服器基礎知識、Apache伺服器和其他WEB伺服器介紹、Apache伺服器搭建、HTTP介紹。
PHP基礎：
PHP基礎語法、使用PHP處理簡單的GET或者POST請求、
AJAX上篇：
Ajax簡介和非同步的概念、Ajax框架的封裝、XMLHttpRequest對象詳細介紹方法、兼容性處理方法、Ajax框架的封裝、Ajax中緩存問題、XML介紹和使用。
AJAX下篇：
JSON和JSON解析、數據綁定和模板技術、JSONP、跨域技術、圖片預讀取和lazy-load技術、JQuery框架中的AjaxAPI、使用Ajax實現爆布流案例額。
第四階段：
面向對象進階
面向對象終極篇：
從內存角度到理解JS面向對象、基本類型、復雜類型、原型鏈、ES6中的面向對象、屬性讀寫許可權、設置器、訪問器。
面向對象三大特徵：
繼承性、多態性、封裝性、介面。
設計模式：
面向對象編程思維、單例模式、工廠模式、策略模式、觀察者模式、模板方法模式、代理模式、裝飾者模式、適配器模式、面向切面編程。
第五階段：
封裝一個屬於自己的框架
框架封裝基礎：
事件流、冒泡、捕獲、事件對象、事件框架、選擇框架。
框架封裝中級：
運動原理、單物體運動框架、多物體運動框架、運動框架面向對象封裝。
框架封裝高級和補充：
JQuery框架雛形、可擴展性、模塊化、封裝屬於傳智自己的框架。
第六階段：
模塊化組件開發
面向組件編程：
面向組件編程的方式、面向組件編程的實現原理、面向組件編程實戰、基於組件化思想開發網站應用程序。
面向模塊編程：
AMD設計規范、CMD設計規范、RequireJS，LoadJS、淘寶的SeaJS。
第七階段：
主流的流行框架
Web開發工作流：
GIT/SVN、Yeoman腳手架、NPM/Bower依賴管理工具、Grunt/Gulp/Webpack。
MVC/MVVM/MVW框架：
Angular.js、Backbone.js、Knockout/Ember。
常用庫：
React.js、Vue.js、Zepto.js。
第八階段：
HTML5原生移動應用開發
Cordova：
WebApp/NativeApp/HybirdApp簡介、Cordova簡介、與PhoneGap之間的關系、開發環境搭建、Cordova實戰(創建項目，配置，編譯，調試，部署發布)。
Ionic：
Ionic簡介和同類對比、模板項目解析、常見組件及使用、結合Angular構建APP、常見效果(下拉刷新，上拉載入，側滑導航，選項卡)。
ReactNative：
ReactNative簡介、ReactNative環境配置、創建項目，配置，編譯，調試，部署發布、原生模塊和UI組件、原生常用API。
HTML5+：
HTML5+中國產業聯盟、HTML5PlusRuntime環境、HBuilder開發工具、MUI框架、H5+開發和部署。
第九階段：
Node.js全棧開發：
快速入門：
Node.js發展、生態圈、Io.js、Linux/Windows/OSX環境配置、REPL環境和控制台程序、非同步編程，非阻塞I/O、模塊概念，模塊管理工具、開發流程，調試，測試。
核心模塊和對象：
全局對象global，process，console，util、事件驅動，事件發射器、加密解密，路徑操作，序列化和反序列化、文件流操作、HTTP服務端與客戶端。
Web開發基礎：
HTTP協議，請求響應處理過程、關系型資料庫操作和數據訪問、非關系型資料庫操作和數據訪問、原生的Node.js開發Web應用程序、Web開發工作流、Node.js開發Blog案例。
快速開發框架：
Express簡介+MVC簡介、Express常用API、Express路由模塊、Jade/Ejs模板引擎、使用Express重構Blog案例、Koa等其他常見MVC框架。
希望會給大家帶來幫助！