作者: admin

abp(net core)+easyui+efcore實現倉儲管理系統——ABP WebAPI與EasyUI結合增刪改查之二(二十八)

admin




 










   

       在上一篇 文章中我們學習了TreeGrid的一些基礎知識，接下我們來創建我們開發組織管理功能用到的一些類。關於如何創建類我們之前的文章中已經寫了很多了，這裡會有些簡略。

 

四、定義應用服務接口需要用到的DTO類

      為了在進行查詢時使用, PagedOrgResultRequestDto被用來將模塊數據傳遞到基礎設施層.

       1. 在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊“ABP.TPLMS.Application”項目，在彈出菜單中選擇“添加” > “新建文件夾”，並重命名為“Orgs”

      2. 使用鼠標右鍵單擊我們剛才創建的“Orgs”文件夾，在彈出菜單中選擇“添加” > “新建文件夾”，並重命名為“Dto”。

      3．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 Paged OrgResultRequestDto，然後選擇“添加”。代碼如下。

using Abp.Application.Services.Dto;
using Abp.Application.Services.Dto;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs.Dto
{

public class PagedOrgResultRequestDto : PagedResultRequestDto
    {
        public string Keyword { get; set; }
    }
}

      4．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 OrgDto，然後選擇“添加”。代碼如下。

using Abp.Application.Services.Dto;
using Abp.AutoMapper;
using ABP.TPLMS.Entitys;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs.Dto
{

    [AutoMapFrom(typeof(Org))]
    public class OrgDto : EntityDto<int>
    {

        int m_parentId = 0;
        public string Name { get; set; }       

        public string HotKey { get; set; }
        public int ParentId { get { return m_parentId; } set { m_parentId = value; } }       

        public string ParentName { get; set; }
        public bool IsLeaf { get; set; }
        public bool IsAutoExpand { get; set; }       

        public string IconName { get; set; }
        public int Status { get; set; }
        public int Type { get; set; }      
        public string BizCode { get; set; }       

        public string CustomCode { get; set; }
        public DateTime CreationTime { get; set; }
        public DateTime UpdateTime { get; set; }

        public int CreateId { get; set; }
        public int SortNo { get; set; }
        public int _parentId {
            get { return m_parentId; }          

        }
    }
}

      5．右鍵單擊“Dto”文件夾，然後選擇“添加” > “類”。 將類命名為 CreateUpdateOrgDto，然後選擇“添加”。代碼如下。

 

using Abp.Application.Services.Dto;
using Abp.AutoMapper;
using ABP.TPLMS.Entitys;
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Text;

 
namespace ABP.TPLMS.Orgs.Dto
{

    [AutoMapTo(typeof(Org))]
    public class CreateUpdateOrgDto : EntityDto<int>
    {

        public string Name { get; set; }
        [StringLength(255)]
        public string HotKey { get; set; }

        public int ParentId { get; set; }

        [Required]
        [StringLength(255)]
        public string ParentName { get; set; }

        public bool IsLeaf { get; set; }
        public bool IsAutoExpand { get; set; }

        [StringLength(255)]
        public string IconName { get; set; }

        public int Status { get; set; }
        public int Type { get; set; }

        [StringLength(255)]
        public string BizCode { get; set; }

        [StringLength(100)]
        public string CustomCode { get; set; }
        public DateTime CreationTime { get; set; }
        public DateTime UpdateTime { get; set; }

        public int CreateId { get; set; }
        public int SortNo { get; set; } 

    }
}

 

 

 

五、定義IOrgAppService接口

        6． 在Visual Studio 2017的“解決方案資源管理器”中，鼠標右鍵單擊“Org”文件夾，然後選擇“添加” > “新建項”，在彈出對話框中選擇“接口”。為應用服務定義一個名為 IOrgAppService 的接口。代碼如下。 

using System;
using System.Collections.Generic;
using System.Text;
using Abp.Application.Services;
using ABP.TPLMS.Orgs.Dto; 

 

namespace ABP.TPLMS.Orgs
{
  public  interface IOrgAppService : IAsyncCrudAppService<//定義了CRUD方法

             OrgDto, //用來展示組織信息
             int, //Org實體的主鍵
             PagedOrgResultRequestDto, //獲取組織信息的時候用於分頁
             CreateUpdateOrgDto, //用於創建組織信息
             CreateUpdateOrgDto> //用於更新組織信息

    {
    }
}

 

      六、實現IOrgAppService

       7．在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊“Org”文件夾，然後選擇“添加” > “新建項”，在彈出對話框中選擇“類”。為應用服務定義一個名為 OrgAppService 的服務類。代碼如下。

using Abp.Application.Services;
using Abp.Domain.Repositories;
using ABP.TPLMS.Entitys;
using ABP.TPLMS.Orgs.Dto;
using System;
using System.Collections.Generic;
using System.Text;
 

namespace ABP.TPLMS.Orgs
{

    public class OrgAppService : AsyncCrudAppService<Org, OrgDto, int, PagedOrgResultRequestDto,
                            CreateUpdateOrgDto, CreateUpdateOrgDto>, IOrgAppService 

    {
        public OrgAppService(IRepository<Org, int> repository)

            : base(repository)

        { 

        }
    }
}

七 創建OrgController繼承自TPLMSControllerBase

      1. 在Visual Studio 2017的“解決方案資源管理器”中，右鍵單擊在領域層“ABP.TPLMS.Web.Mvc”項目中的Controller目錄。 選擇“添加” > “新建項…”。如下圖。

 

     2. 在彈出對話框“添加新項-ABP.TPLMS.Web.Mvc”中選擇“控制器類”，然後在名稱輸入框中輸入“OrgsController”，然後點擊“添加”按鈕。

     3.在OrgsController.cs文件中輸入如下代碼，通過構造函數注入對應用服務的依賴。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Abp.AspNetCore.Mvc.Authorization;
using Abp.Web.Models;
using ABP.TPLMS.Controllers;
using ABP.TPLMS.Orgs;
using ABP.TPLMS.Orgs.Dto;
using ABP.TPLMS.Web.Models.Orgs;
using Microsoft.AspNetCore.Mvc;


namespace ABP.TPLMS.Web.Controllers
{
    [AbpMvcAuthorize]
    public class OrgsController : TPLMSControllerBase
    {
        private readonly IOrgAppService _orgAppService;
        private const int MAX_COUNT= 1000;
        
        public OrgsController(IOrgAppService orgAppService)
        {
            _orgAppService = orgAppService;
        }
        [HttpGet]
        // GET: /<controller>/
        public IActionResult Index()
        {
            return View();
        }
        [DontWrapResult]
        [HttpPost]
        public string List()
        {         
            PagedOrgResultRequestDto paged = new PagedOrgResultRequestDto();
            paged.MaxResultCount = MAX_COUNT;
           var userList = _orgAppService.GetAll(paged).GetAwaiter().GetResult().Items;
            int total = userList.Count;
            var json = JsonEasyUI(userList, total);
            return json;
        }       
    }
}

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

靚仔靚女如何用瀏覽器自拍和保存

admin

一、前言

1.核心技術

  • Web Real-Time Communication：網頁即時通信，可以在瀏覽器進行實時語音或者視頻對話的API
  • Canvas：HTML5中的新元素,可以用來來繪製圖形、圖標、以及其它任何視覺性圖像

2.音頻採集的基本概念

  • 攝像頭：用於採集圖像和視頻
  • 麥克風：採集音頻數據
  • 幀率：一秒鐘採集圖像的次數。幀率越高，越平滑流暢
  • 軌：借鑒了多媒體的概念，每條軌數據都是獨立的，如MP4中的音頻軌、視頻軌，是分別被存儲的
  • 流：可以理解為容器。在WebRTC中，流可以分為媒體流（MediaStream）和數據流（DataStream）。
  • 分辨率：2K、1080P、720P等，越清晰，佔用帶寬越多

3.音視頻設備的基本原理

  • 音頻設備
    音頻輸入設備主要是採集音數據，而採集音頻數據的本質是模擬信號轉成数字信號，
    採集到的數據經過量化、編碼，最終開成数字信號，這就是音頻設備要完成的工作。
    人的聽覺範圍的頻率是20Hz~20kHz之間，日常語音交流8kHz就哆了。
    為了追求高品質、高保真，需要將音頻輸入設備採樣率設置在40kHz上才能完整保留原始信號

  • 視頻設備
    當實物光通過鏡頭進行攝像機后，它會通過視頻設備的模數轉換（A/D）模塊，即光學傳感器，將光轉換成数字信號，即RGB數據，獲得RGB數據后，再通過DSP進行優化處理，如自動增強、白平衡、色彩飽和等，等到24位的真彩色圖片

模數轉換使用的採集定理稱為奈奎斯特定理：

在進行模擬 / 数字信號的轉換過程中，當採樣率大於信號中最高頻率的 2 倍時，採樣之後的数字信號就完整地保留原始信號中的信息。

talk is cheap, 上代碼，以下示例運行的時候會請求攝像頭權限，同意即可，接下來就是見證奇迹的時刻！

二、示例

1.示例1-打開攝像頭

