1、你是怎么封裝小程序數(shù)據(jù)請求的？

• 我們會在現(xiàn)在小程序根目錄下，創(chuàng)建一個config.js作為一個獨立的模塊，用以放置API前綴及其它需要全局配置的相關(guān)配置，然后通過export 導(dǎo)出，供其它模塊調(diào)用；
• 創(chuàng)建utils目錄，然后再創(chuàng)建http.js文件，在這個文件里我們會用promise把wx.request封裝成一個HTTP的父類；
• 我們會在項目的models目錄下也就是數(shù)據(jù)層，再創(chuàng)建一個子類然后繼承父類HTTP，在這個子類里面會編寫具體的API請求；
• 最后在視圖層的JS中，完成數(shù)據(jù)的獲取及綁定，渲染到視圖。

2、有哪些傳值的方法？

• navigator組件或wx.navigator；
• 本地存儲；
• app.js中的全局對象；
• 自定義屬性data-xxx；

3、在項目中你如何優(yōu)化小程序的速度？

• 控制上傳包的大小
  1. 勾選開發(fā)者工具中“上傳代碼時，壓縮代碼”選項
  2. 及時清理無用的代碼和資源文件（包括無用的日志代碼）
  3. 減少資源包中的圖片等資源的數(shù)量和大小（理論上除了小icon，其他圖片資源從網(wǎng)絡(luò)下載），圖片資源壓縮率有限
• 采用分包加載機制
  1. 根據(jù)業(yè)務(wù)場景，將用戶訪問率高的頁面放在主包里，將訪問率低的頁面放入子包里，按需加載；
  2. 將小程序中不經(jīng)常使用的頁面放到多個分包內(nèi)，主包只保留最常用的核心頁面；
  3. 使用分包時需要注意代碼和資源文件目錄的劃分。啟動時需要訪問的頁面及其依賴的資源文件應(yīng)放在主包中。
• 采用分包預(yù)加載技術(shù)
  1. 在上一條的基礎(chǔ)上，當(dāng)用戶點擊到子包的目錄時，還是有一個代碼包下載的過程，這會感覺到明顯的卡頓，所以子包也不建議拆的太大，當(dāng)然我們可以采用子包預(yù)加載技術(shù)，并不需要等到用戶點擊到子包頁面后在下載子包，而是可以根據(jù)后期數(shù)據(jù)，做子包預(yù)加載，將用戶在當(dāng)先頁可能點擊的子包頁面先加載，當(dāng)用戶點擊后直接跳轉(zhuǎn)；
  2. 這種基于配置的子包預(yù)加載技術(shù)，是可以根據(jù)用戶網(wǎng)絡(luò)類型來判斷的，當(dāng)用戶處于網(wǎng)絡(luò)條件好時才預(yù)加載，是靈活可控的。
• 首屏加載的優(yōu)化建議
  1. 利用緩存storage API, 對變動頻率比較低的異步數(shù)據(jù)進行緩存，二次啟動時，先利用緩存數(shù)據(jù)進行初始化渲染，然后后臺進行異步數(shù)據(jù)的更新，這不僅優(yōu)化了性能，在無網(wǎng)環(huán)境下，用戶也能很順暢的使用到關(guān)鍵服務(wù)；
  2. 避免白屏，可以在前置頁面將一些有用的字段帶到當(dāng)前頁，進行首次渲染（列表頁的某些數(shù)據(jù)–> 詳情頁），沒有數(shù)據(jù)的模塊可以進行骨架屏的占位，使用戶不會等待的很焦慮，甚至走了；
  3. 及時反饋，及時的對需要用戶等待的交互操作進行反饋，避免用戶以為小程序卡了，無響應(yīng)。
• 避免使用不當(dāng)setData
  1. 不要過于頻繁調(diào)用setData，應(yīng)考慮將多次setData合并成一次setData調(diào)用；
  2. 數(shù)據(jù)通信的性能與數(shù)據(jù)量正相關(guān)，因而如果有一些數(shù)據(jù)字段不在界面中展示且數(shù)據(jù)結(jié)構(gòu)比較復(fù)雜或包含長字符串，則不應(yīng)使用setData來設(shè)置這些數(shù)據(jù)；
  3. 與界面渲染無關(guān)的數(shù)據(jù)最好不要設(shè)置在data中，可以考慮設(shè)置在page對象的其他字段下
