1.前言 逛街的時候,看到一篇Android Canvas 方法總結,這篇文章將Canvas一些基本操作介紹的很詳細。從零開始的朋友可以先去刷點經驗,剩下的同學拿起手術刀,我們一起來將Canvas血腥解剖吧。 2.Canvas簡介 官方文件介紹如下 The Canvas class hol

1.專案基類 毫不誇張的說,專案基類封裝的質量決定你的開發速度,後期維護難易度。不過估計很多萌新並沒有理解其中原因,那麼我今天就來分析下,專案基類封裝的質量有多重要。  首先通常來講,入了門的安卓萌新們應該都知道,專案中的activity和fragment必須要有統一的基類,也就是我們常說的BaseA

前言 軟體開發中,經常遇到一種情況:實現一個功能可以有多種演算法或策略,我們根據實際情況選擇不同的演算法或者策略來完成該功能。針對這種情況,常規實現方法是將多種演算法寫在一個類中,然後通過if-else或者switch-case等條件語句來選擇具體的演算法,但是當很多個演算法集中在一個類時,這個類就會

結構體 概念、定義於初始化方式 C 陣列允許定義可儲存相同型別資料項的變數,結構是 C 程式設計中另一種使用者自定義的可用的資料型別,它允許您儲存不同型別的資料項。 結構用於表示一條記錄,假設您想要跟蹤圖書館中書本的動態,您可能需要跟蹤每本書的下列屬性: Title Author Subje

閱讀之前,不妨先思考一個問題,在Android系統中,APP端View檢視的資料是如何傳遞SurfaceFlinger服務的呢?View繪製的資料最終是按照一幀一幀顯示到螢幕的,而每一幀都會佔用一定的儲存空間,在APP端執行draw的時候,資料很明顯是要繪製到APP的程序空間,但是檢視視窗要經過Surfa

前言 安卓的按壓效果的傳統方式是shape.xml檔案,不過如果當專案比較多按鈕都需要自定義按壓效果的話,shape.xml的數量可是非常頭疼的(即使是ctrl c+ ctrlv),故此可以採用動態方式進行按壓效果的實現。 上程式碼 /** * * @param RADIUS * 角度

0x0 前言 今年五月底針對Android app開發的kotlin終於轉正成功,這掀起了一股學習kotlin的熱潮。於是我也趕了一下時髦,看了幾天官網上的文件,大致瞭解了一下kotlin的語法,也手癢癢著想做點什麼,正巧之前的專案裡有一個自定義view想剝離出來寫成一個lib供以後其他專案複用,就用

一、寫在前面 很多時候,你會發現想的再多,不如堅實地邁出第一步,比如說寫分享文章。 借用楊絳先生的話“你的問題主要在於讀書不多而想的太多”,我迄今都覺得這是對包括我在內的大部分人的精神苦惱的最簡潔而樸素的概括。 繼上一篇 焦慮 ,正式出土之後,一直想盡快完成第二篇,無奈一直無法確認自己是否言之有物,

c.gif 可以懸浮在activity上面,在載入fragment時懸浮按鈕不會消失 實現方式很簡單,因為是在應用內部拖動的,只需要通過Activity獲取WindowManager,然後將要拖動的view設定上去就行設定程式碼: WindowManager wm = (WindowM

歡迎Follow我的GitHub, 關注我的CSDN. 其餘參考Android目錄 所以,如何使程式碼變得更好?好的程式碼可以被識別為易於閱讀、理解、除錯和修改的程式碼,而且最重要的是很少有缺陷。顯然,編寫好的程式碼需要花費更多的時間,但從長遠來看,它也有更多的價值,因為維護成本更低,而且更易於重用

版權宣告:本文為博主原創文章,未經博主允許不得轉載。系列教程:Android開發之從零開始系列 大家要是看到有錯誤的地方或者有啥好的建議,歡迎留言評論 前言:專案開發中難免會敲很多重複的程式碼,尤其是像 Adapter(介面卡)這種使用頻率高且格式基本一致的類,這篇部落格將以 Re

在日常開發過程中時常需要用到設計模式,但是設計模式有23種,如何將這些設計模式瞭然於胸並且能在實際開發過程中應用得得心應手呢?和我一起跟著《Android原始碼設計模式解析與實戰》一書邊學邊應用吧! 設計模式系列文章 Android 設計模式之單例模式 Android 設計模式之Builder模式

前言:常常會忘記一些很基礎的知識點,所以把這些個常用卻很少從頭寫到尾的程式碼知識,做了個簡單的從頭到尾的簡單瀏覽。需要時看一看,可以幫助加快我們回憶的速度。 FragmentTransaction 中對Fragment有如下幾種操作: 1,attach(), detach()不是很常用;2,add

前言 前段時間,專案中用到了webSocket,特此來記錄一下接入方法。webSocket使用場景:社交聊天、彈幕、多玩家遊戲、協同編輯、體育實況更新、基於位置的應用、線上教育、智慧家居等需要高實時的場景。(結合到我們公司的業務,每到大型節日的時候,比如春節啊,可以搞個彈幕祭拜啥的) webSock

app更新了有幾個版本了,估計PM發現是時候優化一下細節了,統一一下標準。所以這期的需求裡就有這麼一項:統一所有頁面的網路錯誤提示,同時不要影響現有的互動流程。 乍一看有20+的頁面,作為一個比較懶的程式設計師,肯定不會想去每個頁面單獨實現,這樣太傻,也難以接受。沒準哪天PM又要大改,那就尷尬了。給