這就是照像的核心功能，以後可以用來化妝，擠痘痘，整理髮型

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>打開攝像頭</title>
</head>
<body>
<h1>打開攝像頭</h1>
<video autoplay playsinline></video>
</body>
</html>

<script>
    const mediaStreamContrains = {
        video: {
            frameRate: {min: 20},
            width: {min: 640, ideal: 1280},
            height: {min: 360, ideal: 720},
            aspectRatio: 16 / 9
        },
        audio: {
            echoCancellation: true,
            noiseSuppression: true,
            autoGainControl: true
        }
    };

    const localVideo = document.querySelector('video');

    function gotLocalMediaStream(mediaStream) {
        localVideo.srcObject = mediaStream;
    }

    function handleLocalMediaStreamError(error) {
        console.log('navigator.getUserMedia error: ', error);
    }

    navigator.mediaDevices.getUserMedia(mediaStreamContrains).then(
        gotLocalMediaStream
    ).catch(
        handleLocalMediaStreamError
    );
</script>

運行結果如下

示例2-拍照保存

這裏展示了兩個按鈕，拍照和保存，yes，就是自拍的核心功能！

<html>
<head>
    <meta charset="UTF-8">
    <title>拍照一分鐘，P圖兩小時</title>
</head>

<body>
<section>
    <div>
        <video autoplay playsinline id="player"></video>
    </div>

</section>
<section>
    <div>
        <button id="snapshot">拍照</button>
        <button id="download">下載</button>
    </div>
    <div>
        <canvas id="picture"></canvas>
    </div>
</section>
</body>
</html>


<script>
    'use strict';

    var videoplay = document.querySelector('video#player');

    function gotMediaStream(stream) {
        window.stream = stream;
        videoplay.srcObject = stream;
    }

    function handleError(err) {
        console.log('getUserMedia error:', err);
    }

    function start() {
        var constraints = {
            video: {
                width: 1280,
                height: 720,
                frameRate: 15,
                facingMode: 'enviroment'
            },
            audio: false
        }

        navigator.mediaDevices.getUserMedia(constraints)
            .then(gotMediaStream)
            .catch(handleError);
    }


    //拍照
    var snapshot = document.querySelector('button#snapshot');
    snapshot.onclick = function () {
        var picture = document.querySelector('canvas#picture');
        picture.width = 1280;
        picture.height = 720;
        picture.getContext('2d').drawImage(videoplay, 0, 0, picture.width, picture.height);
    };


    //下載
    function downLoad(url) {
        var oA = document.createElement("a");
        oA.download = 'photo';// 設置下載的文件名，默認是'下載'
        oA.href = url;
        document.body.appendChild(oA);
        oA.click();
        oA.remove(); // 下載之後把創建的元素刪除
    }

    document.querySelector("button#download").onclick = function () {
        downLoad(picture.toDataURL("image/jpeg"));
    };

    start();

</script>

運行結果如下

就是這麼簡單！

重點方法和參數解釋

  • 1.方法：avigator.mediaDevices.getUserMedia(constraints);
    返回一個promise對象，調用成功，可以通過promise對象獲取MediaStream對象，

  • 2.參數：mediaStreamContrains
    傳入的constraints參數類型為 MediaStreamConstraints，可以指定 MediaStream 中包含哪些類型的媒體軌（音頻軌、視頻軌），並且可為這些媒體軌設置一些限制。
    視頻的幀率最小 20 幀每秒；
    寬度最小是 640，理想的寬度是 1280；
    高度最小是 360，最理想高度是 720；
    寬高比是 16:9；
    對於音頻則是開啟迴音消除、降噪以及自動增益功能。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

不只是換殼上市！EC-05 與 Gogoro S2 實測比較

admin

EC-05 由台灣山葉（YAMAHA）和 Gogoro 聯手打造，動力系統採用與 Gogoro S2 相同的 G2 鋁合金水冷永磁同步馬達（S-Version），許多人不禁疑問 EC-05 和 Gogoro S2 到底有什麼差別？難道只是換了一個車殼？更別說 EC-05 的價格還比 Gogoro S2 貴了 2,820 元。為了比較其中的差別，《科技新報》試駕了 EC-05 和 2020 年式的 Gogoro S2，帶來兩台車的第一手觀察。

EC-05 配備嵌合式環型頭燈，能在夜間騎乘時避免光線發散，確保前方視野的明亮程度。Gogoro S2 同樣配備環型頭燈，不過形狀略有不同，和一般機車一樣完全外露。EC-05 的後照鏡為菱形設計，視野較為寬廣，Gogoro S2 的後照鏡是圓形，視野較狹窄，而且騎乘者容易被自己的身體擋住部分視線。

Gogoro S2 前方配備了多功能置物箱，可以擺放手機和手套等小型物品，也能做為飲料置杯架使用，EC-05 就沒有這項裝置。Gogoro S2 的前方置物箱內附 USB 充電插槽，EC-05 的 USB 插孔則位於後座的置物箱。EC-05 使用無線智慧鑰匙，靠近車輛後按壓鑰匙的灰色部分進行解鎖。Gogoro S2 則使用 iQ system 智慧鑰匙卡，只要輕觸 S 標誌就能解鎖。

EC-05（左）配備嵌合式環型頭燈，Gogoro S2 的頭燈則外露。

EC-05 後照鏡呈菱形，視野較寬廣。

Gogoro S2 的後照鏡為圓形。

Gogoro S2 配備多功能置物箱，並附有 USB 充電插槽。

EC-05 的 USB 充電插槽位於後置物箱內側。

EC-05 以無線智慧鑰匙解鎖。

試乘時騎行陽明山的山路，EC-05 的穩定度和避震能力優於 Gogoro S2，在路面凹凸不平時較不容易顛簸，雙載騎乘時的差距更加明顯。EC-05 的座墊將後座的後方略為墊高，讓座墊呈現「山」字型的結構，側邊則採切削設計，讓騎乘者的腿部更為舒適。Gogoro S2 的後座較為平滑，中間使用皮質材質並標有「S」字樣。雖然乍看之下差異不大，但實際騎乘時後座乘客的感受明顯不同。

EC-05 的乘客在機車減速和加速時都更容易維持穩定，比較不會有往後飛出去或往前貼到前方騎乘者身上的狀況，即使長時間乘坐也不會滑動。Gogoro S2 的後座把手較為平直，EC-05 的把手彎曲向上，對於手不夠長的乘客更容易抓握。相較於 Gogoro S2，EC-05 能給予後座乘客更安穩的乘坐體驗。

EC-05 的座墊呈現「山」字型的凸起，讓後座乘客乘坐時更穩定。

Gogoro S2 的座墊較為平滑。

EC-05 與 Gogoro S2 座墊比較。

EC-05 的後座把手彎曲向上，較容易抓握。

Gogoro S2 的後座把手平直，手沒那麼長的後座乘客較難抓握。

EC-05（右）與 Gogoro S2 的後座把手差異從車尾可以明顯看出。

由於 EC-05 與 Gogoro S2 採用相同的動力系統，因此性能上的數據相差無幾。EC-05 最大馬力為 10hp，安全極速達到時速 90 公里，靜止加速到時速 50 公里需要 3.9 秒。Gogoro S2 最大馬力為 10.18hp，安全極速達到時速 92 公里，靜止加速到時速 50 公里僅需 3.8 秒，各方面都是 Gogoro S2 稍勝。

相較於 Gogoro S2，EC-05 的儀表板略為調整傾斜角度並向前方移動，用以減少騎乘者所需的視線移動。EC-05 的腳踏板具有菱形的凸起幫助止滑，讓騎乘時腳的位置可以更穩定。Gogoro S2 的腳踏板則是完全平滑，並有著「gogoro」的字樣。

EC-05 在車及座墊高度上也有更動，車高為 1,180 mm 略高於 Gogoro S2 的 1,080 mm，座高則以 768 mm 略低於 Gogoro S2 的 780 mm。調整過後 EC-05 在龍頭和座墊間的空間增加，騎乘時較為舒適也不容易意外按壓到喇叭等按鍵。不過 EC-05 的龍頭相較 Gogoro S2 略為沉重，力氣較小的使用者操控時可能會稍微費力。

EC-05 的腳踏板具有止滑的菱形格紋。

Gogoro S2 的腳踏板較為平滑。

身高 176 公分的騎乘者與 EC-05 的比例。

身高 156 公分的騎乘者與 EC-05 的比例。

YAMAHA 的設計理念標榜「人機官能」，也就是在設計時結合機械結構和人體工學。這樣的概念讓 EC-05 看似與 Gogoro S2 僅有微幅的差異，但這些細節卻在騎乘時能發揮不成比例的效果。至於這樣的差別值不值得多花 2,820 元購買，那就要看個人是否在意這些細節帶來的感受。

EC-05 提供藍灰色、深黑色、深藍灰色和白銀色 4 種顏色讓消費者選擇，定價為台幣 99,800 元。Gogoro S2 僅有灰黑色一個款式，定價為台幣 96,980 元。

（合作媒體：。圖片來源：）

延伸閱讀：

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

中油換電站今年採競標，Gogoro累計 285 站、光陽 146 站