• 用戶事件使用不當(dāng)
  1. 視圖層將事件反饋給邏輯層時，同樣需要一個通信過程，通信的方向是從視圖層到邏輯層。因為這個通信過程是異步的，會產(chǎn)生一定的延遲，延遲時間同樣與傳輸?shù)臄?shù)據(jù)量正相關(guān)，數(shù)據(jù)量小于64KB時在30ms內(nèi)。降低延遲時間的方法主要有兩個。
  2. 去掉不必要的事件綁定（WXML中的bind和catch），從而減少通信的數(shù)據(jù)量和次數(shù)；
  3. 事件綁定時需要傳輸target和currentTarget的dataset，因而不要在節(jié)點的data前綴屬性中放置過大的數(shù)據(jù)。
• 視圖層渲染原理
  1. 首次渲染（優(yōu)化視圖節(jié)點），初始渲染發(fā)生在頁面剛剛創(chuàng)建時。初始渲染時，將初始數(shù)據(jù)套用在對應(yīng)的WXML片段上生成節(jié)點樹。節(jié)點樹也就是在開發(fā)者工具WXML面板中看到的頁面樹結(jié)構(gòu)，它包含頁面內(nèi)所有組件節(jié)點的名稱、屬性值和事件回調(diào)函數(shù)等信息。最后根據(jù)節(jié)點樹包含的各個節(jié)點，在界面上依次創(chuàng)建出各個組件。在這整個流程中，時間開銷大體上與節(jié)點樹中節(jié)點的總量成正比例關(guān)系。因而減少WXML中節(jié)點的數(shù)量可以有效降低初始渲染和重渲染的時間開銷，提升渲染性能。
  2. 重渲染（減少setData數(shù)據(jù)量），初始渲染完畢后，視圖層可以多次應(yīng)用setData的數(shù)據(jù)。每次應(yīng)用setData數(shù)據(jù)時，都會執(zhí)行重渲染來更新界面。初始渲染中得到的data和當(dāng)前節(jié)點樹會保留下來用于重渲染。每次重渲染時，將data和setData數(shù)據(jù)套用在WXML片段上，得到一個新節(jié)點樹。然后將新節(jié)點樹與當(dāng)前節(jié)點樹進行比較，這樣可以得到哪些節(jié)點的哪些屬性需要更新、哪些節(jié)點需要添加或移除。最后，將setData數(shù)據(jù)合并到data中，并用新節(jié)點樹替換舊節(jié)點樹，用于下一次重渲染。在進行當(dāng)前節(jié)點樹與新節(jié)點樹的比較時，會著重比較setData數(shù)據(jù)影響到的節(jié)點屬性。因而，去掉不必要設(shè)置的數(shù)據(jù)、減少setData的數(shù)據(jù)量也有助于提升這一個步驟的性能。
• 使用自定義組件
  1. 自定義組件的更新只在組件內(nèi)部進行，不受頁面其他不能分內(nèi)容的影響；比如一些運營活動的定時模塊可以單獨抽出來，做成一個定時組件，定時組件的更新并不會影響頁面上其他元素的更新；各個組件也將具有各自獨立的邏輯空間。每個組件都分別擁有自己的獨立的數(shù)據(jù)、setData調(diào)用。

4、小程序與原生APP對比，分別說出他們優(yōu)劣？

5、簡述微信小程序原理

1. 小程序是個啥？

本質(zhì)其實就是（混合）的app 介于web app與native 原生app之間，具備豐富的調(diào)用手機各種功能的接口，同時又具備靈活性，跨平臺

2. 小程序的開發(fā)流程：

申請小程序帳號（獲得appid）、安裝小程序開發(fā)者調(diào)試工具、配置項目等等

3. 小程序和傳統(tǒng)web的區(qū)別

web網(wǎng)頁開發(fā)渲染線程和腳本是互斥的，而小程序?qū)τ趦烧呤欠珠_的，分別運行在不同的進程中，是基于雙線程的
小程序邏輯層和渲染層是分開的所以沒有DOM、BOM，相關(guān)API也不能使用（所以好多第三方和dom有關(guān)的庫也不能使用）
每個頁面都是不同的webview渲染，減輕了單個webview的壓力

4. 運行環(huán)境差異

5. 小程序的代碼組成

