之前在做乙個android專案時遇到了這樣乙個需求，要求螢幕上的內容是基於2*4動態排版的，其中相連的小塊可以隨機合併或不合併，使用者每次開啟這個介面時看到的介面布局都不一樣，大概類此下面這樣的草圖：
一開始的想法是按照傳統的方式，為該頁面準備多個布局，在程式執行時隨機選擇乙個布局檔案，可是掐指一算，這種2*4的布局可以衍生出來的版面有好幾十種，顯然這種思路不太靠譜。所以，考慮在程式中用**來實現動態排版。
現在要解決的問題是，圖中的每一小塊都代表著乙個viewgroup物件，這些viewgroup物件中又包括文字等資訊，那麼這些viewgroup如何像上面那樣填充在父容器中呢？沒錯，只要知道了每乙個viewgroup物件的座標和尺寸，就可以將它「擺」到視窗上，所以問題回到了如何
確定每乙個viewgroup的座標和尺寸的問題上了。
為了確定每乙個viewgroup的座標和尺寸我們可以通過演算法來「切割」螢幕，為了簡化我們的操作，在這裡借助乙個自定義的抽象「螢幕」類：screen，它封裝了座標和尺寸資訊，這個類的結構如下：
public class screen
public screen(int x, int y, int width, int height)
}
以上思路的核心是：不是直接操作螢幕的容器物件，而是以抽象的screen為中介，先將螢幕「切割」為我們需要的小塊，再以這些小塊封裝的資訊為基礎構造viewgroup。
Android螢幕適配的乙個另類方法
關於android手機螢幕適配，我至今沒找到乙個合適的方法.於是自己想了乙個歪招。原理也比較簡單，例如大多手機的標準解析度是1920 1080或1280 720 但是遇到1800 1080或1184 720的就麻煩了 何況有些手機還有虛擬按鍵狀態列 其實也簡單,把1800當1920來用，1184當1...
動態規劃的另類解法 鋼條切割
作為一名演算法愛好者，遇到問題總希望找到最優的解決方案，作為一名工程師，卻需要在頻繁變更的需求中快速給出響應。在最快和最優中，往往需要找到一種平衡。筆者在最近的工作中有所感悟，以動態規劃中經典的鋼條切割問題為例，在此記錄一二。給定一段長度為 n n 英吋的鋼條和乙個 表pi i 1 2,m m n ...
鋪滿螢幕的布局方法
我們可以通過設定html和body的高度來填滿整個瀏覽器螢幕的高度 html body 如果我們將html和body都設定為height 100 時,body的高度僅會被設定為瀏覽器螢幕的高度.當body裡的內容高度大於瀏覽器螢幕高度時,會因為預設的設定overflow visible使得高出的部分...