admin

中油從 107 年起，依據經濟部智慧電動機車能源補充設施普及計畫(公建計畫)於加油站建置電動機車充電、換電設備，去年僅睿能 Gogoro 參與設 144 站，今年增加光陽 Ionex，兩家採公開競標方式，由光陽 Ionex 獲得 3 標共 146 站，睿能 Gogoro 得到 1 標 48 站；其中，睿能 Gogoro 扣除合約到期站數，再加上先前自建設站，在台灣中油加油站中有 285 站可為消費者服務。

經濟部工業局委託台灣銀行辦理共同供應契約設備系統招標，其中電池交換設備系統得標廠商都需符合安全規範審核，108 年換電設備系統之得標廠商共有睿能 Gogoro 及光陽 Ionex 兩家，中油考量消費者的便利性及設備使用公平性兩大原則，於採購系統設備前即採取公開方式辦理合作經營招標。

中油表示，北部地區有 52 站與睿能 Gogoro 合作的換電站，今年合約陸續到期，睿能 Gogoro 依據契約與決標結果遷移設備，為執行公建計畫，中油將此52站列入今年建置194站換電站的地點，公建換電站依各縣市站點打散，再平均分4案開標，讓每一標案站點均涵蓋各縣市，投標結果為光陽 Ionex 獲得 3 標（146 站）、睿能 Gogoro 得 1 標（48 站），原先台灣中油與睿能 Gogoro 合約到期的52站中，有38站改由光陽Ionex得標。

中油指出，上述政府電動機車充、換電站公建計畫，於 107 年已執行 161 站，其中 144 座換電站均為睿能 Gogoro 所有，另有充電 17 站，今年預計建置 216 座充換電站，其中 194 座為換電站，光陽 Ionex 有 146 站、睿能 Gogoro 48 站，另有充電 22 站，以總數來說，再加上睿能 Gogoro 之前的自建站 79 站，其仍在台灣中油有 285 站，光陽 Ionex 有 146 站為消費者服務，明年亦將配合政府預算持續建置更多站點，協助政府綠能政策推動。

（本文內容由 授權使用。首圖來源：Gogoro）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

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

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

※公開收購3c價格,不怕被賤賣!

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

夏季電動機車市場正熱，Gogoro 掛牌數突破 20 萬

admin

2019 年台灣電動機車市場百家爭鳴，也帶動市場熱度，越來越多消費者願意選擇電動機車。電動機車大廠 Gogoro 宣布旗下總掛牌數正式達 20 萬輛，寫下新的里程碑。

根據工研院產科國際所推估，台灣電動機車年銷量可以突破 15 萬輛，成長速度超過全球平均。2019 年夏季包括 Gogoro、光陽（Kymco）、山葉（YAMAHA）、中華汽車 eMOVING 和宏佳騰等品牌都推出新的電動機車，代表車廠也清楚了解市場對電動機車的需求。

受惠於暑假旺季提前發酵，加上受到新車效應與即將到來的開學季影響，Gogoro 從 2019 年 5 月以來已連續 4 個月單月掛牌數破萬，這也讓 Gogoro 總掛牌數正式達到 20 萬輛。在全新發表的 Gogoro S2 ABS 車款助攻之下，讓 Gogoro 在 8 月單月掛牌市占率達 16.35%，即使 8 月整體機車市場下滑 20%，仍然保持穩定成長。

Gogoro 資深行銷總監陳彥揚表示：「今年夏天對 Gogoro 來說深具意義，連續 4 個月掛牌破萬，帶動 Gogoro 總車主數超越 20 萬大關，除了非常感謝車主的熱情支持，業界的投入及政府政策的推動，也是電動機車產業發展向前邁進的關鍵要素，期盼能快速跟上全球化電動車趨勢的腳步。」

每年最具代表性的車主活動「快閃台北橋」將於 9 月 29 日舉辦，2018 年活動以 1,303 台機車創下「世界最大規模電動機車遊行」的金氏世界紀錄，Gogoro 也將擴大邀請所有電動機車車主，今年活動時集結台北橋。

8 月推出的「暢快騎 0 元起」購車方案廣受歡迎，Gogoro 為了慶祝車主數量突破 20 萬大關，宣布活動時間將延長至 9 月 30 日，購買 Gogoro 全車系即贈送 6 個月電池服務資費 299 元，無論選擇什麼方案每個月都可抵扣電池資費 299 元。即日起至 9 月 30 日購買 Gogoro 全車系並符合學生資格的車主，即可享有 12 期 0 利率分期優惠，同時再送「1 年期車碰車險」。

（合作媒體：。首圖來源：Gogoro）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※公開收購3c價格,不怕被賤賣!

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

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

※帶您來看台北網站建置，台北網頁設計，各種案例分享

SpringBoot源碼學習系列之SpringMVC自動配置

admin

目錄

源碼學習系列之WebMvc自動配置原理筆記

@

web的自動配置在SpringBoot項目中是一個很重要的方面，實現代碼在spring-boot-autoconfigure工程里：

按照官方文檔的說法，SpringBoot官方的說法，Springboot的SpringMVC自動配置，主要提供了如下自動配置：

WebMvcAutoConfiguration.java這個類很關鍵，這個就是SpringBoot Springmvc自動配置的一個很關鍵的配置類

@Configuration(proxyBeanMethods = false)//指定WebMvcAutoConfiguration不代理方法
@ConditionalOnWebApplication(type = Type.SERVLET)//在web環境(selvlet)才會起效
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class })//系統有有Servlet，DispatcherServlet(Spring核心的分發器)，WebMvcConfigurer的情況，這個自動配置類才起效
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)//系統沒有WebMvcConfigurationSupport這個類的情況，自動配置起效
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class,
        ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {
....
}

翻下源碼，可以看到WebMvcAutoConfiguration自動配置類里還有一個WebMvcConfigurer類型的配置類，2.2.1版本是implements WebMvcConfigurer接口，1.+版本是extends WebMvcConfigurerAdapter 

@Configuration(proxyBeanMethods = false)//定義為配置類
    @Import(EnableWebMvcConfiguration.class)//spring底層註解,將EnableWebMvcConfiguration加到容器
    @EnableConfigurationProperties({ WebMvcProperties.class, ResourceProperties.class })//使WebMvcProperties、ResourceProperties配置類生效
    @Order(0)
    public static class WebMvcAutoConfigurationAdapter implements WebMvcConfigurer {
    ....
}

1、ContentNegotiatingViewResolver

如圖，是視圖解析器的自動配置，這個類起效的情況是系統沒有ContentNegotiatingViewResolver類的情況，就調用改方法自動創建ContentNegotiatingViewResolver類

關鍵的是ContentNegotiatingViewResolver類，翻下ContentNegotiatingViewResolver類，找到如下重要的初始化方法

@Override
    protected void initServletContext(ServletContext servletContext) {
    //調用Spring的BeanFactoryUtils掃描容器里的所有視圖解析器ViewResolver類
        Collection<ViewResolver> matchingBeans =
                BeanFactoryUtils.beansOfTypeIncludingAncestors(obtainApplicationContext(), ViewResolver.class).values();
        if (this.viewResolvers == null) {
            this.viewResolvers = new ArrayList<>(matchingBeans.size());
            //遍歷候選的viewResolvers，封裝到this.viewResolvers列表
            for (ViewResolver viewResolver : matchingBeans) {
                if (this != viewResolver) {
                    this.viewResolvers.add(viewResolver);
                }
            }
        }
        else {
            for (int i = 0; i < this.viewResolvers.size(); i++) {
                ViewResolver vr = this.viewResolvers.get(i);
                if (matchingBeans.contains(vr)) {
                    continue;
                }
                String name = vr.getClass().getName() + i;
                obtainApplicationContext().getAutowireCapableBeanFactory().initializeBean(vr, name);
            }

        }
        AnnotationAwareOrderComparator.sort(this.viewResolvers);
        this.cnmFactoryBean.setServletContext(servletContext);
    }

所以ContentNegotiatingViewResolver類的作用就是組合所有的視圖解析器，自動配置了ViewResolver(視圖解析器作用，根據方法返回值得到視圖對象view)

往下翻代碼，可以看到resolveViewName方法，裏面代碼是從this.viewResolvers獲取候選的視圖解析器，遍歷容器里所有視圖，然後通過如圖所標記的獲取候選視圖的方法，獲取候選的視圖列表，再通過getBestView獲取最合適的視圖

遍歷所有的視圖解析器對象，從視圖解析器里獲取候選的視圖，封裝成list保存

ok，跟了源碼就是只要將視圖解析器丟到Spring容器里，就可以加載到

寫個簡單的視圖解析類

DispatcherServlet是Spring核心分發器，找到doDispatch方法，debug，可以看到加的視圖解析器加載到了

2、靜態資源

也就是官方說的，如下圖所示：

翻譯過來就是支持靜態資源包括webjars的自動配置，webjars，就是以maven等等方式打成jar包的靜態資源，可以去看看文檔：

使用的話，直接去webjars官網負責對應的配置，加到項目里就可以