• 與 web 開發(fā)（HTML,CSS,JS）類同，小程序由配置代碼 JSON 文件、模板代碼 WXML 文件、樣式代碼 WXSS 文件以及邏輯代碼 JavaScript 文件組成。
• JSON 文件：在小程序代碼中扮演靜態(tài)配置的作用，在小程序運行之前就決定了小程序一些表現(xiàn)（設(shè)置 navigationBarTitleText 等），需要注意的是小程序是無法在運行過程中去動態(tài)更新 JSON 配置文件從而發(fā)生對應(yīng)的變化的。
• WXML 全稱是 WeiXin Markup Language，是小程序框架設(shè)計的一套標(biāo)簽語言，結(jié)合小程序的基礎(chǔ)組件、事件系統(tǒng)，可以構(gòu)建出頁面的結(jié)構(gòu)。
• 數(shù)據(jù)綁定：用戶界面呈現(xiàn)會因為當(dāng)前時刻數(shù)據(jù)不同而有所不同，或者是因為用戶的操作發(fā)生動態(tài)改變，這就要求程序的運行過程中，要有動態(tài)的去改變渲染界面的能力。在 Web 開發(fā)中，開發(fā)者使用 JavaScript 通過 Dom 接口來完成界面的實時更新。在小程序中，使用 WXML 語言所提供的數(shù)據(jù)綁定功能，來完成此項功能。

• WXSS（WeiXin Style Sheets）是一套用于小程序的樣式語言，用于描述WXML的組件樣式，也就是視覺上的效果。
  在小程序開發(fā)中，開發(fā)者不需要像 Web 開發(fā)那樣去優(yōu)化樣式文件的請求數(shù)量，只需要考慮代碼的組織即可。樣式文件最終會被編譯優(yōu)化。
  在WXSS中，引入了rpx（responsive pixel）尺寸單位。引用新尺寸單位的目的是，適配不同寬度的屏幕，開發(fā)起來更簡單。小程序編譯后，rpx會做一次px換算。換算是以375個物理像素為基準(zhǔn)，也就是在一個寬度為375物理像素的屏幕下，1rpx = 1px。

  
  
  對比

6. 渲染原理(重要)

小程序的渲染層和邏輯層分別由兩個進程管理，通信會由微信客戶端做中轉(zhuǎn)。

1、通信模型

• 微信小程序的框架包含兩部分渲染層(View)和邏輯層(App service)。
  View層用來渲染頁面結(jié)構(gòu)，APPService層用來處理，數(shù)據(jù)請求，接口調(diào)用，它們在兩個線程里運行。
  VIew層使用WebView渲染，邏輯層使用JSCore運行。
• 視圖層和邏輯層是通過微信客戶端(WeixinJsBridage)，來通信的。邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁面更新，視圖層把觸發(fā)的事件通知到邏輯層進行業(yè)務(wù)處理。
  小程序的運行環(huán)境分成渲染層和邏輯層， WXML 模板和 WXSS 樣式工作在渲染層，JS 腳本工作在邏輯層。渲染層和邏輯層是分離的。

• 小程序的渲染層和邏輯層分別由2個線程管理：渲染層的界面使用了WebView 進行渲染；邏輯層采用JsCore線程運行JS腳本。一個小程序存在多個界面，所以渲染層存在多個WebView線程，這兩個線程的通信會經(jīng)由微信客戶端（下文中也會采用Native來代指微信客戶端）做中轉(zhuǎn)，邏輯層發(fā)送網(wǎng)絡(luò)請求也經(jīng)由Native轉(zhuǎn)發(fā)。

  
  
  通信模型

2、數(shù)據(jù)驅(qū)動

• 數(shù)據(jù)驅(qū)動使得數(shù)據(jù)狀態(tài)和視圖綁定在一起,wxml文件對應(yīng)著一個js對象，可以假使這是一個dom樹，當(dāng)數(shù)據(jù)變化時，直接修改dom樹對應(yīng)的js對象，wxml對比js對象前后的差別然后進行部分渲染。這個原理聽起來很熟悉嘛？是的，和vue、react的虛擬DOM大同小異，都是為了避免重復(fù)渲染“dom”做的優(yōu)化。
  渲染層和數(shù)據(jù)相關(guān)。
  邏輯層負(fù)責(zé)產(chǎn)生、處理數(shù)據(jù)。
  邏輯層通過 Page 實例的 setData 方法傳遞數(shù)據(jù)到渲染層。

3、全局?jǐn)?shù)據(jù)

因為渲染層和邏輯層的分離，每打開一個頁面都會各自又一個 WebView進程進行渲染，在邏輯層的JS腳本運行上下文依舊在一個進程中沒有變。所以App里的globalData是可以全局獲取到的

7. 數(shù)據(jù)驅(qū)動

數(shù)據(jù)驅(qū)動使得數(shù)據(jù)狀態(tài)和視圖綁定在一起,wxml文件對應(yīng)著一個js對象，可以假使這是一個dom樹，當(dāng)數(shù)據(jù)變化時，直接修改dom樹對應(yīng)的js對象，wxml對比js對象前后的差別然后進行部分渲染。這個原理聽起來很熟悉嘛？是的，和vue、react的虛擬DOM大同小異，都是為了避免重復(fù)渲染“dom”做的優(yōu)化。

