<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          偽類和偽元素

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          定義:

          偽類和偽元素就是為文檔中不一定存在的結構指定樣式,或者為某些元素(甚至文檔本身)的狀態所指示的幻象類指定樣式。css引入偽類和偽元素概念是為了格式化文檔樹以外的信息。

          偽類的形式:選擇符: 偽類{ 屬性:屬性值 }

          偽元素的形式:選擇符:: 偽元素{ 屬性:屬性值 }

          CSS3規范中要求使用雙冒號(::)表示偽元素,以此來區分偽元素和偽類。

           

          鏈接偽類

          a:link{…}  //指向未訪問的鏈接

          a:visited{…} //指向已訪問的鏈接

           

          動態偽類

          E:hover{…}  //元素上有鼠標指針停留

          E:active{…} //元素被用戶輸入激活

          E:focus{…}  //元素擁有輸入焦點

           

          偽類的順序很重要,一般為link-visited-focus-hover-active。動態偽類可以應用到任何元素,可以為用戶提供一種“強調”的作用。


          E:first-child{…}

          為父元素(可以body,div,ul,ol等)中的第一個子元素E元素設置樣式,注意,E必須是父元素中的第一個子元素。

           

          E:lang(value)

          為E元素中lang屬性為value的元素設置屬性。相當于E[lang |= “value”]。

           

          結合偽類

          a:link:hover{…}//鼠標停留在未訪問的鏈接上

          a:visited:hover{…}//鼠標停留在已訪問的鏈接上

           

          偽元素選擇器

          在文檔中插入假想元素,導致用戶代理對一個假想元素做出響應。

          p:first-letter{…}  //設置首字母樣式,為p塊級元素第一個元素設置樣式

          p:first-line{…}   //設置第一行的樣式,為p塊級元素第一個元素設置樣式

          所有偽元素都必須放在出現該偽元素的選擇器的最后面。

           

          設置之前和之后元素的樣式

          E:before {content:”…”}

          E:after {content:”…”}


          注:關于偽類和偽元素,我的理解并不是很深,不過掌握上面的這些內容,我想也是夠用了。以上內容大部分是《CSS權威指南》中內容,總結了一下方便記憶。關于偽類和偽元素的內容,這里有一個不錯的文章,下面是這篇文章的鏈接:http://www.alloyteam.com/2016/05/summary-of-pseudo-classes-and-pseudo-elements/#prettyPhoto 下面的內容引自這篇文章,可以補充上面的內容,貼在這里方便自己日后查閱。

          偽類與偽元素的具體用法


          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          vue生命周期鉤子函數(11個)

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          說一下vue的聲明周期:

          vue 的生命周期11個鉤子函數是按照以下的順序來的 :(不可逆轉哦,第11個除外) 
          一. 組件創建前后

          1.beforeCreate
          2.created
              
          • 1
          • 2

          如,寫一個子組件,然后掛在到父組件,在子組件中,console.log 子組件中的

          data(){ return { a:1 },
              beforeCreate(){
                  console.log(this.a)//undefined },
              created(){
                  console.log(this.a)//1 }
          }
              
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11


          .


          二. vue啟動前后

          3.beforeMount 4.mounted
              
          • 1
          • 2

          這兩個的意思就是, 
          vue在beforeMount時,還不管事,也就是說,還沒有渲染數據到<div id="app"><div/>里面,此時的這個組件還是空的

          mounted時,才會往<div id="app"><div/> 添加東西,也就是vue正式 
          接管<div id="app"><div/>

          可以獲取#app的innerHTML查看差異;

          beforeMount(){ console.log(document.getElementById('app').innerHTML)//空的
          },
          mounted(){ console.log(document.getElementById('app').innerHTML)//#app里的內容 }
              
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6


          .


          三. 組件更新前后

          5.beforeUpdate 6.updated
              
          • 1
          • 2

          這個就不用我多說了吧?當子組件里面的 視圖改變 的時候觸發。 
          如,做一個按鈕,讓data里面的a++,假如 一開始a是1 
          beforeUpdate返回1 
          updated返回2

          beforeUpdate(){
              console.log(document.getElementById('a').innerHTML)//1 },
          updated(){
              console.log(document.getElementById('a').innerHTML)//2 }
              
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6

          再點一次 
          beforeUpdate返回2 
          updated返回3。。。 

          .


          四. 組件銷毀前后(一般配合v-if使用)

          7.beforeDestroy
          8.destroyed
              
          • 1
          • 2

          給這個子組件用v-if來控制它的銷毀和創建,注意以下:v-show不行。 
          子組件銷毀前觸發beforeDestroy 
          子組件銷毀后觸發destroyed 
          第一次會觸發7.8. 
          創建子組件后會觸發以上的第1.2.3.4.鉤子函數。

          有一個問題,如果我們在子組件里寫一個定時器,然后,子組件被銷毀了,定時器還會執行嗎? 
          答案是會的 
          所以這時候就會用到了destroyed,在組件被銷毀后,我們把定時器給清除就好了。

          所以這兩個鉤子函數一般用于做性能的優化。 

          .


          五. 組件激活時,未激活時

          9.activated
          10.deactivated
              
          • 1
          • 2

          這兩個鉤子函數呢一般配合<keep-alive><keep-alive/>來使用。 
          通過看 四。這個例子,你肯定知道了一個組件怎么被銷毀和創建。 
          但是我們知道通常一個組件是很大的,如果我們總是一直創建、銷毀、創建、銷毀。。。這樣很不合理,而且很浪費性能。。。

          這時候我們就可以用<keep-alive><keep-alive/>配合著兩個鉤子函數來控制組件的激活和不激活。

          說一下<keep-alive><keep-alive/>,它就相當于把你的組件給緩存下來了,目的呢就是不讓組件重復的渲染,然后我們通過v-if觸發,子組件就不會再觸發7 和 8 了,而是只會頻繁的觸發9 和 10 
          這樣性能會比7 和 8 好的多。 

          .


          六. 當捕獲一個來自子孫組件的錯誤時被調用

          11.errorCaptured
              
          • 1

          當子孫組件報錯的時候,父組件會觸發這個鉤子函數,并且會返回三個參數, 
          第一個參數是 錯誤對象 
          第二個參數是 報錯的子孫組件 
          第三個參數是 報錯的子孫組件的具體哪個地方報錯。(如,假如我沒有定義b這個變量,但是我去console.log(b) 這一句肯定會報錯,假如我把這句錯誤代碼寫在了created這個鉤子函數里,那第三個參數會返回就是:created hook

          具體第11個沒深入研究,喜歡的可以去看下官網的 errorCaptured。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


          React生命周期函數詳解和注意事項

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          React生命周期函數

          生命周期函數是指在某一個周期自動執行的函數。 

          React中的生命周期執行過程

          以下是React中的常用的生命周期函數,按個部分中按照自動執行順序列出,這幾個過程可能存在同時進行

          初始化過程(Initialization)

          • consructor()里面初始化PropsState屬性。

          掛載過程(Mounting)

          1. componentWillMount():在組件即將被掛載到頁面的時刻自動執行。
          2. render():將組件掛載到頁面。
          3. componentDidMount():組件被掛載到頁面之后立即執行。

          更新過程(Updating)

          1. componentWillReceiveProps():一個組件要從父組件接收參數, 只要父組件的render()函數非首次(如果這個組件第一次存在與父組件中不會執行,如果已經存在于父組件中才會執行)執行了,子組件的這個生命周期函數就會被執行。如果組件沒有Props屬性則直接跳過
          2. shouldComponentUpdate():組件更行之前檢查是否需要更新,注意這個函數要有一個布爾類型返回值,如果返回false,這一部分的生周期 函數將不會繼續執行,即無論如何組件都不會更新。利用這個生命周期函數可以強制關閉不需要更新的子組件來提升渲染性能
          3. componentWillUpdate():組件更新之前。自動執行。但要在shouldComponentUpdate()執行并返回true之后執行。
          4. render():將組件更新到頁面。
          5. componentDidUpdate():組件更新完成之后立即執行。

          移除過程(Unmounting)

          • componentWillMount():當組件即將被頁面剔除時執行。

          注意事項



          VUE 學習總結之簡單的Rate評分組件

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          說明

          本組件基于element-ui 的圖標庫(星星圖標)

          第一步:

          vue + webpack + element-ui 框架

          第二步:

          創建Rate.vue文件,實現雙向綁定分數

          第三部:

          使用組件

          代碼

          在app.vue中引入組件

          
              
          1. <Rate v-model='value' size="32px">
          2. <span>{{value}} 分</span>
          3. </Rate>
          import Rate from './components/Rate'

          組件

          
              
          1. <template>
          2. <div class="Rating" :value='value'>
          3. <ul class="Rating-list">
          4. <li v-for="s in 5" @click="changeRate(s)">
          5. <i :class="s <= star ? 'el-icon-star-on':'el-icon-star-off'" :style='style'></i>
          6. </li>
          7. </ul>
          8. <slot></slot> <!--顯示用戶自定義內容-->
          9. </div>
          10. </template>

          
              
          1. props: {
          2. size: { //父組件傳值設置字體大小
          3. type: String,
          4. default: '16px'
          5. },
          6. value: { //綁定value,與$emit實現雙向綁定
          7. type:Number,
          8. default:0
          9. }
          10. },
          11. data() {
          12. return {
          13. star: this.value, // 初始化
          14. style: {
          15. fontSize: this.size //通過prop傳值設置星星字體大小
          16. }
          17. }
          18. },
          19. methods: {
          20. changeRate(s) {
          21. this.star = s //更新當前星星數量
          22. this.$emit('input', s); //將當前星星數量s與v-model綁定
          23. }
          24. }

          demo演示



          移動端適配問題解決方案

          周周

          隨著時間的發展,現在基本上人手一部手機的低頭族。做為前端開發的程序猿,在開發移動端web應用的時候,對面一堆各色尺寸不一樣的屏幕,就有點淡淡的憂傷。

          QQ截圖20180705114651.png

          QQ截圖20180705114755.png

          以上是2018年二月份的友盟數據,可在這里查看詳情
          很明顯我們所要實現的就是在上述如此之多的屏幕,都能實現UI大大出的視覺圖上的效果。而要實現這樣的效果主要有兩個難點

          • 各屏幕適配
          • Retina屏下的細節處理(主要是1px的問題)

          各屏幕適配各屏幕的適配,有兩種方案,flexible + rem 與 vw。這三個單詞是什么意思,看著很眼熟,但是這兩個方案居然是什么呢,請允許我細細道來。

          flexible + rem顯而易見,該方案是由rem 以及 flexible組成的。rem (font size of the root element)相對于根元素(即html元素)font-size計算值的倍數,flexible 即 flexible.js, 手淘團隊提供的一個為該方案屏幕適配而寫的一個庫,主要實現的功能就是,根據屏幕的寬度給 html 元素設置一個合適的 font-size 值。

          怎么樣看的不是很懂是吧。讓我來用一個頁面場景再復述一遍。

          正常情況下,我們的UI大大會以iphone6的尺寸為標準,做一套視覺效果圖,并在上面進行標注,給到我們的標注圖,如下所示

          QQ截圖20180705115007.png

          拿到這個圖 我們該如何下手呢

          • 先設置 html 元素的 font-size, 這個值我們暫時設置為 font-size: 37.5px,即1rem = 37.5px;
          • 以iphone6為例子,其屏幕寬度為 750px, 整個屏幕的寬度即 20rem = 37.5 * 20px = 750px;
          • 此時手機號的輸入框為 490px = 13.06777777rem
          • 依次將頁面上的px轉換為rem,這樣我們就得到了全是rem為尺寸單位的頁面

          到這里為止是不是就結束了呢 ? 很遺憾的告訴你并不是。為什么 html 元素的 font-size 要設置為 37.5px呢?現在這個界面在iphone6上能完美顯示了,在iphone5s,iphone6p能完美顯示嗎?(iphone6, iphone6s, iphone7. iphone8屏幕沒有發生變化,本文直接用iphone6代替了。)上面的兩個問題 我們還有沒解決,這個時候就輪到flexible登場了。只需要像如下引入就可實現用js來自動根據屏幕寬度設置 html元素的font-size的值。

          <script src=";引申一下在上述過程中,你會發現,UI給到我們的一般是px標注的圖,我們將其轉化為rem,這個過程其實會花費很大的計算時間。做為一個合格的程序員,我們應該把這種機械性無腦的操作交給計算機來實現。我使用的是PostCss的插件 postcss-px2rem,這個插件能讓我們在寫代碼時候直接寫px,在構建的時候自動將我們所寫的px轉換為rem,大大提升了我們的開發效率。

          vw這個vw的方案,相當而言還比較新。vw 即(viewport width)可視窗口的寬度。之所以把這個方案放在后面來說,是因為viewport在去年(2017年)的時候存在不少的兼容性問題,各個瀏覽器的支持并不是很好。但是來到了2018年這個時間點,viewport單位意見得到了眾多瀏覽器的支持(80.45%)。


          QQ截圖20180705115133.png

          可以在這里查看。
          接下來就讓我們來正式了解下這個方案吧。vw既然是一個尺寸單位,那它的寬度等于多少呢?等于1%整個屏幕的寬度。舉個例子,再次以iphone6手機為例,100vw = 750px => 1vw = 7.5px
          再一次那上次的界面做示范

          QQ截圖20180705115007.png


          • 根據定義,我們了解了在iphone6手機上 1vw = 7.5px
          • 此時手機號的輸入框為 490px = 65.333333vw
          • 依次將頁面上的px轉換為vw,這樣我們就得到了全是vw為尺寸單位的頁面

          到這里為止是不是就結束了呢? 是的就是這么簡單。

          引申一下跟之前一樣的痛點,我們仍然需要花費大量不必要的計算時間去把標注圖中的px轉換為vw,有沒有類似于postcss-px2rem的工具呢?很榮幸能再次站在巨人的肩膀上,已經有大神寫了了類似的PostCss插件 postcss-px-to-viewport

          1px問題移動端的屏幕不僅僅分辨率有差異,其實還有Retina屏的問題。正常情況下,我們代碼里的1px在屏幕上就應該顯示一個像素點,但是在Retina屏下則不僅僅是一個像素點。再次拿iphone6為例,其dpr(device pixel ratio)設備像素比為2,css中一個1x1的點,其實在iphone6上是2x2的點,并且1px的邊框在devicePixelRatio = 2的Retina屏下會顯示成2px,在iPhone6 Plus下甚至會顯示成3px。

          這樣的話,我們就會發現在有些手機上1px明顯跟另外的一些手機的1px粗細不一樣。其實大多數的小公司不會扣這樣的一個細節,比如說我們公司不會。(^__^) 嘻嘻……

          但是作為一個有追求的前端工程師,我們應該盡量的把事情做的完美一點,(ps.像大公司看齊,在大公司這個細節問題其實是不容忽視的,為了自己以后的發展前途,我們有必要把這個細節完善掉的。)

          這個問題的解決方案有很多,個人覺得最簡單方面的還是大漠大大的一種解決方案。使用postcss-write-svg插件,

          @svg 1px-border {  height: 2px;  @rect {    fill: var(--color, black);    width: 100%; height: 50%;    }  }.example {  border: 1px solid transparent;  border-image: svg(1px-border param(--color #00b1ff)) 2 2 stretch;}編譯出來就是

          .example {  border: 1px solid transparent;  border-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='其他小程序中的屏幕適配最近在寫小程序,在小程序里,使用的是小程序的那套,跟平時用的vue全家桶以及react全家桶不一樣,并沒有配置webpack,在這種情況下我們使用postcss其實很困難(反正我是搞不出來/(ㄒoㄒ)/~~)

          那該怎么辦呢,小程序提供了一個自己的單位, rpx(responsive pixel): 可以根據屏幕寬度進行自適應。規定屏幕寬為750rpx。如在 iPhone6 上,屏幕寬度為375px,共有750個物理像素,則750rpx = 375px = 750物理像素,1rpx = 0.5px = 1物理像素。



          設備

          rpx換算px (屏幕寬度/750)
          px換算rpx (750/屏幕寬度)



          iPhone5

          1rpx = 0.42px
          1px = 2.34rpx



          iPhone6

          1rpx = 0.5px
          1px = 2rpx



          iPhone6p

          1rpx = 0.552px
          1px = 1.81rpx

          我們直接用拿到iphone6的標注圖,直接寫rpx就好。



          什么是ATL? (與COM的關系,及MFC與COM的關系)

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          摘要: 什么是ATL(與COM的關系,及MFC與COM的關系)自從1993年Microsoft首次公布了COM技術以后,Windows平臺上的開發模式發生了巨大的變化,以COM為基礎的一系列軟件組件化技術將Windows編程帶入了組件化時代。廣大的開發人員在為COM帶來的軟件組件化趨勢歡欣鼓舞的同時,對于COM開發技術的難度和煩瑣的細節也感到極其的不便。COM編程一度被視為一種高不可攀的技術,令人望而卻步

          什么是ATL (與COM的關系,及MFC與COM的關系)
          自從1993年Microsoft首次公布了COM技術以后,Windows平臺上的開發模式發生了巨大的變化,以COM為基礎的一系列軟件組件化技術將Windows編程帶入了組件化時代。廣大的開發人員在為COM帶來的軟件組件化趨勢歡欣鼓舞的同時,對于COM開發技術的難度和煩瑣的細節也感到極其的不便。COM編程一度被視為一種高不可攀的技術,令人望而卻步。開發人員希望能夠有一種方便快捷的COM開發工具,提高開發效率,更好地利用這項技術。
          針對這種情況,Microsoft公司在推出COMSDK以后,為簡化COM編程,提高開發效率,采取了許多方案,特別是在MFC(MicrosoftFoundationClass)中加入了對COM和OLE的支持。但是隨著Internet的發展,分布式的組件技術要求COM組件能夠在網絡上傳輸,而又盡量節約寶貴的網絡帶寬資源。采用MFC開發的COM組件由于種種限制不能很好地滿足這種需求,因此Microsoft在1995年又推出了一種全新的COM開發工具ATL。
          ATL是ActiveX Template Library的縮寫,它是一套C++模板庫。使用ATL能夠快速地開發出、簡潔的代碼(Effectiveand Slimcode),同時對COM組件的開發提供最大限度的代碼自動生成以及可視化支持。為了方便使用,從MicrosoftVisual C++ 5.0版本開始,Microsoft把ATL集成到VisualC++開發環境中。1998年9月推出的Visual Studio 6.0 集成了ATL3.0版本。目前,ATL已經成為Microsoft標準開發工具中的一個重要成員,日益受到C++開發人員的重視。
          ATL究竟給開發人員帶來了什么樣的益處呢?這還要先從ATL產生以前的COM開發方式說起。
          在ATL產生以前,開發COM組件的方法主要有兩種:一是使用COMSDK直接開發COM組件,另一種方式是通過MFC提供的COM支持來實現。
          直接使用COMSDK開發COM組件是最基本也是最靈活的方式。通過使用Microsoft提供的開發包,我們可以直接編寫COM程序。但是,這種開發方式的難度和工作量都很大,一方面,要求開發者對于COM的技術原理具有比較深入的了解(雖然對技術本身的深刻理解對使用任何一種工具都是非常有益的,但對于COM這樣一整套復雜的技術而言,在短時間內完全掌握是很難的),另一方面,直接使用COMSDK要求開發人員自己去實現COM應用的每一個細節,完成大量的重復性工作。這樣做的結果是,不僅降低了工作效率,同時也使開發人員不得不把許多精力投入到與應用需求本身無關的技術細節中。雖然這種開發方式對于某些特殊的應用很有必要,但這種編程方式并不符合組件化程序設計方法所倡導的可重用性,因此,直接采用COMSDK不是一種理想的開發方式。
          使用MFC提供的COM支持開發COM應用可以說在使用COMSDK基礎上提高了自動化程度,縮短了開發時間。MFC采用面向對象的方式將COM的基本功能封裝在若干MFC的C++類中,開發者通過繼承這些類得到COM支持功能。為了使派生類方便地獲得COM對象的各種特性,MFC中有許多預定義宏,這些宏的功能主要是實現COM接口的定義和對象的注冊等通常在COM對象中要用到的功能。開發者可以使用這些宏來定制COM對象的特性。
          另外,在MFC中還提供對Automation 和 ActiveXControl的支持,對于這兩個方面,VisualC++也提供了相應的AppWizard和ClassWizard支持,這種可視化的工具更加方便了COM應用的開發。
          MFC對COM和OLE的支持確實比手工編寫COM程序有了很大的進步。但是MFC對COM的支持是不夠完善和徹底的,例如對COM接口定義的IDL語言,MFC并沒有任何支持,此外對于近些年來COM和ActiveX技術的新發展MFC也沒有提供靈活的支持。這是由MFC設計的基本出發點決定的。MFC被設計成對Windows平臺編程開發的面向對象的封裝,自然要涉及Windows編程的方方面面,COM作為Windows平臺編程開發的一個部分也得到MFC的支持,但是MFC對COM的支持是以其全局目標為出發點的,因此對COM的支持必然要服從其全局目標。從這個方面而言,MFC對COM的支持不能很好的滿足開發者的要求。
          隨著Internet技術的發展,Microsoft將ActiveX技術作為其網絡戰略的一個重要組成部分大力推廣,然而使用MFC開發的ActiveXControl,代碼冗余量大(所謂的“肥代碼 FatCode”),而且必須要依賴于MFC的運行時刻庫才能正確地運行。雖然MFC的運行時刻庫只有部分功能與COM有關,但是由于MFC的繼承實現的本質,ActiveXControl必須背負運行時刻庫這個沉重的包袱。如果采用靜態連接MFC運行時刻庫的方式,這將使ActiveXControl代碼過于龐大,在網絡上傳輸時將占據寶貴的網絡帶寬資源;如果采用動態連接MFC運行時刻庫的方式,這將要求瀏覽器一方必須具備MFC的運行時刻庫支持??傊甅FC對COM技術的支持在網絡應用的環境下也顯得很不靈活。
          解決上述COM開發方法中的問題正是ATL的基本目標。
          首先ATL的基本目標就是使COM應用開發盡可能地自動化,這個基本目標就決定了ATL只面向COM開發提供支持。目標的明確使ATL對COM技術的支持達到淋漓盡致的地步。對COM開發的任何一個環節和過程,ATL都提供支持,并將與COM開發相關的眾多工具集成到一個統一的編程環境中。對于COM/ActiveX的各種應用,ATL也都提供了完善的Wizard支持。所有這些都極大地方便了開發者的使用,使開發者能夠把注意力集中在與應用本身相關的邏輯上。
          其次,ATL因其采用了特定的基本實現技術,擺脫了大量冗余代碼,使用ATL開發出來的COM應用的代碼簡練,即所謂的“SlimCode”。ATL在實現上盡可能采用優化技術,甚至在其內部提供了所有C/C++開發的程序所必須具有的C啟動代碼的替代部分。同時ATL產生的代碼在運行時不需要依賴于類似MFC程序所需要的龐大的代碼模塊,包含在最終模塊中的功能是用戶認為最基本和最必須的。這些措施使采用ATL開發的COM組件(包括ActiveXControl)可以在網絡環境下實現應用的分布式組件結構。
          第三,ATL的各個版本對Microsoft的基于COM的各種新的組件技術如MTS、ASP等都有很好的支持,ATL對新技術的反應速度大大快于MFC。ATL已經成為Microsoft支持COM應用開發的主要開發工具,因此COM技術方面的新進展在很短的時間內都會在ATL中得到反映。這使開發者使用ATL進行COM編程可以得到直接使用COMSDK編程同樣的靈活性和強大的功能。
          本文的目的就是希望在有限的篇幅中能夠使讀者對ATL的使用和基本原理有一個初步的了解,為廣大的COM開發人員更好地使用ATL開發起到拋磚引玉的作用。


          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          開發中我們需要遵循的幾個設計原則!

          周周

          出處:https://www.cnblogs.com/pengdai


          一、開發原則
          S:單一職責SRP
          O:開放封閉原則OCP
          L:里氏替換原則LSP
          I:接口隔離法則
          D:依賴倒置原則DIP
          合成/聚合復用原則
          迪米特法則
          在軟件開發中,前人對軟件系統的設計和開發總結了一些原則和模式, 不管用什么語言做開發,都將對我們系統設計和開發提供指導意義。本文主要將總結這些常見的原則和具體闡述意義。
          面向對象的基本原則(solid)是五個,但是在經常被提到的除了這五個之外還有迪米特法則和合成復用原則等,所以在常見的文章中有表示寫六大或七大原則的; 除此之外我還將給出一些其它相關書籍和互聯網上出現的原則;

          二、S單一職責SRP

          Single-Responsibility Principle,一個類,最好只做一件事,只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則的引申,將職責定義為引起變化的原因,以提高內聚性減少引起變化的原因。

          1、定義

          一個對象應該只包含單一的職責,并且該職責被完整地封裝在一個類中。(Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.),即又定義有且僅有一個原因使類變更。

          2、原則分析

          一個類或者大到模塊,小到方法,承擔的職責越多,它被復用的可能性越小,而且如果一個類承擔的職責過多,就相當于將這些職責耦合在一起,當其中一個職責變化時,可能會影響其他職責的運作。
          類的職責主要包括兩個方面:數據職責和行為職責,數據職責通過其屬性來體現,而行為職責通過其方法來體現。
          單一職責原則是實現高內聚、低耦合的指導方針,在很多代碼重構手法中都能找到它的存在,它是最簡單但又最難運用的原則,需要設計人員發現類的不同職責并將其分離,而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。

          3、優點

          降低類的復雜性,類的職責清晰明確。比如數據職責和行為職責清晰明確;
          提高類的可讀性和維護性;
          變更引起的風險減低,變更是必不可少的,如果接口的單一職責做得好,一個接口修改只對相應的類有影響,對其他接口無影響,這對系統的擴展性、維護性都有非常大的幫助。
          注意:單一職責原則提出了一個編寫程序的標準,用“職責”或“變化原因”來衡量接口或類設計得是否合理,但是“職責”和“變化原因”都是沒有具體標準的,一個類到底要負責那些職責?這些職責怎么細化?細化后是否都要有一個接口或類?這些都需從實際的情況考慮。因項目而異,因環境而異。

          4、例子

          SpringMVC中Entity、DAO、Service、Controller、Util等的分離。

          三、O開放封閉原則OCP

          Open - ClosedPrinciple,OCP對擴展開放,對修改關閉(設計模式的核心原則)

          1、定義

          一個軟件實體(如類、模塊和函數)應該對擴展開放,對修改關閉。意思是在一個系統或者模塊中,對于擴展是開放的,對于修改是關閉的。一個 好的系統是在不修改源代碼的情況下,可以擴展你的功能。而實現開閉原則的關鍵就是抽象化。

          2、原則分析

          當軟件實體因需求要變化時, 盡量通過擴展已有軟件實體,可以提供新的行為,以滿足對軟件的新的需求,而不是修改已有的代碼,使變化中的軟件有一定的適應性和靈活性 。已有軟件模塊,特別是最重要的抽象層模塊不能再修改,這使變化中的軟件系統有一定的穩定性和延續性。
          實現開閉原則的關鍵就是抽象化 :在"開-閉"原則中,不允許修改的是抽象的類或者接口,允許擴展的是具體的實現類,抽象類和接口在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴展..所以在這里"抽象化"是關鍵!
          可變性的封閉原則:找到系統的可變因素,將它封裝起來。這是對"開-閉"原則最好的實現。不要把你的可變因素放在多個類中,或者散落在程序的各個角落。你應該將可變的因素,封套起來..并且切忌不要把所用的可變因素封套在一起。最好的解決辦法是,分塊封套你的可變因素!避免超大類、超長類、超長方法的出現!!給你的程序增加藝術氣息,將程序藝術化是我們的目標!

          3、例子

          設計模式中模板方法模式和觀察者模式都是開閉原則的極好體現。

          四、L里氏替換原則LSP

          Liskov Substitution Principle,LSP:任何基類可以出現的地方,子類也可以出現;這一思想表現為對繼承機制的約束規范,只有子類能夠替換其基類時,才能夠保證系統在運行期內識別子類,這是保證繼承復用的基礎。

          1、定義

          第一種定義方式相對嚴格:如果對每一個類型為S的對象o1,都有類型為T的對象o2,使得以T定義的所有程序P在所有的對象o1都代換成o2時,程序P的行為沒有變化,那么類型S是類型T的子類型。
          第二種更容易理解的定義方式:所有引用基類(父類)的地方必須能透明地使用其子類的對象。即子類能夠必須能夠替換基類能夠從出現的地方。子類也能在基類 的基礎上新增行為。
          里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授BarbaraLiskov和卡內基.梅隆大學Jeannette Wing教授于1994年提出。其原文如下:Let q(x) be a property provableabout objects x of type T. Then q(y) should be true for objects y of type Swhere S is a subtype of T.

          2、原則分析

          講的是基類和子類的關系,只有這種關系存在時,里氏代換原則才存在。正方形是長方形是理解里氏代換原則的經典例子。
          里氏代換原則可以通俗表述為:在軟件中如果能夠使用基類對象,那么一定能夠使用其子類對象。把基類都替換成它的子類,程序將不會產生任何錯誤和異常,反過來則不成立,如果一個軟件實體使用的是一個子類的話,那么它不一定能夠使用基類。

          里氏代換原則是實現開閉原則的重要方式之一,由于使用基類對象的地方都可以使用子類對象,因此在程序中盡量使用基類類型來對對象進行定義,而在運行時再確定其子類類型,用子類對象來替換父類對象。

          五、I接口隔離法則

          (Interface Segregation Principle,ISL):客戶端不應該依賴那些它不需要的接口。(這個法則與迪米特法則是相通的)

          1、定義

          客戶端不應該依賴那些它不需要的接口。
          另一種定義方法:一旦一個接口太大,則需要將它分割成一些更細小的接口,使用該接口的客戶端僅需知道與之相關的方法即可。
          注意,在該定義中的接口指的是所定義的方法。例如外面調用某個類的public方法。這個方法對外就是接口。

          2、原則分析:

          (1)接口隔離原則是指使用多個專門的接口,而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色,不多不少,不干不該干的事,該干的事都要干。
          ? 一個接口就只代表一個角色,每個角色都有它特定的一個接口,此時這個原則可以叫做“角色隔離原則”。
          ? 接口僅僅提供客戶端需要的行為,即所需的方法,客戶端不需要的行為則隱藏起來,應當為客戶端提供盡可能小的單獨的接口,而不要提供大的總接口。
          (2)使用接口隔離原則拆分接口時,首先必須滿足單一職責原則,將一組相關的操作定義在一個接口中,且在滿足高內聚的前提下,接口中的方法越少越好。
          (3)可以在進行系統設計時采用定制服務的方式,即為不同的客戶端提供寬窄不同的接口,只提供用戶需要的行為,而隱藏用戶不需要的行為。

          六、D依賴倒置原則DIP

          Dependency-Inversion Principle 要依賴抽象,而不要依賴具體的實現, 具體而言就是高層模塊不依賴于底層模塊,二者共同依賴于抽象。抽象不依賴于具體,具體依賴于抽象。

          1、定義

          高層模塊不應該依賴低層模塊,它們都應該依賴抽象。抽象不應該依賴于細節,細節應該依賴于抽象。簡單的說,依賴倒置原則要求客戶端依賴于抽象耦合。原則表述:
          (1)抽象不應當依賴于細節;細節應當依賴于抽象;
          (2)要針對接口編程,不針對實現編程。

          2、原則分析

          (1)如果說開閉原則是面向對象設計的目標,依賴倒轉原則是到達面向設計"開閉"原則的手段..如果要達到最好的"開閉"原則,就要盡量的遵守依賴倒轉原則. 可以說依賴倒轉原則是對"抽象化"的最好規范! 我個人感覺,依賴倒轉原則也是里氏代換原則的補充..你理解了里氏代換原則,再來理解依賴倒轉原則應該是很容易的。
          (2)依賴倒轉原則的常用實現方式之一是在代碼中使用抽象類,而將具體類放在配置文件中。
          (3)類之間的耦合:零耦合關系,具體耦合關系,抽象耦合關系。依賴倒轉原則要求客戶端依賴于抽象耦合,以抽象方式耦合是依賴倒轉原則的關鍵。

          3、例子1

          理解這個依賴倒置,首先我們需要明白依賴在面向對象設計的概念:
          依賴關系(Dependency):是一種使用關系,特定事物的改變有可能會影響到使用該事物的其他事物,在需要表示一個事物使用另一個事物時使用依賴關系。(假設A類的變化引起了B類的變化,則說名B類依賴于A類。)大多數情況下,依賴關系體現在某個類的方法使用另一個類的對象作為參數。在UML中,依賴關系用帶箭頭的虛線表示,由依賴的一方指向被依賴的一方。
          4、例子2
          某系統提供一個數據轉換模塊,可以將來自不同數據源的數據轉換成多種格式,如可以轉換來自數據庫的數據(DatabaseSource)、也可以轉換來自文本文件的數據(TextSource),轉換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。
          由于需求的變化,該系統可能需要增加新的數據源或者新的文件格式,每增加一個新的類型的數據源或者新的類型的文件格式,客戶類MainClass都需要修改源代碼,以便使用新的類,但違背了開閉原則?,F使用依賴倒轉原則對其進行重構。
          當然根據具體的情況,也可以將AbstractSource注入到AbstractStransformer,依賴注入的方式有以下三種:

          [img]https://ss.csdn.net/p?https://mmbiz.qpic.cn/mmbiz_png/ ... rFZQ/640?wx_fmt=png[/img]

          七、合成/聚合復用原則

          (Composite/Aggregate ReusePrinciple ,CARP):要盡量使用對象組合,而不是繼承關系達到軟件復用的目的。

          1、定義

          經常又叫做合成復用原則(Composite ReusePrinciple或CRP),盡量使用對象組合,而不是繼承來達到復用的目的。
          就是在一個新的對象里面使用一些已有的對象,使之成為新對象的一部分;新對象通過向這些對象的委派達到復用已有功能的目的。簡而言之,要盡量使用合成/聚合,盡量不要使用繼承。

          2、原則分析

          (1)在面向對象設計中,可以通過兩種基本方法在不同的環境中復用已有的設計和實現,即通過組合/聚合關系或通過繼承。
          繼承復用:實現簡單,易于擴展。破壞系統的封裝性;從基類繼承而來的實現是靜態的,不可能在運行時發生改變,沒有足夠的靈活性;只能在有限的環境中使用。(“白箱”復用)
          組合/聚合復用:耦合度相對較低,選擇性地調用成員對象的操作;可以在運行時動態進行。(“黑箱”復用)
          (2)組合/聚合可以使系統更加靈活,類與類之間的耦合度降低,一個類的變化對其他類造成的影響相對較少,因此一般首選使用組合/聚合來實現復用;其次才考慮繼承,在使用繼承時,需要嚴格遵循里氏代換原則,有效使用繼承會有助于對問題的理解,降低復雜度,而濫用繼承反而會增加系統構建和維護的難度以及系統的復雜度,因此需要慎重使用繼承復用。
          (3)此原則和里氏代換原則氏相輔相成的,兩者都是具體實現"開-閉"原則的規范。違反這一原則,就無法實現"開-閉"原則,首先我們要明白合成和聚合的概念:
          注意:聚合和組合的區別是什么?
          合成(組合):表示一個整體與部分的關系,指一個依托整體而存在的關系(整體與部分不可以分開);比如眼睛和嘴對于頭來說就是組合關系,沒有了頭就沒有眼睛和嘴,它們是不可分割的。在UML中,組合關系用帶實心菱形的直線表示。
          聚合:聚合是比合成關系的一種更強的依賴關系,也表示整體與部分的關系(整體與部分可以分開);比如螺絲和汽車玩具的關系,螺絲脫離玩具依然可以用在其它設備之上。在UML中,聚合關系用帶空心菱形的直線表示。

          八、迪米特法則

          (Law of Demeter,LoD:系統中的類,盡量不要與其他類互相作用,減少類之間的耦合度。

          1、定義

          又叫最少知識原則(Least Knowledge Principle或簡寫為LKP)幾種形式定義:
          不要和“陌生人”說話。英文定義為:Don't talk to strangers.
          只與你的直接朋友通信。英文定義為:Talk only to your immediate friends.
          每一個軟件單位對其他的單位都只有最少的知識,而且局限于那些與本單位密切相關的軟件單位。
          簡單地說,也就是,一個對象應當對其它對象有盡可能少的了解。一個類應該對自己需要耦合或調用的類知道得最少,你(被耦合或調用的類)的內部是如何復雜都和我沒關系,那是你的事情,我就知道你提供的public方法,我就調用這么多,其他的一概不關心。

          2、法則分析

          朋友類:在迪米特法則中,對于一個對象,其朋友包括以下幾類:
          (1) 當前對象本身(this);
          (2) 以參數形式傳入到當前對象方法中的對象;
          (3) 當前對象的成員對象;
          (4) 如果當前對象的成員對象是一個集合,那么集合中的元素也都是朋友;
          (5) 當前對象所創建的對象。
          任何一個對象,如果滿足上面的條件之一,就是當前對象的“朋友”,否則就是“陌生人”。
          3、狹義法則和廣義法則:
          在狹義的迪米特法則中,如果兩個類之間不必彼此直接通信,那么這兩個類就不應當發生直接的相互作用,如果其中的一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。
          狹義的迪米特法則:可以降低類之間的耦合,但是會在系統中增加大量的小方法并散落在系統的各個角落,它可以使一個系統的局部設計簡化,因為每一個局部都不會和遠距離的對象有直接的關聯,但是也會造成系統的不同模塊之間的通信效率降低,使得系統的不同模塊之間不容易協調。
          廣義的迪米特法則:指對對象之間的信息流量、流向以及信息的影響的控制,主要是對信息隱藏的控制。信息的隱藏可以使各個子系統之間脫耦,從而允許它們獨立地被開發、優化、使用和修改,同時可以促進軟件的復用,由于每一個模塊都不依賴于其他模塊而存在,因此每一個模塊都可以獨立地在其他的地方使用。一個系統的規模越大,信息的隱藏就越重要,而信息隱藏的重要性也就越明顯。
          4、迪米特法則的主要用途:在于控制信息的過載。
          在類的劃分上,應當盡量創建松耦合的類,類之間的耦合度越低,就越有利于復用,一個處在松耦合中的類一旦被修改,不會對關聯的類造成太大波及;
          在類的結構設計上,每一個類都應當盡量降低其成員變量和成員函數的訪問權限;
          在類的設計上,只要有可能,一個類型應當設計成不變類;
          在對其他類的引用上,一個對象對其他對象的引用應當降到。

          5、例子

          外觀模式Facade(結構型)
          迪米特法則與設計模式Facade模式、Mediator模式
          系統中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因為在你的系統中,擴展的時候,你可能需要修改這些類,而類與類之間的關系,決定了修改的復雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如A類依賴B類,則B類依賴C類,當你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類. 如果此時C類再依賴D類的話,呵呵,我想這樣的修改有的受了。

          九、Q&A1、面向對象設計其他原則?

          封裝變化;
          少用繼承多用組合;
          針對接口編程、不針對實現編程;
          為交互對象之間的松耦合設計而努力;
          類應該對擴展開發、對修改封閉(開閉OCP原則);
          依賴抽象,不要依賴于具體類(依賴倒置DIP原則);
          密友原則:只和朋友交談(最少知識原則,迪米特法則);
          說明:一個對象應當對其他對象有盡可能少的了解,將方法調用保持在界限內,只調用屬于以下范圍的方法: 該對象本身(本地方法)對象的組件 被當作方法參數傳進來的對象 此方法創建或實例化的任何對象;
          別找我(調用我) 我會找你(調用你)(好萊塢原則);
          一個類只有一個引起它變化的原因(單一職責SRP原則);

          2、你能解釋一下里氏替換原則嗎?

          嚴格定義:如果對每一個類型為S的對象o1,都有類型為T的對象o2,使得以T定義的所有程序P在所有的對象用o1替換o2時,程序P的行為沒有變化,那么類型S是類型T的子類型。
          通俗表述:所有引用基類(父類)的地方必須能透明地使用其子類的對象。也就是說子類可以擴展父類的功能,但不能改變父類原有的功能。它包含以下4層含義:
          • 子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法。
          • 子類中可以增加自己特有的方法。
          • 當子類的方法重載父類的方法時,方法的前置條件(即方法的形參)要比父類方法的輸入參數更寬松。
          • 當子類的方法實現父類的抽象方法時,方法的后置條件(即方法的返回值)要比父類更嚴格。

          3、什么情況下會違反迪米特法則?為什么會有這個問題?

          迪米特法則建議“只和朋友說話,不要陌生人說話”,以此來減少類之間的耦合。

          4、給我一個符合開閉原則的設計模式的例子?

          開閉原則要求你的代碼對擴展開放,對修改關閉。這個意思就是說,如果你想增加一個新的功能,你可以很容易的在不改變已測試過的代碼的前提下增加新的代碼。有好幾個設計模式是基于開閉原則的,如策略模式,如果你需要一個新的策略,只需要實現接口,增加配置,不需要改變核心邏輯。一個正在工作的例子是 Collections.sort() 方法,這就是基于策略模式,遵循開閉原則的,你不需為新的對象修改 sort() 方法,你需要做的僅僅是實現你自己的 Comparator 接口。

          5、什么時候使用享元模式(蠅量模式)?

          享元模式通過共享對象來避免創建太多的對象。為了使用享元模式,你需要確保你的對象是不可變的,這樣你才能安全的共享。JDK 中 String 池、Integer 池以及 Long 池都是很好的使用了享元模式的例子。




          jQuery-瀑布流【CSS】CSS隱藏元素的五種方法

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          用css隱藏頁面元素有許多種方法。

          1. 1、opacity:0
          2. 2、visibility:hidden
          3. 3、diaplay:none
          4. 4、position:absolute

          opacity

               opacity屬性的意思是設置一個元素的透明度。它不是為改變元素的邊界框(bounding box)而設計的。這一位著將opacity設置為0只能從視覺上隱藏元素。而元素本身依然占據它自己的位置并對網頁的布局起作用,它也將響應用戶交互。


          visibility

               第二個要說的屬性是visibility。將它的值設為hidden將隱藏我們的元素。如同opacity屬性,被隱藏的元素依然會對我們的網頁布局起作用。與opacity唯一不同的是它不會響應任何用戶交互。此外元素在讀屏軟件中會被隱藏

              注意,如果一個元素的visibility被設置為hidden,同時想要顯示它的某個子孫元素,只要將那個元素的visibility顯式設置為visible即可。

              

          dispaly

              display屬性依照詞義真正隱藏元素。將display屬性設為none確保元素不可見并且連盒模型也不生成。使用這個屬性,被隱藏的元素不占據任何空間。不僅如此,一旦display設為none任何對該元素直接打用戶交互操作都不可能生效。此外,讀屏軟件也不會讀到元素的內容。這種方式產生的效果就像元素完全不存在。

              任何這個元素的子孫元素也會被同時隱藏。為這個屬性添加過度動畫是無效的,他的任何不同狀態值之間的切換總是會立即生效。

              不過請注意,通過DOM依然可以訪問到這個元素。因此你可以通過DOM來操作它。


          position

              假設有一個元素你想要與它交互,但是你又不想讓它影響你的網頁布局,沒有合適的屬性可以處理這種情況(opacity和visibility影響布局mdisplay不影響布局但又無法直接交互)。在這種情況下,只能考慮將元素移出可視區域。這個辦法既不會影響布局,有可能讓元素保持可以操作。

          1. .hide {
          2. position: absolute;
          3. top: -9999px;
          4. left: -9999px;
          5. }


          clip-path

              隱藏元素的另一種方法是通過剪裁它們實現。

          1. .hide {
          2. clip-path: polygon(0px 0px,0px 0px,0px 0px,0px 0px);
          3. }

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          CSS隱藏元素的五種方法

          seo達人

          如果您想訂閱本博客內容,每天自動發到您的郵箱中, 請點這里

          用css隱藏頁面元素有許多種方法。

          1. 1、opacity:0
          2. 2、visibility:hidden
          3. 3、diaplay:none
          4. 4、position:absolute

          opacity

               opacity屬性的意思是設置一個元素的透明度。它不是為改變元素的邊界框(bounding box)而設計的。這一位著將opacity設置為0只能從視覺上隱藏元素。而元素本身依然占據它自己的位置并對網頁的布局起作用,它也將響應用戶交互。


          visibility

               第二個要說的屬性是visibility。將它的值設為hidden將隱藏我們的元素。如同opacity屬性,被隱藏的元素依然會對我們的網頁布局起作用。與opacity唯一不同的是它不會響應任何用戶交互。此外元素在讀屏軟件中會被隱藏

              注意,如果一個元素的visibility被設置為hidden,同時想要顯示它的某個子孫元素,只要將那個元素的visibility顯式設置為visible即可。

              

          dispaly

              display屬性依照詞義真正隱藏元素。將display屬性設為none確保元素不可見并且連盒模型也不生成。使用這個屬性,被隱藏的元素不占據任何空間。不僅如此,一旦display設為none任何對該元素直接打用戶交互操作都不可能生效。此外,讀屏軟件也不會讀到元素的內容。這種方式產生的效果就像元素完全不存在。

              任何這個元素的子孫元素也會被同時隱藏。為這個屬性添加過度動畫是無效的,他的任何不同狀態值之間的切換總是會立即生效。

              不過請注意,通過DOM依然可以訪問到這個元素。因此你可以通過DOM來操作它。


          position

              假設有一個元素你想要與它交互,但是你又不想讓它影響你的網頁布局,沒有合適的屬性可以處理這種情況(opacity和visibility影響布局mdisplay不影響布局但又無法直接交互)。在這種情況下,只能考慮將元素移出可視區域。這個辦法既不會影響布局,有可能讓元素保持可以操作。

          1. .hide {
          2. position: absolute;
          3. top: -9999px;
          4. left: -9999px;
          5. }


          clip-path

              隱藏元素的另一種方法是通過剪裁它們實現。

          1. .hide {
          2. clip-path: polygon(0px 0px,0px 0px,0px 0px,0px 0px);
          3. }

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


          談談移動端布局

          周周

          移動端推廣速度快,效果好,越來越多的企業,商家開始重視移動站的建設和移動頁面(h5)的制作。隨著移動頁面的玩法越來越多,對前端技術的要求也會越來越高。

          選擇合適的布局,是寫好移動頁面的第一步。今天我們就來談談移動端的布局問題。
          為什么移動端布局如此混亂?這是由多方的原因造成的。
          1. css這套技術系統本身十分混亂,基本上可以說毫無規律可言,依賴于技術人員的熟練程度而不是邏輯更多一些;
          2.css歷經了多個時代的升級,每一次升級之后,新的技術標準和舊的基本上沒有任何關聯。比如:table布局,div+css布局,flex布局,grid布局等;
          3. 手機終端市場的混亂。當前市場上手機的尺寸五花八門;加上由iphone的retina技術帶來的dpr的混亂;

          關于移動設備一些基本概念的理解。



          一. 物理設備像素。
          思考:為什么手電筒只能發出一種顏色的光,而我們的屏幕能發出這么多種顏色的光?
          因為我們的屏幕是由無數個小的手電筒組成的,每個點可以發不同顏色的光,最后就組成了我們看到的彩色的效果。
          每張圖片都是由色點組成的,每個色點稱為一個像素。一張圖片由30萬個色點組成,這個圖片的像素就是30W。我們常說相機是多少像素,這個像素實際就是在說這款照相機的感器件有多少個,有100W個感光器件的相機就是100W像素的相機,有4000W個感光器件的相機就是4000W像素,以此類推。一臺100W像素的相機拍攝的照片洗成5寸的照片會比洗成6寸清晰一點。
          二. 屏幕分辨率
          屏幕分辨率是屏幕每行的像素點數*每列的像素點數,每個屏幕有自己的分辨率。屏幕分辨率越高,所呈現的色彩越多,清晰度越高。
          結論:
          1. 像素的單位本質上是:個數,100像素你可以理解成你有100個手電筒;
          2. 同樣大小(比如1cm*1cm大小的矩形),里面的像素越多,畫面越清晰;
          三.css像素
          在pc端1css像素相當于1物理設備像素。
          思考:
          我們的手機分辨率是640*1136(iphone 5和iphone 5s的物理設備分辨率),如果我們打開一個純粹pc端的網站會出現什么情況?
          (比如jumei.com,min-width是1090px,在pc端的我的電腦的設備寬度是1280,通過screen.width進行檢測)
          我們會發現網站會縮小到我們可以看到整個網站(www.jubi.com)
          則會發現,有滾動條了,因為禁止縮放了
          四. dpr
          1個css像素占多少物理設備像素
          思考:iphone 5或者iphone 5s一屏幕能看到的極限是多少寬度?
          應該是320(這是默認的可視區的css寬度) * 2 = 640px
          以上,我們學習完了所有關于移動端布局相關的概念,接下來,我們來聊一聊布局的思路。
          假如我們有640px的設計稿,我們如何才能讓用戶全部看到呢?
          思路一:百分比布局
          把尺寸除以2,比如我們量出來的是640px ---> 實際上我們只寫320px;
          如果是iphone 6怎么辦? iphone 6的寬度是375px;
          由于320和375的寬度其實差別不大,我們可以不定寬度,也就是把整體寬度設定為100%,然后其他的全部量出來是多少。
          布局方法
          - 拿到設計師給我們的設計稿之后(推薦640px),把所有量出來的尺寸除以2即可
          - 遇到等分就用百分比
          - 左浮動 + 右浮動(導航部分實現、折扣推薦導航部分) --> 適合于所有的元素寬度固定的
          - 左浮動 + padding擠(見超值折扣推薦內容部分) 本質上元素大小在任何尺寸下面都是一致,改變的其實是元素與元素之間的間距大小 --> 適合一個元素寬度固定,另一個寬度自適應;

          網站示例

          http://m.duba.com/

          http://m.lagou.com/

          百分比布局的缺點
          在大屏幕的手機下顯示效果會變成有些頁面元素寬度被拉的很長,但是高度還是和原來一樣,實際顯示非常的不協調,這就是流式布局的最致命的缺點,往往只有幾個尺寸的手機下看到的效果是令人滿意的,其實很多視覺設計師應該無法接受這種效果,因為他們的設計圖在大屏幕手機下看到的效果相當于是被橫向拉長來一樣。流式布局并不是最理想的實現方式,通過大量的百分比布局,會經常出現許多兼容性的問題,還有就是對設計有很多的限制,因為他們在設計之初就需要考慮流式布局對元素造成的影響,只能設計橫向拉伸的元素布局,設計的時候存在很多局限性。
          思路二:rem布局
          如何理解rem布局?
          思考一個問題,假如我們的設計稿是750px,我們量出來一個盒子的寬度是75px,那么在640px下面,它應該是多少合適呢? 答案是:64
          問題,如果才能保證你寫的css的尺寸只需要寫一次,在不同的屏幕尺寸下面不用改?
          假如我們在750px下面,我們讓html的font-size為75,則這個盒子的寬度是1rem,在640px下面我們讓html的font-size為64,則這個盒子的寬度也是1rem,問題就這樣解決了。
          那么實際開發中,該用什么樣等布局思路?
          我們打開m.jd.com,m.vip.com,會發現,實際上沒有一個網站用了純粹的百分比或者rem布局,經常會發現各種布局思路混在一起,因為沒有一套布局思路能夠通用保證不出問題
          為什么rem不是萬能的?
          比如1px,如果我們在dpr是2的情況下就會變得很粗,我們知道那并不是真正的1像素。
          推薦布局思路——使用由阿里出品的lib-flexible庫。

          網址:https://github.com/amfe/lib-flexible


          該如何使用呢?
          1. 引入布局用的flexible.js要注意的是不要再寫meta:viewport標簽了,因為flexible.js會自動幫你創建;
          2. 引入base.css;
          3. 把設計師的設計稿拿過來,標注稿基準字體大小 = 標注稿寬度 / 10,如標注稿寬為750,標注稿基準字體大小為75;標注稿寬為640,標注稿基準字體大小為64;
          4. 除了字體大小以外,其他所有的均按rem來,比如你的設計稿是750px的,那么,假如你量出來的是75px,則是1rem;
          字體除外,要根據不同的dpr設置不同的大小,比如如果是750的設計稿,那么字體假如是24px,則在dpr為1的情況下是16px,dpr2的情況下是24px,dpr3的情況下是32px(這塊涉及到字體專業知識,總結一句話就是沒有人會考慮用奇數字體,https://www.zhihu.com/question/20440679,所以不能讓工具幫我們自動算,得寫死。
          以上是我個人關于移動端布局的一些總結。如有不妥的地方,還請指正。
          最后附上關于移動端常見問題當網址:



          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合