路徑都是在META-INF/webjars/**

WebMvcAutoConfiguration.addResourceHandlers，這個是比較重要的資源配置方法

@Override
        public void addResourceHandlers(ResourceHandlerRegistry registry) {
            if (!this.resourceProperties.isAddMappings()) {
                logger.debug("Default resource handling disabled");
                return;
            }
            Duration cachePeriod = this.resourceProperties.getCache().getPeriod();
            //CacheControl是Spring框架提供的http緩存
            CacheControl cacheControl = this.resourceProperties.getCache().getCachecontrol().toHttpCacheControl();
            //讀取到webjars資源，將classpath:/META-INF/resources/webjars/的webjars資源都掃描出來
            if (!registry.hasMappingForPattern("/webjars/**")) {
                customizeResourceHandlerRegistration(registry.addResourceHandler("/webjars/**")
                        .addResourceLocations("classpath:/META-INF/resources/webjars/")
                        .setCachePeriod(getSeconds(cachePeriod)).setCacheControl(cacheControl));
            }
            String staticPathPattern = this.mvcProperties.getStaticPathPattern();
            if (!registry.hasMappingForPattern(staticPathPattern)) {
                customizeResourceHandlerRegistration(registry.addResourceHandler(staticPathPattern)
                        .addResourceLocations(getResourceLocations(this.resourceProperties.getStaticLocations()))
                        .setCachePeriod(getSeconds(cachePeriod)).setCacheControl(cacheControl));
            }
        }

ok，通過源碼可以知道，Springboot支持webjars和其它等等靜態資源，其它的靜態資源要放在如下目錄里，Springboot就能自動加載到

  • classpath:/META-INF/resources/
  • classpath:/resources/
  • classpath:/static/
  • classpath:/public/
  • classpath:/

3、自動註冊 Converter, GenericConverter, and Formatter beans.

翻譯過來就是自動註冊了 Converter, GenericConverter, and Formatter beans.

  • Converter：轉換器 ，作用就是能自動進行類型轉換
    eg： public String hello(User user)，這是一個方法，然後前端視圖傳來的參數通過轉換器能夠根據屬性進行映射，然後進行屬性類型轉換
  • Formatter ：格式化器，eg：比如對前端傳來的日期2019/11/25，進行格式化處理

源碼在這裏，WebMvcAutoConfiguration.addFormatters方法是添加格式化器的方法

同理，也是從Spring容器里將這幾種類拿過來

當然，還有其它的，比如WebMvcAutoConfiguration.localeResolver方法是實現i18n國際化語言支持的自動配置

@Bean
        @ConditionalOnMissingBean//沒有自定義localeResolver的情況
        @ConditionalOnProperty(prefix = "spring.mvc", name = "locale")//application.properties有配置了spring.mvc.locale
        public LocaleResolver localeResolver() {
            if (this.mvcProperties.getLocaleResolver() == WebMvcProperties.LocaleResolver.FIXED) {
                return new FixedLocaleResolver(this.mvcProperties.getLocale());
            }
            //默認使用AcceptHeaderLocaleResolver 
            AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver();
            localeResolver.setDefaultLocale(this.mvcProperties.getLocale());
            return localeResolver;
        }

具體的源碼參考我之前博客：，博客裏面有涉及源碼的

4、支持HttpMessageConverters

HttpMessageConverters ：消息轉換器，Springmvc中用來轉換http請求和響應的

源碼里是通過configureMessageConverters方法實現，很顯然也是從容器里獲取的

官方文檔里也進行了比較詳細描述，Springboot已經為我們自動配置了json的、xml的自動轉換器，當然你也可以自己添加

5、支持MessageCodesResolver

MessageCodesResolver：是消息解析器，WebMvcAutoConfiguration.getMessageCodesResolver是實現Exception異常信息格式的

WebMvcProperties配置文件定義的一個異常枚舉值

格式為如圖所示，定了了錯誤代碼是生成規則：

6、首頁支持

Springboot默認的首頁是index.html，也就是你在classpath路徑丟個index.html文件，就被Springboot默認為首頁，或者說歡迎頁

如圖示代碼，就是遍歷靜態資源文件，然後獲取index.html作為歡迎頁面

7、網站logo設置

Springboot1.+版本，是有默認的logo圖標的，2.2.1版本，經過全局搜索，沒有發現給自定義的圖標，使用的話，是直接丟在classpath路徑，文件命名為favicon.ico，不過在2.2.1代碼並沒有找到相應的配置代碼，1.+版本是有的，不過文檔還是有描述了

8、ConfigurableWebBindingInitializer 初始綁定器

跟下源碼，也是從Spring容器里獲取的，然後注意到，如果沒有這個ConfigurableWebBindingInitializer ，代碼就會調用基類的getConfigurableWebBindingInitializer

源碼，這裏也是創建一個getConfigurableWebBindingInitializer

ConfigurableWebBindingInitializer 是Springboot為系統自動配置的，當然我們也可以自己定義一個ConfigurableWebBindingInitializer ，然後加載到容器里即可

初始化綁定的方法，ok，本博客簡單跟一下源碼

注意：
ok，Springboot官方文檔里還有這樣的描述，如圖所示

意思是，在使用webmvcConfigurer配置的時候，不要使用@EnableWebMvc註解，為什麼不要使用呢？因為使用了@EnableWebMvc，就是實現全面接管SpringMVC自動配置，也就是說其它的自動配置都會失效，全部自己配置

原理是為什麼？可以簡單跟一下源碼，如圖，SpringMVC自動配置類，有這個很關鍵的註解，這個註解的意思是@WebMvcConfigurationSupport註解不在系統時候自動配置才起效

然後為什麼加了@EnableWebMvc自動配置就可以被全面接管？點一下@EnableWebMvc源碼

很顯然，DelegatingWebMvcConfiguration類extends WebMvcConfigurationSupport類，所以這也就是為什麼@EnableWebMvc註解能實現全面接管自動配置的原理

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

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

js 關於apply和call的理解使用

admin

　　關於call和apply，以前也思考良久，很多時候都以為記住了，但是，我太難了。今天我特地寫下筆記，希望可以完全掌握這個東西，也希望可以幫助到任何想對學習這個東西的同學。

一.apply函數定義與理解，先從apply函數出發

　　在MDN上，apply的定義是：

　　　　“apply()方法調用一個具有給定this值的函數，以及作為一個數組（或）提供的參數。”

　　我的理解是：apply的前面有個含有this的對象，設為A，apply()的參數里，也含有一個含有this的對象設為B。則A.apply(B)，表示A代碼執行調用了B，B代碼照常執行，執行后的結果作為apply的參數，然後apply把這個結果所指代表示的this替換掉A本身的this，接着執行A代碼。

　　比如：

 1     var aa = {
 2         _name:111,
 3         _age:222,
 4         _f:function(){
 5             console.log(this)
 6             console.log(this._name)
 7         }
 8     }
 9     var cc = {
10         _name:0,
11         _age:0,
12         _f:function(){
13             console.log(this)
14             console.log(this._name)
15         }
16     }
17     cc._f.apply(aa)//此時aa表示的this就是aa本身
18     cc._f.apply(aa._f)//此時aa._f表示的this就是aa._f本身
19     
20     /**
21      * 此時aa._f()表示的this，就是執行后的結果本身。aa._f()執行后，沒有返回值，所以應該是undefined，而undefined作為call和apply的參數時，call和apply前面的方法 cc._f 的this會替換成全局對象window。
22      * 參考MDN：https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Function/apply 的參數說明
23      */
24     cc._f.apply(aa._f())

執行結果：

　　1.參數為aa

　　

　　這兩行的打印的都是來自 cc._f 方法內的那兩句console 。aa的時候算是初始化，裏面的 aa._f 方法沒有執行。

　　2.參數為aa.f

　　

　　這兩行的打印的都是來自 cc._f 方法內的那兩句console 。aa.f 的時候應該也算是初始化，或者是整個函數當參數傳但是不執行這個參數，即 aa._f 方法沒有執行。

　　3.參數為aa.f()

 　　

　　這四行的打印，前面兩行來自 aa._f() 方法執行打印的；後面兩行是來自cc._f()方法打印的。

　　后兩行解析：aa._f()執行后，沒有返回值，所以是undefined，在apply執行解析后，cc._f()的this變成的window，所以打印了window。window裏面沒有_name這個屬性，所以undefined。

 二.apply與call的區分

　　1.apply()

　　　　A.apply(B, [1,2,3]) 後面的參數是arguments對象或類似數組的對象，它會被自動解析為A的參數；

　　　　對於A.apply(B) / A.call(B) , 簡單講，B先執行，執行后根據結果去執行A。這個時候，用A去執行B的內容代碼，然後再執行自己的代碼。

　　比如：

    var f1 = function(a,b){
        console.log(a+b)
    }
    var f2 = function(a,b,c){
        console.log(a,b,c)
    }
    f2.apply(f1,[1,2])//1 2 undefined

 　　先執行f1，f1執行后（f1是f1，不是f1()執行方法，所以console.log(a+b)這行代碼並沒有執行，相當於，初始化了代碼f1），由於沒有返回值，所以結果是undefined，f2執行的時候this指向window；參數中的 ” [1,2] “，解析后變成 f2 的參數 “ 1,2，undefined ”，執行f2方法后，打印出1,2，undefined三個值