8. 全局?jǐn)?shù)據(jù)

因為渲染層和邏輯層的分離，每打開一個頁面都會各自又一個 WebView進程進行渲染，在邏輯層的JS腳本運行上下文依舊在一個進程中沒有變。所以App里的globalData是可以全局獲取到的。

6、分析小程序優(yōu)劣

7、小程序與h5的區(qū)別

簡單來說，小程序是一種應(yīng)用，運行的環(huán)境是微信（App）；H5是一種技術(shù)，依附的外殼是是瀏覽器。

1. 運行環(huán)境的不同

• H5的運行環(huán)境是瀏覽器，包括webview，而微信小程序的運行環(huán)境并非完整的瀏覽器，因為小程序的開發(fā)過程中只用到一部分H5技術(shù)。
• 小程序的運行環(huán)境是微信開發(fā)團隊基于瀏覽器內(nèi)核完全重構(gòu)的一個內(nèi)置解析器，針對性做了優(yōu)化，配合自己定義的開發(fā)語言標(biāo)準(zhǔn)，提升了小程序的性能。

2.系統(tǒng)權(quán)限

• 這里的系統(tǒng)權(quán)限，可以理解為隱私級別比較高的，如通訊錄，或能調(diào)用硬件的，比如藍牙功能等。從這個角度看，H5 本身可以說幾乎是沒有什么系統(tǒng)權(quán)限的。雖然也有攝像頭之類的接口，但是重度依賴瀏覽器能力，兼容性有限。
• 而小程序，由于依賴微信客戶端本身，所以微信小程序團隊將客戶端的很多能力開放給了小程序環(huán)境，當(dāng)然，前提是你給微信也授權(quán)了相關(guān)的能力，比如允許訪問麥克風(fēng)，允許訪問相冊等。
  所以，如果你的產(chǎn)品重度依賴這些能力，那小程序一定是不二之選，因為 H5 很難做到這些，對于很多小程序提供的能力，H5 是根本沒有可能實現(xiàn)的。

3. 開發(fā)成本

• H5 的開發(fā)，涉及開發(fā)工具（vscode、Atom等）、前端框架（Angular、react等）、模塊管理工具（Webpack 、Browserify 等）、任務(wù)管理工具（Grunt、Gulp等），還有UI庫選擇、接口調(diào)用工具（ajax、Fetch Api等）、瀏覽器兼容性等等。盡管這些工具可定制化非常高，大部分開發(fā)者也有自己的配置模板，但對于項目中各種外部庫的版本迭代、版本升級，這些成本加在一起那就是個不小數(shù)目了。
• 而開發(fā)一個微信小程序，由于微信團隊提供了開發(fā)者工具，并且規(guī)范了開發(fā)標(biāo)準(zhǔn)，則簡單得多。前端常見的HTML、CSS變成了微信自定義的WXML、WXSS，WXML，官方文檔中都有明確的使用介紹，開發(fā)者按照說明專注寫程序就可以了。需要調(diào)用后端接口時，調(diào)用發(fā)起請求API；需要上傳下載時，調(diào)用上傳下載API；需要數(shù)據(jù)緩存時，調(diào)用本地存儲API；引入地圖、使用羅盤、調(diào)用支付、調(diào)用掃碼等等功能都可以直接使用；UI庫方面，框架帶有自家weui庫加成。并且在使用這些API時，不用考慮瀏覽器兼容性，不用擔(dān)心出現(xiàn)BUG，顯而易見微信小程序的開發(fā)成本相對低很多。

4. 運行流暢度的不同

• 在運行流暢度方面，無論對于用戶還是開發(fā)者，都可以直觀體驗出兩者的差異。這也是普通大眾最容易區(qū)分小程序與H5的一點。打開H5，實際上是打開一個網(wǎng)頁，而網(wǎng)頁需要在瀏覽器中渲染。所以加載這一過程，會給人明顯的「卡頓」感覺，面對復(fù)雜的業(yè)務(wù)邏輯或者豐富的頁面交互時尤為明顯。
• 而微信小程序，它的代碼直接在微信上運行，省去了通過瀏覽器渲染的步驟，因此，在微信中使用小程序，才會比H5流暢很多。除了首次打開需要幾秒的加載時間外，小程序各個頁面的切換、跳轉(zhuǎn)等體驗已經(jīng)媲美原生App，有著同樣的柔絲般順滑的效果。

