標籤: 網頁設計

  • 7.99萬起,今天上市的大空間6座車真是家用好選擇!

    7.99萬起,今天上市的大空間6座車真是家用好選擇!

    尾部在擾流板、貫穿尾燈的鍍鉻裝飾、黑色塑料擋板的組合下,形成了一種層次感。敦厚的車尾部,更是讓它充滿安全感。仿木材料的中控台,還有一個大尺寸豎直中控屏幕,以及是手感極佳的平底式運動方向盤,它在簡約風格中加入一點運動的元素。

    “一輛車究竟是多少座位最好?”,除了自己,還有配偶,加上父母以及自己的孩子,或許還是雙胞胎,這樣看來起碼是6座車型,另外一般而言緊湊型轎車後排乘坐3成年人是比較難受的事情。

    正是為了滿足用戶這種需求,比亞迪宋MAX前期推出了7座車型,如今更是推出了6座車型,官方指導價為:7.99-12.99萬。那麼它表現如何呢?

    6座,就是它最大的不同

    6座版本的比亞迪宋max依然有着4680*1810*1680mm的車身尺寸,以及是能夠帶來充足空間表現的2785mm軸距。並且在座椅配置上一樣保留了7座車型的優點,諸如第三排寬大保護作用大的頭枕、座椅採用打孔真皮材質。

    它採用了2+2+2的6座布局,獨立第二排座椅可以帶來比7座車型更舒適的體驗,加上獨立的可調節座椅扶手,座椅包裹性更佳。中部通道寬度為190mm,乘客進出第三排更為優雅。

    在實際的乘坐它表現讓人滿意,前排以及第二排座椅包裹性極佳,並且頂配車型上前排座椅還具備主副駕座椅通風加熱、第二排預警限力安全帶等配置。唯獨是第三排由於車身結構問題坐墊與地板距離較近,腿部支撐較弱,中長途旅行中更適合乘坐小孩子或者是身材嬌小的成年人。

    設計以及配置,和7座車型無異

    6座版本的宋MAX在設計上和7座車型保持了一致,犀利大燈帶有的鍍鉻裝飾條以及LED日間行車燈和大尺寸進氣格柵橫向裝飾條連成一體,拉寬了視覺寬度。這個“大嘴”配上這兇狠犀利的大燈,就形成了它’Dragon Face”設計的基本元素。

    4680mm車身長度的它在逐漸下滑的懸浮式車頂襯托下,顯得車身相當修長,低矮的腰線則降低了它的視覺重心,讓它整體有着一種動感、衝勁。

    尾部在擾流板、貫穿尾燈的鍍鉻裝飾、黑色塑料擋板的組合下,形成了一種層次感。敦厚的車尾部,更是讓它充滿安全感。

    仿木材料的中控台,還有一個大尺寸豎直中控屏幕,以及是手感極佳的平底式運動方向盤,它在簡約風格中加入一點運動的元素。

    生產實力強大、自產自銷的比亞迪能夠有效控製成本,所以它在配置配備上相當慷慨,標配了ESp車身穩定系統、17英寸鋁合金輪轂、自動空調、遠程啟動等等。又或者是一些“跨級般”的配置,諸如選配的LED自動大燈。

    操控,或許可以說沉穩自信?

    比亞迪宋MAX全系車型採用前麥弗遜后扭力梁懸架,處於這個級別的主流水平。動力方面搭載了最大輸出功率154馬力的1.5T直噴發動機,匹配的是6MT或者6速雙離合變速箱。

    在日常使用中它整體表現出同價位中較高的水準,應付城市使用這套渦輪增壓+雙離合的動力總成顯得游刃有餘,能夠有效地控制轉速在1500rpm之中,需要提速的時候154馬力的底蘊讓超車動作比較從容,而且它1750rpm就開始進入240牛米的最大輸出扭矩區間,相比競爭對手們最大扭矩輸出更早。只是低速在1、2擋切換時會有絕大多數雙離合變速箱的小不足——輕微頓挫感。

    據比亞迪官方稱,比亞迪宋max有着前奔馳底盤調校工程師漢斯柯克參与調校,讓它更注重舒適性,所以宋max駕駛起來有着厚重的行駛質感。能夠過濾掉路面各種細碎振動的同時,還有讓人安心的高速穩定性。受制於全系搭配的液壓轉向助力,宋max轉向略有虛位,並不可以說是精準,幸好較強的懸架支撐帶來了較小的車身傾側,扳回了一城。

    總的來說,比亞迪宋max相比同價位對手有着不少的優勢,諸如更佳的底盤表現、更豐富的配置以及更出色的外觀,這恰恰迎合如今消費者開始接受這些“體面”MpV的用戶趨勢。6座車型,則是滿足了消費者不同的乘坐需求,多一種選擇未嘗不是一種好事。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※教你寫出一流的銷售文案?

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※回頭車貨運收費標準

    ※別再煩惱如何寫文案,掌握八大原則!

    ※超省錢租車方案

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 架構思考-業務快速增長時的容量問題

    架構思考-業務快速增長時的容量問題

    背景

    之前做過一個項目,數據庫存儲採用的是mysql。當時面臨着業務指數級的增長,存儲容量不足。當時採用的措施是

     

    1>短期解決容量的問題

    mysql從5.6升級5.7,因為數據核心且重要,數據庫主從同步採用的是全同步, 利用5.7并行複製新特性,減少了主從同步的延遲,提高了吞吐量。

     

    當時業務量高峰是2000TPS,5.6時可承受的最大TPS是3000,升級到5.7壓測可承受的最大TPD是5000.

     

    2>流量拆分,從根本上解決容量問題

    首先進行容量評估,通過對於業務開展規劃、活動預估,年底的容量會翻5倍。由於目前指數級增長的特性,數據庫要預留至少4倍的冗餘。

     

    要對數據庫進行擴容,因為我們已經使用的是最頂配的SSD物理機了,就算可以在linux內核層面對numa進行綁核和非綁核等測試調參優化性能,提升容量也很有限。注意:一般的業務系統numa綁核會提高性能,但是mysql等數據庫系統是相反的。

     

    所以垂直擴容不成功,就看看是否可以拆分流量。mysql流量拆分方式有x軸拆分(水平拆分)、y軸拆分(垂直拆分)、z軸拆分。

     

    其中y軸拆分(垂直拆分)就是目前都在說做垂直領域,就是在一個細分領域里做深入的意思。由此可以很容易的記住垂直拆分的意思就是按照業務領域進行拆分,專庫專用。實際上能按領域拆分是最理想的,因為這種拆分業務清晰;拆分規則明確;系統之間整合或擴展容易。但是因為當時的業務已經很簡單,y軸拆分已經沒有什麼空間,這種拆分不能達到擴容20倍的目的。

     

    z軸拆分近幾年沒有聽說過了,實際上大家也一直在用。這種方式是將一張大表拆分為子母表,就是分為概要信息和詳細信息。這種拆分方式對解決容量問題意義不大。

     

    比較可行的一個方案是水平拆分。就是常說的分庫分表。按照容量評估,數據庫水平拆分一拆十,根據業務特點找一個標準字段來進行取模。

     

    水平拆分一個技術點在於新老切換。

    採用的是數據庫雙寫的方式,採用異步確保性的補償型事務,發送實時和延遲兩個MQ,通過開關來控制以老數據為準還是新數據庫為準。開始時以老數據庫為準,觀察新老數據沒有一致性問題之後,在一個低峰期,關閉了系統入口,等數據庫沒有任何變更之後切換開關,再打開系統入口。

     

    問題

    對於容量問題,上面採用的是一次性拆分到位的方法。對於一個規模稍大的公司來講,10組物理機(1組包含1主N從)的成本還好。

    1>如果量級再次升級,需要每周增加10台數據庫才能支撐容量呢?

    2>並且對系統可用性還有強要求,1s的停機都不可以接受呢?

     

    解決方案分析

    垂直流量拆分

    首先我要分析的是每周增加10台數據庫這個容量是不是合理的。是否存在放大效應或者說可以減少對mysql這種昂貴資源的使用,轉為增加對HBase、Elasticsearch這種低成本高擴展性資源的使用呢?

     

    基於這個思路,我們需要梳理下是否有可垂直拆分的流量。比如正向流量和負向流量。所謂正向流量是指比如交易下單,負向流量就是取消訂單,包括已付款取消、未付款取消、已到貨取消、未到貨取消等等。實際上負向流量在總訂單里佔比很少,但是業務要比正向交易業務複雜。將正向和逆向拆分的一個主要優勢是分治思想,可以降低兩部分各自的複雜度。將流量拆分重心轉移到正向流量上。

     

    對於正向流量,一個業務比較常用的流量拆分思路是CQRS命令查詢分離,也就是常說的讀寫分離。如果讀流量大於寫流量。可以考慮能否將讀流量進一步拆分。拆分成實時和離線,將實時性要求不高的查詢走ES。ES的數據可以通過同步binlog變更獲得。

     

    另外一個思路是將數據庫按照歷史數據來拆分。就是數據庫里只保存一定時間內的實時數據。超過指定時間則進行數據歸檔。將數據歸檔到HBase等,一般對於歷史的查詢實時性要求也不是很高。

     

    垂直流量拆分可能遇到的問題

    以上方法都是只考慮問題1如果量級再次升級,需要每周增加10台數據庫才能支撐容量的方案。如果再考慮問題2並且對系統可用性還有強要求,1s的停機都不可以接受。就需要看上述方案可能會遇到的問題。

     

    拆分正向流量和負向流量、CQRS都需要改造,改造過程就需要過渡。過渡可以採用上面說的雙寫方式,觀察運行情況進行切換。切換過程中也可以不關閉流量。

     

    麻煩的是數據歸檔。因為數據歸檔后刪除數據庫的數據,變更生效時,針對innodb來說,意味着數據結構重建,頻繁IO。這會影響OLTP在線事務的處理。可以考慮按表來歸檔,控制操作頻率,控制單位時間內對IO的影響。

     

    分佈式關係型數據庫

    分佈式關係型數據庫本質上是通過增加代理等方式將分庫分表做的更加隱蔽。

     

    阿里巴巴分佈式關係數據庫(DRDS),前身是淘寶分佈式數據層(TDDL),核心就是用於分庫分表管理的代理層,宣稱可實現平滑擴容。

     

     

    擴容過程實際是物理數據遷移的過程,引擎層按照分庫遷移后的邏輯先在物理節點上建立新的分庫,然後保留一個時間點進行全量的數據遷移。完成全量遷移后,開始基於先前保留的時間點進行增量的數據追趕。當增量數據追趕到兩邊的數據幾乎一致時,對數據庫進行瞬時停寫,將最後的數據追平,引擎層進行分庫邏輯的路由切換,路由規則切換完成后就完成了核心的擴容邏輯,整個切換過程在毫秒級別完成。

     

    因為整個過程是毫秒級,所以可以做到業務層沒有感知,等多就是看到擴容過程中請求延時增加了不到1s。從原理上來說是可行的。

     

    NOSQL解決方案

    像這麼大的數據量一個很好的參考是12306。12306採用的是Geode。它是有數據庫功能的內存數據網格(In-Memory Data Grid,IMDG)。其重要特性是

     

    1)集群內存總容量,現在Geode可以實現單個節點200-300GB內存,總集群包含300個節點的大型集群,因此總容量可以達到90TB左右的級別。

     

    2)Geode集群功能非常強大,實現了內存中數據Shard分佈,自動管理,集群故障自動恢復,自動平均分佈等一系列企業級的功能,而且有自帶的集群間數據同步功能。

     

    3)在CAP原理下(不了解的話可以百度一下CAP不可能三角),Geode可以保證集群內數據的強一致性,注意是真正的強一致性而不是最終一致性,再加上分區可用性,因此是一個CP型的產品,可以提供統一的數據視圖,支持高併發下的acid事務。

     

    採用新的解決方案最大問題是平滑過渡,平滑過渡方面我還是覺得上面提到的數據庫雙寫方式安全可靠。

     

    系統共建的解決方案

    如果達到我所說的量級,基本上在一個行業中是處於垄斷地位的。並不是一家純的互聯網公司。這種公司可以採用和互聯網大廠合作的方式、用已經有這方面經驗的大廠,來根據自己內部系統的特性共建一套合適自己的定製化數據庫。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※推薦評價好的iphone維修中心

  • UniRx精講(二):獨立的 Update &UniRx 的基本語法格式

    UniRx精講(二):獨立的 Update &UniRx 的基本語法格式

    獨立的 Update

    在 UniRx 簡介的時候,筆者講了一種比較麻煩的情況:就是在 MonoBehaviour 的 Update 中摻雜了大量互相無關的邏輯,導致代碼非常不容易閱讀。

    這種情況我們平時在項目開發中非常常見,代碼如下:

    private void Update()
    {
    	if (A)
    	{
    		...
    	}
    
    	if (B)
    	{
    		...
    		if (D)
    		{
    			...
    		}
    		else {}
    	}
    
    	switch (C)
    	{
    		...
    	}
    
    	if (Input.GetMouseButtonUp(0))
    	{
    		...
    	}
    }
    

    Update 方法中代碼冗長,而且干擾視線,非常影響閱讀。

    而使用 UniRx 則可以改善這個問題。

    void Start()
    {
    	// A 邏輯,實現了 xx
    	Observable.EveryUpdate()
    			.Subscribe(_ => 
    			{
    				if (A)
    				{
    					...
    				}
    			}).AddTo(this);
    	
    
    	// B 邏輯,實現了 xx
    	Observable.EveryUpdate()
    			.Subscribe(_ =>
    			{
    				if (B)
    				{
    					...
    					if (D)
    					{
    						...
    					}
    				else {}
    				}
    			}).AddTo(this);
    
    	// C 邏輯,實現了 xx
    	Observable.EveryUpdate()
    			.Subscribe(_ =>
    			{
    				switch (C)
    				{
    					...
    				}
    			}).AddTo(this);
    
    	// 鼠標點擊檢測邏輯
    	Observable.EveryUpdate()
    			.Subscribe(_ => {
    			{
    				if (Input.GetMouseButtonUp(0))
    				{
    					...
    				}
    			}).AddTo(this);
    }
    

    雖然在代碼長度上沒有任何改善,但是最起碼,這些 Update 邏輯互相之間獨立了。
    狀態跳轉、延時等等這些經常在 Update 里實現的邏輯,都可以使用以上這種方式獨立。

    使用 UniRx 可以對我們工程中的代碼進行了改善,而筆者接觸 UniRx 之後,就再也沒有使用過 Update 方法了。

    不過以上的這種 UniRx 使用方式,是比較初級的,而這種使用方式,隨着對 UniRx 的深入學習,也會漸漸淘汰,因為等我們入門之後,會學習更好的實現方式。

    今天的內容就這些。

    知識地圖

    UniRx 的基本語法格式

    在之前的兩篇文章中,我們學習了 UniRx 的 Timer 和 Update 這兩個 API,但是對代碼的工作原理還沒有進行過介紹。在這篇文章中,我們就來試着理解一下 UniRx 的代碼工作原理及 UniRx 的基本語法格式。

    先搬出來第一篇文章中 Delay 的實現代碼:

    /****************************************************************************
     * http://liangxiegame.com liangxie
     ****************************************************************************/
     
    using System;
    using UniRx;
    using UnityEngine;
    
    namespace UniRxLesson
    {
    	public class DelayExample : MonoBehaviour
    	{
    		private void Start()
    		{
    			Observable.Timer(TimeSpan.FromSeconds(2.0f)).Subscribe(_ =>
    			{
    				Debug.Log("延時兩秒"); 
    				
    			}).AddTo(this);
    		}
    	}
    }
    

    代碼中的 Observable.XXX().Subscribe() 是非常經典的 UniRx 格式。只要理解了這種格式就可以看懂大部分的 UniRx 的用法了。

    首先解決代碼中的詞彙問題:

    • Observable:可觀察的,是形容詞,它形容後邊的詞(Timer)是可觀察的,我們可以直接把 Observable 後邊的詞理解成發布者。
    • Timer:定時器,名詞,被 Observable 修飾,所以是發布者,是事件的發送方。
    • Subscribe:訂閱,是動詞,它訂閱誰呢?當然是前邊的 Timer,這裏可以理解成訂閱者,也就是事件的接收方。
    • AddTo:添加到,這個我們暫時不用理解得太深刻,只需要知道它是與 MonoBehaviour 進行生命周期綁定即可。

    以上的代碼,連起來則是:可被觀察(監聽)的.Timer().訂閱()
    理順了之後應該是:訂閱可被觀察的定時器。

    其概念關係很容易理解。

    • Timer 是可觀察的。
    • 可觀察的才能被訂閱。
    Observable.XXX().Subscribe();
    

    這行代碼我們可以理解為:可被觀察(監聽)的 XX,註冊。

    以上筆者從發布者和訂閱者這個角度進行了簡單的介紹,以便大家理解。
    但是 UniRx 的側重點,不是發布者和訂閱者這兩個概念如何使用,而是事件從發布者到訂閱者之間的過程如何處理。
    所以這兩個點不重要,重要的是兩點之間的線,也就是事件的傳遞過程。

    這裏先不說得太深入,在入門之後,會用很大的篇幅去深入介紹這些概念的。

    今天的 UniRx 的基本語法格式的介紹就到這裏,我們下一篇再見,拜拜~

    知識地圖

    更多內容
    QFramework 地址:https://github.com/liangxiegame/QFramework
    QQ 交流群:623597263
    涼鞋的主頁:https://liangxiegame.com/zhuanlan
    關注公眾號:liangxiegame 獲取第一時間更新通知及更多的免費內容。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

  • 【溫故知新】 編程原則和方法論

    寫了這麼多年代碼,依舊做不好一個項目

    做好一個項目是人力、產品、業務、技術、運營的結合,可能還疊加一點時機的因素,就我們碼農而言,工作就是搬磚,實現產品, 給業務提供支撐。
    “給祖傳代碼加 BUG 修 BUG”,“拿起鍵盤一把梭”這些戲謔程序員的話,聽多了真的會讓程序員麻木,彷彿大家都是這麼乾的。
    從業多年,堆過 shi 山,接手過祖傳代碼, 已經不能沉下氣去查看、調試 shi 山代碼, 說實話,很累。
    本人一直推崇寫流暢、自然、可自解釋的代碼,讓優雅成為一種習慣, 給自己留個念想、給後人留個好評。

    溫故而知新,聊一聊現代編程幾大常見的編程原則

    普世原則
    KISS (Keep It Simple Stupid) 保持系統結構簡單可信賴
    YAGNI (you aren’t gonna need it) 當前確實需要,再去做
    Do The Simplest Things That Could Possibly Work 思考最簡單可行的辦法
    Separation of Concerns 關注點分離
    Keep Things DRY 保持代碼結構清爽 Don’t repeat yourself
    Code For The Maintainer 站在維護者角度寫代碼
    Avoid Premature Optimization 避免提前優化
    Boy-Scout Rule 清掃戰場:清理口水話註釋、無效代碼
    模塊(類)間
    Minimise Coupling 低耦合
    Law of Demeter Don’t talk to strangers,對象方法只接觸該接觸的對象、字段、入參
    Composition Over Inheritance 組合而不是繼承
    Orthogonality 正相關,概念上不相關的事物不應在系統中強行相關
    Robustness Principle 代碼健壯性
    Inversion of Control 控制反轉
    模塊(類)
    Maximise Cohesion 高內聚
    Likov Substitution Principle 里斯替代原則:將程序中對象替換到子類型實例,不會報錯。
    Open/Closed Principle 設計的實體對擴展開放,對修改關閉
    Single Responsiblity Principle 單一責任原則
    Hide Implementation Details 隱藏實施細節
    Curly’s Law 柯里定律:為確定目標編寫特定代碼
    Encapsulate What Changes 封裝變化
    Interface Segregation Principle 接口隔離原則
    Command Query Separation 命令查詢分離

    KISS
    大多數系統保持簡單,會運行的很好。

    • 更少的代碼消耗更好的時間,產生更少的 bug,並且容易修改
    • 複雜業務都是由簡單代碼堆砌而成
    • 完美並不是“沒有什麼東西可以再加”,而是“沒有什麼東西可以被去掉”

    YAGNI
    YAGNI 代表“you aren’t gonna need it.”,不要自以為是的提前實現某些邊角,直到真正需要的時候,再來做。

    • 提前做明天才需要做的工作,意味着當前迭代中需要花費更多精力
    • 導致代碼膨脹,軟件變得臃腫且複雜

    Separation of Concerns
    關注點分離是一種將計算機程序分為不同部分的設計原則,這樣每個部分都可以解決一個單獨的關注點。例如應用程序的業務邏輯是一個問題,而用戶界面是另外一個問題,更改用戶界面不應要求更改業務邏輯,反之亦然。

    • 簡化應用程序的開發和維護
    • 如果關注點分離得很好,則各個部分可以重複使用,也可以獨立開發和更新。

    Interface Segregation Principle
    接口隔離,將胖接口修改為多個小接口,調用接口的代碼應該比實現接口的代碼更依賴於接口。
    why:
    如果一個類實現了胖接口的所有方法(部分方法在某次調用時並不需要),那麼在該次調用時我們就會發現此時出現了(部分並不需要的方法),而並沒有機制告訴我們我們現在不應該使用這部分方法。
    how: 避免胖接口,類永遠不必實現違反單一職責原則的接口。可以根據實際多職責劃分為多接口,類實現多接口后, 在調用時以特定接口指代對象,這樣這個對象只能體現特定接口的方法,以此體現接口隔離。

       public interface IA
        {
            void getA();
        }
    
        interface IB
        {
            void getB();
        }
    
        public class Test : IA, IB
        {
            public string Field { get; set; }
            public void getA()
            {
                throw new NotImplementedException();
            }
    
            public void getB()
            {
                throw new NotImplementedException();
            }
        }
        class Program
        {
            static void Main(string[] args)
            {
                Console.WriteLine("Hello World!");
    
                IA a = new Test();
                a.getA();       //  在這個調用處只能看到接口IA的方法, 接口隔離
            }
        }
    

    Command Query Separation
    命令查詢分離: 操作方法就只寫操作邏輯,查詢方法就只寫查詢邏輯,並以明顯的方法名區分自己的動作。
    有了這個原則,程序員可以更加自信地進行編碼:由於查詢方法不會改變狀態,因此可以在任何地方以任何順序使用,使用操作方法時,也心中有數。

    End

    懂得這麼多道理,卻依舊過不好這一生。前人總結的編程原則和方法論需要在實踐中感悟,束之高閣,則始終不能體會編程的魅力和快感

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計最專業,超強功能平台可客製化

  • Spring系列.AOP使用

    AOP簡介

    利用面向對象的方法可以很好的組織代碼,也可以繼承的方式實現代碼重用。但是項目中總是會出現一些重複的代碼,並且不太方便使用繼承的方式把他們重用管理起來,比如說通用日誌打印,事務處理和安全檢查等。我們可以將這些代碼封裝起來,做成通用模塊,但是還是需要在代碼中每處需要的地方進行显示調用,使用起來不方便。這是時候就是利用AOP的時候。

    AOP是一種編程範式,用來解決特定的問題,不能解決所有問題,可以看做是OOP的補充,常見的編程範式還有:

    • 面向過程編程;
    • 面向對象編程;
    • 面向函數編程(函數式編程);
    • 事件驅動編程(GUI開發中比較常見);
    • 面向切面編程

    AOP的常見使用場景

    • 性能監控,在方法調用前後記錄調用時間,方法執行太長或超時報警;
    • 緩存代理,緩存某方法的返回值,下次執行該方法時,直接從緩存里獲取;
    • 軟件破解,使用AOP修改軟件的驗證類的判斷邏輯;
    • 記錄日誌,在方法執行前後記錄系統日誌;
    • 工作流系統,工作流系統需要將業務代碼和流程引擎代碼混合在一起執行,那麼我們可以使用AOP將其分離,並動態掛接業務;
    • 權限驗證,方法執行前驗證是否有權限執行當前方法,沒有則拋出沒有權限執行異常,由業務代碼捕捉;
    • 事務處理 。

    Spring AOP相關概念

    • AOP:這種在運行時(或者編譯時或者加載時),動態地將某些公共代碼切入到類的指定方法、指定位置上的編程思想就是面向切面的編程;
    • 切面(Aspect):A modularization of a concern that cuts across multiple classes。在Spring中切面就是一個標註@AspectJ的類,不要想得太複雜;
    • 連接點(Joinpoint):方法執行過程中的某個點,是在應用執行過程中能夠插入切面的一個點。這個點可以是調用方法時、拋出異常時、甚至修改一個字段時。切面代碼可以利用這些點插入到應用的正常流程之中,並添加新的行為;
    • 通知(advice):描述切面要完成什麼工作,以及在什麼時間點進行工作;
    • Pointcut:用來匹配一組連接點,並且pointcut會關聯advice,在pointcut匹配的連接點執行的時候,advice代碼會被執行;
    • Introduction
    • Target object:被織入切面的對象;
    • AOP proxy : 包裝了切面代碼和target代碼的對象,Spring中支持JDK動態代理和
      CGLIB,默認使用JDK動態代理,但是如果被代理的類沒有實現接口,或者用戶強制使用CGLIB,那麼Spring會使用CGLIB代理;
    • Weaving:將切面代碼添加到目標代碼的過程,織入的類型有編譯時織入,加載時織入和運行時織入(Spring是運行時織入)

    SpringAOP可以應用5種類型的通知:

    • 前置通知(Before):在目標方法被調用之前調用通知功能。
    • 後置通知(After):在目標方法完成之後調用通知,此時不會關心方法的輸出是什麼。(不管執行是否成功都執行都執行)
    • 返回通知(After-returning):在目標方法成功執行之後調用通知。
    • 異常通知(After-throwing):在目標方法拋出異常后調用通知。
    • 環繞通知(Around):通知包裹了被通知的方法,在被通知的方法調用之前和調用之後執行自定義的行為。

    Spring AOP相關

    開啟Aop

    
    //自動選擇合適的AOP代理
    //傳統xml這樣配置:<aop:aspectj-autoproxy/>
    
    //exposeProxy = true屬性設置成true,意思是將動態生成的代理類expose到AopContext的ThreadLocal線程
    //可以通過AopContext.currentProxy();獲取到生成的動態代理類。
    
    //proxyTargetClass屬性設置動態代理使用JDK動態代理還是使用CGlib代理,設置成true是使用CGlib代理,false的話是使用JDK動態代理
    
    //注意:如果使用Spring Boot的話,下面的配置可以不需要。AopAutoConfiguration這個自動配置類中已經自動開啟了AOP
    //默認使用CGLIB動態代理,Spring Boot配置的優先級高於下面的配置
    
    @Configuration
    @EnableAspectJAutoProxy(exposeProxy = true,proxyTargetClass = false)
    public class AopConfig {
    
    }
    
    
    

    如果使用傳統的配置方式的話,可按如下配置開啟AOP功能。

    <aop:aspectj-autoproxy/>
    

    定義一個Aspect

    Aspects (classes annotated with @Aspect) can have methods and fields, the same as any other class. They can also contain pointcut, advice, and introduction (inter-type) declarations.

    可以使用普通Bean的定義方式,或者加@Aspect註解的方式定義。一旦一個類被標註成切面類,它就不會成為其他切面的代理對象。

    定義一個PointCut

    切面表達式可以由指示器,通配符和運算符組成

    1. 指示器(Designators)
    • 匹配方法 execution() (重點掌握…)
    • 匹配註解 @target() @args() @within() @annotation()
    • 匹配包/類型 within()
    • 匹配對象 this() bean() target()
    • 匹配參數 args()
    1. Wildcards(通配符)
    • *匹配任意數量的字符
    • +匹配指定類及其子類
    • .. 一般用於匹配任意參數的子包或參數
    1. Operators(運算符)
    • && 與操作符
    • || 或操作符
    • ! 非操作符

    下面給出一個定義PointCut的例子

    package com.csx.demo.spring.boot.aspect;
    
    import org.aspectj.lang.ProceedingJoinPoint;
    import org.aspectj.lang.annotation.*;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.stereotype.Component;
    
    @Component
    @Aspect
    public class MyAspect {
    
        //PointCut匹配的方法必須是Spring中bean的方法
        //Pointcut可以有下列方式來定義或者通過&& || 和!的方式進行組合.
        //下面定義的這些切入點就可以通過&& ||組合
    
        private static Logger logger = LoggerFactory.getLogger(MyAspect.class);
    
        //*:代表方法的返回值可以是任何類型
        //整個表達式匹配controller包下面任何的的echo方法,方法入參樂意是任意
        @Pointcut("execution(* com.csx.demo.spring.boot.controller.*.echo(..))")
        public void pointCut1(){}
    
        //代表echo方法必須有一個參數 參數的類型可以是任意類型
        @Pointcut("execution(* com.csx.demo.spring.boot.controller.*.echo(*))")
        public  void pointCut2(){}
    
        //代表echo方法必須有兩個參數,第一個類型任意,第二個類型必須是String
        @Pointcut("execution(* com.csx.demo.spring.boot.controller.*.echo(*,String))")
        public void pointCut3(){}
    
        //contrller包及其子包下面的任意類的任意方法
        //需要注意的是with和@with都是正對包級別的
        @Pointcut("within(com.csx.demo.spring.boot.controller..*)")
        public void pointCut4(){}
    
        //使用RestController這個註解標註任意類的任意方法
        @Pointcut("@within(org.springframework.web.bind.annotation.RestController)")
        public void pointCut5(){}
    
        //用法和@Within類似
        @Pointcut("@target(org.springframework.web.bind.annotation.RestController)")
        public void pointCut10(){}
    
        //MyService這個接口實現類的任何方法
        //如果MyService是一個類的話,那匹配這個類內部的所有方法
        @Pointcut("this(com.csx.demo.spring.boot.service.MyService)")
        public void pointCut6(){}
    
        @Pointcut("this(com.csx.demo.spring.boot.service.MyServiceImpl)")
        public void pointCut7(){}
    
        //某個bean內部的所有方法
        @Pointcut("bean(myServiceImpl)")
        public void pointCut8(){}
    
        //@within和@target針對類的註解,@annotation是針對方法的註解
        //匹配任何標註GetMaping註解的方法
        @Pointcut("@annotation(org.springframework.web.bind.annotation.GetMapping)")
        public void pointCut9(){}
    
        //匹配只有一個參數,參數類型是String的方法
        @Pointcut("args(String)")
        public void pointCut11(){}
    
    
        @Before("pointCut1()")
        public void befor(){
            logger.info("前置通知vvvv...");
            logger.info("我要做些事情...");
        }
    
        @After("pointCut1()")
        public void after(){
            logger.info("後置通知");
        }
    
        @AfterReturning("pointCut1()")
        public void afterReturn(){
           logger.info("後置返回");
        }
    
         //目標方法拋出相關異常后通知
        @AfterThrowing("pointCut1()")
        public void afterThrowing(){
            logger.info("後置異常");
        }
    
        @Around("pointCut1()")
        public void around(ProceedingJoinPoint point) throws Throwable {
            logger.info("環繞通知...");
            logger.info("我要做些事情...");
            point.proceed();
            logger.info("結束環繞通知");
        }
    
    }
    

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    南投搬家公司費用需注意的眉眉角角,別等搬了再說!

    ※教你寫出一流的銷售文案?

  • LeetCode 77,組合挑戰,你能想出不用遞歸的解法嗎?

    LeetCode 77,組合挑戰,你能想出不用遞歸的解法嗎?

    本文始發於個人公眾號:TechFlow,原創不易,求個關注

    今天是LeetCode第46篇文章,我們一起來LeetCode中的77題,Combinations(組合)。

    這個題目可以說是很精闢了,僅僅用一個單詞的標題就說清楚了大半題意了。這題官方難度是Medium,它在LeetCode當中評價很高,1364人點贊,只有66個反對。通過率53.6%。

    題意

    題目的題意很簡單,給定兩個整數n和k。n表示從1到n的n個自然數,要求隨機從這n個數中抽取k個的所有組合

    樣例

    Input: n = 4, k = 2
    Output:
    [
      [2,4],
      [3,4],
      [2,3],
      [1,2],
      [1,3],
      [1,4],
    ]
    

    全排列的問題我們已經很熟悉了,那麼獲取組合的問題怎麼做呢?

    遞歸

    這是一個全組合問題,實際上我們之前做過全排列問題。我們來分析一下排列和組合的區別,可能很多人知道這兩者的區別,但是對於區別本身的理解和認識不是非常深刻。

    排列和組合有一個巨大的區別在於,排列會考慮物體擺放的順序。也就是說同樣的元素構成,只要這些元素一些交換順序,那麼就會被視為是不同的排列。然而對於組合來說,是不會考慮物體的擺放順序的。只要是這些元素構成,無論它們怎麼調換擺放順序,都是同一種組合。

    我們獲取全排列的時候用的是回溯法,我們當然也可以用回溯法來獲取組合。但問題是,我們怎麼保證獲取到的組合都是元素的組成不同,而不是元素之間的順序不同呢?

    為了保證這一點,需要用到一個慣用的小套路,就是通過下標遞增來控制拿取元素的順序。如果我們限定了拿取元素的下標是遞增的,那麼就可以保證每一次拿取到的組合都是獨一無二的。所以我們就把這一點加在回溯法上即可,只要理解了,並不難實現。

    在代碼的實現當中,我們用上了閉包,省略了幾個參數的傳遞,整體上來說編碼的難度降低了一些。

    class Solution:
        def combine(self, n: int, k: int) -> List[List[int]]:
            def dfs(start, cur):
                # 如果當前已經拿到了K個數的組合,直接加入答案
                # 注意要做深拷貝,否則在之後的回溯過程當中變動也會影響結果
                if len(cur) == k:
                    ret.append(cur[:])
                    return
                
                # 從start+1的位置開始遍歷
                for i in range(start+1, n):
                    cur.append(i+1)
                    dfs(i, cur)
                    # 回溯
                    cur.pop()
                    
            ret = []
            dfs(-1, [])
            return ret
    

    迭代

    這題並不是只有一種做法,我們也可以不用遞歸實現算法。不用遞歸意味着沒有系統幫助我們建棧存儲中間信息了,需要我們自己把迭代過程當中所有變量的關係整理清楚。

    我們假設n=8,k=3,那麼在所有合法的組合當中,最小的組合一定是[1,2,3],最大的組合一定是[6,7,8]。如果我們保證組合當中的元素是有序排列的,那麼組合之間的大小關係也是可以確定的。進而我們可以思考設計一種方案,使得我們可以從最小的組合[1,2,3]一直迭代到[6,7,8],並且我們還要保證在迭代的過程當中,組合當中元素的順序不會被打亂。

    我們可以想象成這n個數在一根“直尺”上排成了一行,我們有k個滑動框在上面移動。這k個滑動框取值的結果就是n個元素中選取k個的組合,並且由於滑動框之間是不能交錯的,所以保證了這k個值是有序的。我們要做的就是設計一種移動滑動框的算法,使得能夠找到所有的組合情況。

    我們可以想象一下,一開始的時候滑動框都聚集在最左邊,我們要移動只能移動最右側的滑動框。我們把滑動框從k移動到了k+1,那麼這個時候它的右側有k-1個滑動框,一共有k個位置。

    那麼這個問題其實轉化成了k個元素當中取k-1個組合的子問題。我們把1-k的這個部分看成是新的“直尺”,我們要在其中移動k-1個滑動框獲取所有的組合。首先,我們需要把這k-1個滑動框全部移動到左側,然後再移動其中最右側的滑動框。然後循環往複,直到所有的滑動框都往右移動了一格為止,這其實是一個遞歸的過程。

    我們不去深究這個遞歸的整個過程,我們只需要理解清楚其中的幾個關鍵點就可以了。首先,對於每一次遞歸來說,我們只會移動這個遞歸範圍內最右側的滑動框,其次我們清楚每一次遞歸過程中的起始狀態。開始狀態就是所有的滑動框全部集中在“直尺”的最左側,結束狀態就是全部集中在最右側。

    我們把上面的邏輯整理一下,假設我們經過一系列操作之後,m個滑動框全部移動到了長度為n的直尺的最右側。這就相當於的組合都已經獲取完了。如果n+1的位置還有滑動框,並且它的右側還可以移動,那麼我們需要將它往右移動一個,到n+2的位置。這個時候剩下的局面就是,為了獲取這些組合,我們需要把這m個滑動框全部再移動到直尺的最左側,重新開始移動。

    我們在實現的時候當然沒有滑動框,我們可以用一個數組記錄滑動框當中的元素。

    我先用遞歸寫一下這段邏輯:

    class Solution:
        def combine(self, n: int, k: int) -> List[List[int]]:
            def comb(window, m, ret):
                ret.append(window[:-1])
    
                # 如果第m位的滑動框不超過直尺的範圍並且m右側的滑動框
                while window[m] < min(n - k + m + 1, window[m+1] - 1):
                    # 向右滑動一位
                    window[m] += 1
                    # 如果m左側還有滑動框,遞歸
                    if m > 0:
                        # 把左側的滑動框全部移動到最左側
                        window[:m] = range(1, m+1)
                        comb(window, m-1, ret)
                    else:
                        # 否則記錄答案
                        ret.append(window[:-1])
    
                    
            ret = []
            window = list(range(1, k+1))
            # 額外多放一個滑動框作為標兵
            window.append(n+1)
            comb(window, k-1, ret)
            return ret
    

    這種解法的速度比上面正規遞歸的速度快了許多,因為我們遞歸的過程當中做了諸多限制,剪掉了很多無關的情況,相當於做了極致的剪枝。

    最關鍵的是上面的這段邏輯我們是可以用循環實現的,所以我們可以用循環來將遞歸的邏輯展開,就得到了下面這段代碼。

    class Solution:
        def combine(self, n: int, k: int) -> List[List[int]]:
            # 構造滑動框
            window = list(range(1, k + 1)) + [n + 1]
            
            ret, j = [], 0
    
            while j < k:
                # 添加答案
                ret.append(window[:k])
    
                j = 0
                # 從最左側的滑動框開始判斷
                # 如果滑動框與它右側滑動框挨着,那麼就將它移動到最左側
                # 因為它右側的滑動框一定會向右移動
                while j < k and window[j + 1] == window[j] + 1:
                    window[j] = j + 1
                    j += 1
                # 連續挨着最右側的滑動框向右移動一格
                window[j] += 1
                
            return ret
    

    這段代碼雖然非常精鍊,但是很難理解,尤其是你沒能理解上面遞歸實現的話,會更難理解。所以我建議,先把遞歸實現的滑動框的方法理解了,再來理解不含遞歸的這段,會容易一些。

    總結

    我們通過回溯法求解組合的方法應該是最簡單也是最基礎的,難度也不大。相比之下後面一種方法則要困難許多,我們直接去啃,往往不得要領。既會疑惑為什麼這樣可以保證能獲得所有的組合,又會不明白其中具體的實現邏輯。所以如果想要弄明白第二種方法,一定要從滑動框這個模型出發

    從代碼實現的角度來說,滑動框方法的遞歸解法比非遞歸的解法還要困難。因為遞歸條件以及邏輯都比較複雜,還涉及到存儲答案的問題。但是從理解上來說,遞歸的解法更加容易理解一些,非遞歸的算法往往會疑惑於j這個指針的取值。所以如果想要理解算法的話,可以從遞歸的代碼入手,想要實現代碼的話,可以從非遞歸的方法入手。

    這道題目非常有意思,值得大家細細思考。

    如果喜歡本文,可以的話,請點個關注,給我一點鼓勵,也方便獲取更多文章。

    本文使用 mdnice 排版

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※別再煩惱如何寫文案,掌握八大原則!

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 求求你,別問了,Java字符串是不可變的

    求求你,別問了,Java字符串是不可變的

    最近,又有好幾個小夥伴問我這個問題:“二哥,為什麼 Java 的 String 要設計成不可變的啊?”說實話,這也是一道非常經典的面試題,面試官超喜歡問。我之前寫過這方面的文章,現在讀起來似乎不太滿意,所以我決定再啰嗦最後一次,交出一份更滿意的答卷,讓小夥伴們在面試官面前更從容一些,更有底氣一些。

    關於不可變對象,還有這樣一個小故事。Java 之父詹姆斯高司令曾在一次採訪中被問及這樣一個問題:“高司令,應該什麼時候使用不可變對象啊?”你猜高司令怎麼回答?

    如有可能,我願意任何時候都使用不可變對象。

    這就是高司令的答案,那有的小夥伴可能不服,老人家會說中文,你瞎扯吧你。也對哈,那就上英文唄:

    I would use an immutable whenever I can.

    這下徹底被打服了吧?老人家還說,不可變有着非常強大的功能,比如說,緩存、安全性、高性能等等。

    01、什麼是不可變對象

    不可變對象在創建后,它的內部狀態會保持不變,這就意味着,一旦我們將一個對象分配給一個變量,就無法再通過任何方式更改對象的狀態了。

    關於不可變對象的更多信息,可以查看我之前寫的另外一篇文章——這次要說不明白immutable類,我就怎麼地,看完啥都明白了。你看,寫系列文章的好處就是這樣,不需要重複造輪子,用到的時候直接搬出來套上就行了。

    02、為什麼 String 是不可變的

    重點來了啊,為什麼 String 是不可變的?原因可以從四個方面說起,緩存、安全性、同步和高性能。

    1)字符串常量池

    字符串恐怕是 Java 中最常用的數據形式了,如果字符串非要謙虛地說自己是老二,就沒有人敢說自己是老大。

    因此,把字符串緩存起來,並且重複使用它們會節省大量堆空間(堆內存用來存儲 Java 中的對象,無論是成員變量、局部變量,還是類變量,它們指向的對象都存儲在堆內存中),因為不同的字符串變量引用的是字符串常量池中的同一個對象。這也正是字符串常量池存在的目的。

    字符串常量池是 Java 虛擬機用來存儲字符串的一個特殊的區域,由於字符串是不可變的,因此 Java 虛擬機可以在字符串常量池中只為同一個字符串存儲一個字符串副本來節省空間。

    字符串常量池的主要使用方法有兩種:

    • 直接使用雙引號聲明出來的字符串對象會直接存儲在常量池中。
    • 否則,可以使用 String 類提供的 intern() 方法強制將當前字符串放入常量池中——常量池中查詢不到當前字符串。

    來看下面這段代碼:

    String s1 = "沉默王二";
    String s2 = "沉默王二";

    System.out.println(s1 == s2); // true

    由於字符串常量池的存在,所以兩個不同的變量都指向了池中同一個字符串對象,從而節省了稀缺的內存資源。如果是通過 new 關鍵字創建的對象,則需要新的堆空間。

    放心,關於字符串常量池,後面有時間的話,我再單獨寫一篇文章詳細地說一說。

    2)安全性

    字符串在 Java 應用程序中的使用範圍非常廣,幾乎無處不在,比如說存儲用戶名、密碼、數據庫連接地址等等這些非常敏感的信息,因此,必須要保證 String 類的絕對安全性。

    來考慮一下下面這段代碼:

    void criticalMethod(String userName) {
        // 檢查用戶名是否合法
        if (!isAlphaNumeric(userName)) {
            throw new SecurityException(); 
        }

        // 初始化數據庫連接
        initializeDatabase();

        // 準備修改用戶狀態
        connection.executeUpdate("UPDATE members SET status = 'active' " +
          " WHERE username = '" + userName + "'");
    }

    通常情況下,用戶名由客戶端傳遞到服務器端,服務器端接收后要先對用戶名進行檢查,再進行其他操作,因為客戶端傳遞過來的信息不一定值得信任。

    如果字符串是可變的,那麼我們在執行 executeUpdate 更新數據庫的時候,就有點不放心,因為即便是安全性檢查通過了,字符串仍然有可能被修改。

    在調用 isAlphaNumeric() 方法進行安全性檢查期間,userName 的值仍然有可能被 criticalMethod() 方法的調用者進行篡改,就容易造成 SQL 注入。

    但如果字符串是不可變的,這方面的擔憂就不存在了。因為在執行更新之前,字符串的值是確定的,就是我們檢查安全性之後的值。

    3)線程安全

    由於字符串是不可變的,因此可以在多線程之間共享,如果一個線程把字符串的值修改為另外一個,那麼就會在字符串常量池中創建另外一個字符串,原有的字符串仍然會保持不變。

    不過,很遺憾,我還不知道怎麼從代碼層面上去證明這一點,只能純理論 yy 一下。小夥伴誰有辦法的,教教我,在線等的那種。

    4)哈希碼

    字符串廣泛應用於 HashMap、HashTable、HashSet 等需要哈希碼作為鍵的數據結構中,在對這些哈希表進行操作的時候,需要頻繁調用 hashCode() 方法來獲取鍵的哈希碼。

    public V put(K key, V value) {
        return putVal(hash(key), key, value, falsetrue);
    }
    static final int hash(Object key) {
        int h;
        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
    }

    由於字符串是不可變性,這就保證了鍵值的哈希值不會發生改變,因此在第一次調用 String 類的 hashCode() 方法時,就對哈希值進行了緩存,此後,就一直返回相同的值。

    /** Cache the hash code for the string */
    private int hash; // Default to 0

    public int hashCode() {
        int h = hash;
        if (h == 0 && !hashIsZero) {
            h = isLatin1() ? StringLatin1.hashCode(value)
                    : StringUTF16.hashCode(value);
            if (h == 0) {
                hashIsZero = true;
            } else {
                hash = h;
            }
        }
        return h;
    }

    由於哈希值被緩存了,這在另外一種層面上提高了哈希表的訪問性能,因為哈希值不用重新計算了。

    假如字符串是可變的,那就意味着哈希碼會有多個,在通過鍵獲取值的時候,就不一定能夠獲取到對的值了。

    你看,字符串常量池的存在,哈希碼的存在,在很大程度上提高了程序的性能。

    03、總結

    好了,我親愛的小夥伴們,以上就是本文的全部內容了。我相信你一定對字符串的不可變性有了充足的了解,由於字符串是不可變的,因此我們可以將它看作是一個特殊的基本數據類型,哪怕是在多線程的環境下,也不用擔心它的值是否會發生改變。

    如果覺得文章對你有點幫助,請微信搜索「 沉默王二 」第一時間閱讀。

    本文已收錄 GitHub,傳送門~ ,裏面更有大廠面試完整考點,歡迎 Star。

    我是沉默王二,一枚有顏值卻靠才華苟且的程序員。關注即可提升學習效率,別忘了三連啊,點贊、收藏、留言,我不挑,嘻嘻

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※超省錢租車方案

    ※教你寫出一流的銷售文案?

    網頁設計最專業,超強功能平台可客製化

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 上次被目擊是1913年!消失百年「沃茲考氏變色龍」現蹤

    摘錄自2020年11月1日自由時報報導

    這真的是百年一見!科學家在非洲島國馬達加斯加西北部,發現難為世人所見的變色龍「沃茲考氏變色龍」(Voeltzkow’s chameleon),上一次這種變色龍被目擊的紀錄,是在100多年前。

    馬達加斯加和德國的研究人員10月30日宣佈這項發現,他們2018年在馬達加斯加西北部探察時,發現了幾隻活「沃茲考氏變色龍」。巴伐利亞自然歷史陳列館(ZSM)的科學家,在期刊「蠑螈」(Salamandra)發表的報告說,基因分析確認,這些物種是拉波德氏變色龍(Labord’s chameleon)的近親。

    上一次發現沃茲考氏變色龍是在1913年,而且,之前也從未有關於雌性「沃茲考氏變色龍」的紀錄。研究人員說,雄性的沃茲考氏變色龍外觀為綠色,相比之下,母變色龍就繽紛得多。研究人員相信,這兩種變色龍都只在雨季生活:孵化、迅速成長、與競爭者較勁,然後交配、死亡,這些過程都在短短幾個月內完成。ZSM爬蟲和兩棲動物典藏研究員格勞(Frank Glaw)說,「這些動物基本上是脊椎動物中的浮游類」。現今大規模森林砍伐正威脅牠們的棲地。

    生物多樣性
    國際新聞
    變色龍
    瀕危物種

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※推薦評價好的iphone維修中心

  • 日本香川縣養雞場爆禽流感 將撲殺33萬隻雞

    摘錄自2020年11月5日中央社報導

    日本香川縣三豊市的一處養雞場從11月1日到4日突然有約3800隻雞死亡,經檢驗後驗出H5型禽流感病毒,該養雞場將撲殺約33萬隻雞。

    香川縣政府今天上午召開對策本部會議,決定養雞場飼養的約33萬隻雞將進行撲殺。

    日本的養雞場上次發生禽流感疫情,是2018年1月香川縣讚岐市的養雞場驗出H5型禽流感病毒。

    日本首相菅義偉今天上午聽取報告後,指示相關單位要提醒家禽業者對此高度警戒,並輔導與支援業者預防、收集現場情報;農林水產省與相關部會緊密合作,迅速進行防疫措施,以及對國民盡速提供正確的防疫資訊。

    國際新聞
    日本
    禽流感

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

  • 突變冠狀病毒株恐降疫苗效力 丹麥全面撲殺水貂

    摘錄自2020年11月5日中央社報導

    丹麥總理佛瑞德里克森今(4日)表示,在水貂身上的突變冠狀病毒傳染給人類之後,對未來可能研發出來的疫苗造成風險,因此境內多達1700萬隻水貂將遭全面撲殺。

    丹麥為全世界最大的水貂毛皮生產地,雖然當局自6月以來一再撲殺遭感染的水貂,但境內水貂農場疫情仍持續蔓延。

    佛瑞德里克森(Mette Frederiksen)在記者會上表示,衛生當局發現人體病毒株與水貂身上的病毒株,顯示對抗體的敏感度已降低,有可能影響未來疫苗的效力。

    國際新聞
    丹麥
    水貂

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計最專業,超強功能平台可客製化