　　2.call()

　　　　A.call(B, 1,2,3) 後面的參數都是獨立的參數對象，它們會被自動解析為A的參數；

　　比如：　

    var f1 = function(a,b){
        console.log(a+b)
    }
    var f2 = function(a,b,c){
        console.log(a,b,c)
    }
    f2.call(f1,[1,2])//[1,2] undefined undefined
    f2.call(f1,1,2)//1 2 undefined

 　　參數中的 ” [1,2] “，因為傳入了一個數組，相當於只傳入了第一個參數，b和c參數沒有傳。解析后變成 f2 的參數 “ [1,2]，undefined ，undefined ”，執行f2方法后，打印出 [1,2]，undefined ，undefined 三個值。

三.apply與call帶來的便利

　　1. push();

　　push參數是類似(a,b,c,d,e)如此傳輸的，如果在一個數組的基礎上進行傳輸另一個數組的內容，可以如下：

    //apply用法
    var arr = new Array(1,2,3)
    var arr1 = new Array(11,21,31)
    Array.prototype.push.apply(arr,arr1)
    console.log(arr)//[1, 2, 3, 11, 21, 31]
    
    //call用法
    var arr = new Array(1,2,3)
    var arr1 = new Array(11,21,31)
    Array.prototype.push.call(arr,arr1[0],arr1[1],arr1[2])
    console.log(arr)//[1, 2, 3, 11, 21, 31]

 　　2. 數組利用Math求最大和最小值

　　apply和call的第一個參數，如果是null或者undefined，則apply或call前面的函數會把this指向window

    //apply的用法
    var _maxNum = Math.max.apply(null,[1,3,2,4,5])
    console.log(_maxNum)//5
    var _minNum = Math.min.apply(null,[1,3,2,4,5])
    console.log(_minNum)//1
    
    //call的用法
    var _maxNum = Math.max.call(null,1,3,2,4,5)
    console.log(_maxNum)//5
    var _minNum = Math.min.call(null,1,3,2,4,5)
    console.log(_minNum)//1

 四.總結

　　簡而言之，apply和call函數的第一個參數都是用來替換this指向的對象；apply的第二個參數使用arguments或者類似數組的參數進行傳參，call的第二個或以上的參數，使用獨立單位，一個一個進行傳參；執行順序是apply或call的第一個參數先執行得到結果，然後執行apply或call前面的函數，執行的時候用已經執行的結果所指代的this去執行。apply和call的使用除了參數上的使用方式不同外，功能是一模一樣的。

　　以上內容純屬個人理解，有誤勿噴請指出！謝謝！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

※收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品在網路上成為最夯、最多人討論的話題?

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

【集合系列】- 深入淺出的分析IdentityHashMap

admin

一、摘要

在集合系列的第一章，咱們了解到，Map 的實現類有 HashMap、LinkedHashMap、TreeMap、IdentityHashMap、WeakHashMap、Hashtable、Properties等等。

應該有很多人不知道 IdentityHashMap 的存在，其中不乏工作很多年的 Java 開發者，本文主要從數據結構和算法層面，探討 IdentityHashMap 的實現。

二、簡介

IdentityHashMap 的數據結構很簡單，底層實際就是一個 Object 數組，但是在存儲上並沒有使用鏈表來存儲，而是將 K 和 V 都存放在 Object 數組上。

當添加元素的時候，會根據 Key 計算得到散列位置，如果發現該位置上已經有改元素，直接進行新值替換；如果沒有，直接進行存放。當元素個數達到一定閾值時，Object 數組會自動進行擴容處理。

打開 IdentityHashMap 的源碼，可以看到 IdentityHashMap 繼承了AbstractMap 抽象類，實現了Map接口、可序列化接口、可克隆接口。

public class IdentityHashMap<K,V>
    extends AbstractMap<K,V>
    implements Map<K,V>, java.io.Serializable, Cloneable
{
    /**默認容量大小*/
    private static final int DEFAULT_CAPACITY = 32;
    
    /**最小容量*/
    private static final int MINIMUM_CAPACITY = 4;
    
    /**最大容量*/
    private static final int MAXIMUM_CAPACITY = 1 << 29;
    
    /**用於存儲實際元素的表*/
    transient Object[] table;
    
    /**數組大小*/
    int size;

    /**對Map進行結構性修改的次數*/
    transient int modCount;

    /**key為null所對應的值*/
    static final Object NULL_KEY = new Object();
    
    ......
}

可以看到類的底層，使用了一個 Object 數組來存放元素；在對象初始化時，IdentityHashMap 容量大小為64；

public IdentityHashMap() {
        //調用初始化方法
        init(DEFAULT_CAPACITY);
}
private void init(int initCapacity) {
        //數組大小默認為初始化容量的2倍
        table = new Object[2 * initCapacity];
}

三、常用方法介紹

3.1、put方法

put 方法是將指定的 key, value 對添加到 map 里。該方法首先會對map做一次查找，通過==判斷是否存在key，如果有，則將舊value返回，將新value覆蓋舊value；如果沒有，直接插入，數組長度+1，返回null。

源碼如下：

public V put(K key, V value) {
        //判斷key是否為空，如果為空，初始化一個Object為key
        final Object k = maskNull(key);

        retryAfterResize: for (;;) {
            final Object[] tab = table;
            final int len = tab.length;
            //通過key、length獲取數組小編
            int i = hash(k, len);
            
            //循環遍歷是否存在指定的key
            for (Object item; (item = tab[i]) != null;
                 i = nextKeyIndex(i, len)) {
                 //通過==判斷，是否數組中是否存在key
                if (item == k) {
                        V oldValue = (V) tab[i + 1];
                        //新value覆蓋舊value
                    tab[i + 1] = value;
                    //返回舊value
                    return oldValue;
                }
            }
            
            //數組長度 +1
            final int s = size + 1;
            //判斷是否需要擴容
            if (s + (s << 1) > len && resize(len))
                continue retryAfterResize;

            //更新修改次數
            modCount++;
            //將k加入數組
            tab[i] = k;
            //將value加入數組
            tab[i + 1] = value;
            size = s;
            return null;
        }
}

maskNull 函數，判斷 key 是否為空

private static Object maskNull(Object key) {
        return (key == null ? NULL_KEY : key);
}

hash 函數，通過 key 獲取 hash 值，結合數組長度通過位運算獲取數組散列下標

private static int hash(Object x, int length) {
        int h = System.identityHashCode(x);
        // Multiply by -127, and left-shift to use least bit as part of hash
        return ((h << 1) - (h << 8)) & (length - 1);
}

nextKeyIndex 函數，通過 hash 函數計算得到的數組散列下標，進行加2；因為一個 key、value 都存放在數組中，所以一個 map 對象佔用兩個數組下標，所以加2。

private static int nextKeyIndex(int i, int len) {
        return (i + 2 < len ? i + 2 : 0);
}

resize 函數，通過數組長度，進行擴容處理，擴容之後的長度為當前長度的2倍

private boolean resize(int newCapacity) {
        //擴容后的數組長度，為當前數組長度的2倍
        int newLength = newCapacity * 2;

        Object[] oldTable = table;
        int oldLength = oldTable.length;
        if (oldLength == 2 * MAXIMUM_CAPACITY) { // can't expand any further
            if (size == MAXIMUM_CAPACITY - 1)
                throw new IllegalStateException("Capacity exhausted.");
            return false;
        }
        if (oldLength >= newLength)
            return false;

        Object[] newTable = new Object[newLength];
        //將舊數組內容轉移到新數組
        for (int j = 0; j < oldLength; j += 2) {
            Object key = oldTable[j];
            if (key != null) {
                Object value = oldTable[j+1];
                oldTable[j] = null;
                oldTable[j+1] = null;
                int i = hash(key, newLength);
                while (newTable[i] != null)
                    i = nextKeyIndex(i, newLength);
                newTable[i] = key;
                newTable[i + 1] = value;
            }
        }
        table = newTable;
        return true;
}

3.2、get方法

get 方法根據指定的 key 值返回對應的 value。同樣的，該方法會循環遍曆數組，通過==判斷是否存在key，如果有，直接返回value，因為 key、value 是相鄰的存儲在數組中，所以直接在當前數組下標+1，即可獲取 value；如果沒有找到，直接返回null。

值得注意的地方是，在循環遍歷中，是通過==判斷當前元素是否與key相同，如果相同，則返回value。咱們都知道，在 java 中，==對於對象類型參數，判斷的是引用地址，確切的說，是堆內存地址，所以，這裏判斷的是key的引用地址是否相同，如果相同，則返回對應的 value；如果不相同，則返回null。

源碼如下：

public V get(Object key) {
        Object k = maskNull(key);
        Object[] tab = table;
        int len = tab.length;
        int i = hash(k, len);
        
        //循環遍曆數組，直到找到key或者，數組為空為值
        while (true) {
            Object item = tab[i];
            //通過==判斷，當前數組元素與key相同
            if (item == k)
                return (V) tab[i + 1];
            //數組為空
            if (item == null)
                return null;
            i = nextKeyIndex(i, len);
        }
}