5. 迭代周期

• 開發(fā)成本低，未必迭代周期就短。對于 H5 我們可以隨時發(fā)布上線，不用受任何牽制。而小程序的特點，就是每次提交版本都要經(jīng)過微信方面的審核，且審核時間的長短很隨機，著急上線的項目就很無奈了。
  至于其他速度，取決于開發(fā)人員技能熟練程度，系統(tǒng)復(fù)雜度，對基礎(chǔ)能力的依賴等，就不好估算了。

6. 訪問入口

• 在訪問入口這個點上，H5 的核心競爭力就是能在微信之外玩，不依賴微信本身。而小程序的優(yōu)勢，就是有 50+ 微信提供的場景入口，并且聊天界面頂部的“最近使用”和“我的小程序”這個入口，相對 H5 來說是有絕對優(yōu)勢的。
• 用戶關(guān)閉之后，H5 頁面如果想繼續(xù)訪問，可能會通過收藏入口，或者轉(zhuǎn)發(fā)給“文件傳輸助手”等聊天界面保存，還可以縮小到圖標(biāo)稍后閱讀等等。本質(zhì)上還是跟 PC 時代的瀏覽器收藏夾差不多，需要有個地方把 H5 的鏈接地址保存下來，方便下次訪問。如果沒有保存，下次就很難找到了。
• 至于微信內(nèi)的搜索，是可以同時搜索 H5 和小程序的，可以根據(jù) H5 的名字和內(nèi)容、小程序的名字和介紹來搜索。這里 H5 有個天然優(yōu)勢就是，只要你的鏈接在各大搜索引擎提交過，那么使用其他的搜索引擎也能搜出這個 H5，比如百度搜索。

7. 外部限制

• 由于小程序依賴微信平臺，因此微信平臺要對內(nèi)容安全等事項負(fù)責(zé)，比如你想搞個有 UGC 的產(chǎn)品，用 H5 可能還可以趁著監(jiān)管寬松無證裸奔一陣，或者說做大了再補證。
• 而小程序，就很可能完全不能過審，根本上不了線。比如試聽類，社交類，都有對應(yīng)的資質(zhì)，而這個資質(zhì)還可能很難獲得。
• 類似的，H5 頁面可以不用搞 HTTPS，有個網(wǎng)站就能玩，甚至用工具做個小活動也都可以玩。但是小程序，從后端開始就有限制，要求域名備案+HTTPS，一定程度上也是一點成本。
• 此外，小程序?qū)ξ募笮∫灿邢拗?，雖然現(xiàn)在已經(jīng)支持分包加載，但是在文件大小方面，H5 本身是沒有什么限制的。只是實際開發(fā)的時候，要照顧用戶的體驗，不能讓頁面打開太慢。

8、怎么解決小程序的異步問題

1. 場景一（常見）：

• 項目需要獲取code值，在app實例中也就是app.js中定義一個getCode的方法，success之后，在page中的index.js中的onload生命周期中拿到code，通過wx.request傳遞給后臺來換取openid。
  想的很完美，但是實現(xiàn)時發(fā)現(xiàn)，在wx.login還未執(zhí)行完就執(zhí)行了page的onLoad；
  這種異步情況可以使用promise來解決，示例代碼如下：

//app.js
App({
  // 獲取code，然后傳遞給index.js中的onload生命周期
  getCode (data) {
    let _this= this
    return new Promise((resolve => {
      wx.login({
        success: function (res) {
           //模擬異步請求 - 3秒后返回數(shù)據(jù) - resolve出去
          setTimeout(() => {
            resolve(res)
          }, 3000) 
        }
      })
    }))
  }
})

//index.js
//獲取應(yīng)用實例
const app = getApp()
Page({
  data: {
  },
  onLoad: function () {
    // 通過app實例獲取到異步返回的數(shù)據(jù) - code
    app.getCode().then(res => {
      console.log(res.code) // 成功返回；如果不用promise，那code的返回值就是空
    })
  }
})

9、小程序的雙向數(shù)據(jù)綁定和Vue有何不同

小程序直接this.data的屬性是不可以同步到視圖的，必須調(diào)用：

this.setData({})

10、小程序的wxml和html有什么區(qū)別？

• HTML是用于創(chuàng)建網(wǎng)頁的語言。通過使用HTML標(biāo)記標(biāo)簽創(chuàng)建html文檔來創(chuàng)建網(wǎng)頁。

11、小程序的wxss和css有什么區(qū)別？

