摘要：年前放假的最后一天，我們上線了獨(dú)家記憶活動(dòng)宣傳頁(yè)。微信分享主要代碼參考獨(dú)家記憶當(dāng)時(shí)光凝固，當(dāng)回憶定格。這是屬于我和的獨(dú)家記憶。

年前放假的最后一天，我們上線了「My Flyme 獨(dú)家記憶」 H5 活動(dòng)宣傳頁(yè)。

因種種原因，直到放假前幾天，才突然要求我們參與并開(kāi)始項(xiàng)目的前端部分。此時(shí)大概的情況是：所有數(shù)據(jù)已計(jì)算完畢；后端接口已完成待聯(lián)調(diào)；交互視覺(jué)只出了不到四分之一(一共二十多個(gè)頁(yè)面)；我們平時(shí)以中后臺(tái)項(xiàng)目為主，這種活動(dòng)頁(yè)從未涉及。我們真正介入時(shí)距離上線時(shí)間點(diǎn)只有四天，在這種背景下，已經(jīng)談不上探討什么樣的技術(shù)選型最佳，只能是越快越容易實(shí)現(xiàn)越好。于是拉上了所有用得上的前端成員一起努力，最終算是在要求時(shí)間點(diǎn)上實(shí)現(xiàn)了上線目標(biāo)。

這種活動(dòng)宣傳性質(zhì)的頁(yè)面雖然用不上太復(fù)雜的邏輯，但也有很多后臺(tái)項(xiàng)目涉及不到的細(xì)節(jié)，讓我們踩了不少的坑。這里針對(duì)項(xiàng)目開(kāi)發(fā)過(guò)程中涉及的一些主要技術(shù)點(diǎn)作一下總結(jié)回顧。

「My Flyme 獨(dú)家記憶」(DEMO, 數(shù)據(jù)為隨機(jī)制造)：https://lzw.me/pages/demo/myf...

多頁(yè)滑動(dòng)效果，頁(yè)面多，動(dòng)畫元素細(xì)節(jié)多，動(dòng)畫效果簡(jiǎn)單

個(gè)人頁(yè)(主頁(yè)面)需 Flyme 賬號(hào)登錄，自有應(yīng)用內(nèi)要盡量實(shí)現(xiàn)免登錄

將會(huì)在魅族主流應(yīng)用和社區(qū)里推廣

可分享到微信、微博等主流社交媒體

多頁(yè)翻屏滑動(dòng)的效果有很多開(kāi)源的實(shí)現(xiàn)，當(dāng)然希望盡量的簡(jiǎn)單自己實(shí)現(xiàn)也不是很復(fù)雜。我們選擇的是百度開(kāi)源的 iSlider，iSlider 是一款非常優(yōu)秀的翻頁(yè)滑動(dòng)組件。除此之外，還有很多成熟的開(kāi)源實(shí)現(xiàn)可選用：

swiper http://www.swiper.com.cn

iscroll https://github.com/cubiq/iscroll

fullpage.js https://github.com/alvarotrigo/fullPage.js/

Scrollify https://github.com/lukehaas/Scrollify

onepage-scroll https://github.com/peachananr/onepage-scroll

移動(dòng)端屏幕適配常用的方案有如下三種：

固定高度，寬度自適應(yīng)

固定寬度/高度，viewport 縮放

rem 做寬度，viewport 縮放

因?yàn)樯婕岸囗?yè)大量的動(dòng)畫元素，只能是絕對(duì)定位來(lái)快速布局，我們采取了第二種方案：頁(yè)面以 320x640 作為基礎(chǔ)大小布局，在移動(dòng)端根據(jù)實(shí)際的頁(yè)面大小等比縮放。主要適配代碼參考：

+function () {
    function isMobile() {
        return /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini|Mobi/i.test(navigator.userAgent);
    }

    function setScale() {
        var pageScale = 1;

        if (window.top !== window) {
            return pageScale;
        }

        var width = document.documentElement.clientWidth || 360;
        var height = document.documentElement.clientHeight || 640;
        if (width / height >= 360 / 640) {
            // 高度優(yōu)先
            pageScale = height / 640;
        } else {
            pageScale = width / 360;
        }

        var content = "width=" + 360 + ", initial-scale=" + pageScale 
          + ", maximum-scale=" + pageScale + ", user-scalable=no";
        document.getElementById("viewport").setAttribute("content", content);

        return pageScale;
    }

    if (isMobile()) {
        setScale();
    } else {
        try {
            document.getElementsByTagName("html")[0].classList.add("pc");
        } catch (e) {}
    }
}

