動(dòng)效設(shè)計(jì)

1、兩級(jí)吸頂

CoordinatorLayout+AppBarLayout可以輕松的實(shí)現(xiàn)一級(jí)吸頂?shù)墓δ?#xff0c;兩級(jí)吸頂并不支持。要實(shí)現(xiàn)兩級(jí)吸頂，可以有兩種思考：一，在此基礎(chǔ)之上再完成一次吸頂；二，直接重寫兩次吸頂?shù)倪壿?#xff0c;兩次吸頂算法跟一次吸頂算法思路上應(yīng)該是一致的。首頁改版使用了第一種思路，因?yàn)榭紤]到頂部搜索框特殊的過渡動(dòng)畫效果，這塊本身需要自定義，即便使用控件自帶的效果，這塊也要重寫，所以首先完成了頂部搜索框的自定義吸頂效果，然后借力CoordinatorLayout控件實(shí)現(xiàn)了feed流頭部的吸頂。這樣，整個(gè)兩級(jí)吸頂效果就完成了，頂部搜索欄吸頂通過自定義充分滿足了動(dòng)效，后續(xù)擴(kuò)展和修改會(huì)更自如；而feed流頭部使用父級(jí)控件自帶的吸頂效果，大大減輕了再次吸頂?shù)倪壿嬛貙憽?/p>

對(duì)于自定義頂部搜索欄吸頂?shù)墓δ?#xff0c;可以通過AppBarLayout的OnOffsetChangedListener接口監(jiān)聽完成。onOffsetChanged(AppBarLayout appBarLayout, int verticalOffset)方法返回了appBarLayout的垂直偏移量，通過這個(gè)變量基本能完成所有頭部的動(dòng)效。

// 背景圖滑動(dòng)處理if (Math.abs(verticalOffset) < mHeaderHeight) { mIvBackground.scrollTo(0, (int) (-verticalOffset / VELOCITY_OF_REFRESH_BACKGROUND)); // 搜索欄動(dòng)效處理 int width = mCityWidth - mSearcherBarLeftMargin; int height = mHeaderHeight - statusBarHeight - mSearcherBarShadowHeight - mSearcherBarStickyHeight - mSearcherBarStickyTopMargin;; float rate = ((float) width) / height; int rateScrollY = (int) (rate * -verticalOffset); int scrollWidth = rateScrollY > width ? width : rateScrollY; float widthRate = scrollWidth * 1.0f / width; if (rateScrollY < width) { // 搜索框大小 RelativeLayout.LayoutParams searchParams = (RelativeLayout.LayoutParams) mSearcherBar.getLayoutParams(); searchParams.leftMargin = mSearcherBarLeftMargin + scrollWidth; searchParams.height = mSearcherBarHeight - (int)(diffHeight * widthRate); mSearcherBar.setLayoutParams(searchParams); ... }}

2、頭圖動(dòng)效設(shè)計(jì)圖

首頁開發(fā)時(shí)頭圖下拉的參數(shù)設(shè)計(jì)

文案動(dòng)畫區(qū)，放置了下拉刷新的動(dòng)畫和文案，下拉到這個(gè)區(qū)域即展示刷新動(dòng)畫和相應(yīng)的文案。

刷新觸發(fā)區(qū)，下拉到這個(gè)區(qū)域松手后會(huì)觸發(fā)刷新事件，下拉到文案動(dòng)畫區(qū)則不會(huì)觸發(fā)刷新。

二樓觸發(fā)區(qū)，下拉到這個(gè)區(qū)域松手后則觸發(fā)負(fù)二樓的動(dòng)效，以及負(fù)二樓落地；如果負(fù)二樓開關(guān)沒有打開，延續(xù)刷新的功能。

此外，下拉刷新的偏移和頭圖的偏移不是1:1，是500:270的效果，這樣可以形成視差，創(chuàng)造出空間層次感。補(bǔ)充，負(fù)二樓的過渡效果偏移和下拉偏移是1:1的，體現(xiàn)了跟隨效果。

頭圖下拉偏移，通過SmartRefreshLayout的OnMultiPurposeListener接口監(jiān)聽操作。它提供了onHeaderMoving(RefreshHeader header, boolean isDragging, float percent, int offset, int headerHeight, int maxDragHeight)方法，輸出了RefreshHeader下拉的偏移量，通過視差系數(shù)，從而實(shí)現(xiàn)了頭圖的動(dòng)效。