• WXSS(WeiXin Style Sheets)是一套樣式語言，用于描述 WXML 的組件樣式。
  WXSS 用來決定 WXML 的組件應(yīng)該怎么顯示。
  為了適應(yīng)廣大的前端開發(fā)者，WXSS 具有 CSS 大部分特性。同時為了更適合開發(fā)微信小程序，WXSS 對 CSS 進行了擴充以及修改。
  與 CSS 相比，WXSS 擴展的特性有：
  尺寸單位

12、詳述小程序的生命周期

很多同學(xué)容易將小程序生命周期和頁面的生命周期混淆為一起，這兩個其實應(yīng)該是不同卻又相互關(guān)聯(lián)的生命周期

小程序的生命周期

• 小程序啟動后，首先完成小程序的初始化（onLaunch）和顯示（onShow），然后是頁面的加載（onLoad）、顯示（onShow）和渲染（onReady）。如圖“小程序的生命周期”。
• 小程序進入后臺時，先觸發(fā)頁面的生命周期函數(shù)onHide，再觸發(fā)小程序的生命周期函數(shù)onHide；小程序啟動顯示或從后臺進入前臺時，先觸發(fā)小程序的生命周期函數(shù)Onshow，再觸發(fā)頁面的生命周期函數(shù)onShow。
• 這里解釋兩個概念：
  后臺： 當(dāng)用戶點擊左上角關(guān)閉（或者右上角退出），或者按了home鍵離開微信，小程序并沒有直接銷毀，而是進入了后臺。
  前臺： 當(dāng)再次進入微信或者再次打開小程序，又會從后臺進入前臺。
  只有當(dāng)小程序進入后臺一定時間（目前是5分鐘），或者系統(tǒng)資源占用過高，才會被真正的銷毀。

Page 實例的生命周期

• 初始化：視圖線程開始初始化，初始化完成發(fā)送通知到邏輯線程，視圖線程開始等待數(shù)據(jù)，（邏輯線程初始化完成后等待視圖線程的通知，）邏輯線程返回頁面初始數(shù)據(jù)，邏輯線程進入等待激活狀態(tài)。
• 首次渲染：視圖線程拿到初始化渲染數(shù)據(jù)后，開始首次渲染，渲染完成后（視圖層進入持續(xù)渲染狀態(tài)）發(fā)送 【初始化完成通知】給邏輯線程，觸發(fā)生命周期函數(shù)onReady，邏輯線程進入激活態(tài)。
• 持續(xù)渲染狀態(tài)： 用戶交互觸發(fā)事件，邏輯線程處理，通過this.setData更新數(shù)據(jù)到渲染線程,數(shù)據(jù)更新，渲染線程局部更新頁面。
• 前臺->后臺： 用戶關(guān)閉小程序或home鍵退出微信，邏輯線程觸發(fā)生命周期函數(shù)onHide進入后臺態(tài)。
• 后臺->前臺：用戶再次打開微信或小程序，邏輯線程觸發(fā)生命周期函數(shù)onShow進入激活態(tài)。
• 銷毀：頁面或小程序被系統(tǒng)回收或銷毀時，邏輯線程觸發(fā)生命周期函數(shù)onUnload，結(jié)束。

13、詳述小程序組件中的生命周期

• 組件的生命周期，指的是組件自身的一些函數(shù)，這些函數(shù)在特殊的時間點或遇到一些特殊的框架事件時被自動觸發(fā)。
• 其中，最重要的生命周期是 created attached detached ，包含一個組件實例生命流程的最主要時間點。

• 組件實例剛剛被創(chuàng)建好時， created 生命周期被觸發(fā)。此時，組件數(shù)據(jù) this.data 就是在 Component 構(gòu)造器中定義的數(shù)據(jù) data 。 此時還不能調(diào)用 setData 。 通常情況下，這個生命周期只應(yīng)該用于給組件 this 添加一些自定義屬性字段。
• 在組件完全初始化完畢、進入頁面節(jié)點樹后， attached 生命周期被觸發(fā)。此時， this.data 已被初始化為組件的當(dāng)前值。這個生命周期很有用，絕大多數(shù)初始化工作可以在這個時機進行。
• 在組件離開頁面節(jié)點樹后， detached 生命周期被觸發(fā)。退出一個頁面時，如果組件還在頁面節(jié)點樹中，則 detached 會被觸發(fā)。

定義生命周期方法

生命周期方法可以直接定義在 Component 構(gòu)造器的第一級參數(shù)中。
自小程序基礎(chǔ)庫版本 2.2.3 起，組件的的生命周期也可以在 lifetimes 字段內(nèi)進行聲明（這是推薦的方式，其優(yōu)先級最高）。

