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

年前放假的最后一天，我們上線了「My Flyme 獨家記憶」 H5 活動宣傳頁。

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

這種活動宣傳性質的頁面雖然用不上太復雜的邏輯，但也有很多后臺項目涉及不到的細節，讓我們踩了不少的坑。這里針對項目開發過程中涉及的一些主要技術點作一下總結回顧。

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

多頁滑動效果，頁面多，動畫元素細節多，動畫效果簡單

個人頁(主頁面)需 Flyme 賬號登錄，自有應用內要盡量實現免登錄

將會在魅族主流應用和社區里推廣

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

多頁翻屏滑動的效果有很多開源的實現，當然希望盡量的簡單自己實現也不是很復雜。我們選擇的是百度開源的 iSlider，iSlider 是一款非常優秀的翻頁滑動組件。除此之外，還有很多成熟的開源實現可選用：

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

移動端屏幕適配常用的方案有如下三種：

固定高度，寬度自適應

固定寬度/高度，viewport 縮放

rem 做寬度，viewport 縮放

因為涉及多頁大量的動畫元素，只能是絕對定位來快速布局，我們采取了第二種方案：頁面以 320x640 作為基礎大小布局，在移動端根據實際的頁面大小等比縮放。主要適配代碼參考：

+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) {
            // 高度優先
            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) {}
    }
}

這種方案以高度優先，以使得全部內容都能夠出現在可視區域。但有一個問題是，在 webview 內寬高比大于 9/16，于是實際采用了高度的比例縮放，基礎寬度縮放后會小于屏幕寬度，由于涉及動畫的元素采用了絕對定位，這導致這些元素顯示上偏左，右邊出現較多的空白。

對于這種問題，我們的@零零柒同學想到了一種簡單快速的解決方案：取得基礎寬度與真實寬度的縮放比，將所有絕對定位的元素按照該縮放比重新計算 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;
// 每當頁面切換后調用
export function positionFix(dom) {
    if (pageScale === 1 || !offset) {
        return;
    }

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

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

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

        // 只修改絕對定位的元素
        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");
}

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

這個問題也很簡單，圖片引用直接設置 width 以縮放到合適大小；雪碧圖上的圖片則按照 360x640 的頁面大小進行縮放：

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

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

還有一個值得一提的問題是，如何做到布局元素與設計稿完全一致？

這個問題的解決方法是：使用靜態的設計稿圖片作為全屏背景，通過調整各元素到對應位置，從而實現快速定位。我們的一位同學給出了這個方法，并且給出了一個讓頁面元素可拖動并設置最終位置(left/right值)的 jQuery 插件，這使得我們的頁面布局變得簡單而高效。

動畫實現方案一般來說可以選擇CSS3 動畫、引入游戲引擎或使用 svg/canvas。

該方案技術成本簡單，任何前端開發者都能快速上手，但細節實現上工作量大。

從簡單快速開始的角度來說，CSS3 動畫是我們的唯一選擇。使用 CSS3 動畫需要特別注意一點：修改 DOM 會導致頁面重繪，在移動端容易出現卡頓現象。所以應盡可能避免使用會修改 DOM 的 css 屬性，只使用 transform 實現動畫變換效果。

我們的頁面動畫都是循環運動的，全部需要對照動效設計逐一還原實現，花費了大量的人力和時間成本。實現上主要使用了 animation、keyframe、transform 屬性。

此外，對于常見的入場顯示/滑入等動畫效果，只需要使用 transform 和 transition 即可實現需求。對于 css 動畫也有很多優秀而成熟的動畫庫可用，一些參考：

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

下面簡單介紹一下另外的兩種動畫實現方案。

使用 h5 游戲引擎可大幅度降低工作量，能夠相對容易地實現復雜動畫效果，但需要經驗避免入深坑，有較高學習成本，并且需要設計師深度配合。一些參考：

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 實現的動畫效果會比較好，但實現工作量較大，對實踐經驗也有較高的要求。成熟的相關庫參考：

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

由于第一次做這種活動頁，沒有特別注意到微信內分享的問題，直到上線時才發現，分享出去的效果實在太難看，這導致幾位留守到最后的同事緊急探討協調方案，幾乎整晚沒睡覺。

微信內開發應注意這幾點：

下載微信開發者工具（或 TBS Studio），以調試微信內頁面

需要通過認證的公眾號或訂閱號，取得微信 jssdk 分享接口所需的 appId 和 signature

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

window.history.pushState/replaceState 修改了 URL 時需要重新生成 signature 簽名。由于沒有仔細閱讀文檔并意識到這一點，在這個問題上坑了比較多的時間。

我們最終協調到一個部門的訂閱號，并使用他們已實現了的后端 token 簽名生成 API 來實現 jssdk 的分享 API，在 nginx 層對該 API 代理轉發解決跨域安全性相關問題。微信分享主要代碼參考：

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 獨家記憶",
    desc: "當時光凝固，當回憶定格。回首2016 ，我與 Flyme 的點點滴滴都在這里。這是屬于我和 Flyme 的獨家記憶。",
    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 必須使用當前頁面的 URL 地址，否則會失敗！
    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("出錯了：", res.errMsg));
    });
}