這種方案以高度優(yōu)先，以使得全部?jī)?nèi)容都能夠出現(xiàn)在可視區(qū)域。但有一個(gè)問(wèn)題是，在 webview 內(nèi)寬高比大于 9/16，于是實(shí)際采用了高度的比例縮放，基礎(chǔ)寬度縮放后會(huì)小于屏幕寬度，由于涉及動(dòng)畫的元素采用了絕對(duì)定位，這導(dǎo)致這些元素顯示上偏左，右邊出現(xiàn)較多的空白。

對(duì)于這種問(wèn)題，我們的@零零柒同學(xué)想到了一種簡(jiǎn)單快速的解決方案：取得基礎(chǔ)寬度與真實(shí)寬度的縮放比，將所有絕對(duì)定位的元素按照該縮放比重新計(jì)算 left 位移。主要代碼參考：

import $ from "./libs/zepto";

const width = document.documentElement.clientWidth || 360;
const height = document.documentElement.clientHeight || 640;
let pageScale = 1;

if (width / height >= 360 / 640) {
    pageScale = height / 640;
}

const offset = (width - pageScale * 360) / 2;
// 每當(dāng)頁(yè)面切換后調(diào)用
export function positionFix(dom) {
    if (pageScale === 1 || !offset) {
        return;
    }

    // 為一個(gè)頁(yè)面
    const $dom = $(dom);

    if ($dom.hasClass("position-fixed")) {
        return;
    }

    $dom.find(".text-box i, img").forEach((dom, i) => {
        let $this = $(dom),
            left;

        // 只修改絕對(duì)定位的元素
        if ($this.css("position") !== "absolute") {
            return;
        }

        left = +($this.css("left").replace("px", ""));

        $this.css("left", (left + offset) + "px");
        // console.log($(dom).css("left"));
    });

    $dom.addClass("position-fixed");
}

頁(yè)面縮放解決了不同屏幕大小的布局一致性。另外涉及的一個(gè)問(wèn)題是，設(shè)計(jì)稿圖片大小如何進(jìn)行等比縮放？

這個(gè)問(wèn)題也很簡(jiǎn)單，圖片引用直接設(shè)置 width 以縮放到合適大?。谎┍虉D上的圖片則按照 360x640 的頁(yè)面大小進(jìn)行縮放：

對(duì)于絕對(duì)定位的元素，使用 transform: scale(0.333) 進(jìn)行變換縮放

對(duì)于流式布局的元素，使用 zomm(0.333) 進(jìn)行縮放

還有一個(gè)值得一提的問(wèn)題是，如何做到布局元素與設(shè)計(jì)稿完全一致？

這個(gè)問(wèn)題的解決方法是：使用靜態(tài)的設(shè)計(jì)稿圖片作為全屏背景，通過(guò)調(diào)整各元素到對(duì)應(yīng)位置，從而實(shí)現(xiàn)快速定位。我們的一位同學(xué)給出了這個(gè)方法，并且給出了一個(gè)讓頁(yè)面元素可拖動(dòng)并設(shè)置最終位置(left/right值)的 jQuery 插件，這使得我們的頁(yè)面布局變得簡(jiǎn)單而高效。

動(dòng)畫實(shí)現(xiàn)方案一般來(lái)說(shuō)可以選擇CSS3 動(dòng)畫、引入游戲引擎或使用 svg/canvas。

該方案技術(shù)成本簡(jiǎn)單，任何前端開(kāi)發(fā)者都能快速上手，但細(xì)節(jié)實(shí)現(xiàn)上工作量大。

