整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
、盒子模型
下圖中可以看到，在設置width的時候，標準的盒子模型是不包括border和padding的，而在IE瀏覽器中是包括這兩項的。
盒模型是有兩種標準的，一個是標準模型，一個是IE模型。
標準模型中，盒模型的寬高只是內容（content）的寬高，默認正是W3C標準盒模型。
而在IE模型中盒模型的寬高是內容(content)+填充(padding)+邊框(border)的總寬高。
/* 標準模型 */
box-sizing:content-box;
/*IE模型 */
box-sizing:border-box;
box-sizing:content-box padding和border都會撐開盒子，改變盒子的寬度高度
box-sizing:border-box padding和border都不會撐開盒子，不會改變盒子的寬度，盒子的內容會相應縮小。
2、盒子模型屬性
（1）border
border:width style color
style屬性
none 沒有邊框
solid 邊框為實線
dashed 邊框為虛線
dotted 邊框為點線
double 邊框為雙實線
表格的細線邊框合并：border-collapse:collapse
圓角邊框（CSS3）：border-radius:左上角 右上角 右下角 左下角
（2）padding
可以分開設置：padding-left padding-top padding-right padding-bottom
也可以放在一起設置：padding:10px 20px 30px 40px;
順序為↑→↓←
如果設置1個值，表示四個方向是同一個值
如果設置兩個值，表示上下 右左
如果設置三個值，表示上 右左 下
（3）margin
設置方法和padding相同，可以分開設置也可以放在一起設置。
行內元素只有左右外邊距，沒有上下外邊距。在ie6等低版本中是沒有內邊距的。
外邊距可以實現盒子居中，必須滿足兩個條件：
1． 必須是塊級元素
2． 盒子必須指定寬度
然后設置左右外邊距為auto，就可以實現水平居中
清除元素默認內外邊距
padding: 0;
margin: 0;
外邊距合并
場景一：
使用margin定義塊元素的垂直外邊距時，可能會出現外邊距的合并。當上下相鄰的兩個塊元素相遇時，如果上面的元素有margin-bottom，下面的元素有margin-top，則他們之間的垂直間距不是margin-bottom和margin-top的和，而是取兩者中的較大的值作為兩個元素的邊距，這種現象稱為相鄰塊元素垂直外邊距的合并。
解決方法：
避免！（如此羞澀的解決方案）
場景二：
對于兩個嵌套關系的塊元素，如果父元素沒有padding-top和border，則父元素的margin-top會與子元素的margin-top發生合并，合并后的外邊距為兩者中的較大者。
解決方法：
1． 為父元素設定1px的border或padding-top
2． 為父元素添加overflow:hidden
3、盒子陰影
box-shadow:水平位置 垂直位置 模糊距離 陰影尺寸 陰影顏色 內/外陰影
h-shadow 必選，水平陰影的位置，允許負值
v-shadow 必選，垂直陰影的位置，允許負值
blur 可選，模糊距離
spread 可選，陰影的尺寸（影子大小）
color 可選，陰影的顏色
inset 可選，將外部陰影改為內部陰影（外陰影為默認屬性，不需要寫，沒有outset屬性）
本文參考自https://www.jianshu.com/p/83cfe1a343fd。
輯導語：如今人們已經習慣于使用各種智能設備，然而全球有3億左右殘障人群，他們的需求不該被忽略，于是無障礙設計便應運而生。本文作者從色盲用戶的角度出發，分享如何做色彩無障礙設計，一起來學習一下吧。
隨著科技的普及和快速發展，人們越來越頻繁和習慣于使用智能設備，然而全球有3億左右的殘障人群， 無論是從科技還是法律的角度，這群人的需求不該被忽略。
于是無障礙設計應運而生。無障礙具體可拆分為視覺、聽覺、操作、認知、言語交流無障礙. 而色彩是視覺中很重要的部分，我們的世界是五彩繽紛的，不同的色彩被賦予不同的意義，對于色覺障礙人群，我們該如何包容性地設計，讓他們的生活更加便利和美好呢？
無障礙設計無處不在，舉個例子：Spotify有兩種播放模式，一個是隨機播放，一個是循環播放.它通過改變圖標的顏色為綠色，表明激活狀態，但是如果僅僅只是改變顏色，對于色盲用戶來說，不容易識別，因為原本鮮艷的綠色在他們看來是暗淡的：
但是加上小綠點之后，不去依靠顏色也很容易判斷當前的狀態：
再舉個例子：有一款名為FODMAP的應用程序值得借鑒，FODMAP是在腸道中不能正確吸收的糖， 這是一款通過列出食物中各種含糖量，來給用戶提供飲食參考的軟件。
軟件中用紅黃綠表示不同的FODMAP等級，但是這讓色盲用戶感到很困擾：
幸運的是，這個軟件的設置中，可以打開色盲幫助選項， 打開后你看到的界面就變成了這樣：
用顯而易見的符號替換顏色，無論對色盲用戶還是普通用戶，都很友好。
再舉個例子， 英國的在線足球網站在2012年時是這樣的：
色盲用戶根本無法分辨輸贏情況，此舉無疑是白白流失了全國的色盲用戶。后來，他們也意識到了問題，于是現在的設計時這樣的：
每個顏色色塊中填入字母，W代表贏，L代表輸，D代表平局，色盲用戶也可以輕松獲得信息。
但是目前無障礙的普及程度并不高，色盲用戶在日常生活中仍然面臨很多的問題，比如在商店買衣服問題、在線選座問題、無法使用色彩標簽等等。本文將帶你全面地了解如何做好色彩無障礙設計。
色盲的頻率相當高，十二分之一的高加索人（8%），二十分之一的亞洲人（5%）和25分之一的非洲男性（4%）是所謂的“紅綠”色盲。它比AB血型更常見，據統計，平均每12名男性中就有1人有某種形式的色盲， 每200名女性中就有1人， 占人口的4.25%。麥當勞每天為300萬色盲客戶提供服務。亞馬遜每天超過110萬客戶是色盲。
色盲遠比我們想象中的數量要龐大的多，所以設計色盲友好的互聯網產品，這件事情應當被重視和完善。
正常的彩色視覺需要用到三種功能正常的錐形細胞，紅色、綠色和藍色錐形細胞，根據三色錐形細胞的是否缺失，又可以將色盲分為全色盲，雙色色盲和三色色盲。
三色色盲擁有三種錐形細胞， 但是其中一種錐細胞感知的光略微偏離對齊，根據哪種錐形細胞類型“有缺陷”，產生三種不同類型的效果，并且還具有不同的嚴重性。
三種情況分別是是紅色弱，即對紅光的敏感性降低，綠色弱: 對綠光（最常見的色盲形式）的敏感性降低，以及藍色弱: 對藍光的敏感性降低（極為罕見，只有0.001%的發生率）。
對某種類型光的感知力，有敏感性降低的，也有完全感知不到的，程度不一。
因為紅色和綠色錐形細胞感知到的光譜部分明顯重疊，因此紅色和綠色色弱都難以分辨紅色、綠色、褐色和橙色， 所以在診斷的時候常常被統稱為“紅綠色盲”，他們對藍色和紫色以及多種顏色的組合也常常難以區分。
藍色弱很難分辨藍色VS黃色，紫羅蘭VS紅色，藍色VS綠色. 藍色弱眼中是紅粉色，黑白色和青綠色的世界。
1）紅色色弱
2）綠色色弱
3）藍色色弱
雙色色盲只有兩種顏色的錐形細胞，第三種類型的細胞完全缺失. 所以，紅色盲完全無法感知到紅色，綠色盲完全無法感知到綠色，藍色盲完全無法感知到藍色。
同時喪失了紅色和綠色感知力的人生活在暗綠色的世界，所以藍色和黃色會非常突出。
大約1/2的三色色盲看到的世界與雙色色盲看到的很相似，但是三色色盲色彩感知力受光照影響較大，在良好的光照下，他們對色彩的感知力就更好，反之久更糟糕。總的來說， 雙色色盲在辨別色彩方面比三色色盲更容易些。
為了讓大家更清晰的了解不同色盲眼中的世界，這里做一些展示：
1）紅色色盲
2）綠色色盲
3）藍色色盲
全色盲完全沒有任何一種顏色細胞，他們眼中世界是完全的黑白色，就像是黑白電視機那樣.但是我們在做產品無障礙時，基本不會考慮這一類人群，因為全色盲發生的概率實在是太低了，33000人中僅有1人，他們的生活因此有很多阻礙，在正常的光照條件下，也需要戴深色墨鏡。
WAI制定了幾項W3C建議，包括：
WCAG有三種評級: A、AA和AAA，標準從低到高：
WCAG2.1詳細指南完整版可查看: https://www.w3.org/TR/WCAG21/
快速參考WCAG標準: https://www.w3.org/WAI/WCAG21/quickref/？currentsidebar=%23col_overview#use-of-color
WCAG關于顏色的要求描述:https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html
WCAG中將字體分為一般字體和大字體。
大字體是這樣定義的:“大于等于18點常規體或者大于等于14點的粗體，如果是中日韓的語言，就要換算成同等大小”，除卻大字體之外的就是一般文字。
AA評級對于一般文字來說，文字和背景的顏色對比度不少于4.5:1的對比度;對于大字體和（如圖標、表格等等）組件的要求就沒那么嚴格，只要顏色對比不低于3:1即可。
如果帶有文本的按鈕也有彩色邊框，因為邊框沒有提供輔助信息，所以對邊框沒有對比度要求，只要該文字符合AA評級即可。
顏色在特定的語境中，會被賦予特殊的含義，如常見的紅色代表警告，綠色代表合格通過的意思等等，而患有色彩缺陷、視力衰退的老齡化群體、還有使用單色閱讀器（如kindle紙墨水）的人都可能會因此遺漏了顏色所傳達出的重要信息。
同時在用顏色表達某種信息時，為了確保所有的用戶都能接受到信息，需要添加另一種視覺形式，下面給大家舉例說明：
1）文字
文字是最容易讓色盲用戶了解到顏色含義的元素，也是我們首先會考慮到的。
一個典型例子是表單字段上的錯誤狀態， 紅色通常用于表示文本字段中的錯誤， 但是標紅不足以引起色盲用戶的注意，因為從他們的視角看， 紅色的字體在一群黑色的字體中顯得很暗， 很難分辨出來。因此，你需要一個額外的提示，例如文本或圖標，來指示錯誤狀態。
2）圖標
圖標是使用頻率很高的組件， 一些通用圖標的含義甚至不需要Tooltip來解釋，用戶就能一眼識別， 比如設置、警告、成功等等圖標，舉個例子：許多B端界面會通過不同的語義顏色，告知用戶某個流程的狀態，但是對于色盲用戶來說，識別顏色對應的狀態圖例是一件很艱難的事情，但是如果添加圖標輔助信息，一切就變得容易多了！
3）明暗對比
這一點常常被大家忽略.如果兩種顏色的色調不同，但是擁有強烈的明暗對比，那么在這里， 明暗對比也算是另一種視覺輔助形式，只要這兩種顏色的對比不低于3:1（AA）。
只有一種情況例外， 就是用戶需要準確地識別一種特定的顏色，這個時候對比度就不能算在內。
4）符號
舉個例子，標注紅色的文字標簽是必填項，出于無障礙的需要，我們可以在紅色標簽上打一個星號，這樣即使注意不到顏色差異，看到星號也會意識到此項必填。
但是！大多數情況下，星號的尺寸很小（位于左上角），不容易被屏幕閱讀器捕捉到，為了改善這樣的情況，設計者可以增大星號的尺寸，以及為星號添加注釋（Tooltip）， 這個注釋是由開發者完成的， 不借助屏幕閱讀器是無法捕捉這個信息。
5）數字
這是一個丙烯結構式，三個碳原子被標上了三種顏色（化學老師會教我們標記碳原子序號的規律，不過就假設這是老師在給一群初學者的課件吧），那么老師提問“黃色的碳原子和紫色的碳原子中間用的是什么鍵”，色盲學生可能就沒辦法辨別顏色所對應的碳原子了，但是如果標上序號，這樣提問:“1號碳原子和2號碳原子中間用的是什么鍵？”，是不是所有的學生就一目了然了？
6）圖形
減少使用顏色的數量，增加圖形樣式，這樣盲人用戶能夠花費更少的力氣在辨別顏色上。
7）圖案
在顯示圖形或者圖表時，可以提供一些圖案供用戶填充，色盲雖然對顏色不敏感，但是對于圖案卻非常容易察覺區別。
這里推薦幾個提供大量圖案樣式的網站：Http://pattern.monster
交互式地圖（付費使用）：https://www.arcgis.com/index.html
Figma圖案填充插件：Hero Pattern for Image https://www.figma.com/community/plugin/743134103711120154
以折線圖舉例：
再以堆疊條形圖為例：
再舉個倫敦地鐵圖和上海地鐵圖的例子：
WCAG的標準被許多人奉為無障礙法則，但是有些情況下，并不適用。舉個例子：你覺得黑色字體和白色字體在橙色的背景上，哪一種看起來更清晰？
相信有不少人覺得白色字體看起來更舒服，更清晰，但是WCAG的顏色標準卻告訴我們，黑色達到了AAA的級別，而白色卻連AA級別都沒有達到：
不僅僅是我們，在很早之前，就有設計師對此產生疑惑，并做了用戶調研。
Ericka Seastrand 曾在2019年做過一項用戶調研，調研對象是20名色盲用戶，測試問題是: 黑色還是白色的字體在該背景下更突出？ 最后的結果顯示: 61%的用戶認為白色字體更清晰。
這些用戶也給出了具體的原因：
所以謹記：盡信書，則不如無書。WCAG的標準僅供參考，但是實際運用中，應當以用戶的感受為參考，質疑精神是很可貴的！
1）灰色按鈕
有些人認為不能夠使用灰色的按鈕，因為灰色給人以不可用的暗示，但是其實并沒有領悟不可用狀態的本質. 視覺深度才是幫助用戶判斷按鈕狀態的核心.活動狀態是通過顏色對比度而不是色調傳達的。
正常狀態的按鈕的文字與背景對比起來，看上去更接近和占主導地位，而不可用狀態缺乏對比度，文字看起來在更遠的地方。不過灰色按鈕經常被用作二級按鈕，主按鈕都是需要使用彩色。
同樣地，按鈕的各種交互狀態，只要對比度有差異性，能夠傳達視覺深度變化，就是符合無障礙的標準的，以Ant Design舉例：
2）讓你的主按鈕最顯眼
在大多數情況下，設計師們都是通過賦予主按鈕顏色，吸引用戶注意，但是在色盲用戶眼中，主按鈕的顏色差異很難被捕捉到，甚至在有些色盲眼中無法分辨顏色：
為了增加主按鈕和次按鈕的對比， 這個時候我們可以嘗試：
當你在為你的產品或者品牌選擇色彩時，一定要避免下面的色彩組合：
網頁中超鏈接文本很常見，比如百度百科，如果只是用顏色區別超鏈接，對于有些色盲很難注意到這是一個超鏈接，他需要將鼠標滑過時，發現變成一只手，才能知道。
所以對于超鏈接文本，添加下劃線是一個很好的方式：
曾經看過一個色盲講述自己買衣服的難題， 他來到商場，看到一件衣服，但是不確定這個衣服是什么顏色，可是衣服上的標簽也沒有寫顏色，所以他只好硬著頭皮去問商店里其他的人，承受著一些不解和懷疑的目光，如果這件衣服有清晰的顏色標簽的話，就能輕松解決這個問題了。這一點對于購物網站來說，尤其重要。
1. 避免文本和對象被背景遮擋的情況。 例如，文本/對象和背景之間的亮度和飽和度應該有足夠的對比度。避免組合亮度相同但色調不同的顏色。例如，綠色背景上的紅色字符對色盲來說是不可讀的。在深色背景上使用明亮的文本/對象，反之亦然。
2. 文本和對象盡可能粗或大，色盲人很難區分細線和小符號的顏色， 對于彩色文本，一定要使用粗體字體。
3. 小心使用紅色和綠色，對于視覺正常的人來說，純紅色是明亮生動的顏色。但對于色盲來說，它就像藍色或深綠色一樣暗淡。特別是對于紅色盲來說，深紅色看起來幾乎是黑色的。因此，避免在黑色背景上使用紅色字符，包括黑板。但是有一些紅色對色盲來說是鮮活的， 比如：
避免使用純綠色，使用偏藍一點的綠色。
4. 在深藍色背景上無法看清：深紅色、明亮的紫紅色、細線條。
5. 在一堆黑色字體中，很難看到深紅色強調的字體。
6. 盡量減少顏色的數量，可以使用不同的外形和少量容易識別的顏色的組合。
7. 保持顏色色調的對比的同時，也可以添加亮度的對比。
8. 使用種類少且容易識別的字體。
盡量不要使用顏色的名字交流信息. 在演講時，去指代ppt上的某個東西時，不要說“那個紅色的細胞”，嘗試描述除了顏色信息之外的，比如“那個紅色的方形的位于PPT左上角的細胞”。
Stark: 色盲模擬器和顏色對比度檢查器網站， sketch/figma/XD插件 https://www.getstark.co
Color Oracle: 一款免費的色盲模擬軟件，支持Windows，Mac 和 Linux. https://colororacle.org
Sim Daltonism: 一款色盲模擬軟件，可以選擇不同類型的色盲.只有mac版本. https://michelf.ca/projects/mac/sim-daltonism/
Toptal:一款在線模擬色盲工具. https://www.toptal.com/designers/colorfilter
Color-contrast-checker: 顏色對比度檢查器，提供快速調節， figma插件 https://www.figma.com/community/plugin/733159460536249875/A11y—Color-Contrast-Checker
Tanaguru Contrast Finder: 檢測顏色對比度，如果你的顏色沒有達到要求，還會提供新顏色建議. https://contrast-finder.tanaguru.com
Color Review: 提供兩種顏色組合在一起的預覽，檢測結果失敗還會提供顏色建議https://color.review
color contrast checker from polypane: 提供顏色對比和修改建議. https://polypane.app/color-contrast
Accessible colors: 提供顏色對比、修改建議、還可以輸入字體大小和字重. https://accessible-colors.com
Accessible color palette builder:選擇5個顏色，網站會通過分析這些的顏色的排列組合，判斷你的色板是否符合無障礙標準https://toolness.github.io/accessible-color-matrix
contrast grid:通過在左側邊欄手動添加/刪減行列、編輯行列的色值，為您提供這些顏色排列組合的對比度結果，非常高效而且一目了然https://contrast-grid.eightshapes.com
Cloudflare color tool:當你不知道選擇什么顏色毫無頭緒時，你可以嘗試這個網站！它會幫你提取來自某個鏈接、某個圖片的顏色色板，當然你也能輸入色值.然后把這些顏色拖到對應的功能（底色、主色、背景色、描邊色），你就可以預覽下你的產品用了這個色板大概是什么樣子了.它同時也提供這些顏色的排列組合分析https://color.cloudflare.design
少數群體如色盲、老齡化群體、殘障群體等等，在近些年來，他們對無障礙使用互聯網的需求，越來越受到關注，也許你在現在不需要無障礙技術的幫助，但是隨著你變老，在未來的某個階段也許無障礙技術就會大大的幫助你。
色彩無障礙只是無障礙的一小步，但是卻是證明無障礙普及進步的一大步。
參考文章:
https://medium.com/inside-design/a-guide-to-color-accessibility-in-product-design-516e734c160c
https://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness
https://modus.medium.com/the-myths-of-color-contrast-accessibility-4b7fcba77317
https://jfly.uni-koeln.de/color
https://www.bounteous.com/insights/2019/03/22/orange-you-accessible-mini-case-study-color-ratio
本文由郝小七指導http：//www.woshipm.com/u/917803
本文由 @自來卷夏憶 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
gt; 這是一篇有故事的文章 --- 來自一個weex在生產環境中相愛相殺的小碼畜..故事一: Build
雖然
weex
的口號是
一次撰寫 多端運行
, 但其實
build
環節是有差異的,
native
端構建需要使用
weex-loader
, 而
web
端則是使用
vue-loader
,除此以外還有不少差異點, 所以
webpack
需要兩套配置.
最佳實踐
使用
webpack
生成兩套
bundle
,一套是基于
vue-router
的
web spa
, 另一套是
native
端的多入口的
bundlejs
首先假設我們在
src/views
下開發了一堆頁面
build web配置
web端的入口文件有
render.js
import weexVueRenderer from 'weex-vue-render'Vue.use(weexVueRenderer)
main.js
import App from './App.vue'import VueRouter from 'vue-router'import routes from './routes'Vue.use(VueRouter)
App.vue
<template>
webpack.prod.conf.js
入口
const webConfig = merge(getConfig('vue'), {build native配置
native端的打包流程其實就是將
src/views
下的每個
.vue
文件導出為一個個單獨的
vue
實例, 寫一個
node
腳本即可以實現
// build-entry.js
// build-entry.js require('shelljs/global') const path = require('path') const fs = require('fs-extra') const srcPath = path.resolve(__dirname, '../src/views') // 每個.vue頁面 const entryPath = path.resolve(__dirname, '../entry/') // 存放入口文件的文件夾 const FILE_TYPE = '.vue' const getEntryFileContent = path => { return `// 入口文件 import App from '${path}${FILE_TYPE}' /* eslint-disable no-new */ new Vue({ el: '#root', render: h => h(App) }) ` } // 導出方法 module.exports = _ => { // 刪除原目錄 rm('-rf', entryPath) // 寫入每個文件的入口文件 fs.readdirSync(srcPath).forEach(file => { const fullpath = path.resolve(srcPath, file) const extname = path.extname(fullpath) const name = path.basename(file, extname) if (fs.statSync(fullpath).isFile() && extname === FILE_TYPE) { //寫入vue渲染實例 fs.outputFileSync(path.resolve(entryPath, name + '.js'), getEntryFileContent('../src/views/' + name)) } }) const entry = {} // 放入多個entry fs.readdirSync(entryPath).forEach(file => { const name = path.basename(file, path.extname(path.resolve(entryPath, file))) entry[name] = path.resolve(entryPath, name + '.js') }) return entry }webpack.build.conf.js
中生成并打包多入口
const buildEntry = require('./build_entry') // .. // weex配置 const weexConfig = merge(getConfig('weex'), { entry: buildEntry(), // 寫入多入口 output: { path: path.resolve(distPath, './weex'), filename: 'js/[name].js' // weex環境無需使用hash名字 }, module: { rules: [ { test: /\.vue$/, loader: 'weex-loader' } ] } }) module.exports = [webConfig, weexConfig]最終效果
故事二: 使用預處理器
在
vue
單文件中, 我們可以通過在
vue-loader
中配置預處理器, 代碼如下
{ test: /\.vue$/, loader: 'vue-loader', options: { loaders: { scss: 'vue-style-loader!css-loader!sass-loader', // <style> sass: 'vue-style-loader!css-loader!sass-loader?indentedSyntax' // <style> } } }而
weex
在native環境下其實將
css
處理成
json
加載到模塊中, 所以...
使用
vue-loader
配置的預處理器在web環境下正常顯示, 在
native
中是無效的
native環境下不存在全局樣式, 在js文件中
import 'index.css'
也是無效的
解決問題一
研究
weex-loader
源碼后發現在
.vue
中是無需顯示配置
loader
的, 只需要指定
<style>
并且安裝
stylus stylus-loader
即可,
weex-loader
會根據
lang
去尋找對應的
loader
. 但因為
scss
使用
sass-loader
, 會報出
scss-loader not found
, 但因為
sass
默認會解析
scss
語法, 所以直接設置
lang="sass"
是可以寫
scss
語法的, 但是
ide
就沒有語法高亮了. 可以使用如下的寫法
<style> @import './index.scss' </style>
語法高亮, 完美!
解決問題二
雖然沒有全局樣式的概念, 但是支持單獨
import
樣式文件
<style lang="sass">
故事三: 樣式差異
這方面官方文檔已經有比較詳細的描述, 但還是有幾點值得注意的
簡寫
weex
中的樣式不支持簡寫, 所有類似
margin: 0 0 10px 10px
的都是不支持的
背景色
android
下的view是有白色的默認顏色的, 而iOS如果不設置是沒有默認顏色的, 這點需要注意
浮點數誤差
weex
默認使用
750px * 1334px
作為適配尺寸, 實際渲染時由于浮點數的誤差可能會存在幾
px
的誤差, 出現細線等樣式問題, 可以通過加減幾個
px
來調試
嵌套寫法
即使使用了預處理器,
css
嵌套的寫法也是會導致樣式失效的
故事四: 頁面跳轉
weex
下的頁面跳轉有三種形式
native -> weex
:
weex
頁面需要一個控制器作為容器, 此時就是
native
間的跳轉
weex -> native
: 需要通過module形式通過發送事件到native來實現跳轉
weex -> weex
: 使用navigator模塊, 假設兩個
weex
頁面分別為
a.js, b.js
, 可以定義
mixin
方法
function isWeex () { return process.env.COMPILE_ENV === 'weex' // 需要在webpack中自定義這樣就組件里使用
this.push(url), this.pop()
來跳轉
跳轉配置
iOS下頁面跳轉無需配置, 而
android
是需要的, 使用
weexpack platform add android
生成的項目是已配置的, 但官方的文檔里并沒有對于已存在的應用如何接入進行說明
其實
android
中是通過
intent-filter
來攔截跳轉的
<activity
然后我們新建一個
WXPageActivity
來代理所有
weex
頁面的渲染, 核心的代碼如下
[@Override](/user/Override) protected void onCreate(Bundle saveInstanceState) { // ...順便說下...
weex
官方沒有提供可定制的
nav
組件真的是很不方便..經常需要通過
module
橋接
native
來實現跳轉需求
來自@荔枝我大哥 的補充
安卓和蘋果方面可以在原生代碼接管`navigator`這個模塊，安卓方面只需要實現`IActivityNavBarSetter`，蘋果方面好像是`WXNavigatorProtocol`,然后在app啟動初始化weex時注冊即可。
故事五: 頁面間數據傳遞
native -> weex
: 可以在
native
端調用
render
時傳入的
option
中自定義字段, 例如
NSDictary *option = @{@"params": @{}}
， 在
weex
中使用
weex.config.params
取出數據
weex -> weex
: 使用storage
weex -> native
: 使用自定義module
故事六: 圖片加載
官網有提到如何加載網絡圖片 但是加載本地圖片的行為對于三端肯定是不一致的, 也就意味著我們得給
native
重新改一遍引用圖片的路徑再打包...
但是當然是有解決辦法的啦
Step 1
webpack
設置將圖片資源單獨打包, 這個很easy, 此時
bundleJs
訪問的圖片路徑就變成了
/images/..
{Step 2 那么現在我們將同級目錄下的js文件夾與images文件夾放入
native
中, iOS中一般放入
mainBundle
, Android一般放入
src/main/assets
, 接下來只要在
imgloader
接口中擴展替換本地資源路徑的代碼就ok了
iOS
代碼如下:
- (id<WXImageOperationProtocol>)downloadImageWithURL:(NSString *)url imageFrame:(CGRect)imageFrame userInfo:(NSDictionary *)options completed:(void (^)(UIImage *, NSError *, BOOL))completedBlock{ if ([url hasPrefix:@"http://"]) {Android
代碼如下:
[@Override](/user/Override) public void setImage(final String url, final ImageView view,
故事七: 生產環境的實踐
增量更新
方案一
可以使用google-diff-match-patch來實現, google-diff-match-patch擁有許多語言版本的實現, 思路如下:
服務器端構建一套管理前端
bundlejs
的系統, 提供查詢
bundlejs
版本與下載的api
客戶端第一次訪問
weex
頁面時去服務端下載
bundlejs
文件
每次客戶端初始化時靜默訪問服務器判斷是否需要更新, 若需更新, 服務器端
diff
兩個版本的差異, 并返回
diff
,
native
端使用
patch api
生成新版本的
bundlejs
方案二
來自 @荔枝我大哥的補充
我們所有的jsBundle全部加載的線上文件，通過http頭信息設置`E-Tag`結合`cache-control`來實現緩存策略，最終效果就是，A.vue -> A.js, app第一次加載A.js是從網絡下載下來并且保存到本地，app第二次加載A.js是直接加載的保存到本地的 A.js文件，線上A.vue被修改，A.vue -> A.js, app第三次加載A.js時根據緩存策略會知道線上A.js 已經和本地A.js 有差異，于是重新下載A.js到本地并加載. (整個流程通過http緩存策略來實現，無需多余編碼，參考https://developers.google.cn/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn)
還可以參考很多ReactNative的成熟方案, 本質上都是js的熱更新
降級處理
一般情況下, 我們會同時部署一套
web
端界面, 若線上環境的
weex
頁面出現bug, 則使用webview加載
web
版, 推薦依賴服務端api來控制降級的切換
總結
weex
的優勢: 依托于
vue
, 上手簡單. 可以滿足以
vue
為技術主導的公司給
native
雙端提供簡單/少底層交互/熱更新需求的頁面的需求
weex
的劣勢: 在
native
端調整樣式是我心中永遠的痛.. 以及眾所周知的生態問題, 維護組沒有花太多精力解答社區問題, 官方文檔錯誤太多, 導致我在看的時候就順手提了幾個PR(逃
對于文章中提到的沒提到的問題, 歡迎來和筆者討論, 或者參考我的weex-start-kit, 當然點個star也是極好的
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