示例代碼如下：

Component({
  lifetimes: {
    attached() {
      // 在組件實例進入頁面節(jié)點樹時執(zhí)行
    },
    detached() {
      // 在組件實例被從頁面節(jié)點樹移除時執(zhí)行
    },
  },
  // 以下是舊式的定義方式，可以保持對 <2.2.3 版本基礎(chǔ)庫的兼容
  attached() {
    // 在組件實例進入頁面節(jié)點樹時執(zhí)行
  },
  detached() {
    // 在組件實例被從頁面節(jié)點樹移除時執(zhí)行
  },
  // ...
})

在 behaviors 中也可以編寫生命周期方法，同時不會與其他 behaviors 中的同名生命周期相互覆蓋。但要注意，如果一個組件多次直接或間接引用同一個 behavior ，這個 behavior 中的生命周期函數(shù)在一個執(zhí)行時機內(nèi)只會執(zhí)行一次。

可用的全部生命周期如下表所示：

組件所在頁面的生命周期

還有一些特殊的生命周期，它們并非與組件有很強的關(guān)聯(lián)，但有時組件需要獲知，以便組件內(nèi)部處理。這樣的生命周期稱為“組件所在頁面的生命周期”，在 pageLifetimes 定義段中定義。其中可用的生命周期包括：

示例代碼如下：

Component({
  pageLifetimes: {
    show() {
      // 頁面被展示
    },
    hide() {
      // 頁面被隱藏
    },
    resize(size) {
      // 頁面尺寸變化
    }
  }
})

14、詳述小程序的組件通信

• 父傳子
  在子組件的組件標(biāo)簽上通過自定義屬性的形式綁定數(shù)據(jù)或字符串
  在子組件中通過properties對象進行屬性的接收即可。

GitHub：父傳子

• 子傳父
  在子組件中的methods對象中定義方法，在方法中通過this.triggerEvent({})方法，完成事件觸發(fā)
  在子組件標(biāo)簽上綁定（例：bind:在this.triggerEvent定義的事件名稱="回調(diào)函數(shù)" ），在this.triggerEvent定義的事情名稱，最后在回調(diào)函數(shù)中完成邏輯處理。

GitHub：子傳父

• 兄弟
  子傳父
  父作為中轉(zhuǎn)
  父傳子

GitHub：兄弟

15、小程序中的wxs是什么？如何使用？在項目中哪里使用過？

WXS（WeiXin Script）是小程序的一套腳本語言，結(jié)合 WXML，可以構(gòu)建出頁面的結(jié)構(gòu)。

• WXS是為了結(jié)合WXML誕生、使用的（既可以引入也可以直接寫在WXML里），因為JavaScript不能在WXML中調(diào)用或直接在WXML里面寫JavaScript。WXS和JavaScript是兩種不相關(guān)的語言，因此在WXS中不能使用JavaScript的語法，更不能使用ES6的語法。WXS僅僅是語法形式和JavaScript很像，但是并不等同于JavaScript，WXS是有自己獨立的運行環(huán)境的，再強調(diào)一遍，從根本上來說這兩種就是不同的語言，只是在語法上借鑒了JavaScript。具體用法可參考 官方文檔
• 我們在實際開發(fā)中經(jīng)常用到的一個地方就是編寫過濾器，但是大家不要錯誤的認(rèn)為WXS就是為了在小程序編寫過濾器而生的，大家一定要深刻理解WXS是小程序自己的一套腳本語言，主要是為了增強WXML的編程能力的.

wxs詳解

16、詳述在開發(fā)小程序中遇到的問題及解決方案

17、bind和catch綁定事件有什么區(qū)別？

• 事件分為冒泡事件和非冒泡事件：
  冒泡事件：當(dāng)一個組件上的事件被觸發(fā)后，該事件會向父節(jié)點傳遞。
  非冒泡事件：當(dāng)一個組件上的事件被觸發(fā)后，該事件不會向父節(jié)點傳遞。
• bind事件綁定不會阻止冒泡事件向上冒泡，catch事件綁定可以阻止冒泡事件向上冒泡。

18、詳述小程序授權(quán)流程

• 微信授權(quán)機制，現(xiàn)版本和早起的版本有所差別，但是只是授權(quán)流程思路上的小小差異，整體并無太大變化。
  早期版本是直接通過wx.getUserInfo() API來彈出微信授權(quán)窗口“詢問是否授權(quán)”，主動彈出授權(quán)窗口太過靈活對于用戶而言并非良好的體驗，因此現(xiàn)版本修改為了必須通過button組件，讓用戶去主動觸發(fā)才能彈出授權(quán)窗口，直接調(diào)用wx.getUserInfo()已不再出現(xiàn)授權(quán)彈窗