從簡(jiǎn)單快速開(kāi)始的角度來(lái)說(shuō)，CSS3 動(dòng)畫是我們的唯一選擇。使用 CSS3 動(dòng)畫需要特別注意一點(diǎn)：修改 DOM 會(huì)導(dǎo)致頁(yè)面重繪，在移動(dòng)端容易出現(xiàn)卡頓現(xiàn)象。所以應(yīng)盡可能避免使用會(huì)修改 DOM 的 css 屬性，只使用 transform 實(shí)現(xiàn)動(dòng)畫變換效果。

我們的頁(yè)面動(dòng)畫都是循環(huán)運(yùn)動(dòng)的，全部需要對(duì)照動(dòng)效設(shè)計(jì)逐一還原實(shí)現(xiàn)，花費(fèi)了大量的人力和時(shí)間成本。實(shí)現(xiàn)上主要使用了 animation、keyframe、transform 屬性。

此外，對(duì)于常見(jiàn)的入場(chǎng)顯示/滑入等動(dòng)畫效果，只需要使用 transform 和 transition 即可實(shí)現(xiàn)需求。對(duì)于 css 動(dòng)畫也有很多優(yōu)秀而成熟的動(dòng)畫庫(kù)可用，一些參考：

animate.css https://github.com/daneden/animate.css

magic.css https://github.com/miniMAC/magic

Hover.css http://ianlunn.github.io/Hover/

velocity.js https://github.com/julianshapiro/velocity

anime.js https://github.com/juliangarnier/anime

下面簡(jiǎn)單介紹一下另外的兩種動(dòng)畫實(shí)現(xiàn)方案。

使用 h5 游戲引擎可大幅度降低工作量，能夠相對(duì)容易地實(shí)現(xiàn)復(fù)雜動(dòng)畫效果，但需要經(jīng)驗(yàn)避免入深坑，有較高學(xué)習(xí)成本，并且需要設(shè)計(jì)師深度配合。一些參考：

Hilo https://github.com/hiloteam/Hilo

Phaser https://github.com/photonstorm/phaser

pixi.js https://github.com/pixijs/pixi.js

melonjs https://github.com/melonjs/melonjs

playcanvas https://github.com/playcanvas/engine

LayaAir http://www.layabox.com

白鷺引擎 https://www.egret.com

使用 svg/canvas/webGL 實(shí)現(xiàn)的動(dòng)畫效果會(huì)比較好，但實(shí)現(xiàn)工作量較大，對(duì)實(shí)踐經(jīng)驗(yàn)也有較高的要求。成熟的相關(guān)庫(kù)參考：

createJs https://github.com/CreateJS

snap.svg https://github.com/adobe-webplatform/Snap.svg

svg.js https://github.com/svgdotjs/svg.js

d3.js https://d3js.org

threes.js https://threejs.org

由于第一次做這種活動(dòng)頁(yè)，沒(méi)有特別注意到微信內(nèi)分享的問(wèn)題，直到上線時(shí)才發(fā)現(xiàn)，分享出去的效果實(shí)在太難看，這導(dǎo)致幾位留守到最后的同事緊急探討協(xié)調(diào)方案，幾乎整晚沒(méi)睡覺(jué)。

微信內(nèi)開(kāi)發(fā)應(yīng)注意這幾點(diǎn)：

下載微信開(kāi)發(fā)者工具（或 TBS Studio），以調(diào)試微信內(nèi)頁(yè)面

需要通過(guò)認(rèn)證的公眾號(hào)或訂閱號(hào)，取得微信 jssdk 分享接口所需的 appId 和 signature

需要后端 API 管理 signature 簽名的生成與緩存

window.history.pushState/replaceState 修改了 URL 時(shí)需要重新生成 signature 簽名。由于沒(méi)有仔細(xì)閱讀文檔并意識(shí)到這一點(diǎn)，在這個(gè)問(wèn)題上坑了比較多的時(shí)間。

我們最終協(xié)調(diào)到一個(gè)部門的訂閱號(hào)，并使用他們已實(shí)現(xiàn)了的后端 token 簽名生成 API 來(lái)實(shí)現(xiàn) jssdk 的分享 API，在 nginx 層對(duì)該 API 代理轉(zhuǎn)發(fā)解決跨域安全性相關(guān)問(wèn)題。微信分享主要代碼參考：