3.3、remove方法

remove 的作用是通過 key 刪除對應的元素。該方法會循環遍曆數組，通過==判斷是否存在key，如果有，直接將key、value設置為null，對數組進行重新排列，返回舊 value。

源碼如下：

public V remove(Object key) {
        Object k = maskNull(key);
        Object[] tab = table;
        int len = tab.length;
        int i = hash(k, len);

        while (true) {
            Object item = tab[i];
            if (item == k) {
                modCount++;
                //數組長度減1
                size--;
                    V oldValue = (V) tab[i + 1];
                //將key、value設置為null
                tab[i + 1] = null;
                tab[i] = null;
                //刪除該元素后，需要把原來有衝突往後移的元素移到前面來
                closeDeletion(i);
                return oldValue;
            }
            if (item == null)
                return null;
            i = nextKeyIndex(i, len);
        }
}

closeDeletion 函數，刪除該元素后，需要把原來有衝突往後移的元素移到前面來，對數組進行重寫排列；

private void closeDeletion(int d) {
        // Adapted from Knuth Section 6.4 Algorithm R
        Object[] tab = table;
        int len = tab.length;

        Object item;
        for (int i = nextKeyIndex(d, len); (item = tab[i]) != null;
             i = nextKeyIndex(i, len) ) {
            int r = hash(item, len);
            if ((i < r && (r <= d || d <= i)) || (r <= d && d <= i)) {
                tab[d] = item;
                tab[d + 1] = tab[i + 1];
                tab[i] = null;
                tab[i + 1] = null;
                d = i;
            }
        }
}

四、總結

  1. IdentityHashMap 的實現不同於HashMap，雖然也是數組，不過IdentityHashMap中沒有用到鏈表，解決衝突的方式是計算下一個有效索引，並且將數據key和value緊挨着存在map中，即table[i]=key、table[i+1]=value；

  2. IdentityHashMap 允許key、value都為null，當key為null的時候，默認會初始化一個Object對象作為key；

  3. IdentityHashMap在保存、刪除、查詢數據的時候，以key為索引，通過==來判斷數組中元素是否與key相同，本質判斷的是對象的引用地址，如果引用地址相同，那麼在插入的時候，會將value值進行替換；

IdentityHashMap 測試例子：

public static void main(String[] args) {
        Map<String, String> identityMaps = new IdentityHashMap<String, String>();

        identityMaps.put(new String("aa"), "aa");
        identityMaps.put(new String("aa"), "bb");
        identityMaps.put(new String("aa"), "cc");
        identityMaps.put(new String("aa"), "cc");
        //輸出添加的元素
        System.out.println("數組長度："+identityMaps.size() + "，輸出結果：" + identityMaps);
    }

輸出結果：

數組長度：4，輸出結果：{aa=aa, aa=cc, aa=bb, aa=cc}

儘管key的內容是一樣的，但是key的堆地址都不一樣，所以在插入的時候，插入了4條記錄。

五、參考

1、JDK1.7&JDK1.8 源碼

2、

3、

作者：炸雞可樂
出處：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

面試官：你連RESTful都不知道我怎麼敢要你？

admin

目錄

面試官：了解RESTful嗎？

我：聽說過。

面試官：那什麼是RESTful？

我：就是用起來很規範，挺好的

面試官：是RESTful挺好的，還是自我感覺挺好的

我：都挺好的。

面試官：… 把門關上。

我：…. 要幹嘛？先關上再說。

面試官：我說出去把門關上。

我：what ？，奪門而去

@

01 前言

回歸正題，看過很多RESTful相關的文章總結，參齊不齊，結合工作中的使用，非常有必要歸納一下關於RESTful架構方式了，RESTful只是一種架構方式的約束，給出一種約定的標準，完全嚴格遵守RESTful標準並不是很多，也沒有必要。但是在實際運用中，有RESTful標準可以參考，是十分有必要的。

實際上在工作中對api接口規範、命名規則、返回值、授權驗證等進行一定的約束，一般的項目api只要易測試、足夠安全、風格一致可讀性強、沒有歧義調用方便我覺得已經足夠了，接口是給開發人員看的，也不是給普通用戶去調用。

02 RESTful的來源

REST：Representational State Transfer（表象層狀態轉變），如果沒聽說過REST，你一定以為是rest這個單詞，剛開始我也是這樣認為的，後來發現是這三個單詞的縮寫，即使知道了這三個單詞理解起來仍然非常晦澀難懂。如何理解RESTful架構，最好的辦法就是深刻理解消化Representational State Transfer這三個單詞到底意味着什麼。

1.每一個URI代表一種資源；

2.客戶端和服務器之間，傳遞這種資源的某種表現層；

3.客戶端通過四個HTTP動詞（get、post、put、delete），對服務器端資源進行操作，實現”表現層狀態轉化”。

是由美國計算機科學家Roy Fielding（百度百科沒有介紹，真是尷尬了）。Adobe首席科學家、Http協議的首要作者之一、Apache項目聯合創始人。

03 RESTful6大原則

REST之父Roy Fielding在論文中闡述REST架構的6大原則。

1. C-S架構

數據的存儲在Server端，Client端只需使用就行。兩端徹底分離的好處使client端代碼的可移植性變強，Server端的拓展性變強。兩端單獨開發，互不干擾。

2. 無狀態

http請求本身就是無狀態的，基於C-S架構，客戶端的每一次請求帶有充分的信息能夠讓服務端識別。請求所需的一些信息都包含在URL的查詢參數、header、body，服務端能夠根據請求的各種參數，無需保存客戶端的狀態，將響應正確返回給客戶端。無狀態的特徵大大提高的服務端的健壯性和可拓展性。

當然這總無狀態性的約束也是有缺點的，客戶端的每一次請求都必須帶上相同重複的信息確定自己的身份和狀態（這也是必須的），造成傳輸數據的冗餘性，但這種確定對於性能和使用來說，幾乎是忽略不計的。

3.統一的接口

這個才是REST架構的核心，統一的接口對於RESTful服務非常重要。客戶端只需要關注實現接口就可以，接口的可讀性加強，使用人員方便調用。

4.一致的數據格式

服務端返回的數據格式要麼是XML，要麼是Json（獲取數據），或者直接返回狀態碼，有興趣的可以看看博客園的開放平台的操作數據的api，post、put、patch都是返回的一個狀態碼 。

自我描述的信息，每項數據應該是可以自我描述的，方便代碼去處理和解析其中的內容。比如通過HTTP返回的數據裏面有 [MIME type ]信息，我們從MIME type裏面可以知道數據的具體格式，是圖片，視頻還是JSON，客戶端通過body內容、查詢串參數、請求頭和URI（資源名稱）來傳送狀態。服務端通過body內容，響應碼和響應頭傳送狀態給客戶端。這項技術被稱為超媒體（或超文本鏈接）。

除了上述內容外，HATEOS也意味着，必要的時候鏈接也可被包含在返回的body（或頭部）中，以提供URI來檢索對象本身或關聯對象。下文將對此進行更詳細的闡述。

如請求一條微博信息，服務端響應信息應該包含這條微博相關的其他URL，客戶端可以進一步利用這些URL發起請求獲取感興趣的信息，再如分頁可以從第一頁的返回數據中獲取下一頁的URT也是基於這個原理。

4.系統分層

客戶端通常無法表明自己是直接還是間接與端服務器進行連接，分層時同樣要考慮安全策略。

5.可緩存

在萬維網上，客戶端可以緩存頁面的響應內容。因此響應都應隱式或顯式的定義為可緩存的，若不可緩存則要避免客戶端在多次請求後用舊數據或臟數據來響應。管理得當的緩存會部分地或完全地除去客戶端和服務端之間的交互，進一步改善性能和延展性。

6.按需編碼、可定製代碼（可選）

服務端可選擇臨時給客戶端下發一些功能代碼讓客戶端來執行，從而定製和擴展客戶端的某些功能。比如服務端可以返回一些 Javascript 代碼讓客戶端執行，去實現某些特定的功能。
提示：REST架構中的設計準則中，只有按需編碼為可選項。如果某個服務違反了其他任意一項準則，嚴格意思上不能稱之為RESTful風格。

03 RESTful的7個最佳實踐

1. 版本

如github開放平台
https://developer.github.com/v3/

就是將版本放在url，簡潔明了，這個只有用了才知道，一般的項目加版本v1，v2，v3?好吧，這個加版本估計只有大公司大項目才會去使用，說出來不怕尷尬，我真沒用過。有的會將版本號放在header裏面，但是不如url直接了當。

https://example.com/api/v1/

2.參數命名規範

query parameter可以採用駝峰命名法，也可以採用下劃線命名的方式，推薦採用下劃線命名的方式，據說後者比前者的識別度要高，可能是用的人多了吧，因人而異，因團隊規範而異吧。

https://example.com/api/users/today_login 獲取今天登陸的用戶 
https://example.com/api/users/today_login&sort=login_desc 獲取今天登陸的用戶、登陸時間降序排列