// 下拉刷新時(shí)，背景圖的移動(dòng)速率private final static float VELOCITY_OF_REFRESH_BACKGROUND = 500.0f / 270.0f;FrameLayout.LayoutParams lpBg = (FrameLayout.LayoutParams) mIvBackground.getLayoutParams();lpBg.topMargin = mBackgroundTopMargin + (int) (offset / VELOCITY_OF_REFRESH_BACKGROUND);mIvBackground.setLayoutParams(lpBg); 3、負(fù)二樓動(dòng)效設(shè)計(jì)圖

研發(fā)實(shí)現(xiàn)后的負(fù)二樓主頁效果圖

UI劃分區(qū)塊后的布局元素設(shè)計(jì)參考圖

動(dòng)畫頁面漸隱落地頁出現(xiàn)的一個(gè)過渡效果

整個(gè)頁面使用全屏設(shè)計(jì)，對(duì)高度進(jìn)行等比縮放處理以適應(yīng)不同大小的屏幕設(shè)備。整體動(dòng)畫實(shí)現(xiàn)難度不大，問題在落地頁如何從動(dòng)畫頁下面漸顯，我們知道邏輯上，負(fù)二樓頁面和首頁是在一個(gè)層級(jí)，實(shí)現(xiàn)落地頁在動(dòng)畫頁下面實(shí)現(xiàn)就是要實(shí)現(xiàn)落地頁從首頁下面出現(xiàn)。這個(gè)邏輯是行不通的，即便可以改造落地頁，也不能實(shí)現(xiàn)Activity從下面出現(xiàn)的過渡效果。

最終解決方案是，負(fù)二樓動(dòng)畫頁面用一個(gè)Activity實(shí)現(xiàn)，啟動(dòng)負(fù)二樓動(dòng)畫頁之前先啟動(dòng)落地頁，這兩者幾乎先后順序幾乎是保持同步的。然而，同時(shí)啟動(dòng)兩個(gè)ui界面，勢必會(huì)造成動(dòng)畫界面的播放卡頓，尤其是啟動(dòng)承載內(nèi)容繁多的落地頁，對(duì)上層動(dòng)畫頁造成很大的影響。為解決這一問題，采用了“遮掩”的背景效果，即動(dòng)畫頁背景和首頁出現(xiàn)負(fù)二樓過渡效果圖的背景是一致的，且啟動(dòng)動(dòng)畫頁后有短暫停留，是為了把這一停留時(shí)間分配給落地頁先行，從而最大可能的減少卡頓時(shí)長。

4、上下身和主體滑動(dòng)沖突

主體用ScrollView而下身用ListView或RecyclerView會(huì)存在滑動(dòng)沖突問題，這個(gè)我們都知道，當(dāng)然也有解決方案。但是，新版首頁的需求遠(yuǎn)不止這些，它是外層集成下拉刷新和上拉加載功能、內(nèi)部整體滾動(dòng)兩級(jí)吸頂、下半身橫向滾動(dòng)切換頁面為一體的復(fù)雜構(gòu)造，我們不能單純地通過傳統(tǒng)的ScrollView+RecyclerView就可以解決。那么脫離傳統(tǒng)父級(jí)向子級(jí)傳遞事件的思想，Google提供了一套“材料設(shè)計(jì)”的思想來處理這種復(fù)雜的空間關(guān)系，其中一個(gè)精髓就是將傳統(tǒng)開發(fā)設(shè)計(jì)思想顛覆，將子視圖的滑動(dòng)事件向父級(jí)傳遞，通過父級(jí)的消費(fèi)再告知其它子視圖進(jìn)行處理滑動(dòng)，整個(gè)材料形成了一起非線性聯(lián)動(dòng)的效果，創(chuàng)造出空間層級(jí)感。父子級(jí)交互的兩個(gè)通道是通過NestedScrollingParent和NestedScrollingChild兩個(gè)接口協(xié)議通信的。我們通過CoordinatorLayout、AppBarLayout以及RecyclerView幾乎完美地實(shí)現(xiàn)了這三者之間的沖突；幾乎，但還是存在一些缺陷——AppBarLayout下滑，RecyclerView同時(shí)上劃，會(huì)出現(xiàn)CoordinatorLayout消費(fèi)子視圖事件時(shí)的上下抖動(dòng)問題。這個(gè)問題的主要原因是AppBarLayout滑動(dòng)后的Fling效果未結(jié)束時(shí)，又再次觸發(fā)RecyclerView的觸摸事件。找到了這個(gè)原因，就能容易地解決最后的沖突問題了；在觸摸事件里攔截Fling，讓父級(jí)滾動(dòng)在每次子視圖被觸摸時(shí)先停止掉就可以解決沖突問題。

總結(jié)

以上是生活随笔為你收集整理的android开发 视图联动_新版首页技术设计和实现方案(Android)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。