const isWeixinBrowser = /micromessenger/.test(navigator.userAgent.toLowerCase());
const wxJsdk = "http://res.wx.qq.com/open/js/jweixin-1.1.0.js";
const jsApiList = ["checkJsApi", "onMenuShareTimeline", "onMenuShareAppMessage", "onMenuShareQQ", "onMenuShareWeibo"];
let opts = {
    title: "My Flyme 獨(dú)家記憶",
    desc: "當(dāng)時(shí)光凝固，當(dāng)回憶定格?；厥?016 ，我與 Flyme 的點(diǎn)點(diǎn)滴滴都在這里。這是屬于我和 Flyme 的獨(dú)家記憶。",
    link: "",
    imgUrl: ""
}, loadedwx = false;

function initShareEvent(wx) {
    const option = {
        ...opts,
        trigger: function (res) {console.log("trigger", res)},
        success: function (res) { console.log("已分享", res) },
        cancel: function (res) { console.log("已取消", res) },
        fail: function (res) { console.log(JSON.stringify(res)) } 
    };

    wx.onMenuShareAppMessage(option); // 分享給朋友
    wx.onMenuShareTimeline(option);   // 分享到朋友圈
    wx.onMenuShareQQ(option);         // 分享到QQ
    wx.onMenuShareWeibo(option);      // 分享到微博
    wx.onMenuShareQZone(option);      // 分享到QZone
}
function checkJsApi(wx) {
    wx.checkJsApi({
        jsApiList,
        success: () => initShareEvent(wx),
        error: err => console.log("checkJsApi error: ", err)
    });
}
function initConfig(wx) {
    // 特別注意，這里 link 必須使用當(dāng)前頁(yè)面的 URL 地址，否則會(huì)失敗！
    opts.link = encodeURIComponent(document.location.href.split("#")[0]);
    return $.ajax({
        url: "/wechat_api/get_js_ticket?&url=" + opts.link,
        dataType:"jsonp", //指定為jsonp類型
        jsonp:"callback"
    }).done((res) => {
        wx.config({
            debug: process.env.NODE_ENV === "development",
            appId: "wx0000000000000000",
            nonceStr: res.data.nonceStr,
            timestamp: res.data.timestamp,
            signature: res.data.signature,
            jsApiList
        });
    });
}
export default options => {
    if (loadedwx || !isWeixinBrowser) { return }

    require([wxJsdk], (wx) => {
        loadedwx = true;
        $.extend(true, opts, options);
        initConfig(wx);
        wx.ready(() => checkJsApi(wx));
        wx.error((res) => console.error("出錯(cuò)了：", res.errMsg));
    });
}

微信分享 API 需要公眾號(hào)或訂閱號(hào)，臨時(shí)的活動(dòng)開(kāi)發(fā)可能來(lái)不及折騰，那么一個(gè)折中的辦法是這樣的：在頁(yè)面頭部 img 標(biāo)簽設(shè)置分享顯示的圖片，設(shè)置高度和寬度為 0。示例：

微信會(huì)提取頁(yè)面標(biāo)題和第一張圖片，作為朋友圈分享的標(biāo)題和縮略圖。使用 jssdk 方式分享到朋友圈的效果也是只有標(biāo)題和縮略圖，所以效果上沒(méi)有區(qū)別。比較大的區(qū)別是，“發(fā)送給好友”時(shí)沒(méi)有描述，描述位置變成了頁(yè)面 URL 地址。

由于時(shí)間緊而且設(shè)計(jì)稿是逐步給到的，很多細(xì)節(jié)的優(yōu)化都沒(méi)法去做。最終上線的版本首屏大小約 1.3M，在弱網(wǎng)下的加載時(shí)間會(huì)比較久一些，可優(yōu)化空間還比較大。這里探討一下我們主要考慮到的幾個(gè)點(diǎn)。

一共二十多個(gè)頁(yè)面，我們按每頁(yè)一個(gè) html 模板和一個(gè) less 文件的方式，按頁(yè)面分工開(kāi)發(fā)，在 index.html 頁(yè)面以 script 模板方式引入，由 fis3 實(shí)現(xiàn)模板嵌入。通過(guò) ajax 拿到數(shù)據(jù)后，根據(jù)數(shù)據(jù)替換模板中的數(shù)據(jù)占位符，并進(jìn)行頁(yè)面切割，然后生成 iSlider 需要的數(shù)據(jù)配置項(xiàng)。這樣做的好處是 html 內(nèi)容未寫入到 DOM 時(shí)，涉及的靜態(tài)資源圖片不會(huì)被加載。