wx.getSetting(Object object) 判斷是否已授權(quán) - 詳情參考官網(wǎng)
wx.getUserInfo(Object object) 獲取授權(quán)后的用戶信息 - 詳情參考官網(wǎng)
button 通過button組件詢問用戶是否授權(quán) - 詳情參考官網(wǎng)

小程序授權(quán)流程 - 詳解

19、如何檢測用戶的微信版本是否支持某項功能或API

20、如何分包加載優(yōu)勢在哪

• 什么是分包加載？
  某些情況下，開發(fā)者需要將小程序劃分成不同的子包，在構(gòu)建時打包成不同的分包，用戶在使用時按需進行加載。
  在構(gòu)建小程序分包項目時，構(gòu)建會輸出一個或多個分包。每個使用分包小程序必定含有一個主包。所謂的主包，即放置默認(rèn)啟動頁面/TabBar 頁面，以及一些所有分包都需用到公共資源/JS 腳本；而分包則是根據(jù)開發(fā)者的配置進行劃分。
  在小程序啟動時，默認(rèn)會下載主包并啟動主包內(nèi)頁面，當(dāng)用戶用戶進入分包內(nèi)某個頁面時，客戶端會把對應(yīng)分包下載下來，下載完成后再進行展示。

• 目前小程序分包大小有以下限制：
  整個小程序所有分包大小不超過 8M
  單個分包/主包大小不能超過 2M

• 分包加載的好處
  對小程序進行分包，可以優(yōu)化小程序首次啟動的下載時間，以及在多團隊共同開發(fā)時可以更好的解耦協(xié)作。

• 分包配置
  配置方法
  假設(shè)支持分包的小程序目錄結(jié)構(gòu)如下：

├── app.js
├── app.json
├── app.wxss
├── packageA
│   └── pages
│       ├── cat
│       └── dog
├── packageB
│   └── pages
│       ├── apple
│       └── banana
├── pages
│   ├── index
│   └── logs
└── utils

開發(fā)者通過在 app.json subpackages 字段聲明項目分包結(jié)構(gòu)：

{
  "pages": ["pages/index", "pages/logs"],
  "subpackages": [
    {
      "root": "packageA",
      "pages": ["pages/cat", "pages/dog"]
    },
    {
      "root": "packageB",
      "name": "pack2",
      "pages": ["pages/apple", "pages/banana"]
    }
  ]
}

subpackages 中，每個分包的配置有以下幾項：

• 打包原則
  聲明 subpackages 后，將按 subpackages 配置路徑進行打包，subpackages 配置路徑外的目錄將被打包到 app（主包） 中
  app（主包）也可以有自己的 pages（即最外層的 pages 字段）
  subpackage 的根目錄不能是另外一個 subpackage 內(nèi)的子目錄
  tabBar 頁面必須在 app（主包）內(nèi)
• 引用原則
  packageA 無法 require packageB JS 文件，但可以 require app、自己 package 內(nèi)的 JS 文件
  packageA 無法 import packageB 的 template，但可以 require app、自己 package 內(nèi)的 template
  packageA 無法使用 packageB 的資源，但可以使用 app、自己 package 內(nèi)的資源
• 低版本兼容
  由微信后臺編譯來處理舊版本客戶端的兼容，后臺會編譯兩份代碼包，一份是分包后代碼，另外一份是整包的兼容代碼。 新客戶端用分包，老客戶端還是用的整包，完整包會把各個 subpackage 里面的路徑放到 pages 中。

21、webview中的頁面怎么跳回到小程序中

22、跨小程序如何跳轉(zhuǎn)？

23、實現(xiàn)小程序上拉加載有幾種方式？

24、小程序無法直接解析html標(biāo)簽，但是后臺返回的數(shù)據(jù)有html，這個時候需要借助于插件進行解析，但是會導(dǎo)致小程序變慢，該怎么辦？

25、小程序中的template是什么？如何使用？和組件有什么不同？

26、輪播圖最后一張如何與第一張銜接？

27、小程序自定義彈框滾動與頁面滾動沖突問題如何解決？

28、點擊圖片放大到全屏顯示如何實現(xiàn)？

29、小程序?qū)懺跇?biāo)簽的屬性data值，有哪些需要注意的點

30、怎么把小程序webview中的頁面，在分享的時候加上指定標(biāo)題和圖片？

31、wx:if VS hidden區(qū)別

32、小程序的渲染原理