慚愧，最近下班回家沉迷山口山了，前一陣子搞antlr語法轉換，這一陣子搞微信小程序，一直拖著沒寫(xie) 點啥，一步一步來吧，肯定都得總結點東(dong) 西留給自己看的。
我一直是一個(ge) androids客戶端開發，前端經驗隻停留在w3cschool上麵很基礎的最初版本html,css,js學習(xi) ，純helloworld水準，就學了不到10分鍾。所以這裏也算是給客戶端開發們(men) 打點氣，新的東(dong) 西阻礙的永遠是你上手的動力，而不是這個(ge) 東(dong) 西的難易。順帶強調自己是前端外行，也是希望各位看官關(guan) 於(yu) 內(nei) 容裏如果有很多關(guan) 於(yu) 前端理解的偏差，幫我指正和修改。
加了一些小程序開發群，發現很多常問的問題是：
我的看法是，我反正從(cong) 來都不是這樣學任何一個(ge) 新東(dong) 西的，我就一句話
這也跟個(ge) 人接觸新東(dong) 西的習(xi) 慣有關(guan) ，反正我是完全不喜歡那種打算學個(ge) 新東(dong) 西（注意是’新’東(dong) 西），然後就問一下有啥經典書(shu) 籍麽(me) ？先抱著一本16開，三四厘米厚的一本大厚書(shu) ，（我習(xi) 慣叫磚書(shu) ，很厚很大砸人很疼），看個(ge) 好幾天一個(ge) 禮拜的，然後還沒上手。或者聽到個(ge) 新東(dong) 西技術是html，然後美名其曰技術儲(chu) 備，倆(lia) 仨禮拜略微看明白點html，css，但也毫無實戰經驗，倆(lia) 仨禮拜，連小程序的邊都沒摸到。
對於(yu) ’新’東(dong) 西，等係統化的出書(shu) ，黃花菜都涼了啊，以前搗鼓RN的時候，無數人問RN有什麽(me) 好書(shu) 看，現在RN書(shu) 停留的版本都是0.2X之前，並且一個(ge) 個(ge) 都很淺，現在0.3X已經天翻地覆了，這種啥都等係統化整理文章，做好技術儲(chu) 備，再開始動手，完全不是我的個(ge) 人學習(xi) 風格。
直接上手是最快的，雖然資料少，但是有源碼下，源碼是最好的指導方案，沒源碼，官方文檔，Github交流，網上及時閱讀最新的碎片化博客文章，這些絕對是最快的學習(xi) 和了解’新’東(dong) 西的手段。
光讀光看是絕對沒用的，最有效最有效的手段是，直接上手，上項目，哪怕是仿寫(xie) 一些開放API接口的app（知乎日報，豆瓣電影，有太多開放提供服務器api，讓廣大客戶端開發者練手的）
以上隻是我的個(ge) 人學習(xi) 習(xi) 慣，因人而異
當初RN出來就是這樣一波風氣，小程序出來也是，我對任何這種話題是毫無興(xing) 趣！這種然並卵的話題，鍵盤俠(xia) 們(men) 熱火朝天討論幾個(ge) 小時，時間就過去了，然後就可以happy下班了，有這功夫demo都寫(xie) 出來了，項目都上線了
上麵其實也扯了太多的廢話，微信小程序其實有自己的IDE開發環境，一切都在這個(ge) 開發環境裏麵，下載官方IDE開發包，開始運行，就可以直接開發預覽小程序了。
但這裏有個(ge) IDE開發包破解的問題，小程序目前需要是需要邀請碼的，有邀請碼你就會(hui) 有屬於(yu) 你業(ye) 務的微信小程序appId，有邀請碼的好處是你可以把小程序部署到真機上，沒有邀請碼，無論你是否破解了IDE，你都無法真機預覽，但是IDE裏麵的模擬器預覽完全沒有問題，能運行，能實現絕大部分功能，完全可以項目上先開發起來，等待一旦公測，就直接上線。
先說結論：現在的最新版本IDE，完全不需要破解！
服務項目
網站首頁
TEL：021-61554458無AppID的按鈕，點了後會得到提示無AppID部分功能受限
首先，感謝@老郭以迅雷不及掩耳盜鈴之神速第一時間破解了微信官方IDE，並且開源提供給大家使用，GitHub weapp-ide crack
因為(wei) 在早期的版本，微信的IDE，沒有AppID的人是無法體(ti) 驗的，必須經過破解，才能開始自己寫(xie) demo進行練手。而老郭在第一時間破解了IDE，讓所有人能從(cong) 代碼上第一時間體(ti) 驗這個(ge) 神秘的小程序（真機就沒辦法了）
後來倒逼微信官方，把小程序IDE直接開放，才有了上麵提到的無AppID模式。
但是，我使用破解IDE的時候，發現很多人遇到了個(ge) 問題，按部就班一步一步把IDE破解了，創建新工程的時候，是沒有quickstart這一部的，如果什麽(me) 都不太懂的人做到這一部，一打開工程，一個(ge) 文件沒有直接點運行，直接會(hui) 報錯，什麽(me) can not find app.js之類的，context之類的錯誤，我看到這個(ge) 後，直接從(cong) 網上順手找個(ge) demo（就在老郭的Git裏就有）扔到目錄裏，就一切運行了。
所以目前我的感受就是，破解倒逼了微信官方開放無AppID體(ti) 驗，簡直太威武了，但對於(yu) 經驗尚淺的新手，破解的一大堆東(dong) 西和步驟，很可能會(hui) 出現一大堆不知道為(wei) 啥的錯誤提示的時候，真的不如直接下最新版IDE，不破解直接無AppID體(ti) 驗。
官方文檔其實內(nei) 容真的不多，很多東(dong) 西寫(xie) 的很淺，光看文檔我是覺得很是吃力，因為(wei) 很多前端開發的概念並不深入，很多標簽，css的名字及其陌生，所以輔助上別人的demo食用就很讚
項目基礎文件
getApp()可以獲得app.js的這個app對象。頁麵文件
如果一個(ge) 頁麵起名叫HomePage，那麽(me) 我們(men) 就應該自行手動創建3個(ge) 文件，文件名一致才會(hui) 被係統正確的識別
還可以有個(ge) 可選的HomePage.json文件，頁麵也是可以擁有自己的.json文件進行一些專(zhuan) 屬配置的，但是頁麵的json可以配置的字段不如app.json多，職能配置關(guan) 於(yu) 本window相關(guan) 的一些表現，比如
後麵開始動手畫UI了，這個(ge) 我沒有啥教學的，因為(wei) 上文提供的github各種demo裏麵豐(feng) 富多彩的所有組件用法已經夠全的了，我這手把手的教如何寫(xie) 一個(ge) 按鈕，如何寫(xie) 一個(ge) text，如何水平排布好幾段文字，這就有點太無腦了。我舉(ju) 例幾個(ge) 項目中用到的界麵，然後寫(xie) 點我這個(ge) 小白在趟出這些界麵的時候遇到的一些問題點吧
小程序天然有一套數據和UI的綁定機製，在js文件裏有如下代碼，在onload裏麵發起網絡請求，網絡請求後回來，handleResponse，再之後setData，可以看到這個(ge) data其實就是一個(ge) vm
當任何時候在js邏輯裏麵，修改了data，這樣的wxml中，這種就是告訴負責UI的WXML，這塊UI要和bookList這個(ge) data裏麵的一個(ge) 字段進行綁定，任何時候data發生了變化，這個(ge) UI都會(hui) 根據最新的數據結果刷新
可以看出來，我的2個(ge) 頁麵，最重要的就是一個(ge) 書(shu) 籍詳情Cell，進行複用，避免代碼大量的機械性重複。
模塊化得從(cong) 3個(ge) 層麵，js，wxss，wxml來說
module.exports就可以封裝js的api模塊提供外部使用@import來把別的文件的樣式，導入全局，這樣各自page都能使用了<template>的方式創建一個模板，模板支持使用data傳入數據，我的項目裏沒這麽使用過，我用的另一種方案<include>他的作用其實隻是原封不動的代碼字符串拷貝，會拷貝目標wxml文件裏除<template>外所有的標簽，原封不動的拷貝替換到<include>位置（這是純字符串複製，不能支持指定代碼靈活變化，需要靈活變化請使用模板）下麵這個(ge) 代碼就是我的bookCell的wxml代碼，可以看到這裏大量使用了進行UI和data的綁定，這樣每次setData，都會(hui) 讓ui直接生效，但我這裏重點給大家看一下關(guan) 於(yu) 綁定點擊事件。
官方文檔裏麵寫(xie) 的真是比較簡單，bindtap="tapBook"寫(xie) 好了這一句後，每當這個(ge) UI元素被點擊的時候，都一定會(hui) 觸發對應page的.js文件中tapBook這個(ge) jsfunction，看起來很容易，但傳(chuan) 值呢？發生點擊我怎麽(me) 知道點擊的時候是哪個(ge) book被點擊了？第幾個(ge) 本書(shu) ？書(shu) 的id是啥？關(guan) 鍵就在這裏
data-sectionIndex="" data-rowIndex=""
這一行給添加了2個(ge) 屬性，都是以data-開頭，自定義(yi) 的名字為(wei) 結束，並且綁定上了2個(ge) 數據（for 循環的index，for循環後麵說），這樣添加自定義(yi) 的data-xx屬性就是為(wei) 點擊事件傳(chuan) 遞屬性的關(guan) 鍵
這是對應js代碼，當觸發tapBook的時候，會(hui) 把event當做參數傳(chuan) 入，event.currentTarget.dataset.xxx 就能獲取你剛才data-xx綁定的數據，我剛才把sectionIndex rowIndex的列表點擊index綁上了，於(yu) 是通過這個(ge) 方法取出來了。
切記，你在wxml裏幾遍data-xx，寫(xie) 了大寫(xie) 英文字母，此處在js裏調用的時候被自動全部變成小寫(xie) 了，你再寫(xie) 大寫(xie) 是undefine的
官方文檔裏麵給了好幾種for循環的方案，什麽(me) ，都可以綁定上一個(ge) js數組數據，然後按著數組的個(ge) 數循環渲染列表形UI，
這就是一個(ge) for循環創建列表的例子
wx:for的意思是告訴這個內用循環創建內容，循環所綁定的數組是listItem.column_list.book_infowx:for-item的意思是，你在下麵寫當次循環需要用到的具體數組元素，你起名成listBookItemwx:for-index的意思是，你在下麵寫檔次循環需要用到的數組下表，你起名成了rowIndex循環內(nei) 我include的代碼，就是上文點擊事件傳(chuan) 值介紹的代碼，這時候我們(men) 回過頭去看
<text class="novelBookTitleText">[] </text>
<view class="novelBookDesc" data-sectionIndex="" data-rowIndex="" bindtap="tapBook" tapIndex="">
怎麽(me) 樣，用到listBookItem數據在綁定上了吧，用到rowIndex在點擊事件了把，同理可知sectionIndex其實是另外一個(ge) 我沒展示的外層循環的wx:for-index定義(yi) 。
所謂API其實就是，在js文件裏，微信也提供了很多native API，以wx.xxx開頭，官方API文檔，包括很多內(nei) 容，我就不一一舉(ju) 例了，這裏舉(ju) 例幾個(ge) 比較重要的分類
可以看出，都是直接跟網絡，跟設備，相關(guan) 的信息。
我們(men) 在小程序mvvm裏麵已經看到了一段關(guan) 於(yu) wx.request的演示，這裏演示一下，界麵之間跳轉
wx.nativateTo是有數量限製的，小程序界麵棧層級不能超過5的，所以很多場景可以選擇使用wx.redirectTo
可以看到，界麵跳轉通過url跳轉，而傳(chuan) 值也通過url的方式傳(chuan) 值，你傳(chuan) 過去的值會(hui) 直接寫(xie) 進onLoad生命周期函數的options參數裏麵，名字和你在url裏麵寫(xie) 的是一樣的。
說實話，一直以來都在做客戶端開發，這種css式的界麵開發模式，實在是太陌生了，css式的思維，css式的嵌套，對一個(ge) 新手來說有點痛苦。
我的Github上麵的小程序Demo 這裏麵的代碼其實不多，基本上是我們(men) 項目的雛形，但最讓我頭疼的就是那些css，我整整寫(xie) 了一整天，才大約摸到一丟(diu) 丟(diu) 前端開發，css思維的方式方法
這個(ge) 我也沒啥好說的，畢竟我是大大大大菜鳥，就是多寫(xie) 寫(xie) 就有感覺了。
值得一提的是IDE對於(yu) WXSS文件裏，css的代碼補全非常讚，各種都能第一時間補全，對於(yu) 我這個(ge) 根本記不住那麽(me) 多css名字的新手來說，這個(ge) 實在是太好了。
另外，完全支持- position: absolute和- position: relative的絕對坐標布局，也完全支持flexBox的彈性盒子布局，和我一起的小夥(huo) 伴表示，基本上大部分的css都是直接可以用，我把線上項目遷移到wxss的時候也感覺到了，打開chrome的debug模式，照著線上wap站，原封不動的照著寫(xie) css布局參數，基本上沒有任何問題
大家玩起來就知道了，微信小程序的調試模式，和chrome的debug模式一模一樣，其實這個(ge) ide就是拿nw.js寫(xie) 的，裏麵是一套webkit，源碼裏麵就有chrome的debug’tool的js代碼哈哈
關(guan) 於(yu) 這個(ge) 小程序底層是如何運作的，在剛出的第一天，就引來無數的遐想，wx獨有的wxml wxss到底是拿什麽(me) 做的？到底是不是h5?到底能不能做成native體(ti) 驗？無數人都在猜測。
在最開始的時候，ide被破解，並且被證實ide是基於(yu) webkit做的，很多人猜微信在真機上就是webview啦（後麵事實證明，目前也還真是）
但我當時就覺得這其實說明不了啥，wx特別抽象出來的 wxml結構，就是想定義(yi) 一個(ge) 獨立出來的獨有抽象層，他雖然目前把這個(ge) 抽象層（一種自己獨有的vdom結構？我是前端新人，不一定對哈），最後又重新通過編譯轉成了html，最後交給webview來展現（輔助綁定上了一些native插件，比如wxapp裏麵的視頻，tab，navi，input keyboard，map等等，都是通過addsubview的方式直接add到UI/WKwebview上的）
但是這並不代表，這樣的架構就是依賴在webkit，和webview的，完全獨有的抽象中間層vdom，就是為(wei) 了擺脫對webkit的依賴，未來可以很輕鬆的切換底層架構，直接切換成reactnative or weex 那樣的vdom + native渲染的模式，這樣就沒了webview的依賴，（雖然現在選擇的方案，是又繞路回到了html和webkit，但依賴和選擇權已經牢牢攥在了自己手裏）
微信小程序開發人員回答渲染機製
這篇文章看起來官方人員態度有點遮遮掩掩，含糊其辭，通篇都沒直指要害-如何渲染，但我覺得解讀一下，是這樣的潛台詞（開玩笑！莫噴：我們(men) 很高大上，我們(men) 抽象了很多東(dong) 西，其實我們(men) 還是主要用webview渲染，輔助了很多native，就是不太好意思這麽(me) 直白的說出來）
但我特別認可微博上的這個(ge) 回答
立即谘詢