微信分享 API 需要公眾號或訂閱號，臨時的活動開發可能來不及折騰，那么一個折中的辦法是這樣的：在頁面頭部 img 標簽設置分享顯示的圖片，設置高度和寬度為 0。示例：

微信會提取頁面標題和第一張圖片，作為朋友圈分享的標題和縮略圖。使用 jssdk 方式分享到朋友圈的效果也是只有標題和縮略圖，所以效果上沒有區別。比較大的區別是，“發送給好友”時沒有描述，描述位置變成了頁面 URL 地址。

由于時間緊而且設計稿是逐步給到的，很多細節的優化都沒法去做。最終上線的版本首屏大小約 1.3M，在弱網下的加載時間會比較久一些，可優化空間還比較大。這里探討一下我們主要考慮到的幾個點。

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

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

另外要提到的一點是，弱網下不同圖片下載的時差較大，會使得不同位置的圖片動畫斷斷續續地出現。為了避免這種不好的效果，我們使用了一個簡單的圖片預加載機制，在預加載完首屏涉及的圖片資源后才隱藏 loading 顯示頁面。

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

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

webp 批量轉換：https://github.com/lzwme/webp-batch-convert

由于要在 Flyme 自帶的近十個主要應用內作推廣入口，涉及到兩個問題：應用內分享和應用內免登錄。

在協調這一塊時發現，各應用都是獨自制定的各不相同的 webview 內相關 js 接口和規范，同一應用不同版本的實現也可能有差異，或者根本沒有相關實現；有規范的文檔也不夠齊全，并且都沒有示例參考；沒有各應用的開發測試版本來做調試。于是花了不少時間各種咨詢，踩了不少的坑，效果也還是不盡人意，最終只在魅族瀏覽器上做到了期望的效果。

沒有統一規范，各自造輪子，于是這種跨部門跨應用的功能需求變得如此艱難。導致這種現象的存在因素很多，可知的一點是也和公司內前端人員處于邊緣化地位的現實有關。過去的一年里，基礎技術支撐部門技術平臺做了一套 hybridApp 解決方案，@chemdemo 同學還將 JSBridge 部分抽離開源了出來：https://github.com/chemdemo/hybrid-js。可能是缺少高層足夠的相關意識和支持力度，并沒有在各業務軟件內得到廣泛應用，反而主要靠內部前端圈間溝通傳播。不過這套方案為了簡潔只實現了很少的通用 API 和可擴展方法，并沒有繼續實現各種業務適用的通用性擴展功能，自然也沒有我們想要的應用內分享和 Flyme 免登錄這兩個功能。

對于這個問題有兩點總結：

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

再好的文檔不如一個 demo

項目初期使用 webpack 進行構建，但由于我們平時的經驗以 fis3 為主，webpack 過于靈活的配置特性使得一些工程化需求需要花時間探索。在我們接手項目后一起討論了一下，果斷轉為熟悉的 fis3 構建體系。使用 fis3 主要解決的問題有：

less 編譯

es6 編譯

js/css 壓縮合并

頁面模板嵌入

發布時 CDN 多帶帶域名的適配

發布時符合內部運維體系線上發布規范的目錄路徑修正

相比較為靈活的 webpack，fis3 更注重流程化整體解決方案，簡單的數十行配置即可實現各種工程化需求。不過 fis3 的發展現在似乎進入了一個瓶頸期/穩定期，社區中對于在 rollup 和 webpack 中大熱的 tree-shaking 等技術幾乎都沒有什么反應。希望它不要沒落了，能有更多的創新吧。有兩點期望：走國際化路線，出英文文檔與社區支持，向國際頂級項目看進；跟進參考業界最新的工程化理念，如有必要出個 fis4 也未嘗不可。

由于涉及到跨部門合作，也沒有太多的時間，項目起初放在了內部的 gitlab 平臺，沒有走 git+gerrit+jenkins+運維發布平臺 這一內部完整的體系。這樣做在前期省去了項目創建、各種權限申請等一堆需要協調溝通的事情，開發協作效率也比較高，但到了發布的階段就突顯出了問題：每次發布都需要由運維人員手動操作，協調發布很花費時間。

另外靜態頁面也沒有獨立出來，想當然地簡單的扔到后端目錄中，結果導致前端的修改需要后端也必須作修改發布，增加了前后端協調的時間成本。

于是，在首次發布后又進行的幾次小迭代中，每次迭代發布都涉及到多人手動協調，十分的浪費時間。

總結一句話：項目構建盡量與已有的成熟的規范一致，以少走彎路。

最后列舉一些移動端 H5 開發可參考的內容：

真機調試 https://github.com/jieyou/remote_inspect_web_on_real_device

vConsole: 客戶端內 H5 調試 https://github.com/WechatFE/vConsole

移動端布局終極解決方案 https://github.com/imochen/hotcss

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

這是我們第一次嘗試這種活動頁，在如此緊湊的時間節點下，沒有什么高大上的東西，更多的是各種采坑嘗試的實踐過程。以上列舉的內容算是對本次開發實踐做一個總結記錄，采用的相關實現方案也可作后續參考。歡迎探討分享你們的經驗。