3.url命名規範

API 命名應該採用約定俗成的方式，保持簡潔明了。在RESTful架構中，每個url代表一種資源所以url中不能有動詞，只能有名詞，並且名詞中也應該使用複數。實現者應使用相應的Http動詞GET、POST、PUT、PATCH、DELETE、HEAD來操作這些資源即可

不規範的的url，冗餘沒有意義，形式不固定，不同的開發者還需要了解文檔才能調用。

https://example.com/api/getallUsers GET 獲取所有用戶 
https://example.com/api/getuser/1 GET 獲取標識為1用戶信息 
https://example.com/api/user/delete/1 GET/POST 刪除標識為1用戶信息 
https://example.com/api/updateUser/1 POST 更新標識為1用戶信息 
https://example.com/api/User/add POST 添加新的用戶

規範后的RESTful風格的url，形式固定，可讀性強，根據users名詞和http動詞就可以操作這些資源

https://example.com/api/users GET 獲取所有用戶信息 
https://example.com/api/users/1 GET 獲取標識為1用戶信息 
https://example.com/api/users/1 DELETE 刪除標識為1用戶信息 
https://example.com/api/users/1 Patch 更新標識為1用戶部分信息,包含在body中 
https://example.com/api/users POST 添加新的用戶

4. 統一返回數據格式

對於合法的請求應該統一返回數據格式，這裏演示的是json

  • code——包含一個整數類型的HTTP響應狀態碼。
  • status——包含文本：”success”，”fail”或”error”。HTTP狀態響應碼在500-599之間為”fail”，在400-499之間為”error”，其它均為”success”（例如：響應狀態碼為1XX、2XX和3XX）。這個根據實際情況其實是可要可不要的。
  • message——當狀態值為”fail”和”error”時有效，用於显示錯誤信息。參照國際化（il8n）標準，它可以包含信息號或者編碼，可以只包含其中一個，或者同時包含並用分隔符隔開。
  • data——包含響應的body。當狀態值為”fail”或”error”時，data僅包含錯誤原因或異常名稱、或者null也是可以的

返回成功的響應json格式

{
  "code": 200,
  "message": "success",
  "data": {
    "userName": "123456",
    "age": 16,
    "address": "beijing"
  }
}

返回失敗的響應json格式

{
  "code": 401,
  "message": "error  message",
  "data": null
}

下面這個ApiResult的泛型類是在項目中用到的，拓展性強，使用方便。返回值使用統一的 ApiResult 或 ApiResult
錯誤返回 使用 ApiResult.Error 進行返回； 成功返回，要求使用 ApiResult.Ok 進行返回

public class ApiResult: ApiResult
    {
        public new static ApiResult<T> Error(string message)
        {
            return new ApiResult<T>
            {
                Code = 1,
                Message = message,
            };
        }
        [JsonProperty("data")]
        public T Data { get; set; }
    }
    public class ApiResult
    {
        public static ApiResult Error(string message)
        {
            return new ApiResult
            {
                Code = 1,
                Message = message,
            };
        }

        public static ApiResult<T> Ok<T>(T data)
        {
            return new ApiResult<T>()
            {
                Code = 0,
                Message = "",
                Data = data
            };
        }
        /// <summary>
        /// 0 是 正常 1 是有錯誤
        /// </summary>
        [JsonProperty("code")]
        public int Code { get; set; }
        [JsonProperty("msg")]
        public string Message { get; set; }

        [JsonIgnore]
        public bool IsSuccess => Code == 0;
    }

5. http狀態碼

在之前開發的xamarin android博客園客戶端的時候，patch、delete、post操作時body響應裏面沒有任何信息，僅僅只有http status code。HTTP狀態碼本身就有足夠的含義，根據http status code就可以知道刪除、添加、修改等是否成功。(ps:有點linux設計的味道哦，沒有返回消息就是最好的消息，表示已經成功了)服務段向用戶返回這些狀態碼並不是一個強制性的約束。簡單點說你可以指定這些狀態，但是不是強制的。常用HTTP狀態碼對照表
HTTP狀態碼也是有規律的

  • 1**請求未成功
  • 2**請求成功、表示成功處理了請求的狀態代碼。
  • 3**請求被重定向、表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向。
  • 4** 請求錯誤這些狀態代碼錶示請求可能出錯，妨礙了服務器的處理。

  • 5**（服務器錯誤）這些狀態代碼錶示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。

    6. 合理使用query parameter

    在請求數據時，客戶端經常會對數據進行過濾和分頁等要求，而這些參數推薦採用HTTP Query Parameter的方式實現

比如設計一個最近登陸的所有用戶
https://example.com/api/users?recently_login_day=3
搜索用戶，並按照註冊時間降序
https://example.com/api/users?recently_login_day=3
搜索用戶，並按照註冊時間升序、活躍度降序
https://example.com/api/users?q=key&sort=create_title_asc,liveness_desc
關於分頁，看看博客園開放平台分頁獲取精華區博文列表
https://api.cnblogs.com/api/blogposts/@picked?pageIndex={pageIndex}&pageSize={pageSize} 
返回示例： 
[ 
{ 
“Id”: 1, 
“Title”: “sample string 2”, 
“Url”: “sample string 3”, 
“Description”: “sample string 4”, 
“Author”: “sample string 5”, 
“BlogApp”: “sample string 6”, 
“Avatar”: “sample string 7”, 
“PostDate”: “2017-06-25T20:13:38.892135+08:00”, 
“ViewCount”: 9, 
“CommentCount”: 10, 
“DiggCount”: 11 
}, 
{ 
“Id”: 1, 
“Title”: “sample string 2”, 
“Url”: “sample string 3”, 
“Description”: “sample string 4”, 
“Author”: “sample string 5”, 
“BlogApp”: “sample string 6”, 
“Avatar”: “sample string 7”, 
“PostDate”: “2017-06-25T20:13:38.892135+08:00”, 
“ViewCount”: 9, 
“CommentCount”: 10, 
“DiggCount”: 11 
} 
]

7. 多表、多參數連接查詢如何設計URL

這是一個比較頭痛的問題，在做單個實體的查詢比較容易和規範操作，但是在實際的API並不是這麼簡單而已，這其中常常會設計到多表連接、多條件篩選、排序等。
比如我想查詢一個獲取在6月份的訂單中大於500元的且用戶地址是北京，用戶年齡在22歲到40歲、購買金額降序排列的訂單列表

https://example.com/api/orders?order_month=6&order_amount_greater=500&address_city=北京&sort=order_amount_desc&age_min=22&age_max=40

從這個URL上看，參數眾多、調用起來還得一個一個仔細對着，而且API本身非常不容易維護，命名看起來不是很容易，不能太長，也不能太隨意。

在.net WebAPI總我們可以使用屬性路由，屬性路由就是講路由附加到特定的控制器或操作方法上裝飾Controll及其使用[Route]屬性定義路由的方法稱為屬性路由。

這種好處就是可以精準地控制URL，而不是基於約定的路由，簡直就是為這種多表查詢量身定製似的的。 從webapi 2開發，現在是RESTful API開發中最推薦的路由類型。
我們可以在Controll中標記Route

[Route(“api/orders/{address}/{month}”)]

Action中的查詢參數就只有金額、排序、年齡。減少了查詢參數、API的可讀性和可維護行增強了。

https://example.com/api/orders/beijing/6?order_amount_greater=500&sort=order_amount_desc&age_min=22&age_max=40

這種屬性路由比如在博客園開放的API也有這方面的應用，如獲取個人博客隨筆列表

請求方式：GET 
請求地址：https://api.cnblogs.com/api/blogs/{blogApp}/posts?pageIndex={pageIndex} 
(ps:blogApp：博客名)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

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

※賣IPHONE,iPhone回收,舊換新!教你怎麼賣才划算?

小白理解安卓虛擬機以及華為的’諾亞方舟’

admin

虛擬機，提到虛擬機，大家可能第一反應就是java中好像有虛擬機這個玩意。但是安卓中的虛擬機是什麼呢？是和java一樣的嗎？那麼我們先來了解一下java中的JVM！

JVM，搞java的肯定對它了解不少。JVM本質上就是一個軟件，是計算機硬件的一層軟件抽象，在這之上才幹夠運行Java程序，JAVA在編譯後會生成相似於彙編語言的JVM字節碼，與C語言編譯后產生的彙編語言不同的是，C編譯成的彙編語言會直接在硬件上跑。但JAVA編譯後生成的字節碼是在JVM上跑，須要由JVM把字節碼翻譯成機器指令。才幹使JAVA程序跑起來。JVM運行在操作系統上，屏蔽了底層實現的差異。從而有了JAVA吹噓的平台獨立性和Write Once Run Anywhere。依據JVM規範實現的詳細虛擬機有幾十種，主流的JVM包括Hotspot、Jikes RVM等。都是用C/C++和彙編編寫的，每一個JRE編譯的時候針對每一個平台編譯。因此下載JRE（JVM、Java核心類庫和支持文件）的時候是分平台的，JVM的作用是把平台無關的.class裏面的字節碼翻譯成平台相關的機器碼，來實現跨平台。