iSlider 默認(rèn)至少加載 3 個(gè)頁(yè)面，每一時(shí)刻也最多保存三個(gè)頁(yè)面實(shí)例。于是首屏加載了三個(gè)頁(yè)面，這正好符合我們的目的。

另外要提到的一點(diǎn)是，弱網(wǎng)下不同圖片下載的時(shí)差較大，會(huì)使得不同位置的圖片動(dòng)畫斷斷續(xù)續(xù)地出現(xiàn)。為了避免這種不好的效果，我們使用了一個(gè)簡(jiǎn)單的圖片預(yù)加載機(jī)制，在預(yù)加載完首屏涉及的圖片資源后才隱藏 loading 顯示頁(yè)面。

該項(xiàng)目涉及圖片資源 500 多張，只有手繪文字圖片做了雪碧圖處理?，F(xiàn)在的移動(dòng)端基本都支持 webp，使用 webp 是必須的。實(shí)際上使用 webp 后，圖片目錄的大小減小了 60%。

以前大家都是用智圖這種在線工具處理少量的圖片，搜索了一下，居然沒(méi)有找到現(xiàn)成的批量生成 webp 的工具庫(kù)，于是寫了一個(gè)批量生成方法。這兩天整理完善了一下，算是造了一個(gè)小輪子，需要的同學(xué)可以關(guān)注下，地址在這里：

webp 批量轉(zhuǎn)換：https://github.com/lzwme/webp-batch-convert

由于要在 Flyme 自帶的近十個(gè)主要應(yīng)用內(nèi)作推廣入口，涉及到兩個(gè)問(wèn)題：應(yīng)用內(nèi)分享和應(yīng)用內(nèi)免登錄。

在協(xié)調(diào)這一塊時(shí)發(fā)現(xiàn)，各應(yīng)用都是獨(dú)自制定的各不相同的 webview 內(nèi)相關(guān) js 接口和規(guī)范，同一應(yīng)用不同版本的實(shí)現(xiàn)也可能有差異，或者根本沒(méi)有相關(guān)實(shí)現(xiàn)；有規(guī)范的文檔也不夠齊全，并且都沒(méi)有示例參考；沒(méi)有各應(yīng)用的開(kāi)發(fā)測(cè)試版本來(lái)做調(diào)試。于是花了不少時(shí)間各種咨詢，踩了不少的坑，效果也還是不盡人意，最終只在魅族瀏覽器上做到了期望的效果。

沒(méi)有統(tǒng)一規(guī)范，各自造輪子，于是這種跨部門跨應(yīng)用的功能需求變得如此艱難。導(dǎo)致這種現(xiàn)象的存在因素很多，可知的一點(diǎn)是也和公司內(nèi)前端人員處于邊緣化地位的現(xiàn)實(shí)有關(guān)。過(guò)去的一年里，基礎(chǔ)技術(shù)支撐部門技術(shù)平臺(tái)做了一套 hybridApp 解決方案，@chemdemo 同學(xué)還將 JSBridge 部分抽離開(kāi)源了出來(lái)：https://github.com/chemdemo/hybrid-js?？赡苁侨鄙俑邔幼銐虻南嚓P(guān)意識(shí)和支持力度，并沒(méi)有在各業(yè)務(wù)軟件內(nèi)得到廣泛應(yīng)用，反而主要靠?jī)?nèi)部前端圈間溝通傳播。不過(guò)這套方案為了簡(jiǎn)潔只實(shí)現(xiàn)了很少的通用 API 和可擴(kuò)展方法，并沒(méi)有繼續(xù)實(shí)現(xiàn)各種業(yè)務(wù)適用的通用性擴(kuò)展功能，自然也沒(méi)有我們想要的應(yīng)用內(nèi)分享和 Flyme 免登錄這兩個(gè)功能。

對(duì)于這個(gè)問(wèn)題有兩點(diǎn)總結(jié)：