說白了，簡單點，就是：

                                                                      Java

                                                                      .java文件 -> .class文件 -> .jar文件

最後執行是class文件，有的會被再次打包成jar文件。

了解了這些之後，我們再去了解Android 中的虛擬機。

一、Dalvik虛擬機

Dalvik虛擬機（ Dalvik Virtual Machine ），簡稱Dalvik VM或者DVM。這就是Android中的虛擬機。最初它的產生，是因為Google為了解決與Oracle之間關於Java相關專利和授權的糾紛，開發了DVM。

Android既然存在虛擬機，肯定也是在這個DVM上執行的。它的執行流程和JVM很像：

                                                                       Android

                                                                      .java文件 –> .class文件 -> .dex文件->.apk

DVM執行的是.dex格式文件，JVM執行的是.class文件，android程序編譯完之後生產.class文件，然後，dex工具會把.class文件處理成.dex文件，然後把資源文件和.dex文件等打包成.apk文件，apk就是android package的意思。

除了上面所說的，專利授權的原因除外，其實還有因為如下原因：

    dvm是基於寄存器的虛擬機，而jvm是基於虛擬棧的虛擬機。寄存器存取速度比棧快得多，dvm可以根據硬件實現最大的優化，比較適合移動設備。

    class文件存在很多的冗餘信息，dex工具會去除冗餘信息，並把所有的.class文件整合到.dex文件中，減少了I/O操作，提高了類的查找速度。

不光是上面這些差異，還有運行環境。 　

   Dalvik : 一個應用啟動都運行一個單獨的虛擬機運行在一個單獨的進程中

   JVM: 只能運行一個實例, 也就是所有應用都運行在同一個JVM中

 

 這個是早先的安卓虛擬機，運行速度還是相當慢的。基於寄存器的虛擬機允許更快的執行時間，但代價是編譯后的程序更大。於是新的Dex字節碼格式odex產生了。它的作用等同於dex，只不過是dex優化后的格式。在App安裝的過程中，會通過Socket向/system/bin/install進程發送dex_opt的指令，對Dex文件進行優化。在DexClassLoader動態加載Dex文件時，也會進行Dex的優化，形成odex文件。

 

為了適應硬件速度的提升，隨後在Android 2.2的DVM中加入了JIT 編譯器（Just-In-Time Compiler）。Dalvik 使用 JIT 進行即時編譯，藉助 Java HotSpot VM，JIT 編譯器可以對執行次數頻繁的 dex/odex 代碼進行編譯與優化，將 dex/odex 中的 Dalvik Code（Smali 指令集）翻譯成相當精簡的 Native Code 去執行，JIT 的引入使得 Dalvik 的性能提升了 3~6 倍。

JIT編譯器的引入，提升了安裝速度，減少了佔用的空間，但隨之帶來的問題就是：多個dex加載會非常慢；JIT中的解釋器解釋的字節碼會帶來CPU和時間的消耗；還有熱點代碼的Monitor一直在運行帶來電量的損耗。

 

 這種情況下，手機動不動就卡是難以避免的。相信各位如果那時候用着Android手機，一定印象非常深刻。因為並不是那麼好用。

這樣的狀況一直持續到Andorid 4.4，帶來了全新的虛擬機運行環境 ART（Android RunTime）的預覽版和全新的編譯策略 AOT（Ahead-of-time）。但那時候。 ART 是和 Dalvik 共存的，用戶可以在兩者之間進行選擇（感覺很奇怪，作為一個愛好者，我當時看到這個東西可以切換都是不曉得是什麼玩意，用戶可都是小白啊，沒有必要共存的吧）。在Android 5.0的時候，ART 全面取代 Dalvik 成為 Android 虛擬機運行環境，至此。Dalvik 退出歷史舞台，AOT 也成為唯一的編譯模式。

二、ART 

AOT 和 JIT 的不同之處在於：JIT 是在運行時進行編譯，是動態編譯，並且每次運行程序的時候都需要對 odex 重新進行編譯；而 AOT 是靜態編譯，應用在安裝的時候會啟動 dex2oat 通過靜態編譯的方式，來將所有的dex文件(包括Multidex)編譯oat文件，編譯完后的oat其實是一個標準的ELF文件，只是相對於普通的ELF文件多加了oat data section以及oat exec section這兩個段而已。(這兩個段裏面主要保存了兩種信息：Dex的文件信息以及類信息和Dex文件編譯之後的機器碼)。預編譯成 ELF 文件，每次運行程序的時候不用重新編譯，是真正意義上的本地應用。運行的文件格式也從odex轉換成了oat格式。

 

其實在Android5.0的時候我們能夠明顯感覺手機好用很多就是因為這個原因，從根本上換掉了那種存在着無法解決弊端的虛擬機。在 Android 5.x 和 6.x 的機器上，系統每次 OTA 升級完成重啟的時候都會有個應用優化的過程，這個過程就是剛才所說的 dex2oat 過程，這個過程比較耗時並且會佔用額外的存儲空間。

AOT 模式的預編譯解決了應用啟動和運行速度和耗資源(電等)問題的同時也帶來了另外兩個問題：

      1、應用安裝和系統升級之後的應用優化比較耗時，並且會更耗時間。因為系統和apk都是越來越大的。

      2、優化后的文件會佔用額外的存儲空間

在經過了兩個Android大版本的穩定后，在Android7.0又再次迎來了JIT的 回歸。

JIT的回歸，可不是把AOT模式給取代了，而是形成 了AOT/JIT 混合編譯模式，這種模式至今仍在使用。

應用在安裝的時候 dex 不會被編譯。

應用在運行時 dex 文件先通過解析器（Interpreter）後會被直接執行（這一步驟跟 Android 2.2 – Android 4.4之前的行為一致），與此同時，熱點函數（Hot Code）會被識別並被 JIT 編譯后存儲在 jit code cache 中並生成 profile 文件以記錄熱點函數的信息。

手機進入 IDLE（空閑） 或者 Charging（充電） 狀態的時候，系統會掃描 App 目錄下的 profile 文件並執行 AOT 過程進行編譯。

（Profile文件會在JIT運行的過程中生成：每個APP都會有自己的Profile文件，保存在App本身的Local Storage中。Profile會保存所調用的類以及函數的Index，通過profman工具進行分析生成）

 

 

個人理解：哪種模式擅長干什麼就讓他去干什麼。

混合編譯模式綜合了 AOT 和 JIT 的各種優點，使得應用在安裝速度加快的同時，運行速度、存儲空間和耗電量等指標都得到了優化。

之前一直在說流暢，真的流暢在Android7.0上才感受到了些許。Android7.0系統也被用了相當長的一段時間。之後的Android8.0和Android9.0都是對各方面的優化，例如編譯文件、編譯器、GC。。

其中，值得一提的是華為的方舟編譯器。

  • 首先會判斷該設備支不支持方舟編譯器，如果支持，則從應用商店下發方舟版本的包
  • 方舟編譯器會把dex文件通過自己的IR翻譯方舟格式的機器碼，據資料說也是一個ELF文件，但是會增加一些段，猜測是Dex中類信息相關的段
  • 通過這種方式，來消除Java與JNI之間的通信的損耗，以及提升運行時的效率
  • 在方舟內部，還重新完善了GC算法，使得GC的頻率大大降低，減少應用卡頓的現象
  • 目前方舟只支持64位的So，並且對於加殼的So會出現一些問題。

方舟編譯器適配的應用，下載手機上都是方舟版本的包，特製的包用方舟編譯器編譯效率大大提升，之後直接執行就可以了，直接略過了在ART虛擬機上預編譯的過程。這樣的結果是很完美的，但是卻也沒辦法跳過一個弊端。那就是生態。還是不管是安卓還是iOS，這麼多年的時間沉澱中，他們的生態系統早就達到了一個非常完善的地步。安卓和iOS應用已經多達上千萬，而方舟適配應用的數量還非常有限。

谷歌宣布將停止對華為提供安卓系統更新之後，華為曝光了自主研發的鴻蒙操作系統。當時網友各種力挺。不過後來，華為董事長梁華在談及鴻蒙系統時稱，鴻蒙系統是為物聯網開發的，用於自動駕駛、遠程醫療等低時延場景。鴻蒙系統是不是兩手準備我們不得而知。但是，一個操作系統最重要的就是它的生態環境。縱觀華為現在的整個格局，目的非常明確，用方舟編譯器來擴大自己的用戶群體。當用戶的基數足夠龐大時，可以隨時隨地建立一個完善的生態系統。如果在未來某一天，Android全面限制華為的使用之後，在這危機關頭鴻蒙系統還是很有可能扛起國產手機的一面大旗。哪怕不是鴻蒙，我們也需要這樣一個生態不是嗎?

最初，突然去了解Android中的虛擬機，一個是想要明白到底Android中的虛擬機和JVM是不是一回事，還有就是想要明白華為發布方舟編譯器到底快到了哪裡。

上述相關資料均來自網絡，侵權必刪。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※公開收購3c價格,不怕被賤賣!

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

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

※帶您來看台北網站建置，台北網頁設計，各種案例分享