統(tǒng)一的公共 SDK 的重要性：避免重復(fù)造輪子，健壯且具有一致性的 API、完善的文檔。

再好的文檔不如一個(gè) demo

項(xiàng)目初期使用 webpack 進(jìn)行構(gòu)建，但由于我們平時(shí)的經(jīng)驗(yàn)以 fis3 為主，webpack 過(guò)于靈活的配置特性使得一些工程化需求需要花時(shí)間探索。在我們接手項(xiàng)目后一起討論了一下，果斷轉(zhuǎn)為熟悉的 fis3 構(gòu)建體系。使用 fis3 主要解決的問(wèn)題有：

less 編譯

es6 編譯

js/css 壓縮合并

頁(yè)面模板嵌入

發(fā)布時(shí) CDN 多帶帶域名的適配

發(fā)布時(shí)符合內(nèi)部運(yùn)維體系線上發(fā)布規(guī)范的目錄路徑修正

相比較為靈活的 webpack，fis3 更注重流程化整體解決方案，簡(jiǎn)單的數(shù)十行配置即可實(shí)現(xiàn)各種工程化需求。不過(guò) fis3 的發(fā)展現(xiàn)在似乎進(jìn)入了一個(gè)瓶頸期/穩(wěn)定期，社區(qū)中對(duì)于在 rollup 和 webpack 中大熱的 tree-shaking 等技術(shù)幾乎都沒(méi)有什么反應(yīng)。希望它不要沒(méi)落了，能有更多的創(chuàng)新吧。有兩點(diǎn)期望：走國(guó)際化路線，出英文文檔與社區(qū)支持，向國(guó)際頂級(jí)項(xiàng)目看進(jìn)；跟進(jìn)參考業(yè)界最新的工程化理念，如有必要出個(gè) fis4 也未嘗不可。

由于涉及到跨部門合作，也沒(méi)有太多的時(shí)間，項(xiàng)目起初放在了內(nèi)部的 gitlab 平臺(tái)，沒(méi)有走 git+gerrit+jenkins+運(yùn)維發(fā)布平臺(tái) 這一內(nèi)部完整的體系。這樣做在前期省去了項(xiàng)目創(chuàng)建、各種權(quán)限申請(qǐng)等一堆需要協(xié)調(diào)溝通的事情，開(kāi)發(fā)協(xié)作效率也比較高，但到了發(fā)布的階段就突顯出了問(wèn)題：每次發(fā)布都需要由運(yùn)維人員手動(dòng)操作，協(xié)調(diào)發(fā)布很花費(fèi)時(shí)間。

另外靜態(tài)頁(yè)面也沒(méi)有獨(dú)立出來(lái)，想當(dāng)然地簡(jiǎn)單的扔到后端目錄中，結(jié)果導(dǎo)致前端的修改需要后端也必須作修改發(fā)布，增加了前后端協(xié)調(diào)的時(shí)間成本。

于是，在首次發(fā)布后又進(jìn)行的幾次小迭代中，每次迭代發(fā)布都涉及到多人手動(dòng)協(xié)調(diào)，十分的浪費(fèi)時(shí)間。

總結(jié)一句話：項(xiàng)目構(gòu)建盡量與已有的成熟的規(guī)范一致，以少走彎路。

最后列舉一些移動(dòng)端 H5 開(kāi)發(fā)可參考的內(nèi)容：

真機(jī)調(diào)試 https://github.com/jieyou/remote_inspect_web_on_real_device

vConsole: 客戶端內(nèi) H5 調(diào)試 https://github.com/WechatFE/vConsole

移動(dòng)端布局終極解決方案 https://github.com/imochen/hotcss

mobileHack https://github.com/RubyLouvre/mobileHack

這是我們第一次嘗試這種活動(dòng)頁(yè)，在如此緊湊的時(shí)間節(jié)點(diǎn)下，沒(méi)有什么高大上的東西，更多的是各種采坑嘗試的實(shí)踐過(guò)程。以上列舉的內(nèi)容算是對(duì)本次開(kāi)發(fā)實(shí)踐做一個(gè)總結(jié)記錄，采用的相關(guān)實(shí)現(xiàn)方案也可作后續(xù)參考。歡迎探討分享你們的經(jīng)